Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v8 1/4] coresight: cti: Convert trigger usage fields to dynamic bitmaps and arrays
From: Jie Gan @ 2026-04-27  2:47 UTC (permalink / raw)
  To: Yingchao Deng, Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
	Alexander Shishkin
  Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
	quic_yingdeng, Jinlong Mao, Tingwei Zhang
In-Reply-To: <1c99a162-475e-4d6c-af85-a16322d31476@oss.qualcomm.com>



On 4/27/2026 9:48 AM, Jie Gan wrote:
> 
> 
> On 4/26/2026 5:44 PM, Yingchao Deng wrote:
>> Replace the fixed-size u32 fields in the cti_config and cti_trig_grp
>> structure with dynamically allocated bitmaps and arrays. This allows
>> memory to be allocated based on the actual number of triggers during 
>> probe
>> time, reducing memory footprint and improving scalability for platforms
>> with varying trigger counts.
>>
>> Signed-off-by: Yingchao Deng <yingchao.deng@oss.qualcomm.com>
>> ---
>>   drivers/hwtracing/coresight/coresight-cti-core.c   | 59 ++++++++++++ 
>> +++++-----
>>   .../hwtracing/coresight/coresight-cti-platform.c   | 26 +++++++---
>>   drivers/hwtracing/coresight/coresight-cti-sysfs.c  | 14 ++---
>>   drivers/hwtracing/coresight/coresight-cti.h        | 12 ++---
>>   4 files changed, 76 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/ 
>> drivers/hwtracing/coresight/coresight-cti-core.c
>> index 2f4c9362709a..4e7d12bd2d3e 100644
>> --- a/drivers/hwtracing/coresight/coresight-cti-core.c
>> +++ b/drivers/hwtracing/coresight/coresight-cti-core.c
>> @@ -161,8 +161,8 @@ void cti_write_intack(struct device *dev, u32 ackval)
>>   /* DEVID[19:16] - number of CTM channels */
>>   #define CTI_DEVID_CTMCHANNELS(devid_val) ((int) BMVAL(devid_val, 16, 
>> 19))
>> -static void cti_set_default_config(struct device *dev,
>> -                   struct cti_drvdata *drvdata)
>> +static int cti_set_default_config(struct device *dev,
>> +                  struct cti_drvdata *drvdata)
>>   {
>>       struct cti_config *config = &drvdata->config;
>>       u32 devid;
>> @@ -181,6 +181,26 @@ static void cti_set_default_config(struct device 
>> *dev,
>>           config->nr_trig_max = CTIINOUTEN_MAX;
>>       }
>> +    config->trig_in_use = devm_bitmap_zalloc(dev, config- 
>> >nr_trig_max, GFP_KERNEL);
>> +    if (!config->trig_in_use)
>> +        return -ENOMEM;
>> +
>> +    config->trig_out_use = devm_bitmap_zalloc(dev, config- 
>> >nr_trig_max, GFP_KERNEL);
>> +    if (!config->trig_out_use)
>> +        return -ENOMEM;
>> +
>> +    config->trig_out_filter = devm_bitmap_zalloc(dev, config- 
>> >nr_trig_max, GFP_KERNEL);
>> +    if (!config->trig_out_filter)
>> +        return -ENOMEM;
>> +
>> +    config->ctiinen = devm_kcalloc(dev, config->nr_trig_max, 
>> sizeof(u32), GFP_KERNEL);
>> +    if (!config->ctiinen)
>> +        return -ENOMEM;
>> +
>> +    config->ctiouten = devm_kcalloc(dev, config->nr_trig_max, 
>> sizeof(u32), GFP_KERNEL);
>> +    if (!config->ctiouten)
>> +        return -ENOMEM;
>> +
>>       config->nr_ctm_channels = CTI_DEVID_CTMCHANNELS(devid);
>>       /* Most regs default to 0 as zalloc'ed except...*/
>> @@ -189,6 +209,7 @@ static void cti_set_default_config(struct device 
>> *dev,
>>       config->enable_req_count = 0;
>>       config->asicctl_impl = !!FIELD_GET(GENMASK(4, 0), devid);
>> +    return 0;
>>   }
>>   /*
>> @@ -219,8 +240,10 @@ int cti_add_connection_entry(struct device *dev, 
>> struct cti_drvdata *drvdata,
>>       cti_dev->nr_trig_con++;
>>       /* add connection usage bit info to overall info */
>> -    drvdata->config.trig_in_use |= tc->con_in->used_mask;
>> -    drvdata->config.trig_out_use |= tc->con_out->used_mask;
>> +    bitmap_or(drvdata->config.trig_in_use, drvdata->config.trig_in_use,
>> +          tc->con_in->used_mask, drvdata->config.nr_trig_max);
>> +    bitmap_or(drvdata->config.trig_out_use, drvdata- 
>> >config.trig_out_use,
>> +          tc->con_out->used_mask, drvdata->config.nr_trig_max);
>>       return 0;
>>   }
>> @@ -231,6 +254,8 @@ struct cti_trig_con *cti_allocate_trig_con(struct 
>> device *dev, int in_sigs,
>>   {
>>       struct cti_trig_con *tc = NULL;
>>       struct cti_trig_grp *in = NULL, *out = NULL;
>> +    struct cti_drvdata *drvdata = dev_get_drvdata(dev);
>> +    int n_trigs = drvdata->config.nr_trig_max;
>>       tc = devm_kzalloc(dev, sizeof(struct cti_trig_con), GFP_KERNEL);
>>       if (!tc)
>> @@ -242,12 +267,20 @@ struct cti_trig_con 
>> *cti_allocate_trig_con(struct device *dev, int in_sigs,
>>       if (!in)
>>           return NULL;
>> +    in->used_mask = devm_bitmap_zalloc(dev, n_trigs, GFP_KERNEL);
>> +    if (!in->used_mask)
>> +        return NULL;
>> +
>>       out = devm_kzalloc(dev,
>>                  offsetof(struct cti_trig_grp, sig_types[out_sigs]),
>>                  GFP_KERNEL);
>>       if (!out)
>>           return NULL;
>> +    out->used_mask = devm_bitmap_zalloc(dev, n_trigs, GFP_KERNEL);
>> +    if (!out->used_mask)
>> +        return NULL;
>> +
>>       tc->con_in = in;
>>       tc->con_out = out;
>>       tc->con_in->nr_sigs = in_sigs;
>> @@ -263,7 +296,6 @@ int cti_add_default_connection(struct device *dev, 
>> struct cti_drvdata *drvdata)
>>   {
>>       int ret = 0;
>>       int n_trigs = drvdata->config.nr_trig_max;
>> -    u32 n_trig_mask = GENMASK(n_trigs - 1, 0);
>>       struct cti_trig_con *tc = NULL;
>>       /*
>> @@ -274,8 +306,8 @@ int cti_add_default_connection(struct device *dev, 
>> struct cti_drvdata *drvdata)
>>       if (!tc)
>>           return -ENOMEM;
>> -    tc->con_in->used_mask = n_trig_mask;
>> -    tc->con_out->used_mask = n_trig_mask;
>> +    bitmap_fill(tc->con_in->used_mask, n_trigs);
>> +    bitmap_fill(tc->con_out->used_mask, n_trigs);
>>       ret = cti_add_connection_entry(dev, drvdata, tc, NULL, "default");
>>       return ret;
>>   }
>> @@ -288,7 +320,6 @@ int cti_channel_trig_op(struct device *dev, enum 
>> cti_chan_op op,
>>   {
>>       struct cti_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>       struct cti_config *config = &drvdata->config;
>> -    u32 trig_bitmask;
>>       u32 chan_bitmask;
>>       u32 reg_value;
>>       int reg_offset;
>> @@ -298,18 +329,16 @@ int cti_channel_trig_op(struct device *dev, enum 
>> cti_chan_op op,
>>          (trigger_idx >= config->nr_trig_max))
>>           return -EINVAL;
>> -    trig_bitmask = BIT(trigger_idx);
>> -
>>       /* ensure registered triggers and not out filtered */
>>       if (direction == CTI_TRIG_IN)    {
>> -        if (!(trig_bitmask & config->trig_in_use))
>> +        if (!(test_bit(trigger_idx, config->trig_in_use)))
>>               return -EINVAL;
>>       } else {
>> -        if (!(trig_bitmask & config->trig_out_use))
>> +        if (!(test_bit(trigger_idx, config->trig_out_use)))
>>               return -EINVAL;
>>           if ((config->trig_filter_enable) &&
>> -            (config->trig_out_filter & trig_bitmask))
>> +            test_bit(trigger_idx, config->trig_out_filter))
>>               return -EINVAL;
>>       }
>> @@ -687,7 +716,9 @@ static int cti_probe(struct amba_device *adev, 
>> const struct amba_id *id)
>>       raw_spin_lock_init(&drvdata->spinlock);
>>       /* initialise CTI driver config values */
>> -    cti_set_default_config(dev, drvdata);
>> +    ret = cti_set_default_config(dev, drvdata);
>> +    if (ret)
>> +        return ret;
>>       pdata = coresight_cti_get_platform_data(dev);
>>       if (IS_ERR(pdata)) {
>> diff --git a/drivers/hwtracing/coresight/coresight-cti-platform.c b/ 
>> drivers/hwtracing/coresight/coresight-cti-platform.c
>> index 4eff96f48594..557debbc8ca4 100644
>> --- a/drivers/hwtracing/coresight/coresight-cti-platform.c
>> +++ b/drivers/hwtracing/coresight/coresight-cti-platform.c
>> @@ -136,8 +136,8 @@ static int 
>> cti_plat_create_v8_etm_connection(struct device *dev,
>>           goto create_v8_etm_out;
>>       /* build connection data */
>> -    tc->con_in->used_mask = 0xF0; /* sigs <4,5,6,7> */
>> -    tc->con_out->used_mask = 0xF0; /* sigs <4,5,6,7> */
>> +    bitmap_set(tc->con_in->used_mask, 4, 4); /* sigs <4,5,6,7> */
>> +    bitmap_set(tc->con_out->used_mask, 4, 4); /* sigs <4,5,6,7> */
>>       /*
>>        * The EXTOUT type signals from the ETM are connected to a set 
>> of input
>> @@ -194,10 +194,10 @@ static int cti_plat_create_v8_connections(struct 
>> device *dev,
>>           goto of_create_v8_out;
>>       /* Set the v8 PE CTI connection data */
>> -    tc->con_in->used_mask = 0x3; /* sigs <0 1> */
>> +    bitmap_set(tc->con_in->used_mask, 0, 2); /* sigs <0 1> */
>>       tc->con_in->sig_types[0] = PE_DBGTRIGGER;
>>       tc->con_in->sig_types[1] = PE_PMUIRQ;
>> -    tc->con_out->used_mask = 0x7; /* sigs <0 1 2 > */
>> +    bitmap_set(tc->con_out->used_mask, 0, 3); /* sigs <0 1 2 > */
>>       tc->con_out->sig_types[0] = PE_EDBGREQ;
>>       tc->con_out->sig_types[1] = PE_DBGRESTART;
>>       tc->con_out->sig_types[2] = PE_CTIIRQ;
>> @@ -213,7 +213,7 @@ static int cti_plat_create_v8_connections(struct 
>> device *dev,
>>           goto of_create_v8_out;
>>       /* filter pe_edbgreq - PE trigout sig <0> */
>> -    drvdata->config.trig_out_filter |= 0x1;
>> +    set_bit(0, drvdata->config.trig_out_filter);
>>   of_create_v8_out:
>>       return ret;
>> @@ -257,7 +257,7 @@ static int cti_plat_read_trig_group(struct 
>> cti_trig_grp *tgrp,
>>       if (!err) {
>>           /* set the signal usage mask */
>>           for (idx = 0; idx < tgrp->nr_sigs; idx++)
>> -            tgrp->used_mask |= BIT(values[idx]);
>> +            set_bit(values[idx], tgrp->used_mask);
>>       }
>>       kfree(values);
>> @@ -316,23 +316,33 @@ static int cti_plat_process_filter_sigs(struct 
>> cti_drvdata *drvdata,
>>   {
>>       struct cti_trig_grp *tg = NULL;
>>       int err = 0, nr_filter_sigs;
>> +    int nr_trigs = drvdata->config.nr_trig_max;
>>       nr_filter_sigs = cti_plat_count_sig_elements(fwnode,
>>                                CTI_DT_FILTER_OUT_SIGS);
>>       if (nr_filter_sigs == 0)
>>           return 0;
>> -    if (nr_filter_sigs > drvdata->config.nr_trig_max)
>> +    if (nr_filter_sigs > nr_trigs)
>>           return -EINVAL;
>>       tg = kzalloc_obj(*tg);
>>       if (!tg)
>>           return -ENOMEM;
>> +    tg->used_mask = bitmap_zalloc(nr_trigs, GFP_KERNEL);
>> +    if (!tg->used_mask) {
>> +        kfree(tg);
>> +        return -ENOMEM;
>> +    }
>> +
>>       err = cti_plat_read_trig_group(tg, fwnode, CTI_DT_FILTER_OUT_SIGS);
>>       if (!err)
>> -        drvdata->config.trig_out_filter |= tg->used_mask;
>> +        bitmap_or(drvdata->config.trig_out_filter,
>> +              drvdata->config.trig_out_filter,
>> +              tg->used_mask, nr_trigs);
> 
> The error may be silently ignored when a memory allocation error 
> occured. I think it's better to add a log print to tell user what happened.

My fault here, please ignore this comment.
This error will be handled by probe fail process.

Thanks,
Jie


> 
> Thanks,
> Jie
> 
>> +    bitmap_free(tg->used_mask);
>>       kfree(tg);
>>       return err;
>>   }
>> diff --git a/drivers/hwtracing/coresight/coresight-cti-sysfs.c b/ 
>> drivers/hwtracing/coresight/coresight-cti-sysfs.c
>> index 3fe2c916d228..2bbfa405cb6b 100644
>> --- a/drivers/hwtracing/coresight/coresight-cti-sysfs.c
>> +++ b/drivers/hwtracing/coresight/coresight-cti-sysfs.c
>> @@ -719,12 +719,12 @@ static ssize_t trigout_filtered_show(struct 
>> device *dev,
>>       struct cti_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>       struct cti_config *cfg = &drvdata->config;
>>       int nr_trig_max = cfg->nr_trig_max;
>> -    unsigned long mask = cfg->trig_out_filter;
>> +    unsigned long *mask = cfg->trig_out_filter;
>> -    if (mask == 0)
>> +    if (bitmap_empty(mask, nr_trig_max))
>>           return 0;
>> -    return sysfs_emit(buf, "%*pbl\n", nr_trig_max, &mask);
>> +    return sysfs_emit(buf, "%*pbl\n", nr_trig_max, mask);
>>   }
>>   static DEVICE_ATTR_RO(trigout_filtered);
>> @@ -931,9 +931,9 @@ static ssize_t trigin_sig_show(struct device *dev,
>>       struct cti_trig_con *con = (struct cti_trig_con *)ext_attr->var;
>>       struct cti_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>       struct cti_config *cfg = &drvdata->config;
>> -    unsigned long mask = con->con_in->used_mask;
>> +    unsigned long *mask = con->con_in->used_mask;
>> -    return sysfs_emit(buf, "%*pbl\n", cfg->nr_trig_max, &mask);
>> +    return sysfs_emit(buf, "%*pbl\n", cfg->nr_trig_max, mask);
>>   }
>>   static ssize_t trigout_sig_show(struct device *dev,
>> @@ -945,9 +945,9 @@ static ssize_t trigout_sig_show(struct device *dev,
>>       struct cti_trig_con *con = (struct cti_trig_con *)ext_attr->var;
>>       struct cti_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>       struct cti_config *cfg = &drvdata->config;
>> -    unsigned long mask = con->con_out->used_mask;
>> +    unsigned long *mask = con->con_out->used_mask;
>> -    return sysfs_emit(buf, "%*pbl\n", cfg->nr_trig_max, &mask);
>> +    return sysfs_emit(buf, "%*pbl\n", cfg->nr_trig_max, mask);
>>   }
>>   /* convert a sig type id to a name */
>> diff --git a/drivers/hwtracing/coresight/coresight-cti.h b/drivers/ 
>> hwtracing/coresight/coresight-cti.h
>> index c5f9e79fabc6..ef079fc18b72 100644
>> --- a/drivers/hwtracing/coresight/coresight-cti.h
>> +++ b/drivers/hwtracing/coresight/coresight-cti.h
>> @@ -68,7 +68,7 @@ struct fwnode_handle;
>>    */
>>   struct cti_trig_grp {
>>       int nr_sigs;
>> -    u32 used_mask;
>> +    unsigned long *used_mask;
>>       int sig_types[];
>>   };
>> @@ -145,17 +145,17 @@ struct cti_config {
>>       int enable_req_count;
>>       /* registered triggers and filtering */
>> -    u32 trig_in_use;
>> -    u32 trig_out_use;
>> -    u32 trig_out_filter;
>> +    unsigned long *trig_in_use;
>> +    unsigned long *trig_out_use;
>> +    unsigned long *trig_out_filter;
>>       bool trig_filter_enable;
>>       u8 xtrig_rchan_sel;
>>       /* cti cross trig programmable regs */
>>       u32 ctiappset;
>>       u8 ctiinout_sel;
>> -    u32 ctiinen[CTIINOUTEN_MAX];
>> -    u32 ctiouten[CTIINOUTEN_MAX];
>> +    u32 *ctiinen;
>> +    u32 *ctiouten;
>>       u32 ctigate;
>>       u32 asicctl;
>>   };
>>
> 



^ permalink raw reply

* [PATCH v4 3/4] driver core: platform: set mod_name in driver registration
From: Shashank Balaji @ 2026-04-27  2:41 UTC (permalink / raw)
  To: Suzuki K Poulose, James Clark, Alexander Shishkin,
	Maxime Coquelin, Alexandre Torgue, Greg Kroah-Hartman,
	Rafael J. Wysocki, Danilo Krummrich, Miguel Ojeda, Boqun Feng,
	Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
	Alice Ryhl, Trevor Gross, Richard Cochran, Jonathan Corbet,
	Shuah Khan, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
	Sami Tolvanen, Aaron Tomlin, Mike Leach, Leo Yan, Mike Leach
  Cc: Rahul Bukte, Shashank Balaji, linux-kernel, coresight,
	linux-arm-kernel, driver-core, rust-for-linux, linux-doc,
	Daniel Palmer, Tim Bird, linux-modules
In-Reply-To: <20260427-acpi_mod_name-v4-0-22b42240c9bf@sony.com>

Pass KBUILD_MODNAME through the driver registration macro so that
the driver core can create the module symlink in sysfs for built-in
drivers, and fixup all callers.

The Rust platform adapter is updated to pass the module name through to the new
parameter.

Tested on qemu with:
- x86 defconfig + CONFIG_RUST
- arm64 defconfig + CONFIG_RUST + CONFIG_CORESIGHT stuff

Examples after this patch:

    /sys/bus/platform/drivers/...
        coresight-itnoc/module		-> coresight_tnoc
        coresight-static-tpdm/module	-> coresight_tpdm
        coresight-catu-platform/module	-> coresight_catu
        serial8250/module		-> 8250
        acpi-ged/module			-> acpi
        vmclock/module			-> ptp_vmclock

Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>

---

This patch depends on patches 1 and 2.
---
 drivers/base/platform.c                      | 21 ++++++++++++++-------
 drivers/hwtracing/coresight/coresight-core.c |  5 +++--
 include/linux/coresight.h                    |  5 +++--
 include/linux/platform_device.h              | 17 +++++++++--------
 rust/kernel/platform.rs                      |  4 +++-
 5 files changed, 32 insertions(+), 20 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 75b4698d0e58..2b0cc0889386 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -901,11 +901,14 @@ EXPORT_SYMBOL_GPL(platform_device_register_full);
  * __platform_driver_register - register a driver for platform-level devices
  * @drv: platform driver structure
  * @owner: owning module/driver
+ * @mod_name: module name string
  */
-int __platform_driver_register(struct platform_driver *drv, struct module *owner)
+int __platform_driver_register(struct platform_driver *drv, struct module *owner,
+			       const char *mod_name)
 {
 	drv->driver.owner = owner;
 	drv->driver.bus = &platform_bus_type;
+	drv->driver.mod_name = mod_name;
 
 	return driver_register(&drv->driver);
 }
@@ -938,6 +941,7 @@ static int is_bound_to_driver(struct device *dev, void *driver)
  * @drv: platform driver structure
  * @probe: the driver probe routine, probably from an __init section
  * @module: module which will be the owner of the driver
+ * @mod_name: module name string
  *
  * Use this instead of platform_driver_register() when you know the device
  * is not hotpluggable and has already been registered, and you want to
@@ -955,7 +959,8 @@ static int is_bound_to_driver(struct device *dev, void *driver)
  */
 int __init_or_module __platform_driver_probe(struct platform_driver *drv,
 					     int (*probe)(struct platform_device *),
-					     struct module *module)
+					     struct module *module,
+					     const char *mod_name)
 {
 	int retval;
 
@@ -983,7 +988,7 @@ int __init_or_module __platform_driver_probe(struct platform_driver *drv,
 
 	/* temporary section violation during probe() */
 	drv->probe = probe;
-	retval = __platform_driver_register(drv, module);
+	retval = __platform_driver_register(drv, module, mod_name);
 	if (retval)
 		return retval;
 
@@ -1011,6 +1016,7 @@ EXPORT_SYMBOL_GPL(__platform_driver_probe);
  * @data: platform specific data for this platform device
  * @size: size of platform specific data
  * @module: module which will be the owner of the driver
+ * @mod_name: module name string
  *
  * Use this in legacy-style modules that probe hardware directly and
  * register a single platform device and corresponding platform driver.
@@ -1021,7 +1027,7 @@ struct platform_device * __init_or_module
 __platform_create_bundle(struct platform_driver *driver,
 			 int (*probe)(struct platform_device *),
 			 struct resource *res, unsigned int n_res,
-			 const void *data, size_t size, struct module *module)
+			 const void *data, size_t size, struct module *module, const char *mod_name)
 {
 	struct platform_device *pdev;
 	int error;
@@ -1044,7 +1050,7 @@ __platform_create_bundle(struct platform_driver *driver,
 	if (error)
 		goto err_pdev_put;
 
-	error = __platform_driver_probe(driver, probe, module);
+	error = __platform_driver_probe(driver, probe, module, mod_name);
 	if (error)
 		goto err_pdev_del;
 
@@ -1064,6 +1070,7 @@ EXPORT_SYMBOL_GPL(__platform_create_bundle);
  * @drivers: an array of drivers to register
  * @count: the number of drivers to register
  * @owner: module owning the drivers
+ * @mod_name: module name string
  *
  * Registers platform drivers specified by an array. On failure to register a
  * driver, all previously registered drivers will be unregistered. Callers of
@@ -1073,7 +1080,7 @@ EXPORT_SYMBOL_GPL(__platform_create_bundle);
  * Returns: 0 on success or a negative error code on failure.
  */
 int __platform_register_drivers(struct platform_driver * const *drivers,
-				unsigned int count, struct module *owner)
+				unsigned int count, struct module *owner, const char *mod_name)
 {
 	unsigned int i;
 	int err;
@@ -1081,7 +1088,7 @@ int __platform_register_drivers(struct platform_driver * const *drivers,
 	for (i = 0; i < count; i++) {
 		pr_debug("registering platform driver %ps\n", drivers[i]);
 
-		err = __platform_driver_register(drivers[i], owner);
+		err = __platform_driver_register(drivers[i], owner, mod_name);
 		if (err < 0) {
 			pr_err("failed to register platform driver %ps: %d\n",
 			       drivers[i], err);
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 4ebcbd95b7fb..9c4fdef76833 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -1695,7 +1695,8 @@ module_init(coresight_init);
 module_exit(coresight_exit);
 
 int __coresight_init_driver(const char *drv, struct amba_driver *amba_drv,
-			  struct platform_driver *pdev_drv, struct module *owner)
+			  struct platform_driver *pdev_drv, struct module *owner,
+			  const char *mod_name)
 {
 	int ret;
 
@@ -1705,7 +1706,7 @@ int __coresight_init_driver(const char *drv, struct amba_driver *amba_drv,
 		return ret;
 	}
 
-	ret = __platform_driver_register(pdev_drv, owner);
+	ret = __platform_driver_register(pdev_drv, owner, mod_name);
 	if (!ret)
 		return 0;
 
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index b9ec5f195907..d7ae0527d039 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -692,9 +692,10 @@ coresight_find_output_type(struct coresight_platform_data *pdata,
 			   union coresight_dev_subtype subtype);
 
 #define coresight_init_driver(drv, amba_drv, pdev_drv) \
-	__coresight_init_driver(drv, amba_drv, pdev_drv, THIS_MODULE)
+	__coresight_init_driver(drv, amba_drv, pdev_drv, THIS_MODULE, KBUILD_MODNAME)
 int __coresight_init_driver(const char *drv, struct amba_driver *amba_drv,
-			  struct platform_driver *pdev_drv, struct module *owner);
+			  struct platform_driver *pdev_drv, struct module *owner,
+			  const char *mod_name);
 
 void coresight_remove_driver(struct amba_driver *amba_drv,
 			     struct platform_driver *pdev_drv);
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 975400a472e3..26e6a43358e2 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -293,18 +293,19 @@ struct platform_driver {
  * use a macro to avoid include chaining to get THIS_MODULE
  */
 #define platform_driver_register(drv) \
-	__platform_driver_register(drv, THIS_MODULE)
+	__platform_driver_register(drv, THIS_MODULE, KBUILD_MODNAME)
 extern int __platform_driver_register(struct platform_driver *,
-					struct module *);
+					struct module *, const char *mod_name);
 extern void platform_driver_unregister(struct platform_driver *);
 
 /* non-hotpluggable platform devices may use this so that probe() and
  * its support may live in __init sections, conserving runtime memory.
  */
 #define platform_driver_probe(drv, probe) \
-	__platform_driver_probe(drv, probe, THIS_MODULE)
+	__platform_driver_probe(drv, probe, THIS_MODULE, KBUILD_MODNAME)
 extern int __platform_driver_probe(struct platform_driver *driver,
-		int (*probe)(struct platform_device *), struct module *module);
+		int (*probe)(struct platform_device *), struct module *module,
+		const char *mod_name);
 
 static inline void *platform_get_drvdata(const struct platform_device *pdev)
 {
@@ -368,19 +369,19 @@ static int __init __platform_driver##_init(void) \
 device_initcall(__platform_driver##_init); \
 
 #define platform_create_bundle(driver, probe, res, n_res, data, size) \
-	__platform_create_bundle(driver, probe, res, n_res, data, size, THIS_MODULE)
+	__platform_create_bundle(driver, probe, res, n_res, data, size, THIS_MODULE, KBUILD_MODNAME)
 extern struct platform_device *__platform_create_bundle(
 	struct platform_driver *driver, int (*probe)(struct platform_device *),
 	struct resource *res, unsigned int n_res,
-	const void *data, size_t size, struct module *module);
+	const void *data, size_t size, struct module *module, const char *mod_name);
 
 int __platform_register_drivers(struct platform_driver * const *drivers,
-				unsigned int count, struct module *owner);
+				unsigned int count, struct module *owner, const char *mod_name);
 void platform_unregister_drivers(struct platform_driver * const *drivers,
 				 unsigned int count);
 
 #define platform_register_drivers(drivers, count) \
-	__platform_register_drivers(drivers, count, THIS_MODULE)
+	__platform_register_drivers(drivers, count, THIS_MODULE, KBUILD_MODNAME)
 
 #ifdef CONFIG_SUSPEND
 extern int platform_pm_suspend(struct device *dev);
diff --git a/rust/kernel/platform.rs b/rust/kernel/platform.rs
index 8917d4ee499f..2d626eecc450 100644
--- a/rust/kernel/platform.rs
+++ b/rust/kernel/platform.rs
@@ -82,7 +82,9 @@ unsafe fn register(
         }
 
         // SAFETY: `pdrv` is guaranteed to be a valid `DriverType`.
-        to_result(unsafe { bindings::__platform_driver_register(pdrv.get(), module.0) })
+        to_result(unsafe {
+            bindings::__platform_driver_register(pdrv.get(), module.0, name.as_char_ptr())
+        })
     }
 
     unsafe fn unregister(pdrv: &Opaque<Self::DriverType>) {

-- 
2.43.0



^ permalink raw reply related

* [PATCH v4 1/4] kernel: param: initialize module_kset before do_initcalls()
From: Shashank Balaji @ 2026-04-27  2:41 UTC (permalink / raw)
  To: Suzuki K Poulose, James Clark, Alexander Shishkin,
	Maxime Coquelin, Alexandre Torgue, Greg Kroah-Hartman,
	Rafael J. Wysocki, Danilo Krummrich, Miguel Ojeda, Boqun Feng,
	Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
	Alice Ryhl, Trevor Gross, Richard Cochran, Jonathan Corbet,
	Shuah Khan, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
	Sami Tolvanen, Aaron Tomlin, Mike Leach, Leo Yan, Mike Leach
  Cc: Rahul Bukte, Shashank Balaji, linux-kernel, coresight,
	linux-arm-kernel, driver-core, rust-for-linux, linux-doc,
	Daniel Palmer, Tim Bird, linux-modules
In-Reply-To: <20260427-acpi_mod_name-v4-0-22b42240c9bf@sony.com>

module_kset is initialized in param_sysfs_init(), a subsys_initcall. A number
of platform drivers register themselves prior to subsys_initcalls
(tegra194_cbb_driver registers in a pure_initcall, for example). With an
upcoming patch ("driver core: platform: set mod_name in driver registration")
that sets their mod_name in struct device_driver, lookup_or_create_module_kobject()
will be called for those drivers, which calls kset_find_obj(module_kset, mod_name).
This causes a null deref because module_kset isn't alive yet.

Fix this by initializing module_kset in do_basic_setup() before do_initcalls().
Modernize the pr_warn while we're at it.

Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suggested-by: Gary Guo <gary@garyguo.net>
Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
---
 include/linux/module.h |  4 ++++
 init/main.c            |  1 +
 kernel/params.c        | 21 +++++++++------------
 3 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/include/linux/module.h b/include/linux/module.h
index 7566815fabbe..6478596e8f9f 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -886,6 +886,10 @@ static inline void module_for_each_mod(int(*func)(struct module *mod, void *data
 #ifdef CONFIG_SYSFS
 extern struct kset *module_kset;
 extern const struct kobj_type module_ktype;
+
+void param_sysfs_init(void);
+#else
+static inline void param_sysfs_init(void) {}
 #endif /* CONFIG_SYSFS */
 
 #define symbol_request(x) try_then_request_module(symbol_get(x), "symbol:" #x)
diff --git a/init/main.c b/init/main.c
index 96f93bb06c49..01552c6b62ff 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1486,6 +1486,7 @@ static void __init do_basic_setup(void)
 	ksysfs_init();
 	driver_init();
 	init_irq_proc();
+	param_sysfs_init();
 	do_ctors();
 	do_initcalls();
 }
diff --git a/kernel/params.c b/kernel/params.c
index 74d620bc2521..d1e3934fb3a7 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -942,22 +942,19 @@ const struct kobj_type module_ktype = {
 /*
  * param_sysfs_init - create "module" kset
  *
- * This must be done before the initramfs is unpacked and
- * request_module() thus becomes possible, because otherwise the
- * module load would fail in mod_sysfs_init.
+ * Must run before:
+ * - do_initcalls(): some drivers register during initcalls and rely on
+ *   module_kset existing for their sysfs module symlink.
+ * - rootfs_initcall (initramfs unpack): request_module() becomes possible.
+ *   But if module_kset is null, module load would fail in mod_sysfs_init(),
+ *   causing request_module() to fail.
  */
-static int __init param_sysfs_init(void)
+void __init param_sysfs_init(void)
 {
 	module_kset = kset_create_and_add("module", &module_uevent_ops, NULL);
-	if (!module_kset) {
-		printk(KERN_WARNING "%s (%d): error creating kset\n",
-			__FILE__, __LINE__);
-		return -ENOMEM;
-	}
-
-	return 0;
+	if (!module_kset)
+		pr_warn("Error creating module kset\n");
 }
-subsys_initcall(param_sysfs_init);
 
 /*
  * param_sysfs_builtin_init - add sysfs version and parameter

-- 
2.43.0



^ permalink raw reply related

* [PATCH v4 2/4] coresight: pass THIS_MODULE implicitly through a macro
From: Shashank Balaji @ 2026-04-27  2:41 UTC (permalink / raw)
  To: Suzuki K Poulose, James Clark, Alexander Shishkin,
	Maxime Coquelin, Alexandre Torgue, Greg Kroah-Hartman,
	Rafael J. Wysocki, Danilo Krummrich, Miguel Ojeda, Boqun Feng,
	Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
	Alice Ryhl, Trevor Gross, Richard Cochran, Jonathan Corbet,
	Shuah Khan, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
	Sami Tolvanen, Aaron Tomlin, Mike Leach, Leo Yan, Mike Leach
  Cc: Rahul Bukte, Shashank Balaji, linux-kernel, coresight,
	linux-arm-kernel, driver-core, rust-for-linux, linux-doc,
	Daniel Palmer, Tim Bird, linux-modules
In-Reply-To: <20260427-acpi_mod_name-v4-0-22b42240c9bf@sony.com>

Rename coresight_init_driver() to __coresight_init_driver() and replace
it with a macro wrapper that passes THIS_MODULE implicitly. This is in line with
what other buses do.

Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
---
 drivers/hwtracing/coresight/coresight-catu.c       | 2 +-
 drivers/hwtracing/coresight/coresight-core.c       | 4 ++--
 drivers/hwtracing/coresight/coresight-cpu-debug.c  | 3 +--
 drivers/hwtracing/coresight/coresight-funnel.c     | 3 +--
 drivers/hwtracing/coresight/coresight-replicator.c | 3 +--
 drivers/hwtracing/coresight/coresight-stm.c        | 2 +-
 drivers/hwtracing/coresight/coresight-tmc-core.c   | 2 +-
 drivers/hwtracing/coresight/coresight-tnoc.c       | 2 +-
 drivers/hwtracing/coresight/coresight-tpdm.c       | 3 +--
 drivers/hwtracing/coresight/coresight-tpiu.c       | 2 +-
 include/linux/coresight.h                          | 4 +++-
 11 files changed, 14 insertions(+), 16 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-catu.c b/drivers/hwtracing/coresight/coresight-catu.c
index ce71dcddfca2..0c8698c8fc5e 100644
--- a/drivers/hwtracing/coresight/coresight-catu.c
+++ b/drivers/hwtracing/coresight/coresight-catu.c
@@ -706,7 +706,7 @@ static int __init catu_init(void)
 {
 	int ret;
 
-	ret = coresight_init_driver("catu", &catu_driver, &catu_platform_driver, THIS_MODULE);
+	ret = coresight_init_driver("catu", &catu_driver, &catu_platform_driver);
 	tmc_etr_set_catu_ops(&etr_catu_buf_ops);
 	return ret;
 }
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 46f247f73cf6..4ebcbd95b7fb 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -1694,7 +1694,7 @@ static void __exit coresight_exit(void)
 module_init(coresight_init);
 module_exit(coresight_exit);
 
-int coresight_init_driver(const char *drv, struct amba_driver *amba_drv,
+int __coresight_init_driver(const char *drv, struct amba_driver *amba_drv,
 			  struct platform_driver *pdev_drv, struct module *owner)
 {
 	int ret;
@@ -1713,7 +1713,7 @@ int coresight_init_driver(const char *drv, struct amba_driver *amba_drv,
 	amba_driver_unregister(amba_drv);
 	return ret;
 }
-EXPORT_SYMBOL_GPL(coresight_init_driver);
+EXPORT_SYMBOL_GPL(__coresight_init_driver);
 
 void coresight_remove_driver(struct amba_driver *amba_drv,
 			     struct platform_driver *pdev_drv)
diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c b/drivers/hwtracing/coresight/coresight-cpu-debug.c
index 629614278e46..3a806c1d50ea 100644
--- a/drivers/hwtracing/coresight/coresight-cpu-debug.c
+++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
@@ -757,8 +757,7 @@ static struct platform_driver debug_platform_driver = {
 
 static int __init debug_init(void)
 {
-	return coresight_init_driver("debug", &debug_driver, &debug_platform_driver,
-				     THIS_MODULE);
+	return coresight_init_driver("debug", &debug_driver, &debug_platform_driver);
 }
 
 static void __exit debug_exit(void)
diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c
index 3f56ceccd8c9..0abc11f0690c 100644
--- a/drivers/hwtracing/coresight/coresight-funnel.c
+++ b/drivers/hwtracing/coresight/coresight-funnel.c
@@ -412,8 +412,7 @@ static struct amba_driver dynamic_funnel_driver = {
 
 static int __init funnel_init(void)
 {
-	return coresight_init_driver("funnel", &dynamic_funnel_driver, &funnel_driver,
-				     THIS_MODULE);
+	return coresight_init_driver("funnel", &dynamic_funnel_driver, &funnel_driver);
 }
 
 static void __exit funnel_exit(void)
diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
index 07fc04f53b88..2f382de357ee 100644
--- a/drivers/hwtracing/coresight/coresight-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-replicator.c
@@ -418,8 +418,7 @@ static struct amba_driver dynamic_replicator_driver = {
 
 static int __init replicator_init(void)
 {
-	return coresight_init_driver("replicator", &dynamic_replicator_driver, &replicator_driver,
-				     THIS_MODULE);
+	return coresight_init_driver("replicator", &dynamic_replicator_driver, &replicator_driver);
 }
 
 static void __exit replicator_exit(void)
diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
index aca6cec7885a..4e860519a73f 100644
--- a/drivers/hwtracing/coresight/coresight-stm.c
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -1050,7 +1050,7 @@ static struct platform_driver stm_platform_driver = {
 
 static int __init stm_init(void)
 {
-	return coresight_init_driver("stm", &stm_driver, &stm_platform_driver, THIS_MODULE);
+	return coresight_init_driver("stm", &stm_driver, &stm_platform_driver);
 }
 
 static void __exit stm_exit(void)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c
index c89fe996af23..bc5a133ada3e 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-core.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-core.c
@@ -1046,7 +1046,7 @@ static struct platform_driver tmc_platform_driver = {
 
 static int __init tmc_init(void)
 {
-	return coresight_init_driver("tmc", &tmc_driver, &tmc_platform_driver, THIS_MODULE);
+	return coresight_init_driver("tmc", &tmc_driver, &tmc_platform_driver);
 }
 
 static void __exit tmc_exit(void)
diff --git a/drivers/hwtracing/coresight/coresight-tnoc.c b/drivers/hwtracing/coresight/coresight-tnoc.c
index 96a25877b824..9e8de4323d28 100644
--- a/drivers/hwtracing/coresight/coresight-tnoc.c
+++ b/drivers/hwtracing/coresight/coresight-tnoc.c
@@ -344,7 +344,7 @@ static struct platform_driver itnoc_driver = {
 
 static int __init tnoc_init(void)
 {
-	return coresight_init_driver("tnoc", &trace_noc_driver, &itnoc_driver, THIS_MODULE);
+	return coresight_init_driver("tnoc", &trace_noc_driver, &itnoc_driver);
 }
 
 static void __exit tnoc_exit(void)
diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c
index eaf7210af648..8464edbba2d4 100644
--- a/drivers/hwtracing/coresight/coresight-tpdm.c
+++ b/drivers/hwtracing/coresight/coresight-tpdm.c
@@ -1563,8 +1563,7 @@ static struct platform_driver static_tpdm_driver = {
 
 static int __init tpdm_init(void)
 {
-	return coresight_init_driver("tpdm", &dynamic_tpdm_driver, &static_tpdm_driver,
-				     THIS_MODULE);
+	return coresight_init_driver("tpdm", &dynamic_tpdm_driver, &static_tpdm_driver);
 }
 
 static void __exit tpdm_exit(void)
diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
index b8560b140e0f..7b029d2eb389 100644
--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -310,7 +310,7 @@ static struct platform_driver tpiu_platform_driver = {
 
 static int __init tpiu_init(void)
 {
-	return coresight_init_driver("tpiu", &tpiu_driver, &tpiu_platform_driver, THIS_MODULE);
+	return coresight_init_driver("tpiu", &tpiu_driver, &tpiu_platform_driver);
 }
 
 static void __exit tpiu_exit(void)
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 2131febebee9..b9ec5f195907 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -691,7 +691,9 @@ coresight_find_output_type(struct coresight_platform_data *pdata,
 			   enum coresight_dev_type type,
 			   union coresight_dev_subtype subtype);
 
-int coresight_init_driver(const char *drv, struct amba_driver *amba_drv,
+#define coresight_init_driver(drv, amba_drv, pdev_drv) \
+	__coresight_init_driver(drv, amba_drv, pdev_drv, THIS_MODULE)
+int __coresight_init_driver(const char *drv, struct amba_driver *amba_drv,
 			  struct platform_driver *pdev_drv, struct module *owner);
 
 void coresight_remove_driver(struct amba_driver *amba_drv,

-- 
2.43.0



^ permalink raw reply related

* [PATCH v4 4/4] docs: driver-api: add mod_name argument to __platform_register_drivers()
From: Shashank Balaji @ 2026-04-27  2:41 UTC (permalink / raw)
  To: Suzuki K Poulose, James Clark, Alexander Shishkin,
	Maxime Coquelin, Alexandre Torgue, Greg Kroah-Hartman,
	Rafael J. Wysocki, Danilo Krummrich, Miguel Ojeda, Boqun Feng,
	Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
	Alice Ryhl, Trevor Gross, Richard Cochran, Jonathan Corbet,
	Shuah Khan, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
	Sami Tolvanen, Aaron Tomlin, Mike Leach, Leo Yan, Mike Leach
  Cc: Rahul Bukte, Shashank Balaji, linux-kernel, coresight,
	linux-arm-kernel, driver-core, rust-for-linux, linux-doc,
	Daniel Palmer, Tim Bird, linux-modules
In-Reply-To: <20260427-acpi_mod_name-v4-0-22b42240c9bf@sony.com>

Sync the function signature of __platform_register_driver() between the code and
the doc.

Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
---
 Documentation/driver-api/driver-model/platform.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/driver-api/driver-model/platform.rst b/Documentation/driver-api/driver-model/platform.rst
index cf5ff48d3115..9673470bded2 100644
--- a/Documentation/driver-api/driver-model/platform.rst
+++ b/Documentation/driver-api/driver-model/platform.rst
@@ -70,7 +70,8 @@ Kernel modules can be composed of several platform drivers. The platform core
 provides helpers to register and unregister an array of drivers::
 
 	int __platform_register_drivers(struct platform_driver * const *drivers,
-				      unsigned int count, struct module *owner);
+				      unsigned int count, struct module *owner,
+				      const char *mod_name);
 	void platform_unregister_drivers(struct platform_driver * const *drivers,
 					 unsigned int count);
 

-- 
2.43.0



^ permalink raw reply related

* [PATCH v4 0/4] Enable sysfs module symlink for more built-in drivers
From: Shashank Balaji @ 2026-04-27  2:41 UTC (permalink / raw)
  To: Suzuki K Poulose, James Clark, Alexander Shishkin,
	Maxime Coquelin, Alexandre Torgue, Greg Kroah-Hartman,
	Rafael J. Wysocki, Danilo Krummrich, Miguel Ojeda, Boqun Feng,
	Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
	Alice Ryhl, Trevor Gross, Richard Cochran, Jonathan Corbet,
	Shuah Khan, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
	Sami Tolvanen, Aaron Tomlin, Mike Leach, Leo Yan, Mike Leach
  Cc: Rahul Bukte, Shashank Balaji, linux-kernel, coresight,
	linux-arm-kernel, driver-core, rust-for-linux, linux-doc,
	Daniel Palmer, Tim Bird, linux-modules
In-Reply-To: <20260422-acpi_mod_name-v3-0-a184eff9ff6f@sony.com>

struct device_driver's mod_name is not set by a number of bus' driver registration
functions. Without that, built-in drivers don't have the module symlink in sysfs.
We want this to go from unbound driver name -> module name -> kernel config name.
This is useful on embedded platforms to minimize kernel config, reduce kernel size,
and reduce boot time.

In order to achieve this, mod_name has to be set to KBUILD_MODNAME, and this has
to be done for all buses which don't yet do this.

Here are some treewide stats:
- 110 registration functions across all bus types
- 20 of them set mod_name
- Remaining 90 do not set mod_name:
    1. 36 functions under pattern 1:
        They have a __register function + register macro. KBUILD_MODNAME needs to
        be passed and the function needs to take mod_name as input.
    2. 42 functions under pattern 2:
        These have no macro wrapper. They need a double-underscore rename + macro
        wrapper to make them similar to pattern 1.
    3. Remaining 12 do not have such a clean registration interface. More analysis
       is required.

We plan to start with pattern 1, since it's the easiest category of changes.
Within that, for now we're only sending the platform patch. If we get the go-ahead
on that, we'll send the remaining ones.

Patch 3 depends on patches 1 and 2.

Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
---
Changes in v4:
- Initialize module_kset in do_basic_setup() before do_initcalls() (Gary)
- Add commit body to the documentation patch (Greg)
- Link to v3: https://patch.msgid.link/20260422-acpi_mod_name-v3-0-a184eff9ff6f@sony.com

Changes in v3:
- Initialize module_kset on-demand (Greg)
- Make coresight driver registration happen through a macro (Greg)
- Split up the patch adding mod_name to platform driver registrations (Greg)
- Link to v2: https://patch.msgid.link/20260421-acpi_mod_name-v2-0-e73f9310dad3@sony.com

Changes in v2:
- Drop acpi patch, send platform instead (Rafael)
- Link to v1: https://patch.msgid.link/20260416-acpi_mod_name-v1-0-1a4d96fd86c9@sony.com

To: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Mike Leach <mike.leach@linaro.org>
To: James Clark <james.clark@linaro.org>
To: Alexander Shishkin <alexander.shishkin@linux.intel.com>
To: Maxime Coquelin <mcoquelin.stm32@gmail.com>
To: Alexandre Torgue <alexandre.torgue@foss.st.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
To: Danilo Krummrich <dakr@kernel.org>
To: Miguel Ojeda <ojeda@kernel.org>
To: Boqun Feng <boqun@kernel.org>
To: Gary Guo <gary@garyguo.net>
To: Björn Roy Baron <bjorn3_gh@protonmail.com>
To: Benno Lossin <lossin@kernel.org>
To: Andreas Hindborg <a.hindborg@kernel.org>
To: Alice Ryhl <aliceryhl@google.com>
To: Trevor Gross <tmgross@umich.edu>
To: Richard Cochran <richardcochran@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Shuah Khan <skhan@linuxfoundation.org>
To: Luis Chamberlain <mcgrof@kernel.org>
To: Petr Pavlu <petr.pavlu@suse.com>
To: Daniel Gomez <da.gomez@kernel.org>
To: Sami Tolvanen <samitolvanen@google.com>
To: Aaron Tomlin <atomlin@atomlin.com>
To: Mike Leach <mike.leach@arm.com>
To: Leo Yan <leo.yan@arm.com>
Cc: linux-kernel@vger.kernel.org
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: driver-core@lists.linux.dev
Cc: rust-for-linux@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: Shashank Balaji <shashank.mahadasyam@sony.com>
Cc: Rahul Bukte <rahul.bukte@sony.com>
Cc: Daniel Palmer <daniel.palmer@sony.com>
Cc: Tim Bird <tim.bird@sony.com>
Cc: linux-modules@vger.kernel.org

---
Shashank Balaji (4):
      kernel: param: initialize module_kset before do_initcalls()
      coresight: pass THIS_MODULE implicitly through a macro
      driver core: platform: set mod_name in driver registration
      docs: driver-api: add mod_name argument to __platform_register_drivers()

 Documentation/driver-api/driver-model/platform.rst |  3 ++-
 drivers/base/platform.c                            | 21 ++++++++++++++-------
 drivers/hwtracing/coresight/coresight-catu.c       |  2 +-
 drivers/hwtracing/coresight/coresight-core.c       |  9 +++++----
 drivers/hwtracing/coresight/coresight-cpu-debug.c  |  3 +--
 drivers/hwtracing/coresight/coresight-funnel.c     |  3 +--
 drivers/hwtracing/coresight/coresight-replicator.c |  3 +--
 drivers/hwtracing/coresight/coresight-stm.c        |  2 +-
 drivers/hwtracing/coresight/coresight-tmc-core.c   |  2 +-
 drivers/hwtracing/coresight/coresight-tnoc.c       |  2 +-
 drivers/hwtracing/coresight/coresight-tpdm.c       |  3 +--
 drivers/hwtracing/coresight/coresight-tpiu.c       |  2 +-
 include/linux/coresight.h                          |  7 +++++--
 include/linux/module.h                             |  4 ++++
 include/linux/platform_device.h                    | 17 +++++++++--------
 init/main.c                                        |  1 +
 kernel/params.c                                    | 21 +++++++++------------
 rust/kernel/platform.rs                            |  4 +++-
 18 files changed, 61 insertions(+), 48 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260416-acpi_mod_name-f645a76e337b

Best regards,
--  
Shashank Balaji <shashank.mahadasyam@sony.com>



^ permalink raw reply

* [PATCH v4 3/3] remoteproc: imx_rproc: Add support for i.MX94
From: Peng Fan (OSS) @ 2026-04-27  2:41 UTC (permalink / raw)
  To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
	Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
  Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
	Peng Fan
In-Reply-To: <20260427-imx943-rproc-v4-0-68d7c7253acd@nxp.com>

From: Peng Fan <peng.fan@nxp.com>

Add basic remoteproc support for the i.MX94 M-core processors, including
address translation tables(dev addr is from view of remote processor,
sys addr is from view of main processor) and device configuration data for
the CM70, CM71, and CM33S cores.

Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 65 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index c21782be4bb69d830479f538a091bda48b740ca4..7f54322244acacb32d8fe17f5e62b6aba21b3084 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -145,6 +145,41 @@ static const struct imx_rproc_att imx_rproc_att_imx95_m7[] = {
 	{ 0x80000000, 0x80000000, 0x50000000, 0 },
 };
 
+static const struct imx_rproc_att imx_rproc_att_imx94_m70[] = {
+	/* dev addr , sys addr  , size	    , flags */
+	/* TCM CODE NON-SECURE */
+	{ 0x00000000, 0x203C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+	/* TCM SYS NON-SECURE*/
+	{ 0x20000000, 0x20400000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+	/* DDR */
+	{ 0x80000000, 0x80000000, 0x10000000, 0 },
+};
+
+static const struct imx_rproc_att imx_rproc_att_imx94_m71[] = {
+	/* dev addr , sys addr  , size	    , flags */
+	/* TCM CODE NON-SECURE */
+	{ 0x00000000, 0x202C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+	/* TCM SYS NON-SECURE*/
+	{ 0x20000000, 0x20300000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+	/* DDR */
+	{ 0x80000000, 0x80000000, 0x10000000, 0 },
+};
+
+static const struct imx_rproc_att imx_rproc_att_imx94_m33s[] = {
+	/* dev addr , sys addr  , size	    , flags */
+	/* TCM CODE NON-SECURE */
+	{ 0x0FFC0000, 0x209C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+	/* TCM SYS NON-SECURE */
+	{ 0x20000000, 0x20A00000, 0x00040000, ATT_OWN | ATT_IOMEM },
+	/* M33S OCRAM NON-SECURE */
+	{ 0x20800000, 0x20800000, 0x180000, ATT_OWN | ATT_IOMEM },
+
+	/* DDR */
+	{ 0x80000000, 0x80000000, 0x10000000, 0 },
+};
+
 static const struct imx_rproc_att imx_rproc_att_imx93[] = {
 	/* dev addr , sys addr  , size	    , flags */
 	/* TCM CODE NON-SECURE */
@@ -1477,6 +1512,33 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx93 = {
 	.flags		= IMX_RPROC_NEED_CLKS,
 };
 
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m70 = {
+	.att		= imx_rproc_att_imx94_m70,
+	.att_size	= ARRAY_SIZE(imx_rproc_att_imx94_m70),
+	.ops		= &imx_rproc_ops_sm_lmm,
+	.cpuid		= 1,
+	.lmid		= 2,
+	.reset_vector_mask = GENMASK_U32(31, 16),
+};
+
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m71 = {
+	.att		= imx_rproc_att_imx94_m71,
+	.att_size	= ARRAY_SIZE(imx_rproc_att_imx94_m71),
+	.ops		= &imx_rproc_ops_sm_lmm,
+	.cpuid		= 7,
+	.lmid		= 3,
+	.reset_vector_mask = GENMASK_U32(31, 16),
+};
+
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m33s = {
+	.att		= imx_rproc_att_imx94_m33s,
+	.att_size	= ARRAY_SIZE(imx_rproc_att_imx94_m33s),
+	.ops		= &imx_rproc_ops_sm_lmm,
+	.cpuid		= 8,
+	.lmid		= 1,
+	.reset_vector_mask = GENMASK_U32(31, 16),
+};
+
 static const struct imx_rproc_dcfg imx_rproc_cfg_imx95_m7 = {
 	.att		= imx_rproc_att_imx95_m7,
 	.att_size	= ARRAY_SIZE(imx_rproc_att_imx95_m7),
@@ -1501,6 +1563,9 @@ static const struct of_device_id imx_rproc_of_match[] = {
 	{ .compatible = "fsl,imx8qm-cm4", .data = &imx_rproc_cfg_imx8qm },
 	{ .compatible = "fsl,imx8ulp-cm33", .data = &imx_rproc_cfg_imx8ulp },
 	{ .compatible = "fsl,imx93-cm33", .data = &imx_rproc_cfg_imx93 },
+	{ .compatible = "fsl,imx94-cm70", .data = &imx_rproc_cfg_imx94_m70 },
+	{ .compatible = "fsl,imx94-cm71", .data = &imx_rproc_cfg_imx94_m71 },
+	{ .compatible = "fsl,imx94-cm33s", .data = &imx_rproc_cfg_imx94_m33s },
 	{ .compatible = "fsl,imx95-cm7", .data = &imx_rproc_cfg_imx95_m7 },
 	{},
 };

-- 
2.37.1



^ permalink raw reply related

* [PATCH v4 2/3] remoteproc: imx_rproc: Program non-zero SM CPU/LMM reset vector
From: Peng Fan (OSS) @ 2026-04-27  2:41 UTC (permalink / raw)
  To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
	Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
  Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
	Peng Fan
In-Reply-To: <20260427-imx943-rproc-v4-0-68d7c7253acd@nxp.com>

From: Peng Fan <peng.fan@nxp.com>

Cortex-M[7,33] processors use a fixed reset vector table format:

  0x00  Initial SP value
  0x04  Reset vector
  0x08  NMI
  0x0C  ...
  ...
  IRQ[n]

In ELF images, the corresponding layout is:

reset_vectors:  --> hardware reset address
        .word __stack_end__
        .word Reset_Handler
        .word NMI_Handler
        .word HardFault_Handler
        ...
        .word UART_IRQHandler
        .word SPI_IRQHandler
        ...

Reset_Handler:  --> ELF entry point address
        ...

The hardware fetches the first two words from reset_vectors and populates
SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
Reset_Handler.

However, the ELF entry point does not always match the hardware reset
address. For example, on i.MX94 CM33S:

  ELF entry point:     0x0ffc211d
  hardware reset base: 0x0ffc0000 (default reset value, sw programmable)

Current driver always programs the reset vector as 0. But i.MX94 CM33S's
default reset base is 0x0ffc0000, so the correct reset vector must be
passed to the SM API; otherwise the M33 Sync core cannot boot successfully.

rproc_elf_get_boot_addr() returns the ELF entry point, which is not the
hardware reset vector address. Fix the issue by deriving the hardware reset
vector locally using a SoC-specific mask:

  reset_vector = rproc->bootaddr & reset_vector_mask

The ELF entry point semantics remain unchanged. The masking is applied only
at the point where the SM reset vector is programmed.

Add reset_vector_mask = GENMASK_U32(31, 16) to the i.MX95 M7 configuration
so the hardware reset vector is derived correctly. Without this mask, the
SM reset vector would be programmed with an unaligned ELF entry point and
the M7 core would fail to boot.

Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 27 +++++++++++++++++++++++++--
 drivers/remoteproc/imx_rproc.h |  2 ++
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 0dd80e688b0ea3df4c66e5726884dc86c8a5a881..c21782be4bb69d830479f538a091bda48b740ca4 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -339,13 +339,32 @@ static int imx_rproc_scu_api_start(struct rproc *rproc)
 	return imx_sc_pm_cpu_start(priv->ipc_handle, priv->rsrc_id, true, priv->entry);
 }
 
+static u64 imx_rproc_sm_get_reset_vector(struct rproc *rproc)
+{
+	struct imx_rproc *priv = rproc->priv;
+	u32 reset_vector_mask = priv->dcfg->reset_vector_mask ?: GENMASK(31, 0);
+
+	/*
+	 * The hardware fetches the first two words from reset_vectors
+	 * (hardware reset address) and populates SP and PC using the first
+	 * two words. Execution proceeds from PC. The ELF entry point does
+	 * not always match the hardware reset address.
+	 * To derive the correct hardware reset address, the lower address
+	 * bits must be masked off before programming the reset vector.
+	 */
+	return rproc->bootaddr & reset_vector_mask;
+}
+
 static int imx_rproc_sm_cpu_start(struct rproc *rproc)
 {
 	struct imx_rproc *priv = rproc->priv;
 	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
+	u64 reset_vector;
 	int ret;
 
-	ret = scmi_imx_cpu_reset_vector_set(dcfg->cpuid, 0, true, false, false);
+	reset_vector = imx_rproc_sm_get_reset_vector(rproc);
+
+	ret = scmi_imx_cpu_reset_vector_set(dcfg->cpuid, reset_vector, true, false, false);
 	if (ret) {
 		dev_err(priv->dev, "Failed to set reset vector cpuid(%u): %d\n", dcfg->cpuid, ret);
 		return ret;
@@ -359,13 +378,16 @@ static int imx_rproc_sm_lmm_start(struct rproc *rproc)
 	struct imx_rproc *priv = rproc->priv;
 	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
 	struct device *dev = priv->dev;
+	u64 reset_vector;
 	int ret;
 
+	reset_vector = imx_rproc_sm_get_reset_vector(rproc);
+
 	/*
 	 * If the remoteproc core can't start the M7, it will already be
 	 * handled in imx_rproc_sm_lmm_prepare().
 	 */
-	ret = scmi_imx_lmm_reset_vector_set(dcfg->lmid, dcfg->cpuid, 0, 0);
+	ret = scmi_imx_lmm_reset_vector_set(dcfg->lmid, dcfg->cpuid, 0, reset_vector);
 	if (ret) {
 		dev_err(dev, "Failed to set reset vector lmid(%u), cpuid(%u): %d\n",
 			dcfg->lmid, dcfg->cpuid, ret);
@@ -1462,6 +1484,7 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx95_m7 = {
 	/* Must align with System Manager Firmware */
 	.cpuid		= 1, /* Use 1 as cpu id for M7 core */
 	.lmid		= 1, /* Use 1 as Logical Machine ID where M7 resides */
+	.reset_vector_mask = GENMASK_U32(31, 16),
 };
 
 static const struct of_device_id imx_rproc_of_match[] = {
diff --git a/drivers/remoteproc/imx_rproc.h b/drivers/remoteproc/imx_rproc.h
index d37e6f90548cec727b4aeb874680b42af85bdbb4..0d7d48352a1091ad24e8e083172ce6da6d26ae10 100644
--- a/drivers/remoteproc/imx_rproc.h
+++ b/drivers/remoteproc/imx_rproc.h
@@ -41,6 +41,8 @@ struct imx_rproc_dcfg {
 	/* For System Manager(SM) based SoCs */
 	u32				cpuid; /* ID of the remote core */
 	u32				lmid;  /* ID of the Logcial Machine */
+	/* reset_vector = elf_entry_addr & reset_vector_mask */
+	u32				reset_vector_mask;
 };
 
 #endif /* _IMX_RPROC_H */

-- 
2.37.1



^ permalink raw reply related

* [PATCH v4 1/3] dt-bindings: remoteproc: imx-rproc: Support i.MX94
From: Peng Fan (OSS) @ 2026-04-27  2:41 UTC (permalink / raw)
  To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
	Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
  Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
	Peng Fan
In-Reply-To: <20260427-imx943-rproc-v4-0-68d7c7253acd@nxp.com>

From: Peng Fan <peng.fan@nxp.com>

Add compatible string for:
 Cortex-M7 core[0,1] in i.MX94
 Cortex-M33 Sync core in i.MX94

To i.MX94, Cortex-M7 core0 and core1 have different memory view from
Cortex-A55 core, so different compatible string is used.

Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index ce8ec0119469c8fc0979a192b6e3d3a03108d7d2..c18f71b648890da9c25a2f3309d8dbec5bb8d226 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -28,6 +28,9 @@ properties:
       - fsl,imx8qxp-cm4
       - fsl,imx8ulp-cm33
       - fsl,imx93-cm33
+      - fsl,imx94-cm33s
+      - fsl,imx94-cm70
+      - fsl,imx94-cm71
       - fsl,imx95-cm7
 
   clocks:

-- 
2.37.1



^ permalink raw reply related

* [PATCH v4 0/3] Add i.MX94 remoteproc support and reset vector handling improvements
From: Peng Fan (OSS) @ 2026-04-27  2:41 UTC (permalink / raw)
  To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
	Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
  Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
	Peng Fan

This series adds remoteproc support for the i.MX94 family, including the
CM70, CM71, and CM33S cores, and derive the hardware reset vector for
Cortex‑M processors whose ELF entry point does not directly correspond to
the actual reset address.

Background:
Cortex‑M processors fetch their initial SP and PC from a fixed reset vector
table. While ELF images embed the entry point (e_entry), this value is
not always aligned to the hardware reset address. On platforms such as
i.MX94 CM33S, masking is required to compute the correct reset vector
address before programming the SoC reset registers.

Similarly, on i.MX95, the existing implementation always programs a reset
vector of 0x0, which only works when executing entirely from TCM. When
firmware is loaded into DDR, the driver must pass the correct reset vector
to the SM CPU/LMM interfaces.

Summary of patches:
[1]dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask
Adds a new DT property allowing SoCs to specify a mask for deriving the
hardware reset vector from the ELF entry point.

[2]remoteproc: imx_rproc: Program non-zero SM CPU/LMM reset vector
Ensures the correct reset vector is passed to SM APIs by introducing a
helper (imx_rproc_sm_get_reset_vector()) that applies the reset‑vector
mask.

[3]remoteproc: imx_rproc: Add support for i.MX94 remoteproc
Adds address translation tables and configuration data for CM70, CM71,
and CM33S, enabling full remoteproc operation on i.MX94.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Changes in v4:
- Daniel raised the M33S secure region was not included, but since I not
  have image to test secure region, so drop the Secure alias region for
  all. Updated DDR region. R-b kept since this is a minor change.
- Add R-b for patch 2
- Link to v3: https://lore.kernel.org/r/20260415-imx943-rproc-v3-0-9fa7528db8ca@nxp.com

Changes in v3:
- Patch 2: 
  Drop R-b because of changes in V3

  Following suggestion from Mathieu that apply reset vector in
  scmi_imx_[cpu,lmm]_reset_vector_set(), not change the meaning of
  rproc->bootaddr, add helper imx_rproc_sm_get_reset_vector() to get reset
  vector and use the hlper in scmi_imx_[cpu,lmm]_reset_vector_set().

  Add reset-vector-mask for i.MX95 CM7 to avoid breaking i.MX95 CM7
  boot.

- Link to v2: https://lore.kernel.org/r/20260327-imx943-rproc-v2-0-a547a3588730@nxp.com

Changes in v2:
- Drop fsl,reset-vector-mask by using fixed value in driver for per device
- Add R-b for i.MX94 dt-binding
- Update commit log to include dev addr and sys addr
- Link to v1: https://lore.kernel.org/r/20260312-imx943-rproc-v1-0-3e66596592a8@nxp.com

---
Peng Fan (3):
      dt-bindings: remoteproc: imx-rproc: Support i.MX94
      remoteproc: imx_rproc: Program non-zero SM CPU/LMM reset vector
      remoteproc: imx_rproc: Add support for i.MX94

 .../bindings/remoteproc/fsl,imx-rproc.yaml         |  3 +
 drivers/remoteproc/imx_rproc.c                     | 92 +++++++++++++++++++++-
 drivers/remoteproc/imx_rproc.h                     |  2 +
 3 files changed, 95 insertions(+), 2 deletions(-)
---
base-commit: 724699d8d0523909da51fda8d1e10c1ff867b280
change-id: 20260311-imx943-rproc-2050e00b65f7

Best regards,
-- 
Peng Fan <peng.fan@nxp.com>



^ permalink raw reply

* [PATCH v2] cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()
From: Jinjie Ruan @ 2026-04-27  2:35 UTC (permalink / raw)
  To: catalin.marinas, will, punit.agrawal, rafael.j.wysocki,
	fengchengwen, chenl311, suzuki.poulose, maz, timothy.hayes,
	lpieralisi, mrigendra.chaubey, arnd, sudeep.holla, yangyicong,
	jic23, pierre.gondois, linux-arm-kernel, linux-kernel,
	james.morse
  Cc: ruanjinjie

On arm64, when booting with `maxcpus` greater than the number of present
CPUs (e.g., QEMU -smp cpus=4,maxcpus=8), some CPUs are marked as 'present'
but have not yet been registered via register_cpu(). Consequently,
the per-cpu device objects for these CPUs are not yet initialized.

In cpuhp_smt_enable(), the code iterates over all present CPUs. Calling
_cpu_up() for these unregistered CPUs eventually leads to
sysfs_create_group() being called with a NULL kobject (or a kobject
without a directory), triggering the following warning in
fs/sysfs/group.c:

	if (WARN_ON(!kobj || (!update && !kobj->sd)))
		return -EINVAL;

When booting with ACPI, arm64 smp_prepare_cpus() currently sets all
enumerated CPUs as "present" regardless of their status in the MADT. This
causes issues with SMT hotplug control. For instance, with QEMU's
"-smp 4,maxcpus=8" configuration, the MADT GICC entries are populated as
follows: the first four CPUs are marked Enabled while the remaining four
are marked Online Capable to support potential hot-plugging.

Fix this by:

1. When booting with ACPI, checking the ACPI_MADT_ENABLED flag in the GICC
   entry before calling set_cpu_present() during SMP initialization.

2. Properly managing the present mask in acpi_map_cpu() and
   acpi_unmap_cpu() to support actual CPU hotplug events, This aligns with
   other architectures like x86 and LoongArch.

This ensures that only physically available or explicitly enabled CPUs
are in the present mask, keeping the SMT control logic consistent with
the actual hardware state.

How to reproduce:

	1. echo off > /sys/devices/system/cpu/smt/control
		psci: CPU1 killed (polled 0 ms)
		psci: CPU3 killed (polled 0 ms)

	2. echo 2 > /sys/devices/system/cpu/smt/control

	Detected PIPT I-cache on CPU1
	GICv3: CPU1: found redistributor 1 region 0:0x00000000080c0000
	CPU1: Booted secondary processor 0x0000000001 [0x410fd082]
	Detected PIPT I-cache on CPU3
	GICv3: CPU3: found redistributor 3 region 0:0x0000000008100000
	CPU3: Booted secondary processor 0x0000000003 [0x410fd082]
	------------[ cut here ]------------
	WARNING: fs/sysfs/group.c:137 at internal_create_group+0x41c/0x4bc, CPU#2: sh/181
	Modules linked in:
	CPU: 2 UID: 0 PID: 181 Comm: sh Not tainted 7.0.0-rc1-00010-g8d13386c7624 #142 PREEMPT
	Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
	pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
	pc : internal_create_group+0x41c/0x4bc
	lr : sysfs_create_group+0x18/0x24
	sp : ffff80008078ba40
	x29: ffff80008078ba40 x28: ffff296c980ad000 x27: ffff00007fb94128
	x26: 0000000000000054 x25: ffffd693e845f3f0 x24: 0000000000000001
	x23: 0000000000000001 x22: 0000000000000004 x21: 0000000000000000
	x20: ffffd693e845fc10 x19: 0000000000000004 x18: 00000000ffffffff
	x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
	x14: 0000000000000358 x13: 0000000000000007 x12: 0000000000000350
	x11: 0000000000000008 x10: 0000000000000407 x9 : 0000000000000400
	x8 : ffff00007fbf3b60 x7 : 0000000000000000 x6 : ffffd693e845f3f0
	x5 : ffff00007fb94128 x4 : 0000000000000000 x3 : ffff000000f4eac0
	x2 : ffffd693e7095a08 x1 : 0000000000000000 x0 : 0000000000000000
	Call trace:
	 internal_create_group+0x41c/0x4bc (P)
	 sysfs_create_group+0x18/0x24
	 topology_add_dev+0x1c/0x28
	 cpuhp_invoke_callback+0x104/0x20c
	 __cpuhp_invoke_callback_range+0x94/0x11c
	 _cpu_up+0x200/0x37c
	 cpuhp_smt_enable+0xbc/0x114
	 control_store+0xe8/0x1d4
	 dev_attr_store+0x18/0x2c
	 sysfs_kf_write+0x7c/0x94
	 kernfs_fop_write_iter+0x128/0x1b8
	 vfs_write+0x2b0/0x354
	 ksys_write+0x68/0xfc
	 __arm64_sys_write+0x1c/0x28
	 invoke_syscall+0x48/0x10c
	 el0_svc_common.constprop.0+0x40/0xe8
	 do_el0_svc+0x20/0x2c
	 el0_svc+0x34/0x124
	 el0t_64_sync_handler+0xa0/0xe4
	 el0t_64_sync+0x198/0x19c
	---[ end trace 0000000000000000 ]---

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Yicong Yang <yangyicong@hisilicon.com>
Cc: stable@vger.kernel.org
Link: https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#gic-cpu-interface-gicc-structure
Fixes: eed4583bcf9a6 ("arm64: Kconfig: Enable HOTPLUG_SMT")
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
 arch/arm64/kernel/acpi.c |  2 ++
 arch/arm64/kernel/smp.c  | 12 +++++++++++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 5891f92c2035..681aa2bbc399 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -448,12 +448,14 @@ int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, u32 apci_id,
 		return *pcpu;
 	}
 
+	set_cpu_present(*pcpu, true);
 	return 0;
 }
 EXPORT_SYMBOL(acpi_map_cpu);
 
 int acpi_unmap_cpu(int cpu)
 {
+	set_cpu_present(cpu, false);
 	return 0;
 }
 EXPORT_SYMBOL(acpi_unmap_cpu);
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 1aa324104afb..5932e5b30b71 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -566,6 +566,11 @@ struct acpi_madt_generic_interrupt *acpi_cpu_get_madt_gicc(int cpu)
 }
 EXPORT_SYMBOL_GPL(acpi_cpu_get_madt_gicc);
 
+static bool acpi_cpu_is_present(int cpu)
+{
+	return acpi_cpu_get_madt_gicc(cpu)->flags & ACPI_MADT_ENABLED;
+}
+
 /*
  * acpi_map_gic_cpu_interface - parse processor MADT entry
  *
@@ -670,6 +675,10 @@ static void __init acpi_parse_and_init_cpus(void)
 		early_map_cpu_to_node(i, acpi_numa_get_nid(i));
 }
 #else
+static bool acpi_cpu_is_present(int cpu)
+{
+	return false;
+}
 #define acpi_parse_and_init_cpus(...)	do { } while (0)
 #endif
 
@@ -808,7 +817,8 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
 		if (err)
 			continue;
 
-		set_cpu_present(cpu, true);
+		if (acpi_disabled || acpi_cpu_is_present(cpu))
+			set_cpu_present(cpu, true);
 		numa_store_cpu_info(cpu);
 	}
 }
-- 
2.34.1



^ permalink raw reply related

* Re: [PATCH v8 2/4] coresight: cti: encode trigger register index in register offsets
From: Jie Gan @ 2026-04-27  2:22 UTC (permalink / raw)
  To: Yingchao Deng, Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
	Alexander Shishkin
  Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
	quic_yingdeng, Jinlong Mao, Tingwei Zhang
In-Reply-To: <20260426-extended-cti-v8-2-23b900a4902f@oss.qualcomm.com>



On 4/26/2026 5:44 PM, Yingchao Deng wrote:
> Introduce a small encoding to carry the register index together with the
> base offset in a single u32, and use a common helper to compute the final
> MMIO address. This refactors register access to be based on the encoded
> (reg, nr) pair, reducing duplicated arithmetic and making it easier to
> support variants that bank or relocate trigger-indexed registers.
> 
> Signed-off-by: Yingchao Deng <yingchao.deng@oss.qualcomm.com>
> ---
>   drivers/hwtracing/coresight/coresight-cti-core.c  | 31 +++++++++++++++--------
>   drivers/hwtracing/coresight/coresight-cti-sysfs.c |  4 +--
>   drivers/hwtracing/coresight/coresight-cti.h       | 16 ++++++++++--
>   3 files changed, 36 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/drivers/hwtracing/coresight/coresight-cti-core.c
> index 4e7d12bd2d3e..c4cbeb64365b 100644
> --- a/drivers/hwtracing/coresight/coresight-cti-core.c
> +++ b/drivers/hwtracing/coresight/coresight-cti-core.c
> @@ -42,6 +42,14 @@ static DEFINE_MUTEX(ect_mutex);
>   #define csdev_to_cti_drvdata(csdev)	\
>   	dev_get_drvdata(csdev->dev.parent)
>   
> +static void __iomem *cti_reg_addr(struct cti_drvdata *drvdata, int reg)

u32 reg would be better.

> +{
> +	u32 offset = CTI_REG_CLR_NR(reg);

No functional error but a little bit tricky here.

CTI_REG_CLR_NR(reg) will produce a offset for the bits[0:23], but in the 
comment, you mentioned the base register offset ranges from [0:11].

With my understanding, all CTI register offsets fall within the range b 
0 to 0XFAC, that's why we have bits[0:11]?

Thanks,
Jie

> +	u32 nr = CTI_REG_GET_NR(reg);
> +
> +	return drvdata->base + offset + sizeof(u32) * nr;
> +}
> +
>   /* write set of regs to hardware - call with spinlock claimed */
>   void cti_write_all_hw_regs(struct cti_drvdata *drvdata)
>   {
> @@ -55,16 +63,17 @@ void cti_write_all_hw_regs(struct cti_drvdata *drvdata)
>   
>   	/* write the CTI trigger registers */
>   	for (i = 0; i < config->nr_trig_max; i++) {
> -		writel_relaxed(config->ctiinen[i], drvdata->base + CTIINEN(i));
> +		writel_relaxed(config->ctiinen[i],
> +			       cti_reg_addr(drvdata, CTI_REG_SET_NR(CTIINEN, i)));
>   		writel_relaxed(config->ctiouten[i],
> -			       drvdata->base + CTIOUTEN(i));
> +			       cti_reg_addr(drvdata, CTI_REG_SET_NR(CTIOUTEN, i)));
>   	}
>   
>   	/* other regs */
> -	writel_relaxed(config->ctigate, drvdata->base + CTIGATE);
> +	writel_relaxed(config->ctigate, cti_reg_addr(drvdata, CTIGATE));
>   	if (config->asicctl_impl)
> -		writel_relaxed(config->asicctl, drvdata->base + ASICCTL);
> -	writel_relaxed(config->ctiappset, drvdata->base + CTIAPPSET);
> +		writel_relaxed(config->asicctl, cti_reg_addr(drvdata, ASICCTL));
> +	writel_relaxed(config->ctiappset, cti_reg_addr(drvdata, CTIAPPSET));
>   
>   	/* re-enable CTI */
>   	writel_relaxed(1, drvdata->base + CTICONTROL);
> @@ -127,7 +136,7 @@ u32 cti_read_single_reg(struct cti_drvdata *drvdata, int offset)
>   	int val;
>   
>   	CS_UNLOCK(drvdata->base);
> -	val = readl_relaxed(drvdata->base + offset);
> +	val = readl_relaxed(cti_reg_addr(drvdata, offset));
>   	CS_LOCK(drvdata->base);
>   
>   	return val;
> @@ -136,7 +145,7 @@ u32 cti_read_single_reg(struct cti_drvdata *drvdata, int offset)
>   void cti_write_single_reg(struct cti_drvdata *drvdata, int offset, u32 value)
>   {
>   	CS_UNLOCK(drvdata->base);
> -	writel_relaxed(value, drvdata->base + offset);
> +	writel_relaxed(value, cti_reg_addr(drvdata, offset));
>   	CS_LOCK(drvdata->base);
>   }
>   
> @@ -344,8 +353,7 @@ int cti_channel_trig_op(struct device *dev, enum cti_chan_op op,
>   
>   	/* update the local register values */
>   	chan_bitmask = BIT(channel_idx);
> -	reg_offset = (direction == CTI_TRIG_IN ? CTIINEN(trigger_idx) :
> -		      CTIOUTEN(trigger_idx));
> +	reg_offset = (direction == CTI_TRIG_IN ? CTIINEN : CTIOUTEN);
>   
>   	guard(raw_spinlock_irqsave)(&drvdata->spinlock);
>   
> @@ -365,8 +373,9 @@ int cti_channel_trig_op(struct device *dev, enum cti_chan_op op,
>   
>   	/* write through if enabled */
>   	if (cti_is_active(config))
> -		cti_write_single_reg(drvdata, reg_offset, reg_value);
> -
> +		cti_write_single_reg(drvdata,
> +				     CTI_REG_SET_NR(reg_offset, trigger_idx),
> +				     reg_value);
>   	return 0;
>   }
>   
> diff --git a/drivers/hwtracing/coresight/coresight-cti-sysfs.c b/drivers/hwtracing/coresight/coresight-cti-sysfs.c
> index 2bbfa405cb6b..8b70e7e38ea3 100644
> --- a/drivers/hwtracing/coresight/coresight-cti-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-cti-sysfs.c
> @@ -386,7 +386,7 @@ static ssize_t inen_store(struct device *dev,
>   
>   	/* write through if enabled */
>   	if (cti_is_active(config))
> -		cti_write_single_reg(drvdata, CTIINEN(index), val);
> +		cti_write_single_reg(drvdata, CTI_REG_SET_NR(CTIINEN, index), val);
>   
>   	return size;
>   }
> @@ -427,7 +427,7 @@ static ssize_t outen_store(struct device *dev,
>   
>   	/* write through if enabled */
>   	if (cti_is_active(config))
> -		cti_write_single_reg(drvdata, CTIOUTEN(index), val);
> +		cti_write_single_reg(drvdata, CTI_REG_SET_NR(CTIOUTEN, index), val);
>   
>   	return size;
>   }
> diff --git a/drivers/hwtracing/coresight/coresight-cti.h b/drivers/hwtracing/coresight/coresight-cti.h
> index ef079fc18b72..dd1ba44518c4 100644
> --- a/drivers/hwtracing/coresight/coresight-cti.h
> +++ b/drivers/hwtracing/coresight/coresight-cti.h
> @@ -7,6 +7,7 @@
>   #ifndef _CORESIGHT_CORESIGHT_CTI_H
>   #define _CORESIGHT_CORESIGHT_CTI_H
>   
> +#include <linux/bitfield.h>
>   #include <linux/coresight.h>
>   #include <linux/device.h>
>   #include <linux/list.h>
> @@ -30,8 +31,8 @@ struct fwnode_handle;
>   #define CTIAPPSET		0x014
>   #define CTIAPPCLEAR		0x018
>   #define CTIAPPPULSE		0x01C
> -#define CTIINEN(n)		(0x020 + (4 * n))
> -#define CTIOUTEN(n)		(0x0A0 + (4 * n))
> +#define CTIINEN			0x020
> +#define CTIOUTEN		0x0A0
>   #define CTITRIGINSTATUS		0x130
>   #define CTITRIGOUTSTATUS	0x134
>   #define CTICHINSTATUS		0x138
> @@ -59,6 +60,17 @@ struct fwnode_handle;
>    */
>   #define CTIINOUTEN_MAX		32
>   
> +/*
> + * Encode CTI register offset and register index in one u32:
> + *   - bits[0:11]  : base register offset (0x000 to 0xFFF)
> + *   - bits[24:31] : register index (nr)
> + */
> +#define CTI_REG_NR_MASK			GENMASK(31, 24)
> +#define CTI_REG_GET_NR(reg)		FIELD_GET(CTI_REG_NR_MASK, (reg))
> +#define CTI_REG_SET_NR_CONST(reg, nr)	((reg) | FIELD_PREP_CONST(CTI_REG_NR_MASK, (nr)))
> +#define CTI_REG_SET_NR(reg, nr)		((reg) | FIELD_PREP(CTI_REG_NR_MASK, (nr)))
> +#define CTI_REG_CLR_NR(reg)		((reg) & (~CTI_REG_NR_MASK))
> +
>   /**
>    * Group of related trigger signals
>    *
> 



^ permalink raw reply

* [PATCH] pinctrl: mediatek: eint: Drop base from mtk_eint_chip_write_mask()
From: Chen-Yu Tsai @ 2026-04-27  2:11 UTC (permalink / raw)
  To: Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
	Linus Walleij
  Cc: Chen-Yu Tsai, linux-mediatek, linux-gpio, linux-arm-kernel,
	linux-kernel, Hao Chang, Qingliang Li

When support for multiple EINT base addresses was added in commit
3ef9f710efcb ("pinctrl: mediatek: Add EINT support for multiple
addresses"), mtk_eint_chip_write_mask() was changed to write interrupt
masks for all base addresses in one call. However the "base" parameter
was left around and now causes sparse warnings:

    mtk-eint.c:428:44: warning: incorrect type in argument 2 (different address spaces)
    mtk-eint.c:428:44:    expected void [noderef] __iomem *base
    mtk-eint.c:428:44:    got void [noderef] __iomem **base
    mtk-eint.c:436:44: warning: incorrect type in argument 2 (different address spaces)
    mtk-eint.c:436:44:    expected void [noderef] __iomem *base
    mtk-eint.c:436:44:    got void [noderef] __iomem **base

Since the "base" parameter is no longer needed, just drop it.

Fixes: 3ef9f710efcb ("pinctrl: mediatek: Add EINT support for multiple addresses")
Cc: Hao Chang <ot_chhao.chang@mediatek.com>
Cc: Qingliang Li <qingliang.li@mediatek.com>
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Only compile tested.
---
 drivers/pinctrl/mediatek/mtk-eint.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/mediatek/mtk-eint.c b/drivers/pinctrl/mediatek/mtk-eint.c
index 2a3c04eedc5f..47ac92ea98c2 100644
--- a/drivers/pinctrl/mediatek/mtk-eint.c
+++ b/drivers/pinctrl/mediatek/mtk-eint.c
@@ -246,7 +246,7 @@ static int mtk_eint_irq_set_wake(struct irq_data *d, unsigned int on)
 }
 
 static void mtk_eint_chip_write_mask(const struct mtk_eint *eint,
-				     void __iomem *base, unsigned int **buf)
+				     unsigned int **buf)
 {
 	int inst, port, port_num;
 	void __iomem *reg;
@@ -425,7 +425,7 @@ static void mtk_eint_irq_handler(struct irq_desc *desc)
 
 int mtk_eint_do_suspend(struct mtk_eint *eint)
 {
-	mtk_eint_chip_write_mask(eint, eint->base, eint->wake_mask);
+	mtk_eint_chip_write_mask(eint, eint->wake_mask);
 
 	return 0;
 }
@@ -433,7 +433,7 @@ EXPORT_SYMBOL_GPL(mtk_eint_do_suspend);
 
 int mtk_eint_do_resume(struct mtk_eint *eint)
 {
-	mtk_eint_chip_write_mask(eint, eint->base, eint->cur_mask);
+	mtk_eint_chip_write_mask(eint, eint->cur_mask);
 
 	return 0;
 }
-- 
2.54.0.rc2.544.gc7ae2d5bb8-goog



^ permalink raw reply related

* [PATCH] pinctrl: mediatek: paris: Directly modify registers to set GPIO direction
From: Chen-Yu Tsai @ 2026-04-27  2:10 UTC (permalink / raw)
  To: Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
	Linus Walleij
  Cc: Chen-Yu Tsai, linux-mediatek, linux-gpio, linux-arm-kernel,
	linux-kernel

pinctrl_gpio_direction_input() / pinctrl_gpio_direction_output() take
the pinctrl mutex. This causes a gpiochip operations to need to sleep.
Worse yet, the .can_sleep field in the gpiochip is not set. This causes
the shared GPIO proxy to trip over, as it uses gpiod_cansleep() to check
whether it can use a spinlock or needs a mutex. In this case, it ends
up taking a spinlock, then calls pinctrl_gpio_direction_output(), which
takes a mutex. This causes a huge warning.

While this class of Mediatek hardware does not have separate clear/set
registers, the pinctrl context has a spinlock that is taken whenever
a register read-modify-write is done.

Switch to directly setting the GPIO direction register bits to avoid
the mutex.

Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
 drivers/pinctrl/mediatek/pinctrl-paris.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c b/drivers/pinctrl/mediatek/pinctrl-paris.c
index 6bf37d8085fa..e4c0bc27d984 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -886,19 +886,24 @@ static int mtk_gpio_set(struct gpio_chip *chip, unsigned int gpio, int value)
 
 static int mtk_gpio_direction_input(struct gpio_chip *chip, unsigned int gpio)
 {
-	return pinctrl_gpio_direction_input(chip, gpio);
+	struct mtk_pinctrl *hw = gpiochip_get_data(chip);
+	const struct mtk_pin_desc *desc = &hw->soc->pins[gpio];
+
+	return mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_DIR, 0);
 }
 
 static int mtk_gpio_direction_output(struct gpio_chip *chip, unsigned int gpio,
 				     int value)
 {
+	struct mtk_pinctrl *hw = gpiochip_get_data(chip);
+	const struct mtk_pin_desc *desc = &hw->soc->pins[gpio];
 	int ret;
 
 	ret = mtk_gpio_set(chip, gpio, value);
 	if (ret)
 		return ret;
 
-	return pinctrl_gpio_direction_output(chip, gpio);
+	return mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_DIR, 1);
 }
 
 static int mtk_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
-- 
2.54.0.rc2.544.gc7ae2d5bb8-goog



^ permalink raw reply related

* Re: [PATCH v8 1/4] coresight: cti: Convert trigger usage fields to dynamic bitmaps and arrays
From: Jie Gan @ 2026-04-27  1:48 UTC (permalink / raw)
  To: Yingchao Deng, Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
	Alexander Shishkin
  Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
	quic_yingdeng, Jinlong Mao, Tingwei Zhang
In-Reply-To: <20260426-extended-cti-v8-1-23b900a4902f@oss.qualcomm.com>



On 4/26/2026 5:44 PM, Yingchao Deng wrote:
> Replace the fixed-size u32 fields in the cti_config and cti_trig_grp
> structure with dynamically allocated bitmaps and arrays. This allows
> memory to be allocated based on the actual number of triggers during probe
> time, reducing memory footprint and improving scalability for platforms
> with varying trigger counts.
> 
> Signed-off-by: Yingchao Deng <yingchao.deng@oss.qualcomm.com>
> ---
>   drivers/hwtracing/coresight/coresight-cti-core.c   | 59 +++++++++++++++++-----
>   .../hwtracing/coresight/coresight-cti-platform.c   | 26 +++++++---
>   drivers/hwtracing/coresight/coresight-cti-sysfs.c  | 14 ++---
>   drivers/hwtracing/coresight/coresight-cti.h        | 12 ++---
>   4 files changed, 76 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/drivers/hwtracing/coresight/coresight-cti-core.c
> index 2f4c9362709a..4e7d12bd2d3e 100644
> --- a/drivers/hwtracing/coresight/coresight-cti-core.c
> +++ b/drivers/hwtracing/coresight/coresight-cti-core.c
> @@ -161,8 +161,8 @@ void cti_write_intack(struct device *dev, u32 ackval)
>   /* DEVID[19:16] - number of CTM channels */
>   #define CTI_DEVID_CTMCHANNELS(devid_val) ((int) BMVAL(devid_val, 16, 19))
>   
> -static void cti_set_default_config(struct device *dev,
> -				   struct cti_drvdata *drvdata)
> +static int cti_set_default_config(struct device *dev,
> +				  struct cti_drvdata *drvdata)
>   {
>   	struct cti_config *config = &drvdata->config;
>   	u32 devid;
> @@ -181,6 +181,26 @@ static void cti_set_default_config(struct device *dev,
>   		config->nr_trig_max = CTIINOUTEN_MAX;
>   	}
>   
> +	config->trig_in_use = devm_bitmap_zalloc(dev, config->nr_trig_max, GFP_KERNEL);
> +	if (!config->trig_in_use)
> +		return -ENOMEM;
> +
> +	config->trig_out_use = devm_bitmap_zalloc(dev, config->nr_trig_max, GFP_KERNEL);
> +	if (!config->trig_out_use)
> +		return -ENOMEM;
> +
> +	config->trig_out_filter = devm_bitmap_zalloc(dev, config->nr_trig_max, GFP_KERNEL);
> +	if (!config->trig_out_filter)
> +		return -ENOMEM;
> +
> +	config->ctiinen = devm_kcalloc(dev, config->nr_trig_max, sizeof(u32), GFP_KERNEL);
> +	if (!config->ctiinen)
> +		return -ENOMEM;
> +
> +	config->ctiouten = devm_kcalloc(dev, config->nr_trig_max, sizeof(u32), GFP_KERNEL);
> +	if (!config->ctiouten)
> +		return -ENOMEM;
> +
>   	config->nr_ctm_channels = CTI_DEVID_CTMCHANNELS(devid);
>   
>   	/* Most regs default to 0 as zalloc'ed except...*/
> @@ -189,6 +209,7 @@ static void cti_set_default_config(struct device *dev,
>   	config->enable_req_count = 0;
>   
>   	config->asicctl_impl = !!FIELD_GET(GENMASK(4, 0), devid);
> +	return 0;
>   }
>   
>   /*
> @@ -219,8 +240,10 @@ int cti_add_connection_entry(struct device *dev, struct cti_drvdata *drvdata,
>   	cti_dev->nr_trig_con++;
>   
>   	/* add connection usage bit info to overall info */
> -	drvdata->config.trig_in_use |= tc->con_in->used_mask;
> -	drvdata->config.trig_out_use |= tc->con_out->used_mask;
> +	bitmap_or(drvdata->config.trig_in_use, drvdata->config.trig_in_use,
> +		  tc->con_in->used_mask, drvdata->config.nr_trig_max);
> +	bitmap_or(drvdata->config.trig_out_use, drvdata->config.trig_out_use,
> +		  tc->con_out->used_mask, drvdata->config.nr_trig_max);
>   
>   	return 0;
>   }
> @@ -231,6 +254,8 @@ struct cti_trig_con *cti_allocate_trig_con(struct device *dev, int in_sigs,
>   {
>   	struct cti_trig_con *tc = NULL;
>   	struct cti_trig_grp *in = NULL, *out = NULL;
> +	struct cti_drvdata *drvdata = dev_get_drvdata(dev);
> +	int n_trigs = drvdata->config.nr_trig_max;
>   
>   	tc = devm_kzalloc(dev, sizeof(struct cti_trig_con), GFP_KERNEL);
>   	if (!tc)
> @@ -242,12 +267,20 @@ struct cti_trig_con *cti_allocate_trig_con(struct device *dev, int in_sigs,
>   	if (!in)
>   		return NULL;
>   
> +	in->used_mask = devm_bitmap_zalloc(dev, n_trigs, GFP_KERNEL);
> +	if (!in->used_mask)
> +		return NULL;
> +
>   	out = devm_kzalloc(dev,
>   			   offsetof(struct cti_trig_grp, sig_types[out_sigs]),
>   			   GFP_KERNEL);
>   	if (!out)
>   		return NULL;
>   
> +	out->used_mask = devm_bitmap_zalloc(dev, n_trigs, GFP_KERNEL);
> +	if (!out->used_mask)
> +		return NULL;
> +
>   	tc->con_in = in;
>   	tc->con_out = out;
>   	tc->con_in->nr_sigs = in_sigs;
> @@ -263,7 +296,6 @@ int cti_add_default_connection(struct device *dev, struct cti_drvdata *drvdata)
>   {
>   	int ret = 0;
>   	int n_trigs = drvdata->config.nr_trig_max;
> -	u32 n_trig_mask = GENMASK(n_trigs - 1, 0);
>   	struct cti_trig_con *tc = NULL;
>   
>   	/*
> @@ -274,8 +306,8 @@ int cti_add_default_connection(struct device *dev, struct cti_drvdata *drvdata)
>   	if (!tc)
>   		return -ENOMEM;
>   
> -	tc->con_in->used_mask = n_trig_mask;
> -	tc->con_out->used_mask = n_trig_mask;
> +	bitmap_fill(tc->con_in->used_mask, n_trigs);
> +	bitmap_fill(tc->con_out->used_mask, n_trigs);
>   	ret = cti_add_connection_entry(dev, drvdata, tc, NULL, "default");
>   	return ret;
>   }
> @@ -288,7 +320,6 @@ int cti_channel_trig_op(struct device *dev, enum cti_chan_op op,
>   {
>   	struct cti_drvdata *drvdata = dev_get_drvdata(dev->parent);
>   	struct cti_config *config = &drvdata->config;
> -	u32 trig_bitmask;
>   	u32 chan_bitmask;
>   	u32 reg_value;
>   	int reg_offset;
> @@ -298,18 +329,16 @@ int cti_channel_trig_op(struct device *dev, enum cti_chan_op op,
>   	   (trigger_idx >= config->nr_trig_max))
>   		return -EINVAL;
>   
> -	trig_bitmask = BIT(trigger_idx);
> -
>   	/* ensure registered triggers and not out filtered */
>   	if (direction == CTI_TRIG_IN)	{
> -		if (!(trig_bitmask & config->trig_in_use))
> +		if (!(test_bit(trigger_idx, config->trig_in_use)))
>   			return -EINVAL;
>   	} else {
> -		if (!(trig_bitmask & config->trig_out_use))
> +		if (!(test_bit(trigger_idx, config->trig_out_use)))
>   			return -EINVAL;
>   
>   		if ((config->trig_filter_enable) &&
> -		    (config->trig_out_filter & trig_bitmask))
> +		    test_bit(trigger_idx, config->trig_out_filter))
>   			return -EINVAL;
>   	}
>   
> @@ -687,7 +716,9 @@ static int cti_probe(struct amba_device *adev, const struct amba_id *id)
>   	raw_spin_lock_init(&drvdata->spinlock);
>   
>   	/* initialise CTI driver config values */
> -	cti_set_default_config(dev, drvdata);
> +	ret = cti_set_default_config(dev, drvdata);
> +	if (ret)
> +		return ret;
>   
>   	pdata = coresight_cti_get_platform_data(dev);
>   	if (IS_ERR(pdata)) {
> diff --git a/drivers/hwtracing/coresight/coresight-cti-platform.c b/drivers/hwtracing/coresight/coresight-cti-platform.c
> index 4eff96f48594..557debbc8ca4 100644
> --- a/drivers/hwtracing/coresight/coresight-cti-platform.c
> +++ b/drivers/hwtracing/coresight/coresight-cti-platform.c
> @@ -136,8 +136,8 @@ static int cti_plat_create_v8_etm_connection(struct device *dev,
>   		goto create_v8_etm_out;
>   
>   	/* build connection data */
> -	tc->con_in->used_mask = 0xF0; /* sigs <4,5,6,7> */
> -	tc->con_out->used_mask = 0xF0; /* sigs <4,5,6,7> */
> +	bitmap_set(tc->con_in->used_mask, 4, 4); /* sigs <4,5,6,7> */
> +	bitmap_set(tc->con_out->used_mask, 4, 4); /* sigs <4,5,6,7> */
>   
>   	/*
>   	 * The EXTOUT type signals from the ETM are connected to a set of input
> @@ -194,10 +194,10 @@ static int cti_plat_create_v8_connections(struct device *dev,
>   		goto of_create_v8_out;
>   
>   	/* Set the v8 PE CTI connection data */
> -	tc->con_in->used_mask = 0x3; /* sigs <0 1> */
> +	bitmap_set(tc->con_in->used_mask, 0, 2); /* sigs <0 1> */
>   	tc->con_in->sig_types[0] = PE_DBGTRIGGER;
>   	tc->con_in->sig_types[1] = PE_PMUIRQ;
> -	tc->con_out->used_mask = 0x7; /* sigs <0 1 2 > */
> +	bitmap_set(tc->con_out->used_mask, 0, 3); /* sigs <0 1 2 > */
>   	tc->con_out->sig_types[0] = PE_EDBGREQ;
>   	tc->con_out->sig_types[1] = PE_DBGRESTART;
>   	tc->con_out->sig_types[2] = PE_CTIIRQ;
> @@ -213,7 +213,7 @@ static int cti_plat_create_v8_connections(struct device *dev,
>   		goto of_create_v8_out;
>   
>   	/* filter pe_edbgreq - PE trigout sig <0> */
> -	drvdata->config.trig_out_filter |= 0x1;
> +	set_bit(0, drvdata->config.trig_out_filter);
>   
>   of_create_v8_out:
>   	return ret;
> @@ -257,7 +257,7 @@ static int cti_plat_read_trig_group(struct cti_trig_grp *tgrp,
>   	if (!err) {
>   		/* set the signal usage mask */
>   		for (idx = 0; idx < tgrp->nr_sigs; idx++)
> -			tgrp->used_mask |= BIT(values[idx]);
> +			set_bit(values[idx], tgrp->used_mask);
>   	}
>   
>   	kfree(values);
> @@ -316,23 +316,33 @@ static int cti_plat_process_filter_sigs(struct cti_drvdata *drvdata,
>   {
>   	struct cti_trig_grp *tg = NULL;
>   	int err = 0, nr_filter_sigs;
> +	int nr_trigs = drvdata->config.nr_trig_max;
>   
>   	nr_filter_sigs = cti_plat_count_sig_elements(fwnode,
>   						     CTI_DT_FILTER_OUT_SIGS);
>   	if (nr_filter_sigs == 0)
>   		return 0;
>   
> -	if (nr_filter_sigs > drvdata->config.nr_trig_max)
> +	if (nr_filter_sigs > nr_trigs)
>   		return -EINVAL;
>   
>   	tg = kzalloc_obj(*tg);
>   	if (!tg)
>   		return -ENOMEM;
>   
> +	tg->used_mask = bitmap_zalloc(nr_trigs, GFP_KERNEL);
> +	if (!tg->used_mask) {
> +		kfree(tg);
> +		return -ENOMEM;
> +	}
> +
>   	err = cti_plat_read_trig_group(tg, fwnode, CTI_DT_FILTER_OUT_SIGS);
>   	if (!err)
> -		drvdata->config.trig_out_filter |= tg->used_mask;
> +		bitmap_or(drvdata->config.trig_out_filter,
> +			  drvdata->config.trig_out_filter,
> +			  tg->used_mask, nr_trigs);

The error may be silently ignored when a memory allocation error 
occured. I think it's better to add a log print to tell user what happened.

Thanks,
Jie

>   
> +	bitmap_free(tg->used_mask);
>   	kfree(tg);
>   	return err;
>   }
> diff --git a/drivers/hwtracing/coresight/coresight-cti-sysfs.c b/drivers/hwtracing/coresight/coresight-cti-sysfs.c
> index 3fe2c916d228..2bbfa405cb6b 100644
> --- a/drivers/hwtracing/coresight/coresight-cti-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-cti-sysfs.c
> @@ -719,12 +719,12 @@ static ssize_t trigout_filtered_show(struct device *dev,
>   	struct cti_drvdata *drvdata = dev_get_drvdata(dev->parent);
>   	struct cti_config *cfg = &drvdata->config;
>   	int nr_trig_max = cfg->nr_trig_max;
> -	unsigned long mask = cfg->trig_out_filter;
> +	unsigned long *mask = cfg->trig_out_filter;
>   
> -	if (mask == 0)
> +	if (bitmap_empty(mask, nr_trig_max))
>   		return 0;
>   
> -	return sysfs_emit(buf, "%*pbl\n", nr_trig_max, &mask);
> +	return sysfs_emit(buf, "%*pbl\n", nr_trig_max, mask);
>   }
>   static DEVICE_ATTR_RO(trigout_filtered);
>   
> @@ -931,9 +931,9 @@ static ssize_t trigin_sig_show(struct device *dev,
>   	struct cti_trig_con *con = (struct cti_trig_con *)ext_attr->var;
>   	struct cti_drvdata *drvdata = dev_get_drvdata(dev->parent);
>   	struct cti_config *cfg = &drvdata->config;
> -	unsigned long mask = con->con_in->used_mask;
> +	unsigned long *mask = con->con_in->used_mask;
>   
> -	return sysfs_emit(buf, "%*pbl\n", cfg->nr_trig_max, &mask);
> +	return sysfs_emit(buf, "%*pbl\n", cfg->nr_trig_max, mask);
>   }
>   
>   static ssize_t trigout_sig_show(struct device *dev,
> @@ -945,9 +945,9 @@ static ssize_t trigout_sig_show(struct device *dev,
>   	struct cti_trig_con *con = (struct cti_trig_con *)ext_attr->var;
>   	struct cti_drvdata *drvdata = dev_get_drvdata(dev->parent);
>   	struct cti_config *cfg = &drvdata->config;
> -	unsigned long mask = con->con_out->used_mask;
> +	unsigned long *mask = con->con_out->used_mask;
>   
> -	return sysfs_emit(buf, "%*pbl\n", cfg->nr_trig_max, &mask);
> +	return sysfs_emit(buf, "%*pbl\n", cfg->nr_trig_max, mask);
>   }
>   
>   /* convert a sig type id to a name */
> diff --git a/drivers/hwtracing/coresight/coresight-cti.h b/drivers/hwtracing/coresight/coresight-cti.h
> index c5f9e79fabc6..ef079fc18b72 100644
> --- a/drivers/hwtracing/coresight/coresight-cti.h
> +++ b/drivers/hwtracing/coresight/coresight-cti.h
> @@ -68,7 +68,7 @@ struct fwnode_handle;
>    */
>   struct cti_trig_grp {
>   	int nr_sigs;
> -	u32 used_mask;
> +	unsigned long *used_mask;
>   	int sig_types[];
>   };
>   
> @@ -145,17 +145,17 @@ struct cti_config {
>   	int enable_req_count;
>   
>   	/* registered triggers and filtering */
> -	u32 trig_in_use;
> -	u32 trig_out_use;
> -	u32 trig_out_filter;
> +	unsigned long *trig_in_use;
> +	unsigned long *trig_out_use;
> +	unsigned long *trig_out_filter;
>   	bool trig_filter_enable;
>   	u8 xtrig_rchan_sel;
>   
>   	/* cti cross trig programmable regs */
>   	u32 ctiappset;
>   	u8 ctiinout_sel;
> -	u32 ctiinen[CTIINOUTEN_MAX];
> -	u32 ctiouten[CTIINOUTEN_MAX];
> +	u32 *ctiinen;
> +	u32 *ctiouten;
>   	u32 ctigate;
>   	u32 asicctl;
>   };
> 



^ permalink raw reply

* Re: [PATCH v5 3/6] pwm: Add rockchip PWMv4 driver
From: Damon Ding @ 2026-04-27  1:20 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: Nicolas Frattaroli, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Heiko Stuebner, Lee Jones, William Breathitt Gray,
	kernel, Jonas Karlman, Alexey Charkov, linux-rockchip, linux-pwm,
	devicetree, linux-arm-kernel, linux-kernel, linux-iio
In-Reply-To: <ae4MCRE_hGJ-VcBQ@monoceros>

Hi Uwe,

On 4/26/2026 9:06 PM, Uwe Kleine-König wrote:
> Hello,
> 
> first of all thanks for your extensive testing, very appreciated.
> 
> On Sun, Apr 26, 2026 at 05:44:46PM +0800, Damon Ding wrote:
>> On 4/20/2026 9:52 PM, Nicolas Frattaroli wrote:
>>> The Rockchip RK3576 brings with it a new PWM IP, in downstream code
>>> referred to as "v4". This new IP is different enough from the previous
>>> Rockchip IP that I felt it necessary to add a new driver for it, instead
>>> of shoehorning it in the old one.
>>>
>>> Add this new driver, based on the PWM core's waveform APIs. Its platform
>>> device is registered by the parent mfpwm driver, from which it also
>>> receives a little platform data struct, so that mfpwm can guarantee that
>>> all the platform device drivers spread across different subsystems for
>>> this specific hardware IP do not interfere with each other.
>>>
>>> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>> Tested-by: Damon Ding <damon.ding@rock-chips.com>
>>
>> The continuous mode of all PWM channels has been preliminarily tested
>> and verified working on the RK3576 IoT board.
>>
>> I have tested with several typical period and duty cycle configurations.
>>
>> Following Uwe's suggestion [0], I also tested with libpwm using commands
>> similar to the following:
>>
>> ./pwmset -c 0 -p 0 -P 1000000 -D 500000 -s 5000
> 
> This one is good if you have an oscilloscope (or something similar) to
> verify the output. Without that (or additionally) pwmtestperf creates a
> series of requests that in combination with PWM_DEBUG should uncover
> rounding errors in the .tohw and .fromhw callbacks.

Aha, this is my oversight. I did not elaborate on my verification 
methods. ;-)

I have adopted three ways to complete the test:

1. Measure the output waveform of each channel with a simple logic 
analyzer, Kinst LA2016.
2. Read relevant registers to verify that the configured period and duty 
values match expectations.
3. Connect the PWM continuous output pins to capture input pins 
directly, to confirm the capture measurement results.

> 
> A good set of calls then is:
> 
> 	pwmtestperf -p ... -c ... -P 50000 -S1
> 	pwmtestperf -p ... -c ... -P 50000 -S1 -I
> 
> 	pwmtestperf -p ... -c ... -P 50000 -S-1
> 	pwmtestperf -p ... -c ... -P 50000 -S-1 -I
> 
> (Assuming that 50000 is a sensible period for the device under test.)
> 

Okay, I will look into this tool and run these commands to conduct more 
in-depth verification.

> And yes, I know, I need to document that using something more permanent
> than a mailing list post.
> 

Best regards,
Damon



^ permalink raw reply

* Re: [PATCH v2 3/4] ARM: dts: renesas: r8a7740: Add ZT/ZTR trace clock on R-Mobile A1
From: Marek Vasut @ 2026-04-27  0:32 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Marek Vasut
  Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
	Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
	Stephen Boyd, devicetree, linux-clk, linux-kernel,
	linux-renesas-soc
In-Reply-To: <d246edd2-5f9d-4e95-850d-abff175088a6@kernel.org>

On 4/23/26 4:00 PM, Krzysztof Kozlowski wrote:

Hello Krzysztof,

>>>> "
>>>> WARNING: DT binding docs and includes should be a separate patch. See:
>>>> Documentation/devicetree/bindings/submitting-patches.rst
>>>
>>> So you did not implement it... Include goes with the binding. Always.
>>> Look at other commits.
>> The warning says the exact opposite thing , does it not ?
>>
>> Maybe the warning text needs to be updated ?
> 
> The warning is shown for patches mixing stuff, like DTSI+header, so for
> this context the AND means binding doc plus header are separate FROM
> this patch. Not separate from each other.

Oh, thank you for the clarification.

> To me it is clear, so I don't feel like finding different text. If you
> find it unclear or confusing, you should propose something better.

How about this:

"
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 0d18771f1b013..715a98ccc69f7 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2957,7 +2957,7 @@ sub process {
                                 if (($last_binding_patch != -1) &&
                                     ($last_binding_patch ^ 
$is_binding_patch)) {
                                         WARN("DT_SPLIT_BINDING_PATCH",
-                                            "DT binding docs and 
includes should be a separate patch. See: 
Documentation/devicetree/bindings/submitting-patches.rst\n");
+                                            "DT binding docs and 
includes should be a single patch, but separate from this patch. See: 
Documentation/devicetree/bindings/submitting-patches.rst\n");
                                 }
                         }
"


^ permalink raw reply related

* [PATCH] soc: imx8m: Fix match data lookup for soc device
From: Peng Fan (OSS) @ 2026-04-27  1:01 UTC (permalink / raw)
  To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
	Greg Kroah-Hartman, Rob Herring (Arm), Bartosz Golaszewski
  Cc: imx, linux-arm-kernel, linux-kernel, Peng Fan

From: Peng Fan <peng.fan@nxp.com>

The i.MX8M soc device is registered via platform_device_register_simple(),
so it is not associated with a Device Tree node and the imx8m_soc_driver
has no of_match_table.

As a result, device_get_match_data() always returns NULL when probing
the soc device.

Retrieve the match data directly from the machine compatible using
of_machine_get_match_data(imx8_soc_match), which provides the correct SoC
data.

Fixes: 2524b293a59e5 ("soc: imx8m: don't access of_root directly")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 drivers/soc/imx/soc-imx8m.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/imx/soc-imx8m.c b/drivers/soc/imx/soc-imx8m.c
index 77763a107edbd11302017e3f61ecb4369fda1ab0..fc080e56f50d423b88a673181a6bc986eb4c1691 100644
--- a/drivers/soc/imx/soc-imx8m.c
+++ b/drivers/soc/imx/soc-imx8m.c
@@ -247,7 +247,7 @@ static int imx8m_soc_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
-	data = device_get_match_data(dev);
+	data = of_machine_get_match_data(imx8_soc_match);
 	if (data) {
 		soc_dev_attr->soc_id = data->name;
 		ret = imx8m_soc_prepare(pdev, data->ocotp_compatible);

---
base-commit: 70c8a7ec6715b5fb14e501731b5b9210a16684f7
change-id: 20260424-soc-imx8m-fix-90d7ce2397f5

Best regards,
-- 
Peng Fan <peng.fan@nxp.com>



^ permalink raw reply related

* Re: [PATCH] dt-bindings: Remove the redundant 'type: boolean'
From: Bui Duc Phuc @ 2026-04-27  0:19 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: robh, krzk+dt, conor+dt, nick, dmitry.torokhov, nicolas.ferre,
	alexandre.belloni, claudiu.beznea, lee, heiko, gregkh, linusw,
	zyw, zhangqing, gene_chen, linux-input, devicetree,
	linux-arm-kernel, linux-usb
In-Reply-To: <a145db93-a8ad-4bee-8404-21f356d7d4ab@kernel.org>

Hi Krzysztof,

> Why did you change one file and ignore the rest?

I'm processing the remaining files with caution. Files without
significant descriptions or context will be updated in the upcoming
patches.
Those with specific descriptions require deeper review and will be
handled in separate patch series later.

> Why did you not mention previous feedback I gave you on your patches

> (some time ago), that there are TWO TYPES defined for wakeup-source.

Thanks for mentioning this.
In v2 of the patch, I reviewed the previous discussion between you and
Connor regarding the two types for wakeup-source.
https://lore.kernel.org/all/20260316034606.11304-1-phucduc.bui@gmail.com/

When moving to v3, I followed Rob’s suggestion to use true. I also
sent a follow-up email to confirm this approach,
and since I did not receive further comments, I assumed this direction
was acceptable.

https://lore.kernel.org/all/CAABR9nH3hr+Y5ksD0cn3Gd9XUvmb07X7zJw0b4k_yVbnAuz9=w@mail.gmail.com/


Best Regards,
Phuc


^ permalink raw reply

* Re: [PATCH 1/1] Revert "scsi: ufs: Use pre-calculated offsets in ufshcd_init_lrb()"
From: Ed Tsai (蔡宗軒) @ 2026-04-26 23:41 UTC (permalink / raw)
  To: avri.altman@sandisk.com, matthias.bgg@gmail.com,
	AngeloGioacchino Del Regno, bvanassche@acm.org,
	alim.akhtar@samsung.com, martin.petersen@oracle.com,
	James.Bottomley@HansenPartnership.com
  Cc: Alice Chao (趙珮均), linux-scsi@vger.kernel.org,
	wsd_upstream, linux-kernel@vger.kernel.org,
	Chun-Hung Wu (巫駿宏),
	linux-arm-kernel@lists.infradead.org,
	Naomi Chu (朱詠田),
	linux-mediatek@lists.infradead.org,
	Peter Wang (王信友)
In-Reply-To: <a496a84b-66c8-452e-99b6-622550afeae5@acm.org>

On Fri, 2026-04-24 at 15:55 -0700, Bart Van Assche wrote:
> 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> On 4/23/26 11:35 PM, ed.tsai@mediatek.com wrote:
> > Note that these DMA addresses are only used in ufshcd_print_tr()
> > for
> > error logging, so the impact is limited to misleading error logs.
> 
> Instead of fixing these offsets, please remove the ucd_rsp_dma_addr
> and
> ucd_prdt_dma_addr members from struct ufshcd_lrb.
> 
> Thanks,
> 
> Bart.

Sounds good, I will send a new patch. Thanks.

^ permalink raw reply

* Re: [PATCH 2/2] ASoC: dt-bindings: drop redundant wakeup-source definitions
From: Bui Duc Phuc @ 2026-04-26 23:40 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Lee Jones, Mark Brown, Liam Girdwood, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Joseph Chen,
	Chris Zhong, Zhang Qing, David Rau, Animesh Agarwal, devicetree,
	linux-sound, linux-rockchip, linux-arm-kernel, linux-kernel
In-Reply-To: <20260423-ingenious-psychedelic-jaybird-40bb4d@quoll>

Hi,

> > The 'wakeup-source' property already has its type defined in the core


> TYPES. It is plural.


Thank you for pointing that out. That was a mistake in my wording.
Regarding the two data types, I’m already aware of this and have
discussed it in a previous patch.

https://lore.kernel.org/all/CAABR9nH3hr+Y5ksD0cn3Gd9XUvmb07X7zJw0b4k_yVbnAuz9=w@mail.gmail.com/

> > -  wakeup-source:

> > -    type: boolean

> > -    description:

> > -      Flag to indicate this device can wake system (suspend/resume).

> > +  wakeup-source: true

>

> That's wrong. Commit msg is making here false statements that it is

> redundant. I checked (and you should too!) and driver does clearly

> device_property_read_bool() thus the property CANNOT be the second type.

I think Device Tree bindings should describe the hardware capability.
If the hardware supports wakeup functionality,
referencing the core schema is sufficient. Hardware description should
not be constrained by the current driver implementation
( e.g. the use of device_property_read_bool() ).
Bindings should remain stable and generic, while drivers can evolve over time.

Re-defining the type locally duplicates the core definition. If the
core schema evolves,
this approach would require touching many bindings instead of updating
one central place.

This follows the recent cleanups suggested by Rob

https://lore.kernel.org/all/177628888260.592110.11727813820499601669.robh@kernel.org/
https://lore.kernel.org/all/177679687272.1458365.1328485324673928433.robh@kernel.org/

Best regards,
Phuc


^ permalink raw reply

* New Order- REQUEST FOR QUOTATION-URGENT
From: Andriana Agathocleous @ 2026-04-24  8:52 UTC (permalink / raw)
  To: linux-arm-kernel

Dear Sir/Madam,

Good day.

I am Andriana Agathocleous , Due to our recent project, we want 
to make inquiries about your products and we wish to establish a 
potential business cooperation with your Company. I will send 
requirements for your perusal and quote upon receiving your 
feedback.

Please kindly send your current catalogue, price list, payment 
terms.

Kindly acknowledge this communication and send me feedback upon 
receipt so we can place the order without any further delays.

Best Regards,
Andriana Agathocleous


^ permalink raw reply

* [PATCH] Documentation: ABI: sysfs-class-reboot-mode-reboot_modes: fix doc warnings
From: Randy Dunlap @ 2026-04-26 23:27 UTC (permalink / raw)
  To: linux-kernel
  Cc: Randy Dunlap, linux-pm, linux-arm-kernel, Bartosz Golaszewski,
	Sebastian Reichel, Shivendra Pratap, linux-doc

Repair the docs build warnings in this file by unindenting the description,
adding blank lines, and using `` to quote *arg.

WARNING: Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:36: abi_sys_class_reboot_mode_driver_reboot_modes doesn't have a description
Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils]
Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils]
Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: WARNING: Inline emphasis start-string without end-string. [docutils]
Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils]

Fixes: d3da03025e6d ("Documentation: ABI: Add sysfs-class-reboot-mode-reboot_modes")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: linux-pm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Bartosz Golaszewski <brgl@kernel.org>
Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
Cc: linux-doc@vger.kernel.org

 Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes |   13 ++++++----
 1 file changed, 8 insertions(+), 5 deletions(-)

--- linux-next-20260424.orig/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes
+++ linux-next-20260424/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes
@@ -2,33 +2,36 @@ What:		/sys/class/reboot-mode/<driver>/r
 Date:		March 2026(TBD)
 KernelVersion:	TBD
 Contact:	linux-pm@vger.kernel.org
-		Description:
+Description:
 		This interface exposes the reboot-mode arguments
 		registered with the reboot-mode framework. It is
 		a read-only interface and provides a space
 		separated list of reboot-mode arguments supported
 		on the current platform.
 		Example:
+
 		 recovery fastboot bootloader
 
 		The exact sysfs path may vary depending on the
 		name of the driver that registers the arguments.
-		Example:
+		Example::
+
 		 /sys/class/reboot-mode/nvmem-reboot-mode/reboot_modes
 		 /sys/class/reboot-mode/syscon-reboot-mode/reboot_modes
 		 /sys/class/reboot-mode/qcom-pon/reboot_modes
 
 		The supported arguments can be used by userspace to
 		invoke device reset using the standard reboot() system
-		call interface, with the "argument" as string to "*arg"
-		parameter along with LINUX_REBOOT_CMD_RESTART2.
+		call interface, with the "argument" as string to ``*arg``
+		parameter along with ``LINUX_REBOOT_CMD_RESTART2``.
 
 		A driver can expose the supported arguments by
 		registering them with the reboot-mode framework
 		using the property names that follow the
 		mode-<argument> format.
 		Example:
-		 mode-bootloader, mode-recovery.
+
+		 mode-bootloader, mode-recovery
 
 		This attribute is useful for scripts or initramfs
 		logic that need to programmatically determine


^ permalink raw reply

* Re: (subset) [PATCH 0/3] spi: rockchip: ISR fix and minor cleanups
From: Mark Brown @ 2026-04-26 21:57 UTC (permalink / raw)
  To: heiko, John Madieu
  Cc: jon.lin, linux-spi, linux-arm-kernel, linux-rockchip,
	linux-kernel
In-Reply-To: <20260425092936.2590132-1-john.madieu@gmail.com>

On Sat, 25 Apr 2026 09:29:33 +0000, John Madieu wrote:
> spi: rockchip: ISR fix and minor cleanups
> 
> Hi all,
> 
> This series fixes one real bug in the Rockchip SPI driver and tidies up
> two unrelated cosmetic issues spotted while looking at the same area.
> The patches are independent and could be applied in any order; they are
> ordered here by decreasing severity.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.1

Thanks!

[1/3] spi: rockchip: Read ISR, not IMR, to detect cs-inactive IRQ
      https://git.kernel.org/broonie/spi/c/b4683a239a40
[2/3] spi: rockchip: Drop unused and broken CR0 macros
      https://git.kernel.org/broonie/spi/c/7643978722aa

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



^ permalink raw reply

* Re: [PATCH] Change manual bitfield manipulation to use FIELD_PREP()
From: Mark Brown @ 2026-04-26 21:53 UTC (permalink / raw)
  To: claudiu.beznea, andrei.simion, lgirdwood, perex, tiwai,
	nicolas.ferre, alexandre.belloni, Gabriel Jacob Perin
  Cc: carlos.albmr, linux-sound, linux-arm-kernel
In-Reply-To: <20260421193113.1060213-1-gabrieljp@usp.br>

On Tue, 21 Apr 2026 16:31:13 -0300, Gabriel Jacob Perin wrote:
> Change manual bitfield manipulation to use FIELD_PREP()

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2

Thanks!

[1/1] Change manual bitfield manipulation to use FIELD_PREP()
      https://git.kernel.org/broonie/sound/c/ae93afff9818

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox