>-----Original Message----- >From: Florian Fainelli <f.faine...@gmail.com> >Sent: Wednesday, November 11, 2020 1:25 AM >To: Claudiu Manoil <claudiu.man...@nxp.com>; netdev@vger.kernel.org >Cc: Jakub Kicinski <k...@kernel.org>; David S . Miller ><da...@davemloft.net>; Alexandru Marginean ><alexandru.margin...@nxp.com>; Vladimir Oltean ><vladimir.olt...@nxp.com> >Subject: Re: [PATCH net-next] enetc: Workaround for MDIO register access >issue > >On 11/10/20 7:43 AM, Claudiu Manoil wrote: >> From: Alex Marginean <alexandru.margin...@nxp.com> >> >> Due to a hardware issue, an access to MDIO registers >> that is concurrent with other ENETC register accesses >> may lead to the MDIO access being dropped or corrupted. >> The workaround introduces locking for all register accesses >> to the ENETC register space. To reduce performance impact, >> a readers-writers locking scheme has been implemented. >> The writer in this case is the MDIO access code (irrelevant >> whether that MDIO access is a register read or write), and >> the reader is any access code to non-MDIO ENETC registers. >> Also, the datapath functions acquire the read lock fewer times >> and use _hot accessors. All the rest of the code uses the _wa >> accessors which lock every register access. > >I suppose this is the best you can do given the nature of the bug, my >only concern is that it is error prone and may not really scale over >time as you start adding more features/bug fixes that require making >register accesses and use incorrectly _hot in a context where the >reader's lock is not acquired.
Absolutely, maybe I can use lockdep to insure correctness. I started looking into this. Thanks.