Date:	Fri, 29 Jan 2016 14:12:08 -0600
From:	Corey Minyard <minyard@....org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Andy Lutomirski <luto@...nel.org>,
	OpenIPMI Developers <openipmi-developer@...ts.sourceforge.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	brijeshkumar.singh@....com, Jean Delvare <jdelvare@...e.de>
Subject: Re: [Openipmi-developer] ipmi_si feature request: SMBIOS-based
 autoloading

On 01/26/2016 11:29 AM, Andy Lutomirski wrote:
> On Tue, Jan 26, 2016 at 5:43 AM, Corey Minyard <minyard@....org> 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

Powered by blists - more mailing lists