On Tuesday, December 01, 2015 05:04:33 PM Andy Lutomirski wrote: > On Tue, Dec 1, 2015 at 5:18 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > > On Tuesday, December 01, 2015 03:25:41 AM Zhang, Rui wrote: > >> Hi, all, > >> > >> The problem here is that the ACPI device node has > >> Name (_HID, "INT33D5") // _HID: Hardware ID > >> Name (_CID, "PNP0C02" /* PNP Motherboard Resources */) // > >> _CID: Compatible ID > >> > >> Andy wants to write a driver for INT33D5 device, but unfortunately > >> 1. _CID "PNP0C02" makes it impossible to bind via platform bus > >> 2. Lacking of _CRS makes it impossible to bind via PNP bus. > >> > >> I've seen similar problem before, and the solution is to ask BIOS people to remove the _CID "PNP0C02". > > > > What if they refuse? > > > >> IMO, such AML code does not make sense at all (even if _CRS is provided), because in this case, the _CID and the _HID of the same ACPI device node actually represent two totally different devices. > > > > That's correct. I guess this is a hack for Windows to prevent it from > > displaying "yellow bangs" for devices without "real" drivers. > > > >> OR, a clean way to fix this in Linux is to make the motherboard resource reservation stuff a function call instead of a driver, and invoke the function call in either PNP or ACPI bus code by checking "PNP0C02". In this case, only the device id that represents the physical device (INT33D5 in this case) can be used for device enumeration and driver probing. > > > > OK, but we need to keep the current ordering or there will be regressions in > > some odball configurations. > > > > What about walking (a) creating a list of things that have "PNP0C02" in their > > list of PNP IDs and (b) walking that list after we've completed the initial > > scan and reserving the resources for the ones that still have no drivers? > > > > I'm not really sure how this can work. The driver might be > demand-loaded (maybe even after we're done with initramfs) as a result > of a modalias. > > Could we just change acpi_pnp_attach to return 0 for devices that have > HID != "PNP0C02" and don't have _CRS? Yes, we could. Didn't I say that in the other message? > We could also consider something crazy like allowing ACPI platform > drivers (platform drivers with .acpi_match_table set) to bind pnp > devices. I find it a bit odd that we have two different busses that > have non-natively-enumerable things that come from ACPI. Yeah. The reason is that the PNP bus type was there before and we have a bunch of drivers on it. Plus it handles things that don't enumerate through ACPI and some of them may enumerate via ACPI or non-ACPI. > Or we could have a more general kind of driver interface that can bind > both platform and pnp devices. (It should presumably bind any other > similar busses.) It would match solely based on ACPI/OF data. The rule should be that we always create the same type of a device (either PNP or platform) for the same device ID. Problem is if the device has multiple IDs and some of them are in our list of "knon PNP device IDs" and some of them aren't. I'm tempted to guess that "PNP0C02" may be the only case here and therefore I'm tempted to simply decide to ignore "PNP0C02" in *all* cases when it isn't the device's _HID. Because, honestly, the only reason to put "PNP0C02" into a _CID list I can think about is to make Windows stop complaining about it. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
