From: Corey Minyard <minyard@acm.org>
To: Jean Delvare <jdelvare@suse.de>
Cc: Andy Lutomirski <luto@kernel.org>,
OpenIPMI Developers <openipmi-developer@lists.sourceforge.net>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/5] dmi: Rework to get IPMI autoloading from DMI tables
Date: Fri, 25 Mar 2016 13:37:01 -0500 [thread overview]
Message-ID: <56F5854D.4060504@acm.org> (raw)
In-Reply-To: <CALCETrUw+5+AWUqD5qmZns0JP8XQ8qQ8vZEdsg0Z1CqimosxVg@mail.gmail.com>
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
parent reply other threads:[~2016-03-25 18:37 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <CALCETrUw+5+AWUqD5qmZns0JP8XQ8qQ8vZEdsg0Z1CqimosxVg@mail.gmail.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56F5854D.4060504@acm.org \
--to=minyard@acm.org \
--cc=jdelvare@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=openipmi-developer@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox