Received: by 2002:ab2:7407:0:b0:1f4:b336:87c4 with SMTP id e7csp279067lqn; Fri, 12 Apr 2024 00:41:32 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXjEM4yCMZ9eahP5rhBdKlNSXbVPs2sOnNiovan36fL1g8Aro7ZL//pj2tvk9e9Yi+8TG/Z0R4EvmVXMYVCo5q5k92tZtaUG5jk5Rg9fg== X-Google-Smtp-Source: AGHT+IF6PDFW9SqdHzXi5vo/XOC1dU/Zyx8o3praLjIjxhnCSRsUzjUCS9p65YwbqOWTAtXmWOGq X-Received: by 2002:a17:906:3299:b0:a46:8daa:436f with SMTP id 25-20020a170906329900b00a468daa436fmr1046045ejw.69.1712907692217; Fri, 12 Apr 2024 00:41:32 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712907692; cv=pass; d=google.com; s=arc-20160816; b=bdDNuvDpA/asCh6ZOmm1s28kv3Qtj3X3h8NGkx2G9OmffQuo4T6iYvRTtNRWzZRujM IUIMJA6Bo+lXmRpdjLxiDZQHDCLH/KU2MDo3KwUJeZwhMgNY7jM5zCYWslONZc9y5eEV S9QrJ9XWQWjdHYpj/Xb1bjHShN7VnEjaPApUKOHYvqvK42DEkFQ9ZGHlOO4rCBQhhF/9 F3qI/k0IBjQdmrr/rTf5+CZp7Snw78o7KyjSmRC5lQQmPi1try3u/i1HyJNjksBnL3Vd jzdi1ZR/btkUmIeu9s5ZmJ6MaPbfX5ypxjGoGwHsjwMGZNpSJy2MYebDBfLKNIcZ1BZk zEPA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=Oo3PGpK0EC/yTuKIl+RyXaLyqpAqBUMM5qTOxehIzdQ=; fh=wWiIFzETK5ZMp7ochACSx9WJiLYcYPsfU1eZwMaXRO4=; b=K1lP8kwaFOKqxd5bM6tBCZ3hsmZ5gmzkGdz9UmmMtaeK9wT22TPSFC8ZVEKJwHBMy9 rAYq+KNuh7qpOzATpbkuu41mob0KdlTAhT8GrtmlPqycDFM2iRJivnMsUq0NPIFuUUwL ydbI26Gvs7Wbbhlq7dzDSd96fp5ScaPyzYVGvEXRf2LTgitsXIK2oOVdbpHszBbluGeN Akd8oPZHW57fFy5lAJ9lO5hO7YXLn7W76W9/3RyeqDnlaCG13Eps+WdhGOb1HAddav6l FE0GPunJY8w1IgNN9YPR+JpfxXuvGMRW33xLm7v9v6FswQ7cFFBd4EQmc0iDKHLOvGU3 jJrA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=uaqj3G6J; arc=pass (i=1 dkim=pass dkdomain=linuxfoundation.org); spf=pass (google.com: domain of linux-kernel+bounces-142164-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-142164-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id gb35-20020a170907962300b00a51c4d61266si1464939ejc.308.2024.04.12.00.41.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Apr 2024 00:41:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-142164-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=uaqj3G6J; arc=pass (i=1 dkim=pass dkdomain=linuxfoundation.org); spf=pass (google.com: domain of linux-kernel+bounces-142164-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-142164-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org 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 am.mirrors.kernel.org (Postfix) with ESMTPS id ED7671F22FE4 for ; Fri, 12 Apr 2024 07:41:31 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1BAF44D5BF; Fri, 12 Apr 2024 07:41:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="uaqj3G6J" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1A4AA3218B; Fri, 12 Apr 2024 07:41:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712907683; cv=none; b=Cl9Xi6pRC/J39D3GrX29atxIFjaoJNhtE4rMBG/Il5MWTNibk94PekOmvQhqSNYYs7AxDMW6Lz4u/zU6uyQjON5Dp6RDWf/jX4EboV+gnjw3zKOwcMlqftYHD/TcQta9iuz5T/vUtt+iXXloyhG9ZXkz3FCElfSsvHeHLSVM6XE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712907683; c=relaxed/simple; bh=LR+bEwyj9w9Lz1Iy+tTJ6XhyijBDBX//2OTo3KKfYvk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZntqnS8z51fZ9LiscHVd16ZO3dtGflXAkRT6oQ8Cnpc5nBTix21j5Jplmr8rTvOCjyvlLzlwfHRFQBT/mamsXcIvz+3CGJqiuLBIDKkQhfdOBxSqYi10FUn710SWgz+tYygcaj8YMYunjq3afu7MBPyZBSG5WXYcjLb59KDQik4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=uaqj3G6J; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1DA9CC113CC; Fri, 12 Apr 2024 07:41:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1712907682; bh=LR+bEwyj9w9Lz1Iy+tTJ6XhyijBDBX//2OTo3KKfYvk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uaqj3G6JwGUsGiKVZAnZ/RABtuhKdxdxGmICk8vmMfDrEhUHa8ClA+BCqBs48OjZp t0n+sysKV81IUSZ5qM9PJFCMAPE/FOf2f84Qsb0BDZ6rYgxd9BAkg77O7OFfxI2Nau HXGUtnBS6btQvSv7Bgrr+5Gfg3b+QDwFbdpPdS7o= Date: Fri, 12 Apr 2024 09:41:19 +0200 From: Greg Kroah-Hartman To: Rob Herring Cc: Herve Codina , "Rafael J. Wysocki" , Bjorn Helgaas , Lizhi Hou , Max Zhen , Sonal Santan , Stefano Stabellini , Jonathan Cameron , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, Allan Nielsen , Horatiu Vultur , Steen Hegelund , Thomas Petazzoni , stable@vger.kernel.org Subject: Re: [PATCH v3 2/2] PCI: of: Attach created of_node to existing device Message-ID: <2024041219-impure-upcountry-9e9d@gregkh> References: <20240325153919.199337-1-herve.codina@bootlin.com> <20240325153919.199337-3-herve.codina@bootlin.com> <2024041142-applause-spearman-bd38@gregkh> <20240411203449.GA2641-robh@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240411203449.GA2641-robh@kernel.org> On Thu, Apr 11, 2024 at 03:34:49PM -0500, Rob Herring wrote: > On Thu, Apr 11, 2024 at 03:23:55PM +0200, Greg Kroah-Hartman wrote: > > On Mon, Mar 25, 2024 at 04:39:15PM +0100, Herve Codina wrote: > > > The commit 407d1a51921e ("PCI: Create device tree node for bridge") > > > creates of_node for PCI devices. > > > > > > During the insertion handling of these new DT nodes done by of_platform, > > > new devices (struct device) are created. For each PCI devices a struct > > > device is already present (created and handled by the PCI core). > > > Having a second struct device to represent the exact same PCI device is > > > not correct. > > > > > > On the of_node creation: > > > - tell the of_platform that there is no need to create a device for this > > > node (OF_POPULATED flag), > > > - link this newly created of_node to the already present device, > > > - tell fwnode that the device attached to this of_node is ready using > > > fwnode_dev_initialized(). > > > > > > With this fix, the of_node are available in the sysfs device tree: > > > /sys/devices/platform/soc/d0070000.pcie/ > > > + of_node -> .../devicetree/base/soc/pcie@d0070000 > > > + pci0000:00 > > > + 0000:00:00.0 > > > + of_node -> .../devicetree/base/soc/pcie@d0070000/pci@0,0 > > > + 0000:01:00.0 > > > + of_node -> .../devicetree/base/soc/pcie@d0070000/pci@0,0/dev@0,0 > > > > > > On the of_node removal, revert the operations. > > > > > > Fixes: 407d1a51921e ("PCI: Create device tree node for bridge") > > > Cc: stable@vger.kernel.org > > > Signed-off-by: Herve Codina > > > > I need an ack from the maintainer here before I can take this. > > Correct me if I'm wrong, but having the of_node sysfs link populated or > changed after device_add is a race we lost. Userspace is notified about > the new device and then some time later the symlink shows up. Ah, yes, I missed that, good catch, this will not work. > However, it so far is not appearing that there's an easy way to > reshuffle order of things to fix this. > > Maybe the short term (and stable) answer just don't create any of_node > symlinks on these dynamically created nodes. That would work, but does userspace really need to know this information? thanks, greg k-h