[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 > [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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |