Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp960607rdd; Wed, 10 Jan 2024 04:55:45 -0800 (PST) X-Google-Smtp-Source: AGHT+IGyWgSnbuC3bztMitKPJDu9KJEg5JaftnDE0j6TuGh7NWRj1sfeSF7wB2jQRxmPjaSBezcy X-Received: by 2002:a05:6102:2911:b0:467:c972:7923 with SMTP id cz17-20020a056102291100b00467c9727923mr700751vsb.57.1704891345466; Wed, 10 Jan 2024 04:55:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704891345; cv=none; d=google.com; s=arc-20160816; b=FI2uccsOMHv6ooG+i0x/0zeqveXZl9DgVAbyyxkuVUZ8IN60Bk3wVQJTzZM6rCn0t7 b2Kb3QlOM5emxTESIcWNq89DURym2wChL570yOHCAWNAvyobENLaW5fyoy555PhKEGSt Pz+wZRqUpf8YZxBeDuidwCKFFcFl8RB6ONWeVOWaAWDFxN7K/Z0Yhdo8NbDJdAzdra/p rut5K2F7l7k0cctVOkpvYZEa2j3SIhl6kOqc4D8n6VdivnyOrOd72VdF6W38d44ea6u/ LqAj+fYsWnYsYzazqeFaTl+NaW8mTlGsislpu8f/Mq/PjhxdYxGMtv/dM20T3hPtsRWk l25g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:list-unsubscribe:list-subscribe :list-id:precedence:dkim-signature; bh=7Ee+hHkfAfIFS6WHvmIg35YEx3vQHJAhovJ3w3cPXwo=; fh=Ou2sfbatsjTy48V6fnteK8lVgKixen5XgSBvOE4W8KA=; b=LjzXC1R71Ro3VqFi3AvFq+lJpap7Zpvon1OtBmCsU5HH9gvlNV5OSg0UIKMYKyiHKw SFcs9WsRbwKp6io01SZoYEloDfhK8BQKJf4oJaGcbQSx6Q33E3dZl/RWxJRmmgoxoEVQ Xfej/CdAay+UovvYx9FYOEuqTNDWIMU6ThlKIVX7pcytAasNbNJ9TXNP74W8BUTHcG/a +klRiEMOhuBCd7ghQ5MnUTJSyuPsbqFzGgq0xjTPb20he7Ze+fOAB4dpBfe38jbxPBK6 t+oIo+AM3O28nL5rpwgCvjP4nvcEDUXSKHMr1k9hWq1HbbV5doNZJjwmPKPMHDLnMcNt S1Pg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20230601.gappssmtp.com header.s=20230601 header.b=s20dKFSX; spf=pass (google.com: domain of linux-wireless+bounces-1660-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-wireless+bounces-1660-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id e18-20020ac85992000000b004298fa9947csi4086346qte.662.2024.01.10.04.55.45 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jan 2024 04:55:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-wireless+bounces-1660-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@bgdev-pl.20230601.gappssmtp.com header.s=20230601 header.b=s20dKFSX; spf=pass (google.com: domain of linux-wireless+bounces-1660-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-wireless+bounces-1660-linux.lists.archive=gmail.com@vger.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 ny.mirrors.kernel.org (Postfix) with ESMTPS id 277751C25BED for ; Wed, 10 Jan 2024 12:55:45 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C63B348781; Wed, 10 Jan 2024 12:55:32 +0000 (UTC) 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" X-Original-To: linux-wireless@vger.kernel.org Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) (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 493B7482F9 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 Received: by mail-vs1-f50.google.com with SMTP id ada2fe7eead31-4674ca1a2dbso919337137.0 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=RhG0ylE7IwAfIGMrf/b1CzuOGkTx9yDW1RxaDKroovbYuUR/qpBh0pq2eqpoxnRLn4 aJKn5Hmai0Zhw20R8BqMDFM5MaViziBkt9XzKflZg7AlDcXNsNg5aOjeuc+Ayn8eOXpy UWJxoyBBPS04Zzw2hgcb0rj1yVCx7Gt5TRKyFhqP1mLx9SOgBSoEiQ6mp8CA2yb/mmbs 9WwUWl4Hjq4CUNgUPKVORxOLFXe6yY9vII2ye0Php6/XCLIH7VMI2CLlYz7C7FgDMBbb ySO1iy16bcrhA70+ohKWoBx5hW4311/8f7FQknW2ky3mgv4J/Nw/Vl8xOkEMnrktvVId eSBQ== X-Gm-Message-State: AOJu0Yzb4xyAGzH4jiFTc8Z1CQXj0y5Ttwyy7Y3M0Q1vCer2kGR5c5pF 8Z9NLaLVowlMIZseSMtS8OGoPZPDBHsMBdB0L7wKAMmdGb9yOg== 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: linux-wireless@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 >