On Fri, Jun 26, 2026 at 6:35 AM Corey Minyard <[email protected]> wrote: > > On Thu, Jun 25, 2026 at 05:59:54PM +0200, Michal Clapinski wrote: > > Added a new config option to allow offloading slow part of > > init_ipmi_si. Saves 100ms on my system. > > Are you loading as a module or building IPMI into the kernel?
Building in. I don't know much about IPMI but my system won't boot without it because it can't find the disk. I think some storage controllers need IPMI? > I'm thinking this is a good idea, but not quite done this way. > > I have another long-standing issue that if a BMC is not operational when > the system comes up, it will not continue to try to bring it up, so > you have to reboot or hotmod the device in when it becomes available. > > I'm thinking that instead of pushing off the whole process, push off > just the individual calls to try_smi_init(). I'm assuming that's where > all the time is spent at init. I can implement it this way in v2. > So with that it would be possible to periodically retry a BMC until > it eventually comes up. > > Plus, that way the "unload_when_empty" function won't be broken with > this feature. > > I am also not quite sure what will happen if you try to unload the > module if things are pushed off in a startup state like this. > > I'm also not quite sure how this will affect the ACPI IPMI functions in > the kernel. I would guess it's ok, since it registers to know when the > interface becomes available, but it might be delayed a bit which might > confuse things. Also, it might delay the driver being available til > later at startup, which may confuse userland users. > > I'm also wondering if making this an option makes sense, or if this > should be the way it always works. An option might be nice if it broke > things, I guess. But almost everyone uses modules, and that will be > delayed from boot, anyway. I guess that means ACPI is not an issue, > either. Since my system won't boot without IPMI, it would probably also fail the same way if IPMI was still initializing so I didn't want to break unsuspecting users. In reality it probably wouldn't happen often since IPMI initialization is fast enough to finish before the rest of the kernel. > Just kind of pondering this right now. > > -corey > > > > > Signed-off-by: Michal Clapinski <[email protected]> > > --- > > drivers/char/ipmi/Kconfig | 8 ++++++ > > drivers/char/ipmi/ipmi_si_intf.c | 48 +++++++++++++++++++++----------- > > 2 files changed, 40 insertions(+), 16 deletions(-) > > > > diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig > > index 669f76000197..8419409dc3b9 100644 > > --- a/drivers/char/ipmi/Kconfig > > +++ b/drivers/char/ipmi/Kconfig > > @@ -67,6 +67,14 @@ config IPMI_SI > > Currently, only KCS and SMIC are supported. If > > you are using IPMI, you should probably say "y" here. > > > > +config IPMI_SI_ASYNC_INIT > > + bool 'Asynchronous initialization of IPMI System Interface' > > + depends on IPMI_SI > > + default n > > + help > > + Enables asynchronous init of the IPMI System Interface. > > + It speeds up the boot time. > > + > > config IPMI_SSIF > > tristate 'IPMI SMBus handler (SSIF)' > > depends on I2C > > diff --git a/drivers/char/ipmi/ipmi_si_intf.c > > b/drivers/char/ipmi/ipmi_si_intf.c > > index 9a9d12be9bf7..3e422c7df60a 100644 > > --- a/drivers/char/ipmi/ipmi_si_intf.c > > +++ b/drivers/char/ipmi/ipmi_si_intf.c > > @@ -39,6 +39,7 @@ > > #include <linux/rcupdate.h> > > #include <linux/ipmi.h> > > #include <linux/ipmi_smi.h> > > +#include <linux/async.h> > > #include "ipmi_si.h" > > #include "ipmi_si_sm.h" > > #include <linux/string.h> > > @@ -2174,25 +2175,10 @@ static bool __init ipmi_smi_info_same(struct > > smi_info *e1, struct smi_info *e2) > > e1->io.addr_data == e2->io.addr_data); > > } > > > > -static int __init init_ipmi_si(void) > > +static int __init smi_init_scan(void) > > { > > struct smi_info *e, *e2; > > > > - if (initialized) > > - return 0; > > - > > - ipmi_hardcode_init(); > > - > > - pr_info("IPMI System Interface driver\n"); > > - > > - ipmi_si_platform_init(); > > - > > - ipmi_si_pci_init(); > > - > > - ipmi_si_ls2k_init(); > > - > > - ipmi_si_parisc_init(); > > - > > mutex_lock(&smi_infos_lock); > > > > /* > > @@ -2271,6 +2257,36 @@ static int __init init_ipmi_si(void) > > return 0; > > } > > } > > + > > +static void __init async_smi_init(void *data, async_cookie_t cookie) > > +{ > > + smi_init_scan(); > > +} > > + > > +static int __init init_ipmi_si(void) > > +{ > > + if (initialized) > > + return 0; > > + > > + ipmi_hardcode_init(); > > + > > + pr_info("IPMI System Interface driver\n"); > > + > > + ipmi_si_platform_init(); > > + > > + ipmi_si_pci_init(); > > + > > + ipmi_si_ls2k_init(); > > + > > + ipmi_si_parisc_init(); > > + > > + if (IS_ENABLED(CONFIG_IPMI_SI_ASYNC_INIT)) { > > + async_schedule(async_smi_init, NULL); > > + return 0; > > + } > > + > > + return smi_init_scan(); > > +} > > module_init(init_ipmi_si); > > > > static void wait_msg_processed(struct smi_info *smi_info) > > -- > > 2.55.0.rc0.799.gd6f94ed593-goog > > _______________________________________________ Openipmi-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
