From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ua1-f51.google.com (mail-ua1-f51.google.com [209.85.222.51]) (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 4643E482EF for ; Wed, 10 Jan 2024 12:55:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=bgdev.pl Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=bgdev.pl Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bgdev-pl.20230601.gappssmtp.com header.i=@bgdev-pl.20230601.gappssmtp.com header.b="s20dKFSX" Received: by mail-ua1-f51.google.com with SMTP id a1e0cc1a2514c-7cc7bae27b5so1303557241.2 for ; Wed, 10 Jan 2024 04:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20230601.gappssmtp.com; s=20230601; t=1704891329; x=1705496129; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=7Ee+hHkfAfIFS6WHvmIg35YEx3vQHJAhovJ3w3cPXwo=; b=s20dKFSXv9X0Dth46Eq9po8i1zw++gJAeAovANgJUWtSt/94qMDdNE6z161bIEdp2Z atELqW/ToP33dGrkoHBTOChulkv8Cw7Kv4FTMAuyypFZUkfrX5/Kh6YB3DlBueZvYdEp hzs/zmifuFPCqPeNZwb1WQVnPJHOBHxMIazawurhzd9sIsPVuFMU+IygCX8PilCPsQUr 6rZIP5SHmB3SL+0nfD6hPl1tSEpU7f7BOl8k2oh7MKxCiO5WWpJ4hE5B1l1pVP8bf94c 1gmLonYfjIGcPzZ8dzA2N7wL0S6x5gcjnngKgw86LHphKpQvU/fy+Ut4dVwNSwtJoZS8 MS1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704891329; x=1705496129; h=content-transfer-encoding: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=7Ee+hHkfAfIFS6WHvmIg35YEx3vQHJAhovJ3w3cPXwo=; b=Lc/79I1UWOyEjOMxDUwgYcGEnHCbxDMooiqewYZq16EPkU5/CJbiHLr3Xa7O51My5T FMUjIbya858q3/Lqg1CPgetEQoKuXKIYfcwS1f8KvOagazrMlur1EjO+UVYS0CySDb4W bBp5b0qrF9L3avDqE6sb/KoMvfPWqfnvFCACWJQrM+xATOPxT8cCYtL/U+VNsyXNUlNd sfsZZ0zdmlpJJJuGgWPZJcs5mN+0lqhI1JwZEeGPZNulMH7oYZV3LAlT3dYAFoj8R3h6 iA8JvLc4Woiz9e5OtgmIInzKcTToYAN/WjuWvbWNsNJYcx9tpqVaKM4vHbXouSZ1apgE 95TQ== X-Gm-Message-State: AOJu0YwjFMr0XZPBy+gvKl9Xp7fjyC8hJjXDgyJPGlJ6O+hiJPm1ss+e UnUW68n/OpwTpXIjHwY96Q0+JAMDsI2YReM9NDwRiQKFuwz7og== X-Google-Smtp-Source: AGHT+IFJf1lA0zydsqWg4MMlDwI7GY7aqZwXYX8MZwXUGKbgxRrG/GbjToxomMdYf3iIjG2NRkt8G9T0sjS/5fZgDGY= X-Received: by 2002:a05:6102:6248:b0:466:fd31:def8 with SMTP id gd8-20020a056102624800b00466fd31def8mr866005vsb.55.1704891329157; Wed, 10 Jan 2024 04:55:29 -0800 (PST) Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240104130123.37115-1-brgl@bgdev.pl> <20240104130123.37115-4-brgl@bgdev.pl> <20240109144327.GA10780@wunner.de> In-Reply-To: <20240109144327.GA10780@wunner.de> From: Bartosz Golaszewski Date: Wed, 10 Jan 2024 13:55:18 +0100 Message-ID: Subject: Re: [RFC 3/9] PCI/portdrv: create platform devices for child OF nodes To: Lukas Wunner Cc: Kalle Valo , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Bjorn Andersson , Konrad Dybcio , Catalin Marinas , Will Deacon , Bjorn Helgaas , Heiko Stuebner , Jernej Skrabec , Chris Morgan , Linus Walleij , Geert Uytterhoeven , Arnd Bergmann , Neil Armstrong , =?UTF-8?B?TsOtY29sYXMgRiAuIFIgLiBBIC4gUHJhZG8=?= , Marek Szyprowski , Peng Fan , Robert Richter , Dan Williams , Jonathan Cameron , Terry Bowman , Kuppuswamy Sathyanarayanan , =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , Huacai Chen , Alex Elder , Srini Kandagatla , Greg Kroah-Hartman , linux-wireless@vger.kernel.org, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, Bartosz Golaszewski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 9, 2024 at 3:43=E2=80=AFPM Lukas Wunner wrote= : > > On Thu, Jan 04, 2024 at 02:01:17PM +0100, Bartosz Golaszewski wrote: > > In order to introduce PCIe power-sequencing, we need to create platform > > devices for child nodes of the port driver node. They will get matched > > against the pwrseq drivers (if one exists) and then the actuak PCIe > > device will reuse the node once it's detected on the bus. > [...] > > --- a/drivers/pci/pcie/portdrv.c > > +++ b/drivers/pci/pcie/portdrv.c > > @@ -715,7 +716,7 @@ static int pcie_portdrv_probe(struct pci_dev *dev, > > pm_runtime_allow(&dev->dev); > > } > > > > - return 0; > > + return devm_of_platform_populate(&dev->dev); > > } > > I think this belongs in of_pci_make_dev_node(), portdrv seems totally > the wrong place. Note that you're currently calling this for RCECs > (Root Complex Event Collectors) as well, which is likely not what > you want. > of_pci_make_dev_node() is only called when the relevant PCI device is instantiated which doesn't happen until it's powered-up and scanned - precisely the problem I'm trying to address. Calling this for whomever isn't really a problem though, is it? We will create a platform device alright - if it's defined on the DT - and at worst it won't match against any driver. It seems harmless IMO. > devm functions can't be used in the PCI core, so symmetrically call > of_platform_unpopulate() from of_pci_remove_node(). I don't doubt what you're saying is true (I've seen worse things) but this is the probe() callback of a driver using the driver model. Why wouldn't devres work? Bart > > Thanks, > > Lukas >