dmi: Rework to get IPMI autoloading from DMI tables

Quoted 16 lines · On Wed, Feb 3, 2016 at 9:30 AM, <[email protected]> wrote:

The IPMI driver would not auto-load from DMI tables. So these patches creates a platform device from an IPMI DMI table entry, and then modify the IPMI driver to handle all this.

I followed how ACPI works mostly, with a fwnode and such. But greatly simplified, of course .

Changes from v1:

* Split out the IPMI changes to their own patch. It compiles and works at each step, so no need to mix it up. Should be easier to review now.

* Removed the dmi_zalloc() code, as the dmi_alloc already returns zeroed data.

Quoted 6 lines

* Removed the dummy (no DMI) is_dmi_fwnode() and to_dmi_device() calls as they are only used under CONFIG_DMI.

I'm still not sure about the device name and the driver_override setting. I'd prefer something different, but there's no easy way to provide device matching like ACPI and OF can.

Sorry for being so slow testing this. The whole series is:

Tested-by Andy Lutomirski <[email protected]>

A couple of thoughts that are definitely not prerequisites for this series:

The sysfs hierarchy for the ipmi devices is confusing, at least to me. With these applied, I have a dmi-ipmi-si device and an ipmi-bmc device. The ipmi-bmc device has a link called ipmi0 to the dmi-ipmi-si device. The dmi-ipmi-si device has a link called bmc to the ipmi-bmc device. The dmi-ipmi-si device also has the ipmi class with the ipmi0 class device attached. The dmi-ipmi-si part makes sense to me, but what's the ipmi-bmc for? Could it go away entirely? Should it be a child of the dmi-ipmi-si device?

As for getting ipmi_devintf to autoload, you could stick a modalias in the ipmi class device node (ipmi0) pointing to ipmi_devintf. It would be a bit hackish, but it ought to work, and it would allow blacklisting ipmi_devintf to prevent it from loading. Alternatively, you could merge ipmi_devintf into ipmi_si or export a dummy symbol from ipmi_devintf and require it in ipmi_si.

--Andy