Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a package called ADDR, evaluating to two

[Ross Philipson <Ross.Philipson@xxxxxxxxxx>]

> -----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
> [snip]
> >
> > 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'?
> 
>   Paul

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 
OK.
 - 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.

Ross


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel