linux-kernel - Re: [PATCH v2 0/5] dmi: Rework to get IPMI autoloading from DMI tables

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 25 Mar 2016 13:37:01 -0500
From:	Corey Minyard <minyard@....org>
To:	Jean Delvare <jdelvare@...e.de>
Cc:	Andy Lutomirski <luto@...nel.org>,
	OpenIPMI Developers <openipmi-developer@...ts.sourceforge.net>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/5] dmi: Rework to get IPMI autoloading from DMI
 tables

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