Received: by 2002:ab2:7407:0:b0:1f4:b336:87c4 with SMTP id e7csp56404lqn; Thu, 11 Apr 2024 13:44:11 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCW8wO6oLh1EOZWjEocWuZdjfyy7y0oY/XBxMFScClW6PlaMPTuCLHeq6AQEv4lcMF3iSlY1jg/oAJ2WTr/Vrd9zzA0cyTlesxpa+dhHTQ== X-Google-Smtp-Source: AGHT+IG2dey9hdZHFzypqxZd1k9zTJMQ1LQORDPCLKZQxz8xsSxGdr8c0kFcxyegQLlUN0/pRrQG X-Received: by 2002:a05:6a00:3d4e:b0:6ea:e2d8:468 with SMTP id lp14-20020a056a003d4e00b006eae2d80468mr836998pfb.26.1712868251542; Thu, 11 Apr 2024 13:44:11 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712868251; cv=pass; d=google.com; s=arc-20160816; b=UbQI16gZoORYy5iCnpOjKOZFFFByf+/Am8bpVW65HoZ+aKLOpzqTkTsgFSocNJqeQp HkXeI1CBZ7OmhancdvE0/nf7t6Nufc0AcZ89jEcBGGuk4vdWxLRdMrosGFaFD427hsL8 991HV73BwbeoN5wHzdOeCm8W+z84ygPmuIhxpDoHPKjgD5hHdzGl859Pbs/HUwWsgrAi B5UkOa8lmF7IK3Ifr6fubkvrzqR8xaF0sKNUZ5rVeVCLBzImOzefwSNgmQ+0/g6TZNFh WuAx/uP1jGrbhfFHBHFDtU1CynAY/LWSS9ULHvEZiU/1zd+kAQTub1jJ1MMAm50ncBvo B+ew== 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=d5q1WDRkpZfun4RL4mEeh93brKMpgbxVqyT6hnV0gh0=; fh=xEth188s6Oj5Aa8KG0kT7B7104/UBMjV0d4VwEplMO0=; b=JlgmBEVK5fqZ3xrUpFPCsxKGAy33m0Zpo/ZP51vC7buOi+jXdIaWpfdi8BG9Aq85bK qI92EbL+cbrQo60qN3L9e4iW/cQThtWraAOfvgH/MN6rFY4Dsf3I5ouSBe+B52OZRi2j NKv+fTm7uKP5SrpJeBE2LIjBoyN1O3PQJrB8wkkhhW6xlrS7WnNV6PIYCTLphVMXCKz8 J2g+UQmM3ob+qTeoJu+6tHFvVLHCNNMAV0tdJSsXQqicThRRWcJfAuz1dDMezpqcDy6Q gx1V+ToEP4nizxLe6GimgiWpujZRESFj6LmRRX+cOEHiWQABNEfaOc+g5BKKrYf2UWZP f/hA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=slQfO4Yu; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-141581-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-141581-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id it19-20020a056a00459300b006eb3c2b0472si1915363pfb.378.2024.04.11.13.44.10 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Apr 2024 13:44:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-141581-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=slQfO4Yu; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-141581-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-141581-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.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 sy.mirrors.kernel.org (Postfix) with ESMTPS id 5FD4CB242B0 for ; Thu, 11 Apr 2024 20:35:10 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D4DEA1C287; Thu, 11 Apr 2024 20:34:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="slQfO4Yu" 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 E8A3029417; Thu, 11 Apr 2024 20:34:52 +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=1712867693; cv=none; b=T3sMEgIHIcTI7bC8kzwVdKycOvKW2Y2/CVpC1tue/SkhaK/aiwz6Ag7TPoU89djrshLXFvKAhyNqjJa2v49NxLgoPP6N7lC6sAR9HV0+trjj93yzBXPLJRWcwQ6eFidf3dEOCfrMST/8/Sj4fX0vfA1rwln3Gt/BsS55sGlPXaE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712867693; c=relaxed/simple; bh=9I3BW9al1fnQ0MtkczhNQoRl2kehBKmTZx4LxVoh0cQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IRlxFiV5iAZ26uI74smCxlIIN6C1pGt/hIxg3kVOhrpFCMLy7hGfCW2t6jSMcBCzXfg4r1nANgsDquvABV1Tzm7/CmCkDvyS4HhxgMJA5itVsPP+dPkd2DqxYM6IumMhlGEUex75RjMKy23ZcEf+cGh3sRhxhV9LXaAZGHroO0Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=slQfO4Yu; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2EFD8C072AA; Thu, 11 Apr 2024 20:34:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712867692; bh=9I3BW9al1fnQ0MtkczhNQoRl2kehBKmTZx4LxVoh0cQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=slQfO4YuWHa5Kq1Dp9bOG+CYajJ0A8owzrfeBgxdPAjvZLlJGWQF0nCkyF6hbdrAA U6oHGUoSj+rTAvCp5iywDP3kj64mXITzC0KOYKjGJHrC0JtPTcYApUcEjX18TiIHCm 1nsF7rzWwkOxCZNGzC6U53V8aFAZbblD8KRo0KMuOCCKA9h+iVQ2CDu9n5bM71dHk7 5yDx1iFXzuOvL1VHz3mv4JQFiT3D4tWoHe8peAV2aghVefoAjZQk4GJrONS6M42qXl proNfIXgjsGvEp/SpZdQmvMMCpgvnWUIYNBLykY7I1LW2Om7aAJkbSwhNEBsZPgSHZ oxZPqk4QJSgbQ== Date: Thu, 11 Apr 2024 15:34:49 -0500 From: Rob Herring To: Greg Kroah-Hartman 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: <20240411203449.GA2641-robh@kernel.org> References: <20240325153919.199337-1-herve.codina@bootlin.com> <20240325153919.199337-3-herve.codina@bootlin.com> <2024041142-applause-spearman-bd38@gregkh> 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: <2024041142-applause-spearman-bd38@gregkh> 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. 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. Rob