From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B670C433F5 for ; Wed, 16 Feb 2022 19:12:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238036AbiBPTMY (ORCPT ); Wed, 16 Feb 2022 14:12:24 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:46652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237894AbiBPTMW (ORCPT ); Wed, 16 Feb 2022 14:12:22 -0500 Received: from vps0.lunn.ch (vps0.lunn.ch [185.16.172.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B87B72B261; Wed, 16 Feb 2022 11:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=y13SwYgPMWjW5s5tMs0L28fhHBRBkvCDSKVz5OvZIdA=; b=KHuJPkcvhkjBKYurHM60mrW7h4 X4MhLdNmfxhkT1RuUFSuveKlSTWuEp87Hq78reNsp4o6gyoOzfxHlGp2mA/ja1QipvrQKjGRZszsJ vFDDE7zMm0MuQPjOHtVeon8UgtYTiiCCdCzVOkDtr/cm7FJsj4yF5itDhf396FtO7qe4=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1nKPiY-006FnC-3I; Wed, 16 Feb 2022 20:11:58 +0100 Date: Wed, 16 Feb 2022 20:11:58 +0100 From: Andrew Lunn To: Alvin =?utf-8?Q?=C5=A0ipraga?= Cc: Luiz Angelo Daros de Luca , Alvin =?utf-8?Q?=C5=A0ipraga?= , Linus Walleij , Vivien Didelot , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Jakub Kicinski , Michael Rasmussen , =?utf-8?B?QXLEsW7DpyDDnE5BTA==?= , "open list:NETWORKING DRIVERS" , open list Subject: Re: [PATCH net-next 0/2] net: dsa: realtek: fix PHY register read corruption Message-ID: References: <20220216160500.2341255-1-alvin@pqrs.dk> <87k0dusmar.fsf@bang-olufsen.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k0dusmar.fsf@bang-olufsen.dk> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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. Andrew