From: Lukas Wunner <lukas@wunner.de>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Brian Norris <briannorris@chromium.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Krzysztof Wilczy??ski <kwilczynski@kernel.org>,
Krishna chaitanya chundru <quic_krichai@quicinc.com>,
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Jon Hunter <jonathanh@nvidia.com>,
Saurabh Sengar <ssengar@linux.microsoft.com>
Subject: Re: [PATCH 6.13] PCI/pwrctrl: Skip NULL of_node when unregistering
Date: Sun, 1 Dec 2024 17:13:00 +0100 [thread overview]
Message-ID: <Z0yLDBMAsh0yKWf2@wunner.de> (raw)
In-Reply-To: <20241201082108.qy2reqd56mvrd6ku@thinkpad>
On Sun, Dec 01, 2024 at 01:51:08PM +0530, Manivannan Sadhasivam wrote:
> So we create pwrctl devices starting from PCI bridges. This is because,
> in order for the endpoints to be enumerated, the relevant pwrctl drivers
> need to be probed first (i.e., pci_bus_add_device() will be called for
> the endpoints only when they are detected on the bus, but that cannot
> happen until the relevant pwrctl driver is probed). That's why we have
> the loop in pci_pwrctrl_create_devices() to iterate over the children
> of PCI bridges defined in devicetree.
I think a better approach would be to create a pwrctrl device when
the corresponding PCI device is scanned.
In pci_scan_child_bus_extend(), you'll find this loop:
/* Go find them, Rover! */
for (devfn = 0; devfn < 256; devfn += 8)
pci_scan_slot(bus, devfn);
... where pci_scan_slot() reads the Vendor ID to determine whether
a device is present at the devfn address and then goes on to
create the pci_dev.
I think what you want to do is, just before the Vendor ID is read,
create the pwrctrl device and enable power. The OF node of the
pwrctrl device can be found by way of the devfn, right? So you
can just search whether an OF node exists for a given devfn.
Moreover, for multifunction devices I think you may want to use
refcounting so that the pwrctrl device does not cut power unless
the refcount reaches zero.
Thanks,
Lukas
next prev parent reply other threads:[~2024-12-01 16:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-26 21:04 [PATCH 6.13] PCI/pwrctrl: Skip NULL of_node when unregistering Brian Norris
2024-11-27 5:52 ` Manivannan Sadhasivam
2024-11-27 19:55 ` Jon Hunter
2024-11-29 19:28 ` Bjorn Helgaas
2024-12-01 8:21 ` Manivannan Sadhasivam
2024-12-01 10:54 ` Lukas Wunner
2024-12-09 17:46 ` Manivannan Sadhasivam
2024-12-01 16:13 ` Lukas Wunner [this message]
2024-11-30 18:23 ` Bjorn Helgaas
2024-12-01 8:22 ` 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=Z0yLDBMAsh0yKWf2@wunner.de \
--to=lukas@wunner.de \
--cc=bartosz.golaszewski@linaro.org \
--cc=bhelgaas@google.com \
--cc=briannorris@chromium.org \
--cc=helgaas@kernel.org \
--cc=jonathanh@nvidia.com \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=quic_krichai@quicinc.com \
--cc=ssengar@linux.microsoft.com \
/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