> > On 01/19/2016 02:46 PM, Stuart_Hayes@xxxxxxxx wrote: > > I'm having a problem on a number of systems where the IPMI driver isn't able > to find the ACPI IPMI device. > > > > This is happening because the ACPI scan is attaching the acpi_pnp handler to > the ACPI IPMI device, which is happening because the IPMI device has a _CID of > PNP0C01 in addition to an _HID of IPI0001. This is a problem because > acpi_scan_attach_handler() doesn't know about the IPMI drivers (ipmi_si / > ipmi_ssif), which don't register as PNP or ACPI drivers, but instead expect the > ACPI scan find no applicable driver and thus create a platform device. > > I recently pulled out the pnp code in ipmi_si in favour of a platform device. The > trouble was that you couldn't register both the ipmi_si and ipmi_ssif driver with > IPI0001 (even though they were in different > spaces) because IPI0001 was hard-coded into the acpi_pnp tables. This fix > prevented having to update a lot of firmware. > > Plus I was under the impression that this was the right thing to do, anyway. > Perhaps it wasn't, but I didn't get a comment from the linux-acpi list when I > submitted it (twice). > > > This could be fixed pretty easily by modifying acpi_scan_attach_handler() to > make it return 0 without attaching a handler to devices that have a _HID of > IPI0001 when the kernel has an IPMI driver available (if, say, CONFIG_IPMI_SI, > CONFIG_IPMI_SI_MODULE, CONFIG_IPMI_SSIF, or > CONFIG_IPMI_SSIF_MODULE are defined)... but would this be accepted? > > That sounds like a bad hack to me. > I kind of agree. > > Or is this something that will require reworking the IPMI drivers? Or is there > another way? > > The question in my mind is why the IPMI device has a _CID of PNP0C01 (or > is it PNP0c01? That's the only thing I found.). From what I can tell > from the spec, PNP0c01 is a "system board", and Linux has it as a "memory > controller", neither of which is really applicable. > > But I admit that I don't know very much about these things. I believe the right > place to fix this is the driver, if we can. I'm hoping for a simple solution. > > -corey The _CID of PNP0C01 was added to this device so that operating systems without IPMI support would still reserve its resources. I think the reasoning was that the OS would attach a driver for the _HID of IPI0001 if one exists, and would only fall back to the _CID of PNP0C01 if the OS didn't have anything for IPI0001. Unfortunately, it doesn't work that way in the linux kernel, since the PNP driver for the _CID will take priority over something that requires a platform device to be created. I'll give it some thought. A "whitelist" for creating platform devices (like I believe used to exist in acpi_platform.c) would, I think, take care of this, but that was removed a while back in favor of just making a platform device if no other driver was found... -- 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
