* ipmi_si feature request: SMBIOS-based autoloading @ 2016-01-25 1:45 Andy Lutomirski 2016-01-26 13:32 ` Corey Minyard 0 siblings, 1 reply; 6+ messages in thread From: Andy Lutomirski @ 2016-01-25 1:45 UTC (permalink / raw) To: Corey Minyard, OpenIPMI Developers, linux-kernel, brijeshkumar.singh, Jean Delvare ipmi_si doesn't autoload on systems where it's found via SMBIOS. Could that be fixed? If I were doing it, I'd suggest rigging up some code that's compiled in to the main kernel even if ipmi_si is a module that creates the platform device if the dmi device is there and then set up a modalias so that the platofrm device causes ipmi_si to load. (In general, having the same driver create the platform device and register the platform driver means that autoloading is unlikely to work right. See arch/x86/kernel/pmem.c for an example of a weird legacy device that gets this right.) Alternatively, maybe /sys/firmware/dmi could learn how to advertise modaliases. But that might be a giant mess to solve a tiny problem. --Andy ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ipmi_si feature request: SMBIOS-based autoloading 2016-01-25 1:45 ipmi_si feature request: SMBIOS-based autoloading Andy Lutomirski @ 2016-01-26 13:32 ` Corey Minyard 2016-01-26 13:43 ` [Openipmi-developer] " Corey Minyard 0 siblings, 1 reply; 6+ messages in thread From: Corey Minyard @ 2016-01-26 13:32 UTC (permalink / raw) To: Andy Lutomirski, OpenIPMI Developers, linux-kernel, brijeshkumar.singh, Jean Delvare On 01/24/2016 07:45 PM, Andy Lutomirski wrote: > ipmi_si doesn't autoload on systems where it's found via SMBIOS. > Could that be fixed? I'm not really sure. I kind of assumed this was handled in userland like the ACPI tables. I don't think there are many systems that have SMBIOS and not ACPI, so I'm not sure of the impact here or what to do. > If I were doing it, I'd suggest rigging up some code that's compiled > in to the main kernel even if ipmi_si is a module that creates the > platform device if the dmi device is there and then set up a modalias > so that the platofrm device causes ipmi_si to load. > > (In general, having the same driver create the platform device and > register the platform driver means that autoloading is unlikely to > work right. See arch/x86/kernel/pmem.c for an example of a weird > legacy device that gets this right.) This sounds like kind of a hack. > Alternatively, maybe /sys/firmware/dmi could learn how to advertise > modaliases. But that might be a giant mess to solve a tiny problem. This sounds like the right way, but you are probably right. Are there any other resources that could benefit from this? I"m guessing not. There is already a "dmi_save_ipmi_device" function that gets called when scanning the SMBIOS table (see drivers/firmware/dmi_scan.c). Maybe a tie-in there? That happens pretty early, though, I'm not sure if it's too early. Of course it would be easy to have a file like pmem.c that detects if an IPMI device is in the SMBIOS table and create a platform device for it. Are you willing to do this work? -corey ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Openipmi-developer] ipmi_si feature request: SMBIOS-based autoloading 2016-01-26 13:32 ` Corey Minyard @ 2016-01-26 13:43 ` Corey Minyard 2016-01-26 17:29 ` Andy Lutomirski 0 siblings, 1 reply; 6+ messages in thread From: Corey Minyard @ 2016-01-26 13:43 UTC (permalink / raw) To: Andy Lutomirski, OpenIPMI Developers, linux-kernel, brijeshkumar.singh, Jean Delvare Actually, there is some cleanup that has to occur here, let me look at this a little bit. -corey On 01/26/2016 07:32 AM, Corey Minyard wrote: > On 01/24/2016 07:45 PM, Andy Lutomirski wrote: >> ipmi_si doesn't autoload on systems where it's found via SMBIOS. >> Could that be fixed? > I'm not really sure. I kind of assumed this was handled in userland > like the ACPI tables. I don't think there are many systems that have > SMBIOS and not ACPI, so I'm not sure of the impact here or what > to do. > >> If I were doing it, I'd suggest rigging up some code that's compiled >> in to the main kernel even if ipmi_si is a module that creates the >> platform device if the dmi device is there and then set up a modalias >> so that the platofrm device causes ipmi_si to load. >> >> (In general, having the same driver create the platform device and >> register the platform driver means that autoloading is unlikely to >> work right. See arch/x86/kernel/pmem.c for an example of a weird >> legacy device that gets this right.) > This sounds like kind of a hack. > >> Alternatively, maybe /sys/firmware/dmi could learn how to advertise >> modaliases. But that might be a giant mess to solve a tiny problem. > This sounds like the right way, but you are probably right. Are > there any other resources that could benefit from this? I"m > guessing not. > > There is already a "dmi_save_ipmi_device" function that gets called > when scanning the SMBIOS table (see drivers/firmware/dmi_scan.c). > Maybe a tie-in there? That happens pretty early, though, I'm not > sure if it's too early. > > Of course it would be easy to have a file like pmem.c that detects > if an IPMI device is in the SMBIOS table and create a platform > device for it. > > Are you willing to do this work? > > -corey > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Openipmi-developer mailing list > Openipmi-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openipmi-developer ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Openipmi-developer] ipmi_si feature request: SMBIOS-based autoloading 2016-01-26 13:43 ` [Openipmi-developer] " Corey Minyard @ 2016-01-26 17:29 ` Andy Lutomirski 2016-01-29 20:12 ` Corey Minyard 2016-02-01 8:46 ` Jean Delvare 0 siblings, 2 replies; 6+ messages in thread From: Andy Lutomirski @ 2016-01-26 17:29 UTC (permalink / raw) To: Corey Minyard Cc: Andy Lutomirski, OpenIPMI Developers, linux-kernel, brijeshkumar.singh, Jean Delvare On Tue, Jan 26, 2016 at 5:43 AM, Corey Minyard <minyard@acm.org> wrote: > > On 01/26/2016 07:32 AM, Corey Minyard wrote: >> >> On 01/24/2016 07:45 PM, Andy Lutomirski wrote: >>> >>> ipmi_si doesn't autoload on systems where it's found via SMBIOS. >>> Could that be fixed? >> >> I'm not really sure. I kind of assumed this was handled in userland >> like the ACPI tables. I don't think there are many systems that have >> SMBIOS and not ACPI, so I'm not sure of the impact here or what >> to do. I've never seen it handled in userland adequately on Fedora, Ubuntu, or CentOS. FWIW, it might pay to have ipmi_si pull in ipmi_devintf as well. Then ipmitool would work out of the box. >> >>> If I were doing it, I'd suggest rigging up some code that's compiled >>> in to the main kernel even if ipmi_si is a module that creates the >>> platform device if the dmi device is there and then set up a modalias >>> so that the platofrm device causes ipmi_si to load. >>> >>> (In general, having the same driver create the platform device and >>> register the platform driver means that autoloading is unlikely to >>> work right. See arch/x86/kernel/pmem.c for an example of a weird >>> legacy device that gets this right.) >> >> This sounds like kind of a hack. It's a bit of a hack in that case. It does preserve the general driver model approach where a lower-level thing enumerates the system and instantiates devices and then a higher-level driver binds to the devices. >> >>> Alternatively, maybe /sys/firmware/dmi could learn how to advertise >>> modaliases. But that might be a giant mess to solve a tiny problem. >> >> This sounds like the right way, but you are probably right. Are >> there any other resources that could benefit from this? I"m >> guessing not. No clue. Jean might know. Jean? >> >> There is already a "dmi_save_ipmi_device" function that gets called >> when scanning the SMBIOS table (see drivers/firmware/dmi_scan.c). >> Maybe a tie-in there? That happens pretty early, though, I'm not >> sure if it's too early. >> >> Of course it would be easy to have a file like pmem.c that detects >> if an IPMI device is in the SMBIOS table and create a platform >> device for it. >> >> Are you willing to do this work? I'm willing to do some plumbing, but I'm not sure I want to dig deeply into the innards of ipmi_si initialization. >> >> -corey >> > Actually, there is some cleanup that has to occur here, let me look at this > a little bit. It looks like the driver currently decides how to talk to the hardware and then instantiates the platform device. For my approach to work, it would have to be refactored a bit: instantiate the platform device with the info about how to talk to hardware and then have the platform driver fish that info back out of the platform device. Is that what you're talking about? I also don't understand the distinction between ipmi_si and ipmi_bmc. --Andy ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Openipmi-developer] ipmi_si feature request: SMBIOS-based autoloading 2016-01-26 17:29 ` Andy Lutomirski @ 2016-01-29 20:12 ` Corey Minyard 2016-02-01 8:46 ` Jean Delvare 1 sibling, 0 replies; 6+ messages in thread From: Corey Minyard @ 2016-01-29 20:12 UTC (permalink / raw) To: Andy Lutomirski Cc: Andy Lutomirski, OpenIPMI Developers, linux-kernel, brijeshkumar.singh, Jean Delvare On 01/26/2016 11:29 AM, Andy Lutomirski wrote: > On Tue, Jan 26, 2016 at 5:43 AM, Corey Minyard <minyard@acm.org> wrote: >> On 01/26/2016 07:32 AM, Corey Minyard wrote: >>> On 01/24/2016 07:45 PM, Andy Lutomirski wrote: >>>> ipmi_si doesn't autoload on systems where it's found via SMBIOS. >>>> Could that be fixed? >>> I'm not really sure. I kind of assumed this was handled in userland >>> like the ACPI tables. I don't think there are many systems that have >>> SMBIOS and not ACPI, so I'm not sure of the impact here or what >>> to do. > I've never seen it handled in userland adequately on Fedora, Ubuntu, or CentOS. Well, that was much harder than I expected. There's not much there for handling DMI devices, so I added some basic infrastructure to do this. I looked at some other methods, but they were really hacks. Expect some patches on this soon. > > FWIW, it might pay to have ipmi_si pull in ipmi_devintf as well. Then > ipmitool would work out of the box. Yeah, I've gotten enough complaints on this, I'll go ahead and do it. I tried adding MODULE_SOFTDEP, but that doesn't seem to work out of the box. So I need to figure out the best way to do this. -corey >>>> If I were doing it, I'd suggest rigging up some code that's compiled >>>> in to the main kernel even if ipmi_si is a module that creates the >>>> platform device if the dmi device is there and then set up a modalias >>>> so that the platofrm device causes ipmi_si to load. >>>> >>>> (In general, having the same driver create the platform device and >>>> register the platform driver means that autoloading is unlikely to >>>> work right. See arch/x86/kernel/pmem.c for an example of a weird >>>> legacy device that gets this right.) >>> This sounds like kind of a hack. > It's a bit of a hack in that case. It does preserve the general > driver model approach where a lower-level thing enumerates the system > and instantiates devices and then a higher-level driver binds to the > devices. > >>>> Alternatively, maybe /sys/firmware/dmi could learn how to advertise >>>> modaliases. But that might be a giant mess to solve a tiny problem. >>> This sounds like the right way, but you are probably right. Are >>> there any other resources that could benefit from this? I"m >>> guessing not. > No clue. Jean might know. Jean? > >>> There is already a "dmi_save_ipmi_device" function that gets called >>> when scanning the SMBIOS table (see drivers/firmware/dmi_scan.c). >>> Maybe a tie-in there? That happens pretty early, though, I'm not >>> sure if it's too early. >>> >>> Of course it would be easy to have a file like pmem.c that detects >>> if an IPMI device is in the SMBIOS table and create a platform >>> device for it. >>> >>> Are you willing to do this work? > I'm willing to do some plumbing, but I'm not sure I want to dig deeply > into the innards of ipmi_si initialization. > >>> -corey >>> >> Actually, there is some cleanup that has to occur here, let me look at this >> a little bit. > It looks like the driver currently decides how to talk to the hardware > and then instantiates the platform device. For my approach to work, > it would have to be refactored a bit: instantiate the platform device > with the info about how to talk to hardware and then have the platform > driver fish that info back out of the platform device. Is that what > you're talking about? > > I also don't understand the distinction between ipmi_si and ipmi_bmc. > > --Andy ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Openipmi-developer] ipmi_si feature request: SMBIOS-based autoloading 2016-01-26 17:29 ` Andy Lutomirski 2016-01-29 20:12 ` Corey Minyard @ 2016-02-01 8:46 ` Jean Delvare 1 sibling, 0 replies; 6+ messages in thread From: Jean Delvare @ 2016-02-01 8:46 UTC (permalink / raw) To: Andy Lutomirski Cc: Corey Minyard, Andy Lutomirski, OpenIPMI Developers, linux-kernel, brijeshkumar.singh Le Tuesday 26 January 2016 à 09:29 -0800, Andy Lutomirski a écrit : > On Tue, Jan 26, 2016 at 5:43 AM, Corey Minyard <minyard@acm.org> wrote: > > > > On 01/26/2016 07:32 AM, Corey Minyard wrote: > >> > >> On 01/24/2016 07:45 PM, Andy Lutomirski wrote: > >>> Alternatively, maybe /sys/firmware/dmi could learn how to advertise > >>> modaliases. But that might be a giant mess to solve a tiny problem. > >> > >> This sounds like the right way, but you are probably right. Are > >> there any other resources that could benefit from this? I"m > >> guessing not. > > No clue. Jean might know. Jean? In principle I agree it would be the right thing to do. Now in practice I'm afraid the interest would be limited, because 1* on so many occasions the DMI data is wrong and 2* the level of details that can be encoded in the DMI table data is fairly limited. The IPMI records may be an exception there because IPMI is only found on high-end hardware and this is where in general the DMI data is correct. But for most other records, you want to trust the hardware itself more than the DMI data. So you only want to rely on DMI data for information you can't get in any other way. That being said, advertising a modalias is something fairly safe. The driver getting loaded is free to use or not use the DMI data. And even if the only modalias in /sys/firmware/dmi is going to be for IPMI, I see no reason for not doing that, if it serves the purpose. -- Jean Delvare SUSE L3 Support ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-02-01 8:46 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-01-25 1:45 ipmi_si feature request: SMBIOS-based autoloading Andy Lutomirski 2016-01-26 13:32 ` Corey Minyard 2016-01-26 13:43 ` [Openipmi-developer] " Corey Minyard 2016-01-26 17:29 ` Andy Lutomirski 2016-01-29 20:12 ` Corey Minyard 2016-02-01 8:46 ` Jean Delvare
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.