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;
From:   =?windows-1254?Q?Alvin_=8Aipraga?= <ALSI@bang-olufsen.dk>
To:     Andrew Lunn <andrew@lunn.ch>
CC:     Luiz Angelo Daros de Luca <luizluca@gmail.com>,
        =?windows-1254?Q?Alvin_=8Aipraga?= <alvin@pqrs.dk>,
        Linus Walleij <linus.walleij@linaro.org>,
        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>,
        =?windows-1254?Q?Ar=FDn=E7_=DCNAL?= <arinc.unal@arinc9.com>,
        "open list:NETWORKING DRIVERS" <netdev@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next 0/2] net: dsa: realtek: fix PHY register read
 corruption
Thread-Topic: [PATCH net-next 0/2] net: dsa: realtek: fix PHY register read
 corruption
Thread-Index: AQHYI06+Oi3bmZ4n+EmyFAzgV7y6pg==
Date:   Wed, 16 Feb 2022 19:26:43 +0000
Message-ID: <878ruasjd8.fsf@bang-olufsen.dk>
References: <20220216160500.2341255-1-alvin@pqrs.dk>
        <CAJq09z6Mr7QFSyqWuM1jjm9Dis4Pa2A4yi=NJv1w4FM0WoyqtA@mail.gmail.com>
        <87k0dusmar.fsf@bang-olufsen.dk> <Yg1MfpK5PwiAbGfU@lunn.ch>
In-Reply-To: <Yg1MfpK5PwiAbGfU@lunn.ch> (Andrew Lunn's message of "Wed, 16 Feb
        2022 20:11:58 +0100")
Accept-Language: en-US
Content-Language: en-US
user-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?windows-1254?Q?s+SzKHBl9BnzIAmYT10e9tRshW46AV31KgYSeWrM20XrFwB9P8zvg/cP?=
 =?windows-1254?Q?ck279UEHI9/zzDx2Oag04iPsr9MdS/vmZfpWhkEfuN6Cfqk3H6NbbeEF?=
 =?windows-1254?Q?frJ1id/xmLhfaL6LSwSnmIIqqS/LUwosTwezbtEZCsGw0Kx/zhwk+MzD?=
 =?windows-1254?Q?+x+qAvvCNY1RSi3M9LkMLkrJVKlW4eydJxl5PSYe2X4FV8rLsI7DxdTs?=
 =?windows-1254?Q?p1NZjJxNeg5rrIg1XhkCJtWaAD6wBRo4UV6wBsEt+ABm2P/xog+88Kyz?=
 =?windows-1254?Q?UKqRuQ3bI7bM5Rk6bkN1qYeV6w5rCF4UzGRKenmPVTnU45yUKUJW/kQw?=
 =?windows-1254?Q?aoolUUKrfNLkP9X9UHTGwyBZ59hXgo1MXnK1PcyoLIbXQMcMagx5+k7Q?=
 =?windows-1254?Q?SLzWWEk78IwxoEGGxBhfwaQhwSgI6aZGKsMi6MKVIW5BxmGdO7Aetaq1?=
 =?windows-1254?Q?smtRpdb/lcJTHMBYLHgFdXtYlH01dBYoosahNWIZyP+SIUzcXKZTWTLV?=
 =?windows-1254?Q?0wnpkqPU1OXnL8NclhZ3uoOlwV603OtIaFrgI03CHi7Bh2hzxDjgjqYn?=
 =?windows-1254?Q?BciaT166OHxzl0sc4TgZizJYcC0uW0R3o80qnRRQLtclZSSca0geNkNg?=
 =?windows-1254?Q?iz4nZeYbPvlevaaCZenwCwa1P04HdL6+EgdYCuWF4RmythxtptZScMXu?=
 =?windows-1254?Q?jZ90v023be+u+1eFO/ZnS4+MxP8o3c/2/gg1j0v6an3l6xq4Z4Er6bND?=
 =?windows-1254?Q?nXUvG18vh8ZwSl3KibiLmDfX1KrgCh59eax1q8uTTFb1G+0gGltFdSUh?=
 =?windows-1254?Q?CBavn1RQLS6hQLK9sXg2K2lRTIO5N89QXAb/FBiR//4eqrxx94JGYmzx?=
 =?windows-1254?Q?TF2e5WHC1VtvDDN9Ct3nSN27PK0ngxOjuxSEPkE2CO2epuMQghdSUO72?=
 =?windows-1254?Q?kvO2H+YIP90KPq8bzJrrSmIWop5k1/8s9TZECqURIv7ied7G9eA/72zE?=
 =?windows-1254?Q?TeVvAzmzNc2ietxBrZ3N6uiqEfgQfPTpnZC+P4EQJXzOpEB8FlChutIl?=
 =?windows-1254?Q?3FcBnJoIYJGuWIitBfqpImToVGgej06VxDeA17cFm2FgWpG8uQaCGdGC?=
 =?windows-1254?Q?2q49a0fd7ksmmEtDqcqau95XcKHLBui12yZY69JBcMLiGp/+6GMtZ7ku?=
 =?windows-1254?Q?EDWZZ0RdbX1C737Q4zztjjx7fwocbXi2XDKf+B81KMaBGMWHYvF0lL4z?=
 =?windows-1254?Q?7MzVxTTHuEK2E9YXpwy3b+oDFW2EbcnAYcCOwxlAFuO46IRZvlBed09x?=
 =?windows-1254?Q?hkWOnuU1skEKVHYZHIwJETcOrRKZscUiLWL+jS3w+PLgfmcJujVhpNHz?=
 =?windows-1254?Q?1MNOZcbrgVMBZWfsroDFUkvjcZiF6vIAcGmlmGxDgq69UrAyY0NSKGMp?=
 =?windows-1254?Q?I85pZ5N/AZYkFdYifrWUf7fcwbO6VQn17XOa4xMRPeUOIMKTUiEO2LGD?=
 =?windows-1254?Q?55ygtzXyZDuREPPCLvvRP9d+V7sBLNfxAE9AxoHQa77T3t+Oi22cTsY/?=
 =?windows-1254?Q?zMVWQLa9rqMY2UoAwaQWAzH2L4GVELhkXybVvYtdf1qALpeXMyjuvISU?=
 =?windows-1254?Q?XhBvpTu/rhGPeDZ9nfHIzCIai/TbTKo+8B1Hf3Vu+ZhIDNWei95kVxLZ?=
 =?windows-1254?Q?iSYOOI4x+bFqsiWLysMSDN4Az6UpZXy9J+pB6HFOT+tRGzWlREDp9bta?=
 =?windows-1254?Q?ZceoKt3byXbSe4NfAu4=3D?=
Content-Type: text/plain; charset="windows-1254"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: bang-olufsen.dk
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM6PR03MB3943.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 33bb0bb9-6e2c-4322-b808-08d9f18243fa
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2022 19:26:43.7089
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 210d08b8-83f7-470a-bc96-381193ca14a1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4SYskooHvHLaavVzEhPPNiEt3KaMhUaipgG2viWzOOU4aijSK8YREFnuDrbCFk86RLjEYU08dBe1uJNCtsvagw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0302MB3379
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Andrew Lunn <andrew@lunn.ch> writes:
>> Hmm OK. Actually I'm a bit confused about the mdio_lock: can you explain
>> what it's guarding against, for someone unfamiliar with MDIO?
>
> The more normal use case for MDIO is for PHYs, not switches. There can
> be multiple PHYs on one MDIO bus. And these PHYs each have there own
> state machine in phylib. At any point in time, that state machine can
> request the driver to do something, like poll the PHY status, does it
> have link? To prevent two PHY drivers trying to use the MDIO bus at
> the same time, there is an MDIO lock. At the beginning of an MDIO
> transaction, the lock is taken. And the end of the transaction,
> reading or writing one register of a device on the bus, the lock is
> released.
>
> So the MDIO lock simply ensures there is only one user of the MDIO bus
> at one time, for a single read or write.
>
> For PHYs this is sufficient. For switches, sometimes you need
> additional protection. The granularity of an access might not be a
> single register read or a write. It could be you need to read or write
> a few registers in an atomic way. If that is the case, you need a lock
> at a higher level.

Thank you Andrew for the clear explanation.

Somewhat unrelated to this series, but are you able to explain to me the
difference between:

	mutex_lock(&bus->mdio_lock);
and
	mutex_lock_nested(&bus->mdio_lock, MDIO_MUTEX_NESTED);

While looking at other driver examples I noticed the latter form quite a
few times too.

Kind regards,
Alvin=