Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp6799321rdb; Tue, 2 Jan 2024 14:03:32 -0800 (PST) X-Google-Smtp-Source: AGHT+IFuZWueFsxyrzAXPqcQMyqgCGrTamrlfjsiSk94FKOldKFiAvoUJgzcx7wxOY10OC0aXYm4 X-Received: by 2002:a05:6870:32d4:b0:1fa:a755:fb14 with SMTP id r20-20020a05687032d400b001faa755fb14mr12549473oac.44.1704233012626; Tue, 02 Jan 2024 14:03:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704233012; cv=none; d=google.com; s=arc-20160816; b=JrPicXaf3z5ZVQAv6aOhAU6THFDfs5RsTCDQeRp4JYaeLd+ITaIEZUN793JX8KcJtY MECPf4u/UHEWbF2/ZYFvaeNiXB5ASJmpE4yYmFJtNyk5rG7nAdErdBcNNVH4Ii5z4sbP 7OJsgNLco0V1nR8c/hLBTTiGMoLC9P5fsVSdUucEwSL+4db5pTZ8aU6O3rNxBN+brHbd t4CzFFJP7Ew+h7qdVxCWcPEbZePC3DM4vuKyrAoy9G8Jk/sX5JhRljrVRrnozqvH/TmD C/aQeNrGWOs5kycrBDClhEh8g2pL3ybazbqRPPHXeuLzEuEohpHavzHLUFAZx1R9OBN5 FB+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :dkim-signature; bh=ZrAMhCdZp/DH6n9t5/40nGjHO+BryyqAdvgXAu3yxZg=; fh=I3UF0Gs/kMW73IFk0b0ex4mQxwhaSv1JEcMYBKTQ1Ls=; b=zzNOiBrCHAFo3U0xhbPZcouk07ZR+yPxb6tji77pkOsbJ7bhuyCboLTmkz4+pQLmHi h5Rgff6Iusnwoj8PHrVCL4ACO/85dTMOK812yXN4CHoxrz2a8pXDE1EenEJfOoLihJ86 s+ZvbjQhryGKRUTB4cqDnEiYlYGbdkEUQWpqvQJi1VP7mdmkFXdzQtS6XfWDvwgCsi58 W6woBjoo/75Wb2oxTtoGH6WDsqUtLwjcVj4Wt+tqBjEEQCCL+M3h2xvImsKrzgtE1H/b ux/5rzimDUJWuyn4UwTSdGhvPAlvx8960gpEOEUgK8QY6GiIuuJGQQvQAo3IS4jl/8xt CJEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=ERCXYkmD; spf=pass (google.com: domain of linux-kernel+bounces-14906-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-14906-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id m7-20020a1fee07000000b004b71dacba04si3256526vkh.104.2024.01.02.14.03.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jan 2024 14:03:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-14906-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=ERCXYkmD; spf=pass (google.com: domain of linux-kernel+bounces-14906-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-14906-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 577F01C21543 for ; Tue, 2 Jan 2024 22:03:32 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6F8C21803F; Tue, 2 Jan 2024 21:57:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ERCXYkmD" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 15DA81802D; Tue, 2 Jan 2024 21:57:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2ccec119587so39886251fa.0; Tue, 02 Jan 2024 13:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704232669; x=1704837469; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZrAMhCdZp/DH6n9t5/40nGjHO+BryyqAdvgXAu3yxZg=; b=ERCXYkmD0SYi/uUaACZWyOsk163y6DC0yQsSzONhZelq8wu5oOtPOfr+n12vBnWjiP w3mJ6qC5PAGao6C+8cEgG4zz0e9bRjpYzG9RCacT8R+IjZYxR52gJmhV3X8T0cWKM/b/ KPf23vrHbBtGJbVoVGl9DYZSznt9kjYKHPu6YhDx34wrnq4Z+9v762zeM3S8N1LngSf0 e0bxDG8qtm5rESA76khYforZC5VtqfmLASL/h3Kme/mNh9PuMgjOHP0e0YpVc5CBDB2/ KMbiJft/H6K0VFy5OGvagLGc49tU9j7pn+K/kWXV4a5aG0cPKEFDowbRaH12YGFfkkue p+VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704232669; x=1704837469; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZrAMhCdZp/DH6n9t5/40nGjHO+BryyqAdvgXAu3yxZg=; b=MQrKBgmk1eXok/pqVET80cxO39Q+z+FtIdbiwlDkrcy77Kk+odzr8UrhZFhGpQH3G1 5clNYviXt/QV9tvGPJc8ctVYHyw3IdSq6N+znaVPK9ChRoyI+E2WV2CTi6uGBIpt7sIq VUZeH19rvcMclfvGQOwRIR8QzecwhdzQUgAa/4wYYZFUH5M2sJVGTquBvZnDBv6ElvUd VIw6OrqIsLhTAwTjWNFvoyRx3+j9v72qsDSNSsh5Tw4zqEHA6WRCWVXsV/I15VXPnc9x whmUC+6CVVC6I2UXeHEjznx71306V4yByp+yJ2NjWY9EWLU5s8SFud4QwQ7jZxGjQ8mI fqow== X-Gm-Message-State: AOJu0YyDIYE/Kh92FwxQ5gbkyCE/vI2ZHhivcUX6s1Y3nsZ61ai1Fmjn 6nD+G4dWINcuEP89uTh4D6t4xHbb1dvPQJ3+c1Q= X-Received: by 2002:a2e:8902:0:b0:2cc:5780:6915 with SMTP id d2-20020a2e8902000000b002cc57806915mr8428433lji.10.1704232668610; Tue, 02 Jan 2024 13:57:48 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20231220045228.27079-2-luizluca@gmail.com> In-Reply-To: From: Luiz Angelo Daros de Luca Date: Tue, 2 Jan 2024 18:57:35 -0300 Message-ID: Subject: Re: [PATCH net-next] net: mdio: get/put device node during (un)registration To: "Russell King (Oracle)" Cc: netdev@vger.kernel.org, andrew@lunn.ch, hkallweit1@gmail.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" > On Wed, Dec 20, 2023 at 01:52:29AM -0300, Luiz Angelo Daros de Luca wrote: > > The __of_mdiobus_register() function was storing the device node in > > dev.of_node without increasing its reference count. It implicitly relied > > on the caller to maintain the allocated node until the mdiobus was > > unregistered. > > > > Now, __of_mdiobus_register() will acquire the node before assigning it, > > and of_mdiobus_unregister_callback() will be called at the end of > > mdio_unregister(). > > > > Drivers can now release the node immediately after MDIO registration. > > Some of them are already doing that even before this patch. > > > > Signed-off-by: Luiz Angelo Daros de Luca > > I don't like this, certainly not the use of a method prefixed by a > double-underscore, and neither the conditional nature of "putting" > this. That alone seems to point to there being more issues. Thanks Russel. At least one driver (bcm_sf2_mdio_register) is writing directly to the mii_bus->dev.of_node and not using of_mdiobus_register(). We should not put a node in the MDIO bus if the bus didn't get it before. That's the reason for the conditional putting the node. I wasn't sure about the names. What would be an appropriate name? The same without the prefix? In order to put the node only when the bus was registered by __of_mdiobus_register, I opted for a callback but it might be a better approach. > I also notice that netdev have applied this without *any* review from > phylib maintainers. Grr. Some reviews are required. Should we revert it? > Indeed there are more issues with the refcounting here. If one looks at > drivers/net/phy/mdio_bus.c::of_mdiobus_link_mdiodev(), we find this: > > if (addr == mdiodev->addr) { > device_set_node(dev, of_fwnode_handle(child)); > /* The refcount on "child" is passed to the mdio > * device. Do _not_ use of_node_put(child) here. > */ > return; > > but there is nowhere that this refcount is dropped. The same file where we have the get should also contain the put, ideally in a reverse function like register/unregister. It is too easy to miss a put that should happen in a different context. fixed_phy_unregister seems to be one case where it put that node after phy_device_remove() but I didn't investigate it further if that was related to a different of_node_get. mdiobus_unregister_device might be a nice place to fit that put but I'm not an expert in MDIO API. > Really, the patch should be addressing the problem rather than putting > a sticky-plaster over just one instance of it. I'm trying to address an issue I ran into while modifying a DSA driver. We have drivers putting the node passed to of_mdiobus_register just after it returns. In my option, it feels more natural and this patch fixes that scenario. Other drivers keep that reference until the driver is removed, which might still be too soon without this patch. I guess putting the node should happen between mdiobus_unregister and mdiobus_free. If the driver uses devm variants, it does not control the code between those two methods and it should just hope that it is enough to put the node as its last step. I issue that the child node you pointed to should also be addressed. However, I think they are two different but related issues. Any place we see a device_set_node(), we should see a of_node_get before and a of_node_put when the device is gone. Regards, Luiz