From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF9D72D9780 for ; Fri, 26 Jun 2026 04:35:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782448523; cv=none; b=hp1HwnS/GW6CqAX1yozzWyxQXiVg4NmLkiBF+7Lc+TqSt79hIhzHReLWl4v4uE+6ZhyrH2MXxMQRUUV9GAnzjUoQgmhHxFbvY3grh1PL0d9fKT7G1QQZJyT9NXdbjH+FdDru4tWhBC5QzVnzurXBNHRIM2LNjdEKrAOjqzoY9aU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782448523; c=relaxed/simple; bh=diiXafOqbX0tmu/kz6GK5UMPQedP2Nlz3pt4B0KN+4Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Z23M+7jJKNfsSNq0rGFkOxgFsuq52QIw/J0ftcMsFIjcTCL5s3lPUlbmmlslaefXkHbqk+sYfw4ErAsWMB6YxN0O9knVLvGTYpKgIyYma2uEK0qlWW8KLpV5uVdlFsES7+OWqewTGHusxJWvMP4pXNh0wP7TwT/xvegvo9VnZwo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=minyard.net; spf=pass smtp.mailfrom=minyard.net; dkim=pass (2048-bit key) header.d=minyard.net header.i=@minyard.net header.b=Gjmha3EI; arc=none smtp.client-ip=209.85.210.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=minyard.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=minyard.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=minyard.net header.i=@minyard.net header.b="Gjmha3EI" Received: by mail-ot1-f49.google.com with SMTP id 46e09a7af769-7e6b5c374e5so444350a34.0 for ; Thu, 25 Jun 2026 21:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minyard.net; s=google; t=1782448521; x=1783053321; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=jdfyplQ9EasUEql6K476vKlCuj17zzX9nYS9dLlfSYc=; b=Gjmha3EI5oCCKn5GwDXp1c445ki68UEAu2L3Qxry+iYkhfLSbtBJtFvClr57iZI+YJ 6H63mf6D68TvxILCQ/Z0E5wpvCBIFe15rekrcijP6RISGcHMvaUNZxIuJnY+ZkoEu+Ba zHGOhxPXUByzSIdizno6cGVcwCj+lFJ5p5nWIJRzSlRbs4gvhuwV3pWs3+1oeQmzRco7 ADitqSc7N//AWnv1wGdtli3CtujO8kWPsOBrdk9Ce2gLZzBukA3txh5HTsXgLoSfBfVY SrsVl3lhEAkT2kVFn4aVbyECVr7p7KAEdHyN4j2xNgvKERyttB5VAnqFhKQM/ObAehKj u2AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782448521; x=1783053321; h=in-reply-to:content-disposition:mime-version:references:reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=jdfyplQ9EasUEql6K476vKlCuj17zzX9nYS9dLlfSYc=; b=P8Xuw82gwIBalQ+NEn0oYDqlY0fWWw00koSSHncT7ITb3b6w5V+o81rhtwNOt1ccJu 4KUJfZ/lL0WbXxhPRlb8fmr0vluJDYx5XJ6Blgi6DLqXoNNQP13v1mgaaZ56yGt3Ee2L rJCRm4xBqQrs8YBqsbKRz6uwYmlXHWHE2D4nbeZ0e7/i3hKG5uPUv/0epnbvuQyjouqA CwgXKBJHN3UedAeLqq4BW6i3+2PfURhAbYxlAK6L0V/ZwELNBscebrNq/UK5RpSc56Ic /5vY+o3JVIS7rUYU5H6UA3PvGE9YI/rnypKfbW99xMnujMunVmRzirgqoa+KBIYj4Cqq a29A== X-Forwarded-Encrypted: i=1; AFNElJ8JeKvO18fdEGbLIrGw+tuJoROoFbfBAxv808FS2Kxa8lURia8qOoFP/LyX0OSIDwVhglXpy/OyoYqEKAE=@vger.kernel.org X-Gm-Message-State: AOJu0Yw5fxMAsi3vtmFwkzAZRc9/NNr4aWe2Ahz69mxD028EJZIWhb2o neo088EVqd+cMkJxTOIS01W3X9UmiT13D3FESFaDF8XbInng2BDQwcaK+3t7ugwxFIJJtVMkVQ+ HgOp7 X-Gm-Gg: AfdE7cnCzq03wpwF1MMHUdErh3BNLDq1VgdiQef6kZYFaPcZEy3/WIWWqSS5hNQObwI rIXlHreYyqtaoL8Cq2efVR0TOBKvMi4J8XksAw6HGrETejOGZutk53f+0heiiiwpuB3Me9qAGVG RaF6e14TxZsNnMwfV+ELKdgYxR5kDXz8OKtwVOPeZX+5+qW/OcC63AwDGRqilw0gmOauCNp8MEv uzQEbuWJoIh4vK0x0qM6dEPauJUKaIKsWoHHyDjkt7k28Eoia3FtoTpoVzGU7aA02l29HabVAvv JIPzwDO360IRu5slm+ajrZpPslueOBKXm5VQtWKGpYF3JesAJ4IZsY1hv3GP/K8nXWyh5jAanAT uxv37e6vX+yg7PiIEeLhg/lz1/NqcknCZlmMSzR29J7PsRjR5I12+gcGRpbmIirHPHpHbXXGSom zPnff3AuULVCXL6nw9GrXEQLEYrxV5IeqHf7n9ho1FuWqAAjbpAKu8ByO/bbO9ozz9IqkW0wFsE LcAjaeNVgRM5GRX932+NP//aiDfrU8x0YdJYg== X-Received: by 2002:a05:6820:4df3:b0:694:85da:3f92 with SMTP id 006d021491bc7-6a1126b54d4mr9565146eaf.17.1782448520629; Thu, 25 Jun 2026 21:35:20 -0700 (PDT) Received: from mail.minyard.net ([2001:470:b8f6:1b:c047:37b0:eea4:3569]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-44778b6159fsm10879029fac.11.2026.06.25.21.35.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jun 2026 21:35:19 -0700 (PDT) Date: Thu, 25 Jun 2026 23:35:14 -0500 From: Corey Minyard To: Michal Clapinski Cc: openipmi-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ipmi:si: Add async init to ipmi_si Message-ID: Reply-To: corey@minyard.net References: <20260625155954.1948908-1-mclapinski@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260625155954.1948908-1-mclapinski@google.com> 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? 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. 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. Just kind of pondering this right now. -corey > > Signed-off-by: Michal Clapinski > --- > 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 > #include > #include > +#include > #include "ipmi_si.h" > #include "ipmi_si_sm.h" > #include > @@ -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 >