All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Guoheyi <guoheyi@huawei.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, Shannon Zhao <shannon.zhaosl@gmail.com>,
	qemu-arm@nongnu.org, Corey Minyard <cminyard@mvista.com>,
	wanghaibin.wang@huawei.com
Subject: Re: [PATCH 2/2] arm/virt/acpi: remove _ADR from devices identified by _HID
Date: Thu, 16 Jan 2020 14:25:08 +0100	[thread overview]
Message-ID: <20200116142508.1d82af31@redhat.com> (raw)
In-Reply-To: <a4992b63-e8e7-7f54-341e-f7dd3d7e8880@huawei.com>

On Thu, 16 Jan 2020 19:56:19 +0800
Guoheyi <guoheyi@huawei.com> wrote:

> 在 2020/1/5 20:53, Michael S. Tsirkin 写道:
> > 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.  
> 
> More reading on the spec, I found a statement as below 
> (https://uefi.org/sites/default/files/resources/ACPI_6_3_May16.pdf, 
> section 6.1, on top of page 343):

I'd replace 'It does not make sense ...' sentence with pointer to spec
and quote below in commit message.

> A device object must contain either an _HID object or an _ADR object, 
> but should not contain both

[...]



  reply	other threads:[~2020-01-16 13:26 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
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 [this message]
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=20200116142508.1d82af31@redhat.com \
    --to=imammedo@redhat.com \
    --cc=cminyard@mvista.com \
    --cc=guoheyi@huawei.com \
    --cc=mst@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.