mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hans de Goede <johannes.goede@oss.qualcomm.com>
To: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>,
	Sudeep Holla <sudeep.holla@kernel.org>,
	Cristian Marussi <cristian.marussi@arm.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Nicolas Schier <nsc@kernel.org>
Cc: arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org
Subject: Re: [PATCH 2/2] firmware: arm_scmi: request modules for discovered protocols
Date: Tue, 16 Jun 2026 21:53:25 +0200	[thread overview]
Message-ID: <2d863db7-afad-4413-96db-7a1befca62d6@oss.qualcomm.com> (raw)
In-Reply-To: <20260616-scmi-modalias-v1-2-662b8dd52ab2@oss.qualcomm.com>

Hi,

On 16-Jun-26 20:09, Bjorn Andersson wrote:
> SCMI client devices are created from SCMI driver id tables. If such a
> driver is modular, the core does not know the driver's client name until
> the module has already loaded, so normal device uevent based autoloading
> cannot break the dependency cycle.
> 
> Emit a protocol-level alias for each SCMI device id table entry and
> request that alias when the SCMI core discovers an implemented protocol.
> This loads modules that have registered interest in the protocol; their
> normal SCMI driver registration then requests the concrete client device
> and the SCMI bus matches it by protocol and name.
> 
> This allows e.g. ARM_SCMI_CPUFREQ=m to autoload on systems that expose
> only the SCMI Performance protocol node, where the cpufreq client name
> is Linux-internal and not available from firmware before loading the
> module.
> 
> Assisted-by: Codex:GPT-5.5
> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
> ---
>  drivers/firmware/arm_scmi/driver.c | 2 ++
>  include/linux/mod_devicetable.h    | 1 +
>  scripts/mod/file2alias.c           | 4 +++-
>  3 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index 3e0d975ec94c..8538eedc7c3a 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -47,6 +47,7 @@
>  #include <trace/events/scmi.h>
>  
>  #define SCMI_VENDOR_MODULE_ALIAS_FMT	"scmi-protocol-0x%02x-%s"
> +#define SCMI_MODULE_ALIAS_FMT		SCMI_PROTOCOL_MODULE_PREFIX "0x%02x"
>  
>  static DEFINE_IDA(scmi_id);
>  
> @@ -3362,6 +3363,7 @@ static int scmi_probe(struct platform_device *pdev)
>  		}
>  
>  		of_node_get(child);
> +		request_module(SCMI_MODULE_ALIAS_FMT, prot_id);

I think it would be better to use request_module_nowait() here. AFAICT there
is no need to synchronously wait here for the module to actually get loaded.

Either way the patch looks good to me:

Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>

Regards,

Hans






 


>  		scmi_create_protocol_devices(child, info, prot_id, NULL);
>  	}
>  
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index 769382f2eadd..2cc7e78e35a3 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -477,6 +477,7 @@ struct rpmsg_device_id {
>  
>  #define SCMI_NAME_SIZE		32
>  #define SCMI_MODULE_PREFIX	"scmi:"
> +#define SCMI_PROTOCOL_MODULE_PREFIX	"scmi-protocol-"
>  
>  struct scmi_device_id {
>  	__u8 protocol_id;
> diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
> index a5283f4c8e6f..40a37b6bf1ad 100644
> --- a/scripts/mod/file2alias.c
> +++ b/scripts/mod/file2alias.c
> @@ -852,7 +852,7 @@ static void do_rpmsg_entry(struct module *mod, void *symval)
>  	module_alias_printf(mod, false, RPMSG_DEVICE_MODALIAS_FMT, *name);
>  }
>  
> -/* Looks like: scmi:NN:S */
> +/* Looks like: scmi:NN:S and scmi-protocol-0xNN */
>  static void do_scmi_entry(struct module *mod, void *symval)
>  {
>  	DEF_FIELD(symval, scmi_device_id, protocol_id);
> @@ -860,6 +860,8 @@ static void do_scmi_entry(struct module *mod, void *symval)
>  
>  	module_alias_printf(mod, false, SCMI_MODULE_PREFIX "%02x:%s",
>  			    protocol_id, *name);
> +	module_alias_printf(mod, false, SCMI_PROTOCOL_MODULE_PREFIX "0x%02x",
> +			    protocol_id);
>  }
>  
>  /* Looks like: i2c:S */
> 


      reply	other threads:[~2026-06-16 19:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-16 18:09 [PATCH 0/2] firmware: arm_scmi: Ensure automatic module loading Bjorn Andersson
2026-06-16 18:09 ` [PATCH 1/2] module: add SCMI device table alias support Bjorn Andersson
2026-06-16 19:49   ` Hans de Goede
2026-06-16 18:09 ` [PATCH 2/2] firmware: arm_scmi: request modules for discovered protocols Bjorn Andersson
2026-06-16 19:53   ` Hans de Goede [this message]

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=2d863db7-afad-4413-96db-7a1befca62d6@oss.qualcomm.com \
    --to=johannes.goede@oss.qualcomm.com \
    --cc=arm-scmi@vger.kernel.org \
    --cc=bjorn.andersson@oss.qualcomm.com \
    --cc=cristian.marussi@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=nsc@kernel.org \
    --cc=sudeep.holla@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®