>-----Original Message-----
>From: Andrew Lunn <and...@lunn.ch>
>Sent: Wednesday, November 11, 2020 1:05 AM
>To: Claudiu Manoil <claudiu.man...@nxp.com>
>Cc: netdev@vger.kernel.org; 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 Tue, Nov 10, 2020 at 05:43:04PM +0200, 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.
>
>Hi Claudiu
>
>The code you are adding makes no comment about the odd using of
>read/writer locks. This is going to confused people.
>
>Please could you add helpers, probably as inline functions in a
>header, which take/release the read_lock and the write_lock, which
>don't use the name read_ or write_. Maybe something like
>enetc_lock_mdio()/enetc_unlock_mdio(), enetc_lock_reg(),
>enetc_unlock_reg(). Put comments by the helpers explaining what is
>going on. That should help avoid future confusion and questions.
>
Good point Andrew, will look into using better names and adding comments.
This patch was actually intended as rfc, the final patch should target the
"net"
tree as a fix.
Thanks.
