[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a package called ADDR, evaluating to two
> -----Original Message-----
> From: Paul Durrant
> Sent: Tuesday, November 29, 2011 11:05 AM
> To: Ross Philipson; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
> package called ADDR, evaluating to two
> > -----Original Message-----
> > From: Ross Philipson
> > Paul, perhaps a different _HID might be better. Per the 3.0 spec,
> > ACPI0001 is for SMBus host controller device; this might lead to some
> > confusion for an OSPM. Maybe one of the generic PNP device IDs or
> > perhaps we need a manufacturer ID for Xen?
> I have no problem choosing a different _HID. I just don't have a good
> reference for what name is not going to clash with something else. Looks
> like ACPI0001 was a bad guess. Any better suggestions? What are the
> 'generic PNP device IDs'?
Well I actually brought it up as a discussion point. I have the same sort of
issue - I have a generic device for a virtualized environment. I don't really
want it to be recognized as anything specific. I guess I see three options:
- Use an unassigned APCIXXXX string. I believe the _HID string values of the
form "ACPIXXXX" are defined by the ACPI specs themselves so this may not work
in the long run.
- Use one of the predefined generic container EisaId PNP values. By that I
meant using EisaId(PNP0A05) or EisaId(PNP0A06). Looking at the Linux generic
container driver, it doesn't do very much with these devices so that might be
- Acquire a vendor specific EisaId range for Xen (e.g. EisaId(XENABCD)). Then
we could carve up the product number part of the ID as we see fit.
Anyway, just some ideas.
Xen-devel mailing list