From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753934AbcCYShI (ORCPT ); Fri, 25 Mar 2016 14:37:08 -0400 Received: from mail-ob0-f196.google.com ([209.85.214.196]:35224 "EHLO mail-ob0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753207AbcCYShF (ORCPT ); Fri, 25 Mar 2016 14:37:05 -0400 Reply-To: minyard@acm.org Subject: Re: [PATCH v2 0/5] dmi: Rework to get IPMI autoloading from DMI tables References: <1454520622-22148-1-git-send-email-minyard@acm.org> Cc: Andy Lutomirski , OpenIPMI Developers , linux-kernel To: Jean Delvare From: Corey Minyard Message-ID: <56F5854D.4060504@acm.org> Date: Fri, 25 Mar 2016 13:37:01 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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, 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 > > 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