The 'HFClock', an rwlock, is only used by writers, making it functionally
equivalent to a spinlock.

According to Documentation/locking/spinlocks.rst:

"Reader-writer locks require more atomic memory operations than simple
spinlocks. Unless the reader critical section is long, you are better
off just using spinlocks."

Since read_lock() is never called, switching to a spinlock reduces
overhead and improves efficiency.

Signed-off-by: Yu-Chun Lin <eleanor15x@gmail.com>
---
Build tested only, as I don't have the hardware. 
Ensured all rw_lock -> spinlock conversions are complete, and replacing
rw_lock with spinlock should always be safe.

 drivers/isdn/hardware/mISDN/hfcsusb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c b/drivers/isdn/hardware/mISDN/hfcsusb.c
index e54419a4e731..5041d635ef7f 100644
--- a/drivers/isdn/hardware/mISDN/hfcsusb.c
+++ b/drivers/isdn/hardware/mISDN/hfcsusb.c
@@ -27,7 +27,7 @@ static unsigned int debug;
 static int poll = DEFAULT_TRANSP_BURST_SZ;
 
 static LIST_HEAD(HFClist);
-static DEFINE_RWLOCK(HFClock);
+static DEFINE_SPINLOCK(HFClock);
 
 
 MODULE_AUTHOR("Martin Bachem");
@@ -1895,9 +1895,9 @@ setup_instance(struct hfcsusb *hw, struct device *parent)
 		goto out;
 
 	hfcsusb_cnt++;
-	write_lock_irqsave(&HFClock, flags);
+	spin_lock_irqsave(&HFClock, flags);
 	list_add_tail(&hw->list, &HFClist);
-	write_unlock_irqrestore(&HFClock, flags);
+	spin_unlock_irqrestore(&HFClock, flags);
 	return 0;
 
 out:
-- 
2.43.0

On Sat, Mar 22, 2025 at 01:20:24AM +0800, Yu-Chun Lin wrote:
> The 'HFClock', an rwlock, is only used by writers, making it functionally
> equivalent to a spinlock.
> 
> According to Documentation/locking/spinlocks.rst:
> 
> "Reader-writer locks require more atomic memory operations than simple
> spinlocks. Unless the reader critical section is long, you are better
> off just using spinlocks."
> 
> Since read_lock() is never called, switching to a spinlock reduces
> overhead and improves efficiency.
> 
> Signed-off-by: Yu-Chun Lin <eleanor15x@gmail.com>
> ---
> Build tested only, as I don't have the hardware. 
> Ensured all rw_lock -> spinlock conversions are complete, and replacing
> rw_lock with spinlock should always be safe.
> 
>  drivers/isdn/hardware/mISDN/hfcsusb.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Hi Yu-Chun Lin,

Thanks for your patch.

Unfortunately I think it would be best to leave this rather old
and probably little used driver as-is in this regard unless there
is a demonstrable improvement on real hardware.

Otherwise the small risk of regression and overhead of driver
changes seems to outweigh the theoretical benefit.

-- 
pw-bot: deferred

On Mon, Mar 24, 2025 at 02:21:15PM +0000, Simon Horman wrote:
> On Sat, Mar 22, 2025 at 01:20:24AM +0800, Yu-Chun Lin wrote:
> > The 'HFClock', an rwlock, is only used by writers, making it functionally
> > equivalent to a spinlock.
> > 
> > According to Documentation/locking/spinlocks.rst:
> > 
> > "Reader-writer locks require more atomic memory operations than simple
> > spinlocks. Unless the reader critical section is long, you are better
> > off just using spinlocks."
> > 
> > Since read_lock() is never called, switching to a spinlock reduces
> > overhead and improves efficiency.
> > 
> > Signed-off-by: Yu-Chun Lin <eleanor15x@gmail.com>
> > ---
> > Build tested only, as I don't have the hardware. 
> > Ensured all rw_lock -> spinlock conversions are complete, and replacing
> > rw_lock with spinlock should always be safe.
> > 
> >  drivers/isdn/hardware/mISDN/hfcsusb.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> Hi Yu-Chun Lin,
> 
> Thanks for your patch.
> 
> Unfortunately I think it would be best to leave this rather old
> and probably little used driver as-is in this regard unless there
> is a demonstrable improvement on real hardware.
> 
> Otherwise the small risk of regression and overhead of driver
> changes seems to outweigh the theoretical benefit.

Thank you for your feedback.

I noticed that the MAINTAINERS file lists a maintainer for ISDN, so I
was wondering if he might have access to the necessary hardware for
quick testing.

Since I am new to the kernel, I would like to ask if there have been
any past cases or experiences where similar changes were considered
unsafe. Additionally, I have seen instances where the crypto maintainer
accepted similar patches even without hardware testing. [1]

[1]: https://lore.kernel.org/lkml/20240823183856.561166-1-visitorckw@gmail.com/

Regards,
Yu-Chun

On Thu, Mar 27, 2025 at 11:28:25PM +0800, Yu-Chun Lin wrote:
> On Mon, Mar 24, 2025 at 02:21:15PM +0000, Simon Horman wrote:
> > On Sat, Mar 22, 2025 at 01:20:24AM +0800, Yu-Chun Lin wrote:
> > > The 'HFClock', an rwlock, is only used by writers, making it functionally
> > > equivalent to a spinlock.
> > > 
> > > According to Documentation/locking/spinlocks.rst:
> > > 
> > > "Reader-writer locks require more atomic memory operations than simple
> > > spinlocks. Unless the reader critical section is long, you are better
> > > off just using spinlocks."
> > > 
> > > Since read_lock() is never called, switching to a spinlock reduces
> > > overhead and improves efficiency.
> > > 
> > > Signed-off-by: Yu-Chun Lin <eleanor15x@gmail.com>
> > > ---
> > > Build tested only, as I don't have the hardware. 
> > > Ensured all rw_lock -> spinlock conversions are complete, and replacing
> > > rw_lock with spinlock should always be safe.
> > > 
> > >  drivers/isdn/hardware/mISDN/hfcsusb.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > Hi Yu-Chun Lin,
> > 
> > Thanks for your patch.
> > 
> > Unfortunately I think it would be best to leave this rather old
> > and probably little used driver as-is in this regard unless there
> > is a demonstrable improvement on real hardware.
> > 
> > Otherwise the small risk of regression and overhead of driver
> > changes seems to outweigh the theoretical benefit.
> 
> Thank you for your feedback.
> 
> I noticed that the MAINTAINERS file lists a maintainer for ISDN, so I
> was wondering if he might have access to the necessary hardware for
> quick testing.
> 
> Since I am new to the kernel, I would like to ask if there have been
> any past cases or experiences where similar changes were considered
> unsafe. Additionally, I have seen instances where the crypto maintainer
> accepted similar patches even without hardware testing. [1]
> 
> [1]: https://lore.kernel.org/lkml/20240823183856.561166-1-visitorckw@gmail.com/

I think it is a judgement call, and certainly the crypto maintainer is
free to make their own call. But in this case I do lean towards leaving
the code unchanged in the absence of hardware testing.