On Thu, May 14, 2020 at 03:37:49AM +0200, Marek Vasut wrote:
> On 5/14/20 3:19 AM, Andrew Lunn wrote:
> > On Thu, May 14, 2020 at 02:07:38AM +0200, Marek Vasut wrote:
> >> Pull out bus access locking code into separate functions, this is done
> >> in preparation for unifying the driver with the parallel bus one. The
> >> parallel bus driver does not need heavy mutex locking of the bus and
> >> works better with spinlocks, hence prepare these locking functions to
> >> be overridden then.
> >>
> >> Signed-off-by: Marek Vasut <ma...@denx.de>
> >> Cc: David S. Miller <da...@davemloft.net>
> >> Cc: Lukas Wunner <lu...@wunner.de>
> >> Cc: Petr Stetiar <yn...@true.cz>
> >> Cc: YueHaibing <yuehaib...@huawei.com>
> >
> >
> >> +/**
> >> + * ks8851_lock - register access lock
> >> + * @ks: The chip state
> >> + * @flags: Spinlock flags
> >> + *
> >> + * Claim chip register access lock
> >> + */
> >> +static void ks8851_lock(struct ks8851_net *ks, unsigned long *flags)
> >> +{
> >> + mutex_lock(&ks->lock);
> >> +}
> >
> > Do you actually need flags? It is for spin_lock_irqsave(). Which you
> > use when you have a critical section inside an interrupt handler. But
> > a mutex cannot protect against an interrupt handler. So there should
> > be no need to use spin_lock_irqsave(), spin_lock() should be enough,
> > and that does not need flags.
>
> I do need it, the SPI variant of the device uses threaded interrupt
> handler and does quite a few heavy operations there (like pumping TX
> data across the SPI bus) so it needs the mutex, but the overhead of that
> is too much for the parallel bus variant of the chip (which pumps the
> data in the start_xmit handler directly) and so that one uses spinlock
> both in ks8851_start_xmit_par() and in the IRQ handler.
O.K. thanks for the explanation.
Reviewed-by: Andrew Lunn <and...@lunn.ch>
Andrew
