* Re: [PATCH v2 0/5] dmi: Rework to get IPMI autoloading from DMI tables
[not found] ` <CALCETrUw+5+AWUqD5qmZns0JP8XQ8qQ8vZEdsg0Z1CqimosxVg@mail.gmail.com>
@ 2016-03-25 18:37 ` Corey Minyard
0 siblings, 0 replies; only message in thread
From: Corey Minyard @ 2016-03-25 18:37 UTC (permalink / raw)
To: Jean Delvare; +Cc: Andy Lutomirski, OpenIPMI Developers, linux-kernel
Jean, any status on this?
Thanks,
-corey
On 03/09/2016 10:23 PM, Andy Lutomirski wrote:
> On Wed, Feb 3, 2016 at 9:30 AM, <minyard@acm.org> 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.
>>
>> * 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 <luto@kernel.org>
>
> 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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2016-03-25 18:37 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1454520622-22148-1-git-send-email-minyard@acm.org>
[not found] ` <CALCETrUw+5+AWUqD5qmZns0JP8XQ8qQ8vZEdsg0Z1CqimosxVg@mail.gmail.com>
2016-03-25 18:37 ` [PATCH v2 0/5] dmi: Rework to get IPMI autoloading from DMI tables Corey Minyard
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.