From: Miao Wang <shankerwangmiao@gmail.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Linux ACPI <linux-acpi@vger.kernel.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>
Subject: Re: [PATCH v3 2/7] ACPI: scan: Extract CSI-2 connection graph from _CRS
Date: Sun, 8 Dec 2024 21:53:34 +0800 [thread overview]
Message-ID: <4AE6B366-4F8A-41AC-BCE9-4C39CCFE767F@gmail.com> (raw)
In-Reply-To: <CAJZ5v0hzHONOO=JCCniQONPAhFMLuDaWO=_n=fpStEQyaYP5hg@mail.gmail.com>
> 2024年12月5日 18:54,Rafael J. Wysocki <rafael@kernel.org> 写道:
>
>>
>> Maybe we can prioritize the initialization of the PCI host bridge to
>> fully eliminate this issue?
>
> The problem with this is that the current code requires struct
> acpi_device objects to be present for all PCI devices that have
> corresponding objects in the ACPI Namespace at the time when the host
> bridge is initialized because that causes the PCI bus to be scanned
> for devices and struct acpi_device objects are looked up from there.
>
> To make this work, the "ACPI companion lookup" code needs to be
> changed and that would be kind of a heavy lifting and it may introduce
> some unexpected enumeration ordering issues.
>
> Alternatively, the PCI host bridge could be initialized early, but
> without scanning the PCI bus which would be scanned at the time when
> all of the struct acpi_device objects are present. It looks like this
> could be made work, but it would require some investigation and code
> refactoring.
Thanks again for your explanation on this. I understand that it may need
lots of work. I think it would be better if the fix would become as minor
as possible, because it would be easier to backport and more importantly,
the case where legacy IO device is used on non-x86 ACPI-enabled
architectures is really rare.
I'm currently running out of better ideas, due to my limited experience
on this part of code. I suppose maybe we can scan the ACPI device tree
in three passes, adding one in the beginning to pick out the PCI Host.
But we should deal with the case where evaluating the _CRS of the PCI
Host itself requires reading IO ports, since it seems that the
specification does not forbid this...
If you are familiar with someone in the UEFI forum, maybe this problem
can be raised to them and a clarification can be requested.
Cheers,
Miao Wang
next prev parent reply other threads:[~2024-12-08 13:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-06 16:03 [PATCH v3 0/7] ACPI: scan: MIPI DisCo for Imaging support Rafael J. Wysocki
2023-11-06 16:06 ` [PATCH v3 1/7] ACPI: property: Support using strings in reference properties Rafael J. Wysocki
2023-11-06 16:09 ` [PATCH v3 2/7] ACPI: scan: Extract CSI-2 connection graph from _CRS Rafael J. Wysocki
2024-11-21 21:57 ` Miao Wang
2024-12-03 19:44 ` Rafael J. Wysocki
2024-12-05 7:23 ` Miao Wang
2024-12-05 10:54 ` Rafael J. Wysocki
2024-12-08 13:53 ` Miao Wang [this message]
2023-11-06 16:16 ` [PATCH v3 3/7] ACPI: scan: Extract _CRS CSI-2 connection information into swnodes Rafael J. Wysocki
2023-11-06 16:16 ` [PATCH v3 4/7] device property: Add SOFTWARE_NODE() macro for defining software nodes Rafael J. Wysocki
2023-11-06 16:27 ` [PATCH v3 5/7] ACPI: scan: Extract MIPI DisCo for Imaging data into swnodes Rafael J. Wysocki
2023-11-06 21:50 ` Sakari Ailus
2023-11-07 20:06 ` Rafael J. Wysocki
2023-11-06 16:28 ` [PATCH v3 6/7] ACPI: property: Dig "rotation" property for devices with CSI2 _CRS Rafael J. Wysocki
2023-11-06 16:31 ` [PATCH v3 7/7] ACPI: property: Replicate DT-aligned u32 properties from DisCo for Imaging Rafael J. Wysocki
2023-11-06 16:47 ` [PATCH v3 0/7] ACPI: scan: MIPI DisCo for Imaging support Rafael J. Wysocki
2023-11-07 19:19 ` [PATCH v3.1 5/7] ACPI: scan: Extract MIPI DisCo for Imaging data into swnodes Rafael J. Wysocki
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=4AE6B366-4F8A-41AC-BCE9-4C39CCFE767F@gmail.com \
--to=shankerwangmiao@gmail.com \
--cc=linux-acpi@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=sakari.ailus@linux.intel.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 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.