[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200514011957.GF527401@lunn.ch>
Date: Thu, 14 May 2020 03:19:57 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Marek Vasut <marex@...x.de>
Cc: netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>,
Lukas Wunner <lukas@...ner.de>, Petr Stetiar <ynezz@...e.cz>,
YueHaibing <yuehaibing@...wei.com>
Subject: Re: [PATCH V5 10/19] net: ks8851: Factor out bus lock handling
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 <marex@...x.de>
> Cc: David S. Miller <davem@...emloft.net>
> Cc: Lukas Wunner <lukas@...ner.de>
> Cc: Petr Stetiar <ynezz@...e.cz>
> Cc: YueHaibing <yuehaibing@...wei.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.
Andrew
Powered by blists - more mailing lists