[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <482f27de-f660-4e7a-a1a9-3000b7119567@lunn.ch>
Date: Wed, 17 Sep 2025 14:37:43 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Vladimir Oltean <olteanv@...il.com>
Cc: David Yang <mmyangfl@...il.com>, netdev@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Simon Horman <horms@...nel.org>,
Russell King <linux@...linux.org.uk>, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v9 3/3] net: dsa: yt921x: Add support for
Motorcomm YT921x
> I'm not sure that a "driver lock" is something that drivers need.
> In this case it creates a lot of red tape. Function yt921x_dsa_X() takes
> the driver lock and calls function yt921x_X() which does the work.
> IMO that's part of what gives "vendor crap" drivers their name, when
> there's no reason behind it.
As you said, some methods are protected by RTNL. But not all. And it
is hard to know which are not. A driver lock is KISS, and easy to get
right, easy to see is right, and easy to prove is right. Locking can
be hard, so KISS is good.
Andrew
Powered by blists - more mailing lists