netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Johnson <quic_jjohnson@quicinc.com>
To: Bjorn Andersson <andersson@kernel.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Kalle Valo" <kvalo@kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Konrad Dybcio" <konrad.dybcio@linaro.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Chris Morgan" <macromorgan@hotmail.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Nícolas F . R . A . Prado" <nfraprado@collabora.com>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Peng Fan" <peng.fan@nxp.com>,
	"Robert Richter" <rrichter@amd.com>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
	"Terry Bowman" <terry.bowman@amd.com>,
	"Lukas Wunner" <lukas@wunner.de>,
	"Huacai Chen" <chenhuacai@kernel.org>,
	"Alex Elder" <elder@linaro.org>,
	"Srini Kandagatla" <srinivas.kandagatla@linaro.org>,
	"Abel Vesa" <abel.vesa@linaro.org>,
	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" <bartosz.golaszewski@linaro.org>
Subject: Re: [PATCH 4/9] PCI: create platform devices for child OF nodes of the port node
Date: Thu, 1 Feb 2024 20:50:59 -0800	[thread overview]
Message-ID: <39779388-9aad-43fd-9ede-271ead40cbf7@quicinc.com> (raw)
In-Reply-To: <oiwvcvu6wdmpvhss3t7uaqkl5q73mki5pz6liuv66bap4dr2mp@jtjjwzlvt6za>

On 2/1/2024 4:03 PM, Bjorn Andersson wrote:
> On Wed, Jan 31, 2024 at 12:04:14PM +0100, Bartosz Golaszewski wrote:
>> On Tue, Jan 30, 2024 at 10:54 PM Bjorn Andersson <andersson@kernel.org> wrote:
>>>
>>> On Thu, Jan 18, 2024 at 12:15:27PM +0100, Greg Kroah-Hartman wrote:
>>>> 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
>>>>> <gregkh@linuxfoundation.org> wrote:
>>>>>>
>>>>>> On Wed, Jan 17, 2024 at 05:07:43PM +0100, Bartosz Golaszewski wrote:
>>>>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>>>>
>>>>>>> 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 :)
>>>>
>>>
>>> I believe I missed this part of the discussion, why does this need to be
>>> a platform_device? What does the platform_bus bring that can't be
>>> provided by some other bus?
>>>
>>
>> Does it need to be a platform_device? No, of course not. Does it make
>> sense for it to be one? Yes, for two reasons:
>>
>> 1. The ATH11K WLAN module is represented on the device tree like a
>> platform device, we know it's always there and it consumes regulators
>> from another platform device. The fact it uses PCIe doesn't change the
>> fact that it is logically a platform device.
> 
> Are you referring to the ath11k SNOC (firmware running on co-processor
> in the SoC) variant?
> 
> Afaict the PCIe-attached ath11k is not represented as a platform_device
> in DeviceTree.

Are you considering out-of-tree drivers? My understanding is that there
are different PCIe modules, ones that don't have GPIO-control for x86
and ones that do have GPIO-control for ARM. The out-of-tree cnss
platform driver used for Android has a large amount of DT control
<https://git.codelinaro.org/clo/la/platform/vendor/qcom-opensource/wlan/platform/-/blob/wlan-platform.lnx.1.0.r1-rel/cnss2/power.c?ref_type=heads>

(not sure off hand where the DT files themselves are)

/jeff

  reply	other threads:[~2024-02-02  4:51 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-17 16:07 [PATCH 0/9] PCI: introduce the concept of power sequencing of PCIe devices Bartosz Golaszewski
2024-01-17 16:07 ` [PATCH 1/9] arm64: dts: qcom: qrb5165-rb5: describe the WLAN module of QCA6390 Bartosz Golaszewski
2024-01-17 16:07 ` [PATCH 2/9] arm64: dts: qcom: sm8550-qrd: add Wifi nodes Bartosz Golaszewski
2024-01-17 16:07 ` [PATCH 3/9] arm64: dts: qcom: sm8650-qrd: " Bartosz Golaszewski
2024-01-17 16:07 ` [PATCH 4/9] PCI: create platform devices for child OF nodes of the port node Bartosz Golaszewski
2024-01-17 16:22   ` Dan Williams
2024-01-18 13:11     ` Bartosz Golaszewski
2024-01-17 16:45   ` Greg Kroah-Hartman
2024-01-18 10:58     ` Bartosz Golaszewski
2024-01-18 11:15       ` Greg Kroah-Hartman
2024-01-30 21:54         ` Bjorn Andersson
2024-01-31 11:04           ` Bartosz Golaszewski
2024-02-02  0:03             ` Bjorn Andersson
2024-02-02  4:50               ` Jeff Johnson [this message]
2024-02-02 10:02               ` Bartosz Golaszewski
2024-02-07 16:32                 ` Bartosz Golaszewski
2024-02-14 15:34                   ` Greg Kroah-Hartman
2024-01-17 16:07 ` [PATCH 5/9] PCI: hold the rescan mutex when scanning for the first time Bartosz Golaszewski
2024-01-17 16:07 ` [PATCH 6/9] PCI/pwrseq: add pwrseq core code Bartosz Golaszewski
2024-01-17 16:07 ` [PATCH 7/9] dt-bindings: wireless: ath11k: describe QCA6390 Bartosz Golaszewski
2024-01-17 16:07 ` [PATCH 8/9] dt-bindings: wireless: ath11k: describe WCN7850 Bartosz Golaszewski
2024-01-17 18:07   ` Kalle Valo
2024-01-17 20:01     ` Bartosz Golaszewski
2024-01-17 16:07 ` [PATCH 9/9] PCI/pwrseq: add a pwrseq driver for QCA6390 Bartosz Golaszewski
2024-01-18  5:49   ` Kalle Valo
2024-01-18 17:50   ` Konrad Dybcio
2024-01-17 17:53 ` [PATCH 0/9] PCI: introduce the concept of power sequencing of PCIe devices Neil Armstrong
2024-01-17 18:16 ` Dmitry Baryshkov
2024-01-18 18:53   ` Dmitry Baryshkov
2024-01-19 11:52     ` Bartosz Golaszewski
2024-01-19 12:31       ` Dmitry Baryshkov
2024-01-19 13:35         ` brgl
2024-01-19 14:07           ` Dmitry Baryshkov
2024-01-19 14:11             ` Bartosz Golaszewski
2024-01-19 14:48               ` Bartosz Golaszewski
2024-01-19 16:34       ` Lukas Wunner
2024-01-19 16:45         ` Rob Herring
2024-01-18 14:29 ` Rob Herring
2024-01-18 16:38   ` Bartosz Golaszewski
2024-01-18 16:47   ` Manivannan Sadhasivam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39779388-9aad-43fd-9ede-271ead40cbf7@quicinc.com \
    --to=quic_jjohnson@quicinc.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=abel.vesa@linaro.org \
    --cc=andersson@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=bhelgaas@google.com \
    --cc=brgl@bgdev.pl \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=elder@linaro.org \
    --cc=geert+renesas@glider.be \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko@sntech.de \
    --cc=jernej.skrabec@gmail.com \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=kvalo@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=m.szyprowski@samsung.com \
    --cc=macromorgan@hotmail.com \
    --cc=neil.armstrong@linaro.org \
    --cc=netdev@vger.kernel.org \
    --cc=nfraprado@collabora.com \
    --cc=pabeni@redhat.com \
    --cc=peng.fan@nxp.com \
    --cc=robh+dt@kernel.org \
    --cc=rrichter@amd.com \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=terry.bowman@amd.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).