All of lore.kernel.org
 help / color / mirror / Atom feed
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

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