From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Shannon Zhao <zhaoshenglong@huawei.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
stefano.stabellini@citrix.com, david.vrabel@citrix.com,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
julien.grall@citrix.com, xen-devel@lists.xen.org,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
linux-efi@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ian Campbell <ian.campbell@citrix.com>,
Shannon Zhao <shannon.zhao@linaro.org>,
peter.huangpeng@huawei.com, Len Brown <lenb@kernel.org>,
"open list:ACPI" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen
Date: Fri, 12 Feb 2016 13:57:44 +0100 [thread overview]
Message-ID: <CAJZ5v0j7Vv5B-+CYt=ZAvO+YTj6-0Cm0Bi=1AjG5JbTeNLW3EQ@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1602121138090.27008@kaball.uk.xensource.com>
On Fri, Feb 12, 2016 at 12:50 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 11 Feb 2016, Rafael J. Wysocki wrote:
>> On Thursday, February 11, 2016 04:04:14 PM Stefano Stabellini wrote:
>> > On Wed, 10 Feb 2016, Rafael J. Wysocki wrote:
>> > > On Tuesday, February 09, 2016 11:19:02 AM Stefano Stabellini wrote:
>> > > > On Mon, 8 Feb 2016, Rafael J. Wysocki wrote:
>> > > > > On Monday, February 08, 2016 10:57:01 AM Stefano Stabellini wrote:
>> > > > > > On Sat, 6 Feb 2016, Rafael J. Wysocki wrote:
>> > > > > > > On Fri, Feb 5, 2016 at 4:05 AM, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>> > > > > > > > From: Shannon Zhao <shannon.zhao@linaro.org>
>> > > > > > > >
>> > > > > > > > ACPI 6.0 introduces a new table STAO to list the devices which are used
>> > > > > > > > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
>> > > > > > > > UART is used by Xen. So here it hides UART from Dom0.
>> > > > > > > >
>> > > > > > > > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>> > > > > > > > Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> > > > > > >
>> > > > > > > Well, this doesn't look right to me.
>> > > > > > >
>> > > > > > > We need to find a nicer way to achieve what you want.
>> > > > > >
>> > > > > > I take that you are talking about how to honor the STAO table in Linux.
>> > > > > > Do you have any concrete suggestions?
>> > > > >
>> > > > > I do.
>> > > > >
>> > > > > The last hunk of the patch is likely what it needs to be, although I'm
>> > > > > not sure if the place it is added to is the right one. That's a minor thing,
>> > > > > though.
>> > > > >
>> > > > > The other part is problematic. Not that as it doesn't work, but because of
>> > > > > how it works. With these changes the device will be visible to the OS (in
>> > > > > fact to user space even), but will never be "present". I'm not sure if
>> > > > > that's what you want?
>> > > > >
>> > > > > It might be better to add a check to acpi_bus_type_and_status() that will
>> > > > > evaluate the "should ignore?" thing and return -ENODEV if this is true. This
>> > > > > way the device won't be visible at all.
>> > > >
>> > > > Something like below? Actually your suggestion is better, thank you!
>> > > >
>> > > > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>> > > > index 78d5f02..4778c51 100644
>> > > > --- a/drivers/acpi/scan.c
>> > > > +++ b/drivers/acpi/scan.c
>> > > > @@ -1455,6 +1455,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
>> > > > if (ACPI_FAILURE(status))
>> > > > return -ENODEV;
>> > > >
>> > > > + if (acpi_check_device_is_ignored(handle))
>> > > > + return -ENODEV;
>> > > > +
>> > > > switch (acpi_type) {
>> > > > case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
>> > > > case ACPI_TYPE_DEVICE:
>> > > >
>> > >
>> > > I thought about doing that under ACPI_TYPE_DEVICE, because it shouldn't be
>> > > applicable to the other types. But generally, yes.
>> >
>> > I was pondering about it myself. Maybe an ACPI_TYPE_PROCESSOR object
>> > could theoretically be hidden with the STAO?
>>
>> But this patch won't check for it anyway, will it?
>>
>> It seems to be only checking against the UART address or have I missed
>> anything?
>
> You are right, this patch only checks for the UART address, which is
> critical.
>
> However the STAO also has a "Name List" field with a list of paths in
> ACPI namespace to hide. If not implementing proper "Name List" support,
> at least, as part of this patch, it would be nice to check for the
> presence of the Name List field in the table, and print a warning such
> as "STAO Name List not yet supported" when the field is present.
That would be fine, but anyway it belongs to the table parsing part IMO.
And the check can be moved when adding proper support for the name list part.
Thanks,
Rafael
next prev parent reply other threads:[~2016-02-12 12:57 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 3:05 [PATCH v4 00/17] Add ACPI support for Xen Dom0 on ARM64 Shannon Zhao
2016-02-05 3:05 ` [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen Shannon Zhao
2016-02-06 10:23 ` Rafael J. Wysocki
2016-02-08 10:57 ` Stefano Stabellini
2016-02-08 22:25 ` Rafael J. Wysocki
2016-02-09 11:19 ` Stefano Stabellini
2016-02-10 22:29 ` Rafael J. Wysocki
2016-02-11 16:04 ` Stefano Stabellini
2016-02-11 22:22 ` Rafael J. Wysocki
2016-02-12 11:50 ` Stefano Stabellini
2016-02-12 12:57 ` Rafael J. Wysocki [this message]
2016-02-29 2:02 ` Shannon Zhao
2016-02-05 3:05 ` [PATCH v4 02/17] xen/grant-table: Move xlated_setup_gnttab_pages to common place Shannon Zhao
2016-02-05 3:05 ` [PATCH v4 03/17] Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn Shannon Zhao
2016-02-05 3:05 ` [PATCH v4 04/17] arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table Shannon Zhao
2016-02-05 3:05 ` [PATCH v4 05/17] xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio Shannon Zhao
2016-02-08 11:43 ` Stefano Stabellini
2016-02-05 3:05 ` [PATCH v4 06/17] Xen: ARM: Add support for mapping platform device mmio Shannon Zhao
2016-02-05 3:05 ` [PATCH v4 07/17] Xen: ARM: Add support for mapping AMBA " Shannon Zhao
2016-02-05 3:05 ` [PATCH v4 08/17] Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen Shannon Zhao
2016-02-05 3:05 ` [PATCH v4 09/17] xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ Shannon Zhao
2016-02-05 3:05 ` [PATCH v4 10/17] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI Shannon Zhao
2016-02-05 3:05 ` [PATCH v4 11/17] ARM: XEN: Move xen_early_init() before efi_init() Shannon Zhao
2016-02-05 3:05 ` [PATCH v4 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI Shannon Zhao
2016-02-05 3:05 ` [PATCH v4 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual platforms Shannon Zhao
2016-02-08 11:31 ` Stefano Stabellini
2016-02-05 3:05 ` [PATCH v4 14/17] XEN: EFI: Move x86 specific codes to architecture directory Shannon Zhao
2016-02-05 3:05 ` [PATCH v4 15/17] ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services Shannon Zhao
2016-02-05 3:05 ` [PATCH v4 16/17] FDT: Add a helper to get specified name subnode Shannon Zhao
2016-02-05 14:15 ` Stefano Stabellini
2016-02-09 5:04 ` Rob Herring
2016-02-23 11:13 ` Shannon Zhao
2016-02-24 14:53 ` Rob Herring
2016-02-05 3:05 ` [PATCH v4 17/17] Xen: EFI: Parse DT parameters for Xen specific UEFI Shannon Zhao
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='CAJZ5v0j7Vv5B-+CYt=ZAvO+YTj6-0Cm0Bi=1AjG5JbTeNLW3EQ@mail.gmail.com' \
--to=rafael@kernel.org \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=david.vrabel@citrix.com \
--cc=devicetree@vger.kernel.org \
--cc=ian.campbell@citrix.com \
--cc=julien.grall@citrix.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=peter.huangpeng@huawei.com \
--cc=rjw@rjwysocki.net \
--cc=shannon.zhao@linaro.org \
--cc=stefano.stabellini@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=will.deacon@arm.com \
--cc=xen-devel@lists.xen.org \
--cc=zhaoshenglong@huawei.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).