From mboxrd@z Thu Jan 1 00:00:00 1970 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 81C3123760; Thu, 18 Jan 2024 11:15:30 +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=1705576530; cv=none; b=nB3fJEDyLjZzzsZS6iRyHD+rLkbR0nJLCAwtNdcw/aarR1PqvUBcADcJeNcL76q8ctnkwec7Bt65BVtV0PiCJz7umebKJ5Z7+iq6Krk0IdVpdQv+wvfHfCVIPNdIyTtT9Vw70thfq5VLh4iIY9ZPITEtMEClHWBB7mPsWhZI4Io= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705576530; c=relaxed/simple; bh=w0FBrm4sVu/DLk+0aSDbplyxxPuYJ1uOLaE9EFkd7dc=; h=Received:DKIM-Signature:Date:From:To:Cc:Subject:Message-ID: References:MIME-Version:Content-Type:Content-Disposition: Content-Transfer-Encoding:In-Reply-To; b=ou3syrqEV/+QTF+prdRg8op3aF4sQxlCpDwkGLaJmIVA3NBj5BiRoY+mlwhgvbuHqfy611o7vLb+KHw7kmpKTpNczxJplDflwzp/B/hAhC9OJNrGls/C/2LW1fO/d+dM9NNd+d1Nug6KDKUYay+XMrC93dBW7Ud5wrNuRLmcR/E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=RDlOUNNR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="RDlOUNNR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67825C433F1; Thu, 18 Jan 2024 11:15:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1705576529; bh=w0FBrm4sVu/DLk+0aSDbplyxxPuYJ1uOLaE9EFkd7dc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RDlOUNNRGsPbYHC1L726WS5dkr3VOCBjd+MqAQ3JUuhv4MGJkXgYEYB+5YyQ6MDp6 NB6nu7QYWRq3V7fuP2fZxIS74bHee+zZbKSxRibWClXO4RxoPVbNRHIvtWjRA0ba7D gXUqRp/5zTN7aJpa6bWv04Guwid8cuyD5nfl4a9Y= Date: Thu, 18 Jan 2024 12:15:27 +0100 From: Greg Kroah-Hartman To: Bartosz Golaszewski 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 , =?iso-8859-1?Q?N=EDcolas_F_=2E_R_=2E_A_=2E?= Prado , Marek Szyprowski , Peng Fan , Robert Richter , Dan Williams , Jonathan Cameron , Terry Bowman , Lukas Wunner , Huacai Chen , Alex Elder , Srini Kandagatla , Abel Vesa , 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 Subject: Re: [PATCH 4/9] PCI: create platform devices for child OF nodes of the port node Message-ID: <2024011836-wok-treadmill-c517@gregkh> References: <20240117160748.37682-1-brgl@bgdev.pl> <20240117160748.37682-5-brgl@bgdev.pl> <2024011707-alibi-pregnancy-a64b@gregkh> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Jan 18, 2024 at 11:58:50AM +0100, Bartosz Golaszewski wrote: > On Wed, Jan 17, 2024 at 5:45 PM Greg Kroah-Hartman > wrote: > > > > On Wed, Jan 17, 2024 at 05:07:43PM +0100, Bartosz Golaszewski wrote: > > > From: Bartosz Golaszewski > > > > > > In order to introduce PCI power-sequencing, we need to create platform > > > devices for child nodes of the port node. > > > > Ick, why a platform device? What is the parent of this device, a PCI > > device? If so, then this can't be a platform device, as that's not what > > it is, it's something else so make it a device of that type,. > > > > Greg, > > This is literally what we agreed on at LPC. In fact: during one of the > hall track discussions I said that you typically NAK any attempts at > using the platform bus for "fake" devices but you responded that this > is what the USB on-board HUB does and while it's not pretty, this is > what we need to do. Ah, you need to remind me of these things, this changelog was pretty sparse :) > Now as for the implementation, the way I see it we have two solutions: > either we introduce a fake, top-level PCI slot platform device device > that will reference the PCI host controller by phandle or we will live > with a secondary, "virtual" platform device for power sequencing that > is tied to the actual PCI device. The former requires us to add DT > bindings, add a totally fake DT node representing the "slot" which > doesn't really exist (and Krzysztof already expressed his negative > opinion of that) and then have code that will be more complex than it > needs to be. The latter allows us to not change DT at all (other than > adding regulators, clocks and GPIOs to already existing WLAN nodes), > reuse the existing parent-child relationship between the port node and > the instantiated platform device as well as result in simpler code. > > Given that DT needs to be stable while the underlying C code can > freely change if we find a better solution, I think that the second > option is a no-brainer here. Ok, I remove my objections, sorry about that, my confusion. greg k-h