public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org,
	Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Subject: Re: [PATCH v3 3/5] PCI/pwrctrl: Skip scanning for the device further if pwrctrl device is created
Date: Fri, 21 Feb 2025 23:08:40 +0530	[thread overview]
Message-ID: <20250221173840.dc3eocblfklbrklo@thinkpad> (raw)
In-Reply-To: <20250220232451.GA319309@bhelgaas>

On Thu, Feb 20, 2025 at 05:24:51PM -0600, Bjorn Helgaas wrote:
> On Thu, Jan 16, 2025 at 07:39:13PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > 
> > The pwrctrl core will rescan the bus once the device is powered on. So
> > there is no need to continue scanning for the device further.
> 
> > @@ -2487,7 +2487,14 @@ static struct pci_dev *pci_scan_device(struct pci_bus *bus, int devfn)
> >  	struct pci_dev *dev;
> >  	u32 l;
> >  
> > -	pci_pwrctrl_create_device(bus, devfn);
> > +	/*
> > +	 * Create pwrctrl device (if required) for the PCI device to handle the
> > +	 * power state. If the pwrctrl device is created, then skip scanning
> > +	 * further as the pwrctrl core will rescan the bus after powering on
> > +	 * the device.
> > +	 */
> > +	if (pci_pwrctrl_create_device(bus, devfn))
> > +		return NULL;
> 
> I assume it's possible for the PCI device to already be powered on
> even if there's a pwrctrl device for it?
> 

Yes, if the device was powered on by the bootloader.

> Does this change the enumeration order in that case?  It sounds like
> it may delay enumeration of the PCI device until the pwrctrl core
> rescans the bus?
> 

So previously, while enumerating a PCI device that requires a pwrctrl device
(indicated by DT), its client driver won't be probed until the pwrctrl driver is
probed (thanks to devlink). This was required to make sure that there would be
no race between client drivers and pwrctrl drivers probing parallely.

So in that case, there is no reason to enumerate the such devices in the first
place. That's why this patch is skipping the enumeration for those devices.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

  reply	other threads:[~2025-02-21 17:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-16 14:09 [PATCH v3 0/5] PCI/pwrctrl: Rework pwrctrl driver integration and add driver for PCI slot Manivannan Sadhasivam via B4 Relay
2025-01-16 14:09 ` [PATCH v3 1/5] PCI/pwrctrl: Move creation of pwrctrl devices to pci_scan_device() Manivannan Sadhasivam via B4 Relay
2025-01-16 14:09 ` [PATCH v3 2/5] PCI/pwrctrl: Move pci_pwrctrl_unregister() to pci_destroy_dev() Manivannan Sadhasivam via B4 Relay
2025-01-16 14:09 ` [PATCH v3 3/5] PCI/pwrctrl: Skip scanning for the device further if pwrctrl device is created Manivannan Sadhasivam via B4 Relay
2025-02-20 23:24   ` Bjorn Helgaas
2025-02-21 17:38     ` Manivannan Sadhasivam [this message]
2025-02-20 23:35   ` Bjorn Helgaas
2025-02-21 17:40     ` Manivannan Sadhasivam
2025-03-21  2:59   ` Wei Fang
2025-03-21  4:42     ` Manivannan Sadhasivam
2025-03-21  7:04       ` Wei Fang
2025-03-22  3:23         ` Manivannan Sadhasivam
2025-03-22 11:39           ` Wei Fang
2025-03-24  8:15             ` Manivannan Sadhasivam
2025-03-27  6:02               ` Wei Fang
2025-04-02  8:14                 ` Manivannan Sadhasivam
2025-01-16 14:09 ` [PATCH v3 4/5] dt-bindings: vendor-prefixes: Document the 'pciclass' prefix Manivannan Sadhasivam via B4 Relay
2025-01-16 14:09 ` [PATCH v3 5/5] PCI/pwrctrl: Add pwrctrl driver for PCI Slots Manivannan Sadhasivam via B4 Relay
2025-02-20 14:24 ` [PATCH v3 0/5] PCI/pwrctrl: Rework pwrctrl driver integration and add driver for PCI slot Krzysztof Wilczyński

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=20250221173840.dc3eocblfklbrklo@thinkpad \
    --to=manivannan.sadhasivam@linaro.org \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=bhelgaas@google.com \
    --cc=brgl@bgdev.pl \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=helgaas@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=robh@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