[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200901155945.GG2403519@lunn.ch>
Date: Tue, 1 Sep 2020 17:59:45 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Kurt Kanzenbach <kurt@...utronix.de>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Richard Cochran <richardcochran@...il.com>,
Kamil Alkhouri <kamil.alkhouri@...offenburg.de>,
ilias.apalodimas@...aro.org
Subject: Re: [PATCH v4 2/7] net: dsa: Add DSA driver for Hirschmann Hellcreek
switches
> > >
> > > What is the register lock protecting against, exactly?
> >
> > A lot of the register operations work by:
> >
> > * Select port, priority, vlan or counter
> > * Configure it
> >
> > These sequences have to be atomic. That's what I wanted to ensure.
> >
>
> So, let me rephrase. Is there any code path that is broken, even if only
> theoretically, if you remove the reg_lock?
Maybe, at the moment, RTNL is keeping things atomic. But that is
because there is no HWMON, or MDIO bus. Those sort of operations don't
take the RTNL, and so would be an issue. I've also never audited the
network stack to check RTNL really is held at all the network stack
entry points to a DSA driver. It would be an interesting excesses to
scatter some ASSERT_RTNL() in a DSA driver and see what happens.
Andrew
Powered by blists - more mailing lists