Re: [Openipmi-developer] ipmi_si feature request: SMBIOS-based autoloading

[Corey Minyard]

On 01/26/2016 11:29 AM, Andy Lutomirski wrote:
> On Tue, Jan 26, 2016 at 5:43 AM, Corey Minyard <minyard@xxxxxxx> wrote:
> > On 01/26/2016 07:32 AM, Corey Minyard wrote:
> > > On 01/24/2016 07:45 PM, Andy Lutomirski wrote:
> > > > ipmi_si doesn't autoload on systems where it's found via SMBIOS.
> > > > Could that be fixed?
> > > I'm not really sure.  I kind of assumed this was handled in userland
> > > like the ACPI tables.  I don't think there are many systems that have
> > > SMBIOS and not ACPI, so I'm not sure of the impact here or what
> > > to do.
> I've never seen it handled in userland adequately on Fedora, Ubuntu, or CentOS.

Well, that was much harder than I expected.  There's not much there for
handling DMI devices, so I added some basic infrastructure to do this.  I
looked at some other methods, but they were really hacks.  Expect some
patches on this soon.

> FWIW, it might pay to have ipmi_si pull in ipmi_devintf as well.  Then
> ipmitool would work out of the box.

Yeah, I've gotten enough complaints on this, I'll go ahead and do it.  I 
tried
adding MODULE_SOFTDEP, but that doesn't seem to work out of the box.
So I need to figure out the best way to do this.

-corey

> > > > If I were doing it, I'd suggest rigging up some code that's compiled
> > > > in to the main kernel even if ipmi_si is a module that creates the
> > > > platform device if the dmi device is there and then set up a modalias
> > > > so that the platofrm device causes ipmi_si to load.
> > > >
> > > > (In general, having the same driver create the platform device and
> > > > register the platform driver means that autoloading is unlikely to
> > > > work right.  See arch/x86/kernel/pmem.c for an example of a weird
> > > > legacy device that gets this right.)
> > > This sounds like kind of a hack.
> It's a bit of a hack in that case.  It does preserve the general
> driver model approach where a lower-level thing enumerates the system
> and instantiates devices and then a higher-level driver binds to the
> devices.
>
> > > > Alternatively, maybe /sys/firmware/dmi could learn how to advertise
> > > > modaliases.  But that might be a giant mess to solve a tiny problem.
> > > This sounds like the right way, but you are probably right.  Are
> > > there any other resources that could benefit from this?  I"m
> > > guessing not.
> No clue.  Jean might know.  Jean?
>
> > > There is already a "dmi_save_ipmi_device" function that gets called
> > > when scanning the SMBIOS table (see drivers/firmware/dmi_scan.c).
> > > Maybe a tie-in there?  That happens pretty early, though, I'm not
> > > sure if it's too early.
> > >
> > > Of course it would be easy to have a file like pmem.c that detects
> > > if an IPMI device is in the SMBIOS table and create a platform
> > > device for it.
> > >
> > > Are you willing to do this work?
> I'm willing to do some plumbing, but I'm not sure I want to dig deeply
> into the innards of ipmi_si initialization.
>
> > > -corey
> > Actually, there is some cleanup that has to occur here, let me look at this
> > a little bit.
> It looks like the driver currently decides how to talk to the hardware
> and then instantiates the platform device.  For my approach to work,
> it would have to be refactored a bit: instantiate the platform device
> with the info about how to talk to hardware and then have the platform
> driver fish that info back out of the platform device.  Is that what
> you're talking about?
>
> I also don't understand the distinction between ipmi_si and ipmi_bmc.
>
> --Andy