Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1316158 > unrolled thread

ipmi_si feature request: SMBIOS-based autoloading

Back to article view | Back to linux.kernel

Contents

  ipmi_si feature request: SMBIOS-based autoloading Andy Lutomirski <luto@kernel.org> - 2016-01-25 02:50 +0100
    Re: ipmi_si feature request: SMBIOS-based autoloading Corey Minyard <minyard@acm.org> - 2016-01-26 15:40 +0100
      Re: [Openipmi-developer] ipmi_si feature request: SMBIOS-based  autoloading Corey Minyard <minyard@acm.org> - 2016-01-26 15:50 +0100
        Re: [Openipmi-developer] ipmi_si feature request: SMBIOS-based autoloading Andy Lutomirski <luto@amacapital.net> - 2016-01-26 18:30 +0100

#1316158 — ipmi_si feature request: SMBIOS-based autoloading

ipmi_si doesn't autoload on systems where it's found via SMBIOS.
Could that be fixed?

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.)

Alternatively, maybe /sys/firmware/dmi could learn how to advertise
modaliases.  But that might be a giant mess to solve a tiny problem.

--Andy

[toc] | [next] | [standalone]

#1317974

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.

> 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.

> 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.

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?

-corey

[toc] | [prev] | [next] | [standalone]

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

Actually, there is some cleanup that has to occur here, let me look at 
this a little bit.

-corey

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.
>
>> 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.
>
>> 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.
>
> 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?
>
> -corey
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Openipmi-developer mailing list
> Openipmi-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[toc] | [prev] | [next] | [standalone]

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

On Tue, Jan 26, 2016 at 5:43 AM, Corey Minyard <minyard@acm.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.

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

>>
>>> 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web