From: Oliver Neukum <oneukum@suse.com>
To: Alexander Stein <alexander.stein@ew.tq-group.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Oliver Neukum <oneukum@suse.com>
Cc: Korneliusz Osmenda <korneliuszo@gmail.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/1] Guard pci_create_sysfs_dev_files with atomic value
Date: Thu, 16 Mar 2023 15:01:25 +0100 [thread overview]
Message-ID: <ced8713f-69de-e48a-37eb-4f844e651b6b@suse.com> (raw)
In-Reply-To: <3607385.usQuhbGJ8B@steina-w>
On 16.03.23 14:16, Alexander Stein wrote:
> But isn't the root bridge discovered by the driver (pci-imx6 in this case) for
> that? And the driver probe path eventually calls into the sysfs file creation.
> I compared the file creation to usb, as this is a discoverable bus as well.
> There is no special initialization regarding sysfs.
If you discover a bus system you always have the option of creating of virtual
hotplug event for the root hub or host controller.
But for PCI that is a bad design choice. USB is different.
> If, for some reason, the device enumeration for PCI bus during imx6_pcie_probe
> is delayed after pci_sysfs_init initcall, this initcall essentially does
> nothing, no devices or busses to iterate. Which means the complete pcie sysfs
On your specific system. You cannot use that as a model for all systems.
> creation is done from bridge probe path. There is no reason to iterate over
> discovered PCIe devices/busses separately.
If there is no other PCI device, the loop is a nop. But otherwise it is necessary.
>>> So technically the device is not probed from within a initcall but a
>>> kthread. It is set to be probed asynchronous in imx6_pcie_driver.
>>
>> That may be the problem, respectively that system is incomplete
>> You are registering a PCI bridge. The PCI subsystem should be
>> done setting up when you run. That is just a simple dependency.
>
> Is there such an dependency in the first place? I can't see anything, even the
> late_initcall to pci_resource_alignment_sysfs_init is a different matter.
On your hardware, yes. In the kernel, no.
That is the very point. The kernel is missing a way to represent a dependency.
Regards
Oliver
next prev parent reply other threads:[~2023-03-16 14:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-16 9:15 [PATCH v2 1/1] Guard pci_create_sysfs_dev_files with atomic value Alexander Stein
2023-03-16 9:18 ` Alexander Stein
2023-03-16 9:23 ` Oliver Neukum
2023-03-16 9:33 ` Alexander Stein
2023-03-16 11:17 ` Oliver Neukum
2023-03-16 11:58 ` Alexander Stein
2023-03-16 12:23 ` Oliver Neukum
2023-03-16 13:16 ` Alexander Stein
2023-03-16 14:01 ` Oliver Neukum [this message]
2023-03-16 15:00 ` Alexander Stein
2023-03-21 9:09 ` Oliver Neukum
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=ced8713f-69de-e48a-37eb-4f844e651b6b@suse.com \
--to=oneukum@suse.com \
--cc=alexander.stein@ew.tq-group.com \
--cc=bhelgaas@google.com \
--cc=korneliuszo@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.