All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Heyi Guo <guoheyi@huawei.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Corey Minyard <cminyard@mvista.com>,
	qemu-devel@nongnu.org, Shannon Zhao <shannon.zhaosl@gmail.com>,
	qemu-arm@nongnu.org, Igor Mammedov <imammedo@redhat.com>,
	wanghaibin.wang@huawei.com
Subject: Re: [PATCH 2/2] arm/virt/acpi: remove _ADR from devices identified by _HID
Date: Sun, 5 Jan 2020 07:53:53 -0500	[thread overview]
Message-ID: <20200105074308-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20200105072504-mutt-send-email-mst@kernel.org>

On Sun, Jan 05, 2020 at 07:34:01AM -0500, Michael S. Tsirkin wrote:
> On Thu, Dec 19, 2019 at 02:47:59PM +0800, Heyi Guo wrote:
> > According to ACPI spec, _ADR should be used for device which is on a
> > bus that has a standard enumeration algorithm. It does not make sense
> > to have a _ADR object for devices which already have _HID and will be
> > enumerated by OSPM.
> > 
> > Signed-off-by: Heyi Guo <guoheyi@huawei.com>
> 
> Are you sure? I would think this depends on the ID and the device
> really. E.g. PCI devices all are expected to have _ADR and some of them
> have a _HID.


To clarify I am not commenting on patches.
The spec says this:
	6.1.5 _HID (Hardware ID)

	This object is used to supply OSPM with the device’s PNP ID or ACPI ID. 1

	When describing a platform, use of any _HID objects is optional. However, a _HID object must be

	used to describe any device that will be enumerated by OSPM. OSPM only enumerates a device

	when no bus enumerator can detect the device ID. For example, devices on an ISA bus are

	enumerated by OSPM. Use the _ADR object to describe devices enumerated by bus enumerators

	other than OSPM.


Note: "detect the device ID" not "enumerate the device" which I think
means there's a driver matching this vendor/device ID.

So it seems fine to have _ADR so device is enumerated, and still have
_HID e.g. so ACPI driver can be loaded as fallback if there's
no bus driver.


Note I am not saying the patch itself is not correct.
Maybe these devices are not on any standard bus and that
is why they should not have _ADR? I have not looked.

I am just saying that spec does not seem to imply _HID and _ADR
can't coexist.


> CC Corey who added a device with both HID and ADR to x86 recenly.
> 
> Apropos Corey, why was HID APP0005 chosen?
> 
> > ---
> > Cc: Shannon Zhao <shannon.zhaosl@gmail.com>
> > Cc: Peter Maydell <peter.maydell@linaro.org>
> > Cc: "Michael S. Tsirkin" <mst@redhat.com>
> > Cc: Igor Mammedov <imammedo@redhat.com>
> > Cc: qemu-arm@nongnu.org
> > Cc: qemu-devel@nongnu.org
> > ---
> >  hw/arm/virt-acpi-build.c          |   8 --------
> >  tests/data/acpi/virt/DSDT         | Bin 18449 -> 18426 bytes
> >  tests/data/acpi/virt/DSDT.memhp   | Bin 19786 -> 19763 bytes
> >  tests/data/acpi/virt/DSDT.numamem | Bin 18449 -> 18426 bytes
> >  4 files changed, 8 deletions(-)
> > 
> > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> > index 9f4c7d1889..be752c0ad8 100644
> > --- a/hw/arm/virt-acpi-build.c
> > +++ b/hw/arm/virt-acpi-build.c
> > @@ -78,11 +78,6 @@ static void acpi_dsdt_add_uart(Aml *scope, const MemMapEntry *uart_memmap,
> >                               AML_EXCLUSIVE, &uart_irq, 1));
> >      aml_append(dev, aml_name_decl("_CRS", crs));
> >  
> > -    /* The _ADR entry is used to link this device to the UART described
> > -     * in the SPCR table, i.e. SPCR.base_address.address == _ADR.
> > -     */
> > -    aml_append(dev, aml_name_decl("_ADR", aml_int(uart_memmap->base)));
> > -
> >      aml_append(scope, dev);
> >  }
> >  
> > @@ -170,7 +165,6 @@ static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap,
> >      aml_append(dev, aml_name_decl("_CID", aml_string("PNP0A03")));
> >      aml_append(dev, aml_name_decl("_SEG", aml_int(0)));
> >      aml_append(dev, aml_name_decl("_BBN", aml_int(0)));
> > -    aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> >      aml_append(dev, aml_name_decl("_UID", aml_string("PCI0")));
> >      aml_append(dev, aml_name_decl("_STR", aml_unicode("PCIe 0 Device")));
> >      aml_append(dev, aml_name_decl("_CCA", aml_int(1)));
> > @@ -334,7 +328,6 @@ static void acpi_dsdt_add_gpio(Aml *scope, const MemMapEntry *gpio_memmap,
> >  {
> >      Aml *dev = aml_device("GPO0");
> >      aml_append(dev, aml_name_decl("_HID", aml_string("ARMH0061")));
> > -    aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> >      aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> >  
> >      Aml *crs = aml_resource_template();
> > @@ -364,7 +357,6 @@ static void acpi_dsdt_add_power_button(Aml *scope)
> >  {
> >      Aml *dev = aml_device(ACPI_POWER_BUTTON_DEVICE);
> >      aml_append(dev, aml_name_decl("_HID", aml_string("PNP0C0C")));
> > -    aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> >      aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> >      aml_append(scope, dev);
> >  }
> > diff --git a/tests/data/acpi/virt/DSDT b/tests/data/acpi/virt/DSDT
> 
> 
> Please do not include binary changes in acpi patches.
> 
> See comment at the top of tests/bios-tables-test.c for documentation
> on how to update these.
> 
> -- 
> MST


  reply	other threads:[~2020-01-05 12:54 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-19  6:47 [PATCH 0/2] Some cleanup in arm/virt/acpi Heyi Guo
2019-12-19  6:47 ` [PATCH 1/2] arm/virt/acpi: remove meaningless sub device "PR0" from PCI0 Heyi Guo
2020-01-13 12:37   ` Igor Mammedov
2020-01-16 12:36     ` Guoheyi
2020-01-21  3:48     ` Guoheyi
2020-01-21  6:35     ` Michael S. Tsirkin
2020-01-22  5:39   ` Michael S. Tsirkin
2020-01-22  6:38     ` Guoheyi
2019-12-19  6:47 ` [PATCH 2/2] arm/virt/acpi: remove _ADR from devices identified by _HID Heyi Guo
2020-01-05 12:33   ` Michael S. Tsirkin
2020-01-05 12:53     ` Michael S. Tsirkin [this message]
2020-01-06  2:10       ` Guoheyi
2020-01-13  8:46         ` Guoheyi
2020-01-16 11:56       ` Guoheyi
2020-01-16 13:25         ` Igor Mammedov
2020-01-17  1:54           ` Guoheyi
2020-01-05 22:54     ` Corey Minyard
2020-01-06  9:39       ` Michael S. Tsirkin
2020-01-06 13:07         ` Corey Minyard
2020-01-06 15:51     ` Peter Maydell
2020-01-15  2:03       ` Guoheyi
2020-01-15  6:30         ` Michael S. Tsirkin
2020-01-15  9:25           ` Guoheyi
2020-01-15 10:53             ` Michael S. Tsirkin
2020-01-15 10:55             ` Michael S. Tsirkin
2020-01-16 12:24               ` Peter Maydell
2020-01-17  2:08                 ` Guoheyi
2020-01-13 12:08   ` Igor Mammedov
2020-01-13 13:57     ` Guoheyi
2020-01-13 15:26       ` Andrew Jones
2020-01-15  1:25         ` Guoheyi
2020-01-15 12:08   ` Igor Mammedov
2019-12-19 12:34 ` [PATCH 0/2] Some cleanup in arm/virt/acpi Michael S. Tsirkin

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=20200105074308-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=cminyard@mvista.com \
    --cc=guoheyi@huawei.com \
    --cc=imammedo@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shannon.zhaosl@gmail.com \
    --cc=wanghaibin.wang@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 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.