Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp1353450pxb; Wed, 16 Feb 2022 17:40:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJwQdIHF9I9GnzGEmXBDlRHraLSuGxS1FOUBt1i5bS9k6cnCPnM7UEDj7FK6yiGIi9fULCdO X-Received: by 2002:a17:906:60d6:b0:6cf:e577:c93f with SMTP id f22-20020a17090660d600b006cfe577c93fmr622767ejk.8.1645062043094; Wed, 16 Feb 2022 17:40:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645062043; cv=none; d=google.com; s=arc-20160816; b=clg7kNOJauy7a1chHlO/SGsdkRrhUUBKcahr04edgMzgUMah+EV12DuW/uxcr6hRC6 yjsBr8Gxn66JqRQ/N7NxJtoAB1RS1BGaF0ntahIyMhhFWf04uJA87wPt37MlZe6xYGpz iaU9TPTzlpAit+ERYNssiMKB4KMOjoxz4Cr+kjLKoQUFr+nZgkG3DOL0ITaF2xOURKhk Nc9oXtAKuZ8RxzBYe9ypKjLOs9sLG0lkyCVIJAW+Rb++lVSEtIQhRZbEoMHB9z6LC5ME 2njtlVdH/ITy1pVMgUXT7O3xuN454vA9AAKqcX2hxFRUJCqHE31qgcSFzKF4aRKKCkWk A2GA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=y13SwYgPMWjW5s5tMs0L28fhHBRBkvCDSKVz5OvZIdA=; b=QlglRcrz0lEg/m0q5hYpQWJzWJgBbZ4t3Gs0sh0omQM8PaiyaM2rsud1E5UYigx4sg dEeFYSLuGJ+e8MFdeFAENWpgpW/zWBC50aW3GaXyafGo8TG/TrIvAMjnAUHGhNn6EuOg pp1PGKUTFR1kcspZrFQp9dQfdIgCqVsFkXYEOYn4ZLbVId40vgZug/7Wta5a1EaO/Om9 gTKeKD0ANo1YPN/stbtxNEQIb8v4yJ8X85aeevc0F5Vz453N/aKxLmv+6BOWtC+MsetD UDadfbhCwLUDsgmp63kYT9KHexVcl2VyBgj1xd+lLiJG+5q1C2qOxVrsez1vDhUFN/qF 6+Mg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=KHuJPkcv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q16si3070393edr.30.2022.02.16.17.40.20; Wed, 16 Feb 2022 17:40:43 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=KHuJPkcv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238031AbiBPTMX (ORCPT + 99 others); Wed, 16 Feb 2022 14:12:23 -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> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: 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