Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp291859rdb; Tue, 5 Dec 2023 05:47:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IFH7iWmlrP957u7bTucGkGVenB+aNNoIWizRYYVW1aKio/UtONFaNrlyNeTiRTTDSJLI/RU X-Received: by 2002:a17:90a:c28a:b0:286:c0e2:83f1 with SMTP id f10-20020a17090ac28a00b00286c0e283f1mr1070665pjt.32.1701784036774; Tue, 05 Dec 2023 05:47:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701784036; cv=none; d=google.com; s=arc-20160816; b=tt3u6sVJ7t9RF48rVEk35QeKUZBhnY+qN1mYE/wAUo2jK0raXFAEPr9N3Ksp9Kqkve DPmIENyE+SBhGPB9dni6qDkzPWO0msPCCvPpbTUnyXRh+PQRofIo47dCOmTekdjDqP19 eAKnNLX/VATnkAYbxxOHaKtkJVkuLAC8R3PcIctzG+ssjQ4B1SuPREddTPC9OnOOxywC hIh5SkXLWtcmiyNsoTFpa3CKjTzrdYiVaYEZBwCZewbgG5OCkQe5ygCwz1mStb7B94Rj ELbZfq5JYK8hRnZug16injUzsToGUuN5Wo41HE4CXVrrfE7DBdKDGj9h07PmnujMjduU ME/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=sXLv+BQQhFyIj+OepEyZ/ix18aKE+IuVWy2i+TljFxM=; fh=0CjR/P59gkS3RoA1MzYD3TAB1GMUolY2z17tQE+puF0=; b=hhxeg9ppfaWGvMd80+1QKW2DOgFhsUh0OpFiUfjLloPAJYSb9zUMYer3OdmYpd1Gr4 fOTPsYv0cvaL3uNAq19KJkaj+ToUIizlE8wSbvdRabELL8+Dw5jp4+xJt+3SONcTbWxp NBWf9h+0jgXHQAMAU0UYkawRqQJzgFJGkB1UqOEz1o1CFKs5Mz3h6e6mG5KbAEHAHqgK KVH/R85RZ14RMvb/S0/Io2XS5FgAAWNfYjQSGFVHaKh7WLJpN17nrfHBovRdoURARCzI QWf74rU8GpAtHJr+xV1a1RRPe989vdrioWUf6NW+CU11WxIWRPHIKwJmK1VvuK+5O6z0 5/Fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=uRp6DB8o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id y13-20020a170902ed4d00b001d0d15b9c7dsi127431plb.563.2023.12.05.05.47.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Dec 2023 05:47:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=uRp6DB8o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id E96508043C3D; Tue, 5 Dec 2023 05:47:12 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345482AbjLENqz (ORCPT + 99 others); Tue, 5 Dec 2023 08:46:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55416 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235213AbjLENqy (ORCPT ); Tue, 5 Dec 2023 08:46:54 -0500 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 804C3A8; Tue, 5 Dec 2023 05:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sXLv+BQQhFyIj+OepEyZ/ix18aKE+IuVWy2i+TljFxM=; b=uRp6DB8os5K4RsEy/2tUwm8nTZ KpC14YHGa6Zc3D4mUxpfsJ3voOPTih7Wgr854pnrSTaWgxWU6YVi4d5Drw43VHXLu/E6742PCh+Ra FuWh9NO9KUrSK9WHyfAzriA5bQw1gaXSrh7/O7Lj3Q2Vos66sXrbVZCmQ/QssYHxSW01XNWNF3M3Q O9BeC3qGJbLGnu1O7FdgDDpGwWEDYbnc/364SX/dYvg+3XdxymrG0UxnhIUp4fEnG3MzP+StRFNdk 89kIl+zuljDMmLDi5bAvd9i891rGvYkWGfPfWeU9TRipURrhKE5Kc4/GjMHGY8d5xkyK4BPcrOE+z x6FdkqZg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:36992) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1rAVl6-0006qp-0Q; Tue, 05 Dec 2023 13:46:44 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1rAVl6-0001lK-Gv; Tue, 05 Dec 2023 13:46:44 +0000 Date: Tue, 5 Dec 2023 13:46:44 +0000 From: "Russell King (Oracle)" To: Serge Semin Cc: Andrew Lunn , Heiner Kallweit , Alexandre Torgue , Jose Abreu , Jose Abreu , Maxime Chevallier , Tomer Maimon , Rob Herring , Krzysztof Kozlowski , Conor Dooley , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , openbmc@lists.ozlabs.org, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 06/16] net: pcs: xpcs: Avoid creating dummy XPCS MDIO device Message-ID: References: <20231205103559.9605-1-fancer.lancer@gmail.com> <20231205103559.9605-7-fancer.lancer@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231205103559.9605-7-fancer.lancer@gmail.com> Sender: Russell King (Oracle) X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 05 Dec 2023 05:47:13 -0800 (PST) On Tue, Dec 05, 2023 at 01:35:27PM +0300, Serge Semin wrote: > If the DW XPCS MDIO devices are either left unmasked for being auto-probed > or explicitly registered in the MDIO subsystem by means of the > mdiobus_register_board_info() method there is no point in creating the > dummy MDIO device instance in order to get the DW XPCS handler since the > MDIO core subsystem will create the device during the MDIO bus > registration procedure. All what needs to be done is to just reuse the > MDIO-device instance available in the mii_bus.mdio_map array (using some > getter for it would look better though). It shall prevent the XPCS devices > been accessed over several MDIO-device instances. > > Note since the MDIO-device instance might be retrieved from the MDIO-bus > map array its reference counter shall be increased. If the MDIO-device > instance is created in the xpcs_create_mdiodev() method its reference > counter will be already increased. So there is no point in toggling the > reference counter in the xpcs_create() function. Just drop it from there. > > Signed-off-by: Serge Semin > --- > drivers/net/pcs/pcs-xpcs.c | 26 +++++++++++++------------- > 1 file changed, 13 insertions(+), 13 deletions(-) > > diff --git a/drivers/net/pcs/pcs-xpcs.c b/drivers/net/pcs/pcs-xpcs.c > index 2850122f354a..a53376472394 100644 > --- a/drivers/net/pcs/pcs-xpcs.c > +++ b/drivers/net/pcs/pcs-xpcs.c > @@ -1376,7 +1376,6 @@ static struct dw_xpcs *xpcs_create(struct mdio_device *mdiodev, > if (!xpcs) > return ERR_PTR(-ENOMEM); > > - mdio_device_get(mdiodev); > xpcs->mdiodev = mdiodev; > > xpcs_id = xpcs_get_id(xpcs); > @@ -1417,7 +1416,6 @@ static struct dw_xpcs *xpcs_create(struct mdio_device *mdiodev, > ret = -ENODEV; > > out: > - mdio_device_put(mdiodev); > kfree(xpcs); > > return ERR_PTR(ret); The above two hunks are a completely Unnecessary change. > @@ -1437,19 +1435,21 @@ struct dw_xpcs *xpcs_create_mdiodev(struct mii_bus *bus, int addr, > struct mdio_device *mdiodev; > struct dw_xpcs *xpcs; > > - mdiodev = mdio_device_create(bus, addr); > - if (IS_ERR(mdiodev)) > - return ERR_CAST(mdiodev); > + if (addr >= PHY_MAX_ADDR) > + return ERR_PTR(-EINVAL); > > - xpcs = xpcs_create(mdiodev, interface); > + if (mdiobus_is_registered_device(bus, addr)) { > + mdiodev = bus->mdio_map[addr]; > + mdio_device_get(mdiodev); This is fine - taking a reference on the mdiodev you've got from somewhere else is the right thing to do. > + } else { > + mdiodev = mdio_device_create(bus, addr); > + if (IS_ERR(mdiodev)) > + return ERR_CAST(mdiodev); > + } > > - /* xpcs_create() has taken a refcount on the mdiodev if it was > - * successful. If xpcs_create() fails, this will free the mdio > - * device here. In any case, we don't need to hold our reference > - * anymore, and putting it here will allow mdio_device_put() in > - * xpcs_destroy() to automatically free the mdio device. > - */ > - mdio_device_put(mdiodev); > + xpcs = xpcs_create(mdiodev, interface); > + if (IS_ERR(xpcs)) > + mdio_device_put(mdiodev); Without the change to xpcs_create() you don't need this change - and this is why I say you don't understand refcounting. The point here is that the refcounting management is in each function where references are gained or lost. xpcs_create() creates a new reference to the mdiodev by storing it in the dw_xpcs structure. Therefore, it takes a reference to the mdiodev. If something fails, it drops that reference to restore the refcount as it was on function entry. xpcs_create_mdiodev() as it originally stood creates the mdiodev from the bus/address, and then passes that to xpcs_create(). Once xpcs_create() has finished its work (irrespective of whether it was successful or not) we're done with the mdiodev in this function, so the reference is _always_ put. For your use case, it would be: mdiodev = bus->mdio_map[addr]; mdio_device_get(mdiodev); xpcs = xpcs_create(mdiodev, interface); mdio_device_put(mdiodev); return xpcs; which illustrates this point - we get a reference to the mdiodev by reading it from the array. We do something (calling xpcs_create) with it. If that something was successful, it takes its own refcount otherwise leaves it as-is. We're then done with the mdiodev so we drop the refcount we took. There is no need to make the code more complicated by changing this, so I regard the refcount changes in this patch to be wrong. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!