Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220216160500.2341255-1-alvin@pqrs.dk>
In-Reply-To: <20220216160500.2341255-1-alvin@pqrs.dk>
From:   Luiz Angelo Daros de Luca <luizluca@gmail.com>
Date:   Wed, 16 Feb 2022 14:57:11 -0300
Message-ID: <CAJq09z6Mr7QFSyqWuM1jjm9Dis4Pa2A4yi=NJv1w4FM0WoyqtA@mail.gmail.com>
Subject: Re: [PATCH net-next 0/2] net: dsa: realtek: fix PHY register read corruption
To:     =?UTF-8?Q?Alvin_=C5=A0ipraga?= <alvin@pqrs.dk>
Cc:     Linus Walleij <linus.walleij@linaro.org>,
        Andrew Lunn <andrew@lunn.ch>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Vladimir Oltean <olteanv@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Michael Rasmussen <mir@bang-olufsen.dk>,
        =?UTF-8?Q?Alvin_=C5=A0ipraga?= <alsi@bang-olufsen.dk>,
        =?UTF-8?B?QXLEsW7DpyDDnE5BTA==?= <arinc.unal@arinc9.com>,
        "open list:NETWORKING DRIVERS" <netdev@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

> These two patches fix the issue reported by Ar=C4=B1n=C3=A7 where PHY reg=
ister
> reads sometimes return garbage data.
>
> MAINTAINERS: Please can you help me with the targetting of these two
> patches? This bug is present ca. 5.16, when the SMI version of the
> rtl8365mb driver was introduced. But now in net-next we have the MDIO
> interface from Luiz, where the issue is also present. I am sending what
> I think is an ideal patch series, but should I split it up and send the
> SMI-related changes to net and the MDIO changes to net-next? If so, how
> would I go about splitting it while preventing merge conflicts and build
> errors?
>
> For now I am sending it to net-next so that the whole thing can be
> reviewed. If it's applied, I would gladly backport the fix to the stable
> tree for 5.16, but I am still confused about what to do for 5.17.
>
> Thanks for your help.
>
>
> Alvin =C5=A0ipraga (2):
>   net: dsa: realtek: allow subdrivers to externally lock regmap
>   net: dsa: realtek: rtl8365mb: serialize indirect PHY register access
>
>  drivers/net/dsa/realtek/realtek-mdio.c | 46 +++++++++++++++++++++-
>  drivers/net/dsa/realtek/realtek-smi.c  | 48 +++++++++++++++++++++--
>  drivers/net/dsa/realtek/realtek.h      |  2 +
>  drivers/net/dsa/realtek/rtl8365mb.c    | 54 ++++++++++++++++----------
>  4 files changed, 124 insertions(+), 26 deletions(-)
>
> --
> 2.35.0
>

Thanks for the fix, Alvin.

I still feel like we are trying to go around a regmap limitation
instead of fixing it there. If we control regmap lock (we can define a
custom lock/unlock) and create new regmap_{read,write}_nolock
variants, we'll just need to lock the regmap, do whatever you need,
and unlock it.

BTW, I believe that, for realtek-mdio, a regmap custom lock mechanism
could simply use mdio lock while realtek-smi already has priv->lock.

Regards,