On Wed, Feb 3, 2016 at 9:30 AM, <minyard@xxxxxxx> wrote:
The IPMI driver would not auto-load from DMI tables. So these patchesSorry for being so slow testing this. The whole series is:
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.
* 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.
Tested-by: Andy Lutomirski <luto@xxxxxxxxxx>
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