* Re: [PATCH v3 4/4] iio: light: veml6031x00: add support for events and trigger
From: Javier Carrasco @ 2026-05-25 8:59 UTC (permalink / raw)
To: sashiko-reviews, Javier Carrasco; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260525001350.987641F000E9@smtp.kernel.org>
On Mon May 25, 2026 at 2:13 AM CEST, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 8 potential issue(s) to consider:
>
> New issues:
> - [High] Cache pollution of AF_TRIG causes unintended conversions and unnecessary I2C reads.
> - [High] The trigger reference acquired via iio_trigger_get() is leaked on probe error paths and driver unbind.
> - [High] PM runtime usage counter leaks if the driver unbinds while an event is enabled.
> - [High] Sysfs read/write functions and trigger operations access hardware without acquiring a PM runtime reference.
> - [High] Out-of-bounds array write in veml6031x00_trig_handler when the timestamp channel is enabled.
> - [Medium] Dead event sysfs attributes are exposed when no IRQ is present.
>
> Pre-existing issues:
> - [High] Unbalanced double-put of the runtime PM usage counter on driver unbind.
> - [High] The shutdown action accesses I2C registers after PM runtime has been disabled.
> --
>
> commit cbdd69d1454af4788d5d18a23d3fb6854c9981e9
> Author: Javier Carrasco <javier.carrasco.cruz@gmail.com>
>
> iio: light: veml6031x00: add support for events and trigger
>
> The device provides a shared interrupt line for to notify events and
> data ready, which can be used as a trigger. The interrupt line is not a
> requirement for the device to work. Implement variants for the cases
> whether the interrupt line is provided or not.
>
>> diff --git a/drivers/iio/light/veml6031x00.c b/drivers/iio/light/veml6031x00.c
>> index 9968d4414dc96..c57aaa29abf30 100644
>> --- a/drivers/iio/light/veml6031x00.c
>> +++ b/drivers/iio/light/veml6031x00.c
>
> [ ... ]
>
>> @@ -136,6 +189,8 @@ static const struct iio_chan_spec veml6031x00_channels[] = {
>> .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_INT_TIME),
>> .info_mask_shared_by_all_available = BIT(IIO_CHAN_INFO_INT_TIME),
>> .info_mask_separate_available = BIT(IIO_CHAN_INFO_SCALE),
>> + .event_spec = veml6031x00_event_spec,
>> + .num_event_specs = ARRAY_SIZE(veml6031x00_event_spec),
>
> [Severity: Medium]
> Will this expose dead event sysfs attributes when no IRQ is present?
>
> When i2c->irq is 0, the driver registers veml6031x00_info_no_irq which lacks
> event callbacks. However, this channel array unconditionally defines
> event_spec and num_event_specs. The IIO core will parse these and expose
> event sysfs files. Reading or writing these files will fail with -EINVAL
> because the callbacks are NULL, which violates the sysfs API contract.
>
> [ ... ]
>
@Jonathan: is this how it really works? How can I then dynamically
define even_spec to account for it?
>> +static int veml6031x00_read_event_val(struct iio_dev *iio,
>> + const struct iio_chan_spec *chan,
>> + enum iio_event_type type,
>> + enum iio_event_direction dir,
>> + enum iio_event_info info,
>> + int *val, int *val2)
>> +{
>
> [Severity: High]
> Are PM runtime references needed here before accessing hardware?
>
> This function, as well as veml6031x00_write_event_val() and
> veml6031x00_set_trigger_state(), performs I2C accesses via regmap without
> first calling pm_runtime_resume_and_get(). If the device is
> runtime-suspended and its PM domain has powered it off, will these I2C
> accesses fail or time out?
>
> [ ... ]
>
As I said for [2/4], reading registers in shutdown mode is absolutely
fine.
>> +static int veml6031x00_write_event_config(struct iio_dev *iio,
>> + const struct iio_chan_spec *chan,
>> + enum iio_event_type type,
>> + enum iio_event_direction dir,
>> + bool state)
>> +{
>> + struct veml6031x00_data *data = iio_priv(iio);
>> + int ret;
>> +
>> + guard(mutex)(&data->lock);
>> +
>> + /* avoid multiple increments/decrements from one source */
>> + if (state == data->ev_en)
>> + return 0;
>> +
>> + if (state) {
>> + ret = pm_runtime_resume_and_get(data->dev);
>
> [Severity: High]
> Could this leak the PM runtime usage counter if the driver unbinds?
>
> Enabling an event increments the PM runtime usage counter here. If the
> driver is unbound via sysfs while an event is enabled, the IIO core does
> not automatically disable the event. Since there is no unbind cleanup
> mechanism to release the pending PM reference when data->ev_en is true,
> does this keep the device powered on indefinitely?
>
> [ ... ]
>
@Jonathan: Does the IIO core let the event enabled? What is the
approach to clear it then?
>> +/* AF_TRIG is reset by hardware, but the rest of the fields are persistent */
>> +static int veml6031x00_set_af_trig(struct veml6031x00_data *data, bool state)
>> +{
>> + regcache_drop_region(data->regmap, VEML6031X00_REG_CONF0,
>> + VEML6031X00_REG_CONF0);
>> +
>> + return regmap_update_bits(data->regmap, VEML6031X00_REG_CONF0,
>> + VEML6031X00_CONF0_AF_TRIG,
>> + FIELD_PREP(VEML6031X00_CONF0_AF_TRIG, state));
>> +}
>
> [Severity: High]
> Can this cause unintentional active force conversions due to cache pollution?
>
> This sets the self-clearing AF_TRIG bit using regmap_update_bits().
> Because CONF0 is not marked as a volatile register, regmap_update_bits()
> writes AF_TRIG=1 and caches it. Any subsequent read-modify-write on CONF0
> (e.g., toggling the interrupt or changing integration time) will read the
> cached AF_TRIG=1 and write it back to hardware, unintentionally triggering
> an active force conversion and causing hardware state corruption.
>
> [ ... ]
>
I will define the CONF0 register as volatile to account for this.
>> static irqreturn_t veml6031x00_trig_handler(int irq, void *p)
>> {
>> struct iio_poll_func *pf = p;
>> struct iio_dev *iio = pf->indio_dev;
>> struct veml6031x00_data *data = iio_priv(iio);
>> int ch, ret, i = 0;
>> struct {
>> __le16 chans[2];
>> aligned_s64 timestamp;
>> } scan = { };
>>
>> if (*iio->active_scan_mask == (BIT(VEML6031X00_SCAN_ALS) |
>> BIT(VEML6031X00_SCAN_IR))) {
>> ret = regmap_bulk_read(data->regmap,
>> VEML6031X00_REG_ALS_L,
>> &scan.chans, sizeof(scan.chans));
>> if (ret)
>> goto done;
>> } else {
>> iio_for_each_active_channel(iio, ch) {
>> ret = regmap_bulk_read(data->regmap,
>> iio->channels[ch].address,
>> &scan.chans[i++],
>
> [Severity: High]
> Does this loop cause an out-of-bounds array write if the timestamp
> channel is enabled?
>
> The iio_for_each_active_channel() loop does not exclude the soft timestamp
> channel. If the user enables ALS, IR, and TIMESTAMP channels, the loop
> iterates 3 times. However, the scan.chans array is declared as
> __le16 chans[2]. Processing the timestamp channel increments the index i
> to 2 and writes to scan.chans[2], causing an out-of-bounds memory write.
>
> Furthermore, because the timestamp channel's address is 0, this incorrectly
> attempts a bogus I2C read from VEML6031X00_REG_CONF0.
>
> [ ... ]
>
Not sure if this is a real issue, and the address for channel 0 is not
CONF0 because it is defined in iio_chan_spec
veml6031x00_channels.address.
>> +static int veml6031x00_setup_irq(struct i2c_client *i2c, struct iio_dev *iio)
>> +{
>> + struct veml6031x00_data *data = iio_priv(iio);
>> + struct device *dev = data->dev;
>> + int ret;
>> +
>> + data->trig = devm_iio_trigger_alloc(dev, "%s-drdy%d", iio->name,
>> + iio_device_id(iio));
>> + if (!data->trig)
>> + return -ENOMEM;
>> +
>> + data->trig->ops = &veml6031x00_trigger_ops;
>> + iio_trigger_set_drvdata(data->trig, iio);
>> +
>> + ret = devm_iio_trigger_register(dev, data->trig);
>> + if (ret)
>> + return ret;
>> +
>> + iio->trig = iio_trigger_get(data->trig);
>
> [Severity: High]
> Is the trigger reference acquired here leaked on driver unbind?
>
> Calling iio_trigger_get() increments the trigger device's refcount and the
> driver module's refcount. If the driver fails probe afterwards or is unbound
> later, iio_trigger_put() is never called because there is no devres action
> registered for it and no custom remove callback. Does this permanently leak
> the trigger device reference and prevent the module from being unloaded?
>
> [ ... ]
>
Same here. I believe that only industrialio-trigger.c makes use of
iio_trigger_put().
>> @@ -618,6 +1039,10 @@ static int veml6031x00_probe(struct i2c_client *i2c)
>
> [ ... ]
>
>> ret = devm_add_action_or_reset(dev, veml6031x00_als_shutdown_action, data);
>
> [Severity: High]
> This is a pre-existing issue, but does this shutdown action access I2C
> registers after PM runtime has been disabled?
>
> This action is registered via devm_add_action_or_reset() before PM runtime
> is enabled. On teardown, devm actions run in reverse, meaning PM runtime is
> disabled before the shutdown action runs. The shutdown action then attempts
> I2C writes while PM runtime is disabled. If the device was suspended, it
> cannot be resumed, potentially causing I2C transfer failures.
>
> [ ... ]
>
>> pm_runtime_put_autosuspend(dev);
>
> [Severity: High]
> This is a pre-existing issue, but is there an unbalanced double-put of the
> runtime PM usage counter on driver unbind?
>
> The probe function registers a cleanup action to drop the PM reference via
> devm_pm_runtime_get_noresume(dev). However, this explicit put at the end
> of probe means the devm action will drop the reference a second time on
> unbind, causing a PM usage counter underflow that breaks the PM runtime
> state machine.
As I said for [2/4], there won't be any counter underflow that way.
Best,
Javier
^ permalink raw reply
* Re: [PATCH v3 8/8] ARM: dts: qcom: Add Samsung Galaxy S4
From: Linus Walleij @ 2026-05-25 9:01 UTC (permalink / raw)
To: sashiko-reviews
Cc: Alexandre MINETTE via B4 Relay, conor+dt, devicetree, robh
In-Reply-To: <20260519095042.B71A1C2BCB3@smtp.kernel.org>
On Tue, May 19, 2026 at 11:50 AM <sashiko-bot@kernel.org> wrote:
> > + i2c-muic {
> > + compatible = "i2c-gpio";
> > + sda-gpios = <&tlmm_pinmux 22 GPIO_ACTIVE_HIGH>;
> > + scl-gpios = <&tlmm_pinmux 23 GPIO_ACTIVE_HIGH>;
>
> Does this configuration omit the GPIO_OPEN_DRAIN flag?
That would be:
<&tlmm_pinmux 22 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
Sashiko is right, I2C is open drain by definition, if this doesn't work
something else is wrong, please look into it.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v18 0/7] coresight: ctcu: Enable byte-cntr function for TMC ETR
From: Jie Gan @ 2026-05-25 9:04 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Bjorn Andersson, Konrad Dybcio
Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
devicetree, Konrad Dybcio, Krzysztof Kozlowski
In-Reply-To: <20260507-enable-byte-cntr-for-ctcu-v18-0-2b2d590463a3@oss.qualcomm.com>
On 5/7/2026 10:11 PM, Jie Gan wrote:
> The byte-cntr function provided by the CTCU device is used to count the
> trace data entering the ETR. An interrupt is triggered if the data size
> exceeds the threshold set in the BYTECNTRVAL register. The interrupt
> handler counts the number of triggered interruptions.
>
Gentle ping.
I would be grateful if you could review this patch series when you have
time.
> Based on this concept, the irq_cnt can be used to determine whether
> the etr_buf is full. The ETR device will be disabled when the active
> etr_buf is nearly full or a timeout occurs. The nearly full buffer will
> be switched to background after synced. A new buffer will be picked from
> the etr_buf_list, then restart the ETR device.
>
> The byte-cntr reading functions can access data from the synced and
> deactivated buffer, transferring trace data from the etr_buf to userspace
> without stopping the ETR device.
>
> The byte-cntr read operation has integrated with the file node tmc_etr,
> for example:
> /dev/tmc_etr0
> /dev/tmc_etr1
>
> There are two scenarios for the tmc_etr file node with byte-cntr function:
> 1. BYTECNTRVAL register is configured and byte-cntr is enabled -> byte-cntr read
> 2. BYTECNTRVAL register is reset or byte-cntr is disabled -> original behavior
>
> Shell commands to enable byte-cntr reading for etr0:
> echo 1 > /sys/bus/coresight/devices/ctcu0/irq_enabled0
> echo 1 > /sys/bus/coresight/devices/tmc_etr0/enable_sink
> echo 1 > /sys/bus/coresight/devices/etm0/enable_source
> cat /dev/tmc_etr0
>
> Reset the BYTECNTR register for etr0:
> echo 0 > /sys/bus/coresight/devices/ctcu0/irq_enabled0
>
> Test Report:
> === Module setup ===
> CONFIG_CORESIGHT=y (built-in, no action needed)
> CONFIG_CORESIGHT_LINK_AND_SINK_TMC=y (built-in, no action needed)
> coresight-ctcu: not loaded, running modprobe...
> coresight-ctcu: loaded
> CTCU byte-cntr test
> CTCU : ctcu0
> ETR : tmc_etr0
> source : etm0
> chardev: /dev/tmc_etr0
> module : coresight-ctcu
>
> === T1: device presence ===
> PASS: CTCU device found: ctcu0
> PASS: TMC ETR device found: tmc_etr0
>
> === T2: irq_enabled sysfs attributes ===
> PASS: irq_enabled0 attribute exists
> PASS: irq_enabled0 readable, value=0
> PASS: irq_enabled1 attribute exists
> PASS: irq_enabled1 readable, value=0
>
> === T3: irq_enabled write/read round-trip ===
> PASS: irq_enabled0: write 1 -> read back 1
> PASS: irq_enabled0: write 0 -> read back 0
> PASS: irq_enabled1: write 1 -> read back 1
> PASS: irq_enabled1: write 0 -> read back 0
>
> === T4: byte-cntr read with active trace ===
> [step] cleanup: byte_cntr_disable
> [step] enable_source = 0 (etm0)
> [step] enable_sink = 0 (tmc_etr0)
> [step] set irq_enabled0 = 0
> [step] byte_cntr_disable done
> [step] byte_cntr_enable
> [step] set irq_enabled0 = 1
> [step] set buffer_size = 0x2000000
> [step] enable_sink = 1 (tmc_etr0)
> [step] enable_source = 1 (etm0)
> [step] byte_cntr_enable done
> [step] cat /dev/tmc_etr0 > /tmp/tmc_etr0.bin &
> [step] sleep 5 (accumulate trace data)
> [step] byte_cntr_disable
> [step] enable_source = 0 (etm0)
> [step] enable_sink = 0 (tmc_etr0)
> [step] set irq_enabled0 = 0
> [step] byte_cntr_disable done
> PASS: T4: cat exited naturally after source disabled (EOF delivered)
> PASS: byte-cntr read returned 35333968 bytes -> /tmp/tmc_etr0.bin
> PASS: no kernel warnings/oops after: byte-cntr read
>
> === T5: EBUSY on concurrent open while byte-cntr reading ===
> [step] enable_source = 0 (etm0)
> [step] enable_sink = 0 (tmc_etr0)
> [step] set irq_enabled0 = 0
> [step] byte_cntr_disable done
> [step] set irq_enabled0 = 1
> [step] set buffer_size = 0x2000000
> [step] enable_sink = 1 (tmc_etr0)
> [step] enable_source = 1 (etm0)
> [step] byte_cntr_enable done
> PASS: T5: second open correctly refused (EBUSY)
> [step] enable_source = 0 (etm0)
> [step] enable_sink = 0 (tmc_etr0)
> [step] set irq_enabled0 = 0
> [step] byte_cntr_disable done
> PASS: no kernel warnings/oops after: concurrent open test
>
> === T6: rmmod while byte-cntr read is active ===
> [step] enable_source = 0 (etm0)
> [step] enable_sink = 0 (tmc_etr0)
> [step] set irq_enabled0 = 0
> [step] byte_cntr_disable done
> [step] set irq_enabled0 = 1
> [step] set buffer_size = 0x2000000
> [step] enable_sink = 1 (tmc_etr0)
> [step] enable_source = 1 (etm0)
> [step] byte_cntr_enable done
> PASS: T6: rmmod returned non-zero (device busy), no panic
> PASS: no kernel warnings/oops after: rmmod while reading
> [step] enable_source = 0 (etm0)
> [step] enable_sink = 0 (tmc_etr0)
> [step] set irq_enabled0 = 0
> [step] byte_cntr_disable done
>
> === T7: insmod after rmmod and re-probe sanity ===
> [step] module still loaded after T6, retrying rmmod
> PASS: T7: modprobe coresight-ctcu succeeded
> PASS: T7: CTCU device reappeared: ctcu0
> PASS: no kernel warnings/oops after: insmod / re-probe
>
> ===================================
> ===================================
>
> Results: PASS=20 FAIL=0 SKIP=0
> ---
> Changes in v18:
> 1. add a NULL check for the in_conns instance in patch 1.
> 2. fix a bug in patch 2: the tmc_alloc_etr_buf never return NULL and the
> previous check for the return value is incorrect.
> 3. add more kernel_doc description for tmc_clean_etr_buf_list function
> in patch 2
> - Link to v17: https://lore.kernel.org/r/20260421-enable-byte-cntr-for-ctcu-v17-0-9cf36ff55fc0@oss.qualcomm.com
>
> Changes in v17:
> 1. fix race issue during allocat buffer.
> 2. fix user after free issue observed when remove module.
> - Link to v16: https://lore.kernel.org/r/20260323-enable-byte-cntr-for-ctcu-v16-0-7a413d211b8d@oss.qualcomm.com
>
> Changes in v16:
> 1. Remove lock/unlock processes in patch "coresight: tmc: add create/clean
> functions for etr_buf_list" because we are allocating/freeing memory.
> - Link to v15: https://lore.kernel.org/r/20260313-enable-byte-cntr-for-ctcu-v15-0-1777f14ed319@oss.qualcomm.com
>
> Changes in v15:
> 1. add lockdep_assert_held in patch "coresight: tmc: add create/clean
> functions for etr_buf_list"
> 2. optimize tmc_clean_etr_buf_list function
> 3. optimize the patch "enable byte-cntr for TMC ETR devices" according
> to Suzuki's comments
> - call byte_cntr_sysfs_ops from etr_sysfs_ops
> - optimize the lock usage in all functions
> - remove the buf_node parameter in etr_drvdata, move it to
> byte_cntr_data
> - move the tmc_reset_sysfs_buf function to tmc-etr.c
> - add a read flag to struct etr_buf_node to allow updating pos while
> traversing etr_buf_list during data reads.
> Link to v14: https://lore.kernel.org/r/20260309-enable-byte-cntr-for-ctcu-v14-0-c08823e5a8e6@oss.qualcomm.com
>
> Changes in V14:
> 1. Drop the patch: integrate byte-cntr's sysfs_ops with tmc sysfs file_ops
> 2. Replace tmc_sysfs_ops with byte_cntr_sysfs_ops in byte_cntr_start
> function and restore etr_sysfs_ops in byte_cntr_unprepare function.
> 3. Remove redundant checks in byte‑cntr functions.
> Link to V13: https://lore.kernel.org/all/20260223-enable-byte-cntr-for-ctcu-v13-0-9cb44178b250@oss.qualcomm.com/
>
> Changes in v13:
> 1. initilize the byte_cntr_data->raw_spin_lock before using.
> 2. replace kzalloc with kzalloc_obj.
> Link to V12: https://lore.kernel.org/all/20260203-enable-byte-cntr-for-ctcu-v12-0-7bf81b86b70e@oss.qualcomm.com/
>
> Changes in v12:
> 1. Add a new function for retrieving the CTCU's coresight_dev instead of
> refactor the existing function.
> Link to v11: https://lore.kernel.org/r/20260126-enable-byte-cntr-for-ctcu-v11-0-c0af66ba15cf@oss.qualcomm.com
>
> Changes in v11:
> 1. Correct the description in patch1 for the function coresight_get_in_port.
> 2. Renaming the sysfs_ops to tmc_sysfs_ops per Suzuki's suggestion.
> Link to v10: https://lore.kernel.org/r/20260122-enable-byte-cntr-for-ctcu-v10-0-22978e3c169f@oss.qualcomm.com
>
> Changes in v10:
> 1. fix a free memory issue that is reported by robot for patch 2.
> Link to v9: https://lore.kernel.org/r/20251224-enable-byte-cntr-for-ctcu-v9-0-886c4496fed4@oss.qualcomm.com
>
> Changes in v9:
> 1. Drop the patch: add a new API to retrieve the helper device
> 2. Add a new patch to refactor the tmc_etr_get_catu_device function,
> making it generic to support all types of helper devices associated with ETR.
> 3. Optimizing the code for creating irq_threshold sysfs node.
> 4. Remove interrupt-name property and obtain the IRQ based on the
> in-port number.
> Link to v8: https://lore.kernel.org/r/20251211-enable-byte-cntr-for-ctcu-v8-0-3e12ff313191@oss.qualcomm.com
>
> Changes in V8:
> 1. Optimizing the patch 1 and patch 2 according to Suzuki's comments.
> 2. Combine the patch 3 and patch 4 together.
> 3. Rename the interrupt-name to prevent confusion, for example:etr0->etrirq0.
> Link to V7 - https://lore.kernel.org/all/20251013-enable-byte-cntr-for-ctcu-v7-0-e1e8f41e15dd@oss.qualcomm.com/
>
> Changes in V7:
> 1. rebased on tag next-20251010
> 2. updated info for sysfs node document
> Link to V6 - https://lore.kernel.org/all/20250908-enable-byte-cntr-for-tmc-v6-0-1db9e621441a@oss.qualcomm.com/
>
> Changes in V6:
> 1. rebased on next-20250905.
> 2. fixed the issue that the dtsi file has re-named from sa8775p.dtsi to
> lemans.dtsi.
> 3. fixed some minor issues about comments.
> Link to V5 - https://lore.kernel.org/all/20250812083731.549-1-jie.gan@oss.qualcomm.com/
>
> Changes in V5:
> 1. Add Mike's reviewed-by tag for patchset 1,2,5.
> 2. Remove the function pointer added to helper_ops according to Mike's
> comment, it also results the patchset has been removed.
> 3. Optimizing the paired create/clean functions for etr_buf_list.
> 4. Remove the unneeded parameter "reading" from the etr_buf_node.
> Link to V4 - https://lore.kernel.org/all/20250725100806.1157-1-jie.gan@oss.qualcomm.com/
>
> Changes in V4:
> 1. Rename the function to coresight_get_in_port_dest regarding to Mike's
> comment (patch 1/10).
> 2. Add lock to protect the connections regarding to Mike's comment
> (patch 2/10).
> 3. Move all byte-cntr functions to coresight-ctcu-byte-cntr file.
> 4. Add tmc_read_ops to wrap all read operations for TMC device.
> 5. Add a function in helper_ops to check whether the byte-cntr is
> enabkled.
> 6. Call byte-cntr's read_ops if byte-cntr is enabled when reading data
> from the sysfs node.
> Link to V3 resend - https://lore.kernel.org/all/20250714063109.591-1-jie.gan@oss.qualcomm.com/
>
> Changes in V3 resend:
> 1. rebased on next-20250711.
> Link to V3 - https://lore.kernel.org/all/20250624060438.7469-1-jie.gan@oss.qualcomm.com/
>
> Changes in V3:
> 1. The previous solution has been deprecated.
> 2. Add a etr_buf_list to manage allcated etr buffers.
> 3. Add a logic to switch buffer for ETR.
> 4. Add read functions to read trace data from synced etr buffer.
> Link to V2 - https://lore.kernel.org/all/20250410013330.3609482-1-jie.gan@oss.qualcomm.com/
>
> Changes in V2:
> 1. Removed the independent file node /dev/byte_cntr.
> 2. Integrated the byte-cntr's file operations with current ETR file
> node.
> 3. Optimized the driver code of the CTCU that associated with byte-cntr.
> 4. Add kernel document for the export API tmc_etr_get_rwp_offset.
> 5. Optimized the way to read the rwp_offset according to Mike's
> suggestion.
> 6. Removed the dependency of the dts patch.
> Link to V1 - https://lore.kernel.org/all/20250310090407.2069489-1-quic_jiegan@quicinc.com/
>
> To: Suzuki K Poulose <suzuki.poulose@arm.com>
> To: Mike Leach <mike.leach@arm.com>
> To: James Clark <james.clark@linaro.org>
> To: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> To: Rob Herring <robh@kernel.org>
> To: Krzysztof Kozlowski <krzk+dt@kernel.org>
> To: Conor Dooley <conor+dt@kernel.org>
> To: Tingwei Zhang <tingwei.zhang@oss.qualcomm.com>
> To: Bjorn Andersson <andersson@kernel.org>
> To: Konrad Dybcio <konradybcio@kernel.org>
> Cc: coresight@lists.linaro.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-msm@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>
> ---
> Jie Gan (7):
> coresight: core: refactor ctcu_get_active_port and make it generic
> coresight: tmc: add create/clean functions for etr_buf_list
> coresight: tmc: introduce tmc_sysfs_ops to wrap sysfs read operations
> coresight: etr: add a new function to retrieve the CTCU device
> dt-bindings: arm: add an interrupt property for Coresight CTCU
> coresight: ctcu: enable byte-cntr for TMC ETR devices
> arm64: dts: qcom: lemans: add interrupts to CTCU device
>
> .../ABI/testing/sysfs-bus-coresight-devices-ctcu | 9 +
> .../bindings/arm/qcom,coresight-ctcu.yaml | 10 +
> arch/arm64/boot/dts/qcom/lemans.dtsi | 3 +
> drivers/hwtracing/coresight/Makefile | 2 +-
> drivers/hwtracing/coresight/coresight-core.c | 27 ++
> .../hwtracing/coresight/coresight-ctcu-byte-cntr.c | 304 +++++++++++++++++++++
> drivers/hwtracing/coresight/coresight-ctcu-core.c | 146 ++++++++--
> drivers/hwtracing/coresight/coresight-ctcu.h | 79 +++++-
> drivers/hwtracing/coresight/coresight-priv.h | 2 +
> drivers/hwtracing/coresight/coresight-tmc-core.c | 55 ++--
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 243 +++++++++++++++-
> drivers/hwtracing/coresight/coresight-tmc.h | 42 +++
> 12 files changed, 850 insertions(+), 72 deletions(-)
> ---
> base-commit: 936c21068d7ade00325e40d82bfd2f3f29d9f659
> change-id: 20260309-enable-byte-cntr-for-ctcu-ff86e6198b7f
>
> Best regards,
^ permalink raw reply
* Re: [PATCH v10 6/9] regulator: p3h2x4x: Add driver for on-die regulators in NXP P3H2x4x i3c hub
From: sashiko-bot @ 2026-05-25 9:06 UTC (permalink / raw)
To: Lakshay Piplani; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260525064209.2263045-7-lakshay.piplani@nxp.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Race condition in hardware unlock/lock sequence across regulators
- [Medium] Silent hardware state mismatch due to unhandled errors in lock guard
- [Medium] Missing MODULE_ALIAS prevents automatic module loading
- [Low] Incorrect use of of_match_ptr() on string literals
--
commit 4a0c2a87632650e322585272d36928a08ab2888d
Author: Aman Kumar Pandey <aman.kumarpandey@nxp.com>
regulator: p3h2x4x: Add driver for on-die regulators in NXP P3H2x4x i3c hub
This commit adds a platform driver for the on-die voltage regulators of the
NXP P3H2x4x multi-function I3C Hub device, registering them through the
regulator framework via MFD.
[ ... ]
> diff --git a/drivers/regulator/p3h2840_i3c_hub_regulator.c b/drivers/regulator/p3h2840_i3c_hub_regulator.c
> new file mode 100644
> index 0000000000000..4f2514d4d928e
> --- /dev/null
> +++ b/drivers/regulator/p3h2840_i3c_hub_regulator.c
[ ... ]
> +static void p3h2x4x_reg_guard_enter(struct regulator_dev *rdev,
> + struct p3h2x4x_reg_state *state)
> +{
> + state->restore = false;
> +
> + if (regmap_read(rdev->regmap,
> + P3H2X4X_DEV_REG_PROTECTION_CODE,
> + &state->orig))
> + return;
> +
> + if (state->orig != P3H2X4X_REGISTERS_UNLOCK_CODE) {
> + regmap_write(rdev->regmap,
> + P3H2X4X_DEV_REG_PROTECTION_CODE,
> + P3H2X4X_REGISTERS_UNLOCK_CODE);
[Severity: Medium]
Does this silently ignore hardware I/O errors?
If the I3C/I2C write to unlock the hardware fails, the hardware remains
locked. Because guard constructors cannot propagate errors, the caller will
proceed to modify the regulator configuration. The regmap_update_bits() call
will succeed in software but fail in hardware, causing the kernel's tracking
of the regulator's state to diverge from the physical hardware.
> + state->restore = true;
> + }
> +}
> +
> +static void p3h2x4x_reg_guard_exit(struct regulator_dev *rdev,
> + struct p3h2x4x_reg_state *state)
> +{
> + if (state->restore)
> + regmap_write(rdev->regmap,
> + P3H2X4X_DEV_REG_PROTECTION_CODE,
> + state->orig);
> +}
> +
> +DEFINE_LOCK_GUARD_1(p3h2x4x_reg, struct regulator_dev,
> + p3h2x4x_reg_guard_enter(_T->lock, &_T->state),
> + p3h2x4x_reg_guard_exit(_T->lock, &_T->state),
> + struct p3h2x4x_reg_state state);
[Severity: High]
Can this cause a race condition between different regulators on the same chip?
The p3h2x4x_reg guard is instantiated per-regulator, and the regulator
subsystem only holds a per-regulator lock. If Thread A unlocks the hardware
for ldo-cp0, and Thread B concurrently reads the protection register for
ldo-cp1, Thread B may observe the hardware as already unlocked and skip its
own unlock/restore sequence.
When Thread A completes, it relocks the device. Thread B's subsequent
register update will then be written to a locked hardware state, causing
the write to be discarded and leading to silent state mismatch. Should a
shared lock from the MFD parent be used to ensure atomicity?
> +
> +static int p3h2x4x_regulator_enable(struct regulator_dev *rdev)
> +{
> + guard(p3h2x4x_reg)(rdev);
> + return regulator_enable_regmap(rdev);
> +}
[ ... ]
> +static struct regulator_desc p3h2x4x_regulators[] = {
> + {
> + .name = "ldo-cp0",
> + .of_match = of_match_ptr("ldo-cp0"),
> + .regulators_node = of_match_ptr("regulators"),
[Severity: Low]
Is it safe to use of_match_ptr() on string literals here?
On non-OF builds, of_match_ptr() evaluates to NULL. This breaks regulator
matching for systems that use non-OF firmware interfaces (like ACPI PRP0001
or swnodes) which still rely on these strings to be present. Applying it
to string literals doesn't save any memory since the strings are already
compiled in for the name field.
> + .volt_table = p3h2x4x_voltage_table,
> + .n_voltages = ARRAY_SIZE(p3h2x4x_voltage_table),
> + .ops = &p3h2x4x_ldo_ops,
[ ... ]
> +static struct platform_driver p3h2x4x_regulator_driver = {
> + .driver = {
> + .name = "p3h2x4x-regulator",
> + .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> + },
> + .probe = p3h2x4x_regulator_probe,
> +};
> +module_platform_driver(p3h2x4x_regulator_driver);
> +
> +MODULE_AUTHOR("Aman Kumar Pandey <aman.kumarpandey@nxp.com>");
> +MODULE_AUTHOR("Vikash Bansal <vikash.bansal@nxp.com>");
> +MODULE_AUTHOR("Lakshay Piplani <lakshay.piplani@nxp.com>");
> +MODULE_DESCRIPTION("NXP P3H2X4X I3C HUB Regulator driver");
> +MODULE_LICENSE("GPL");
[Severity: Medium]
Does this prevent automatic module loading?
The driver registers as an MFD child device using a platform driver named
"p3h2x4x-regulator". Because it relies on the platform bus matching by name
and does not provide an id_table or of_match_table, the MFD core will emit
a uevent with MODALIAS=platform:p3h2x4x-regulator. Without a corresponding
MODULE_ALIAS declaration, udev cannot map the uevent to the kernel module.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260525064209.2263045-1-lakshay.piplani@nxp.com?part=6
^ permalink raw reply
* Re: [PATCH v14 04/17] arm64: kexec: Fix image->elf_headers memory leak during retry loop
From: sashiko-bot @ 2026-05-25 9:11 UTC (permalink / raw)
To: Jinjie Ruan; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260525084932.934910-5-ruanjinjie@huawei.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [Critical] Use-After-Free and Double Free due to residual `vfree(headers)` in the error path.
- [Low] Compilation failure when CONFIG_CRASH_DUMP is disabled.
- [Low] Uninitialized variables passed to `load_other_segments()` when loading non-crash kernels.
Pre-existing issues:
- [High] CMA pages allocated for kexec segments are permanently leaked when `image->nr_segments` is truncated.
--
commit c40f3dfedb4fb90dbc751e696184623090b1055a
Author: Jinjie Ruan <ruanjinjie@huawei.com>
arm64: kexec: Fix image->elf_headers memory leak during retry loop
This commit moves the ELF header allocation outside the retry loop in
image_load() to fix a memory leak during kexec placement retries. It reuses
the single allocated buffer and updates load_other_segments() to receive the
headers and size as arguments instead of allocating them internally.
> diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
> index b70f4df15a1ae..79efeaeb71e93 100644
> --- a/arch/arm64/kernel/kexec_image.c
> +++ b/arch/arm64/kernel/kexec_image.c
> @@ -44,6 +44,11 @@ static void *image_load(struct kimage *image,
> struct kexec_buf kbuf = {};
> unsigned long text_offset, kernel_segment_number;
> struct kexec_segment *kernel_segment;
> +#ifdef CONFIG_CRASH_DUMP
> + /* load elf core header */
> + unsigned long headers_sz;
> + void *headers;
> +#endif
> int ret;
[ ... ]
> @@ -89,6 +94,18 @@ static void *image_load(struct kimage *image,
>
> kernel_segment_number = image->nr_segments;
>
> +#ifdef CONFIG_CRASH_DUMP
> + if (image->type == KEXEC_TYPE_CRASH) {
> + ret = prepare_elf_headers(&headers, &headers_sz);
> + if (ret) {
> + pr_err("Preparing elf core header failed\n");
> + return ERR_PTR(ret);
> + }
> + image->elf_headers = headers;
> + image->elf_headers_sz = headers_sz;
> + }
> +#endif
> +
> /*
> * The location of the kernel segment may make it impossible to satisfy
> * the other segment requirements, so we try repeatedly to find a
> @@ -99,7 +116,8 @@ static void *image_load(struct kimage *image,
> kernel_segment = &image->segment[kernel_segment_number];
> ret = load_other_segments(image, kernel_segment->mem,
> kernel_segment->memsz, initrd,
> - initrd_len, cmdline);
> + initrd_len, cmdline,
> + headers, headers_sz);
[Severity: Low]
Will this cause a build failure when CONFIG_CRASH_DUMP is disabled?
The headers and headers_sz variables are declared inside an
#ifdef CONFIG_CRASH_DUMP block, but are unconditionally passed to
load_other_segments() here.
Also, when CONFIG_CRASH_DUMP is enabled but the image is a standard kexec
kernel (image->type != KEXEC_TYPE_CRASH), headers and headers_sz remain
uninitialized.
Could passing these uninitialized variables trigger compiler warnings or
undefined behavior?
> if (!ret)
> break;
>
> @@ -107,7 +125,7 @@ static void *image_load(struct kimage *image,
> * We couldn't find space for the other segments; erase the
> * kernel segment and try the next available hole.
> */
> - image->nr_segments -= 1;
> + image->nr_segments = kernel_segment_number;
[Severity: High]
This is a pre-existing issue, but does truncating image->nr_segments here
leak CMA pages?
When kexec_add_buffer() successfully allocates from CMA, it saves the page
in image->segment_cma[image->nr_segments]. If we erase segments by rolling
back image->nr_segments, the cleanup function kimage_free_cma() will only
iterate up to the new nr_segments.
Are the CMA pages for the discarded segments permanently lost?
> kbuf.buf_min = kernel_segment->mem + kernel_segment->memsz;
> kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
> }
> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> index e31fabed378a5..daf81a873bbd3 100644
> --- a/arch/arm64/kernel/machine_kexec_file.c
> +++ b/arch/arm64/kernel/machine_kexec_file.c
[ ... ]
> @@ -105,16 +106,7 @@ int load_other_segments(struct kimage *image,
> kbuf.buf_min = kernel_load_addr + kernel_size;
>
> #ifdef CONFIG_CRASH_DUMP
> - /* load elf core header */
> - void *headers;
> - unsigned long headers_sz;
> if (image->type == KEXEC_TYPE_CRASH) {
> - ret = prepare_elf_headers(&headers, &headers_sz);
> - if (ret) {
> - pr_err("Preparing elf core header failed\n");
> - goto out_err;
> - }
> -
> kbuf.buffer = headers;
> kbuf.bufsz = headers_sz;
> kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
> @@ -128,9 +120,7 @@ int load_other_segments(struct kimage *image,
> vfree(headers);
> goto out_err;
[Severity: Critical]
Since the headers buffer allocation was moved out to image_load(), does this
vfree() cause a use-after-free and double free?
If kexec_add_buffer() fails, this path frees the headers buffer and returns
an error. The retry loop in image_load() will then unconditionally call
load_other_segments() again, passing the now freed headers pointer back to
kexec_add_buffer().
Additionally, the post-load cleanup function
arch_kimage_file_post_load_cleanup() unconditionally calls
vfree(image->elf_headers).
Could this lead to memory corruption?
> }
> - image->elf_headers = headers;
> image->elf_load_addr = kbuf.mem;
> - image->elf_headers_sz = headers_sz;
>
> kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260525084932.934910-1-ruanjinjie@huawei.com?part=4
^ permalink raw reply
* Re: [PATCH 0/3] dt-bindings: soc: qcom: Add Maili soc related bindings
From: Jingyi Wang @ 2026-05-25 9:09 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh, aiqun.yu,
tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm, devicetree,
linux-kernel, Chunkai Deng
In-Reply-To: <5k7sh2yooj4yn4wtpifyamaw2dglk6xwbix623rvt6i2idkxr5@63rbo7ncduym>
On 5/25/2026 4:35 PM, Dmitry Baryshkov wrote:
> On Sun, May 24, 2026 at 11:29:43PM -0700, Jingyi Wang wrote:
>> Add soc related bindings for Kaanapali Platform including aoss_qmp,
>
> So, are you adding Maili or Kaanapali bindings?
>
sorry, typo here, it should be Maili as title describe.
Thanks,
Jingyi
>> imem and SCM.
>>
>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>> ---
>> Chunkai Deng (1):
>> dt-bindings: soc: qcom,aoss-qmp: Document the Maili AOSS side channel
>>
>> Jingyi Wang (2):
>> dt-bindings: firmware: qcom,scm: Document SCM on Maili SOC
>> dt-bindings: sram: Document qcom,maili-imem compatible
>>
>> Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
>> Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml | 1 +
>> Documentation/devicetree/bindings/sram/sram.yaml | 1 +
>> 3 files changed, 4 insertions(+)
>> ---
>> base-commit: c1ecb239fa3456529a32255359fc78b69eb9d847
>> change-id: 20260524-maili-soc-binding-2a2287fce578
>>
>> Best regards,
>> --
>> Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>>
>
^ permalink raw reply
* Re: [PATCH 04/16] arm64: dts: qcom: shikra: Add cpufreq scaling node
From: Dmitry Baryshkov @ 2026-05-25 9:19 UTC (permalink / raw)
To: Komal Bajaj
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Krzysztof Kozlowski, Georgi Djakov, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, dmaengine, devicetree, linux-kernel,
linux-pm, Imran Shaik, Aastha Pandey
In-Reply-To: <20260525-shikra-dt-m1-v1-4-f51a9838dbaa@oss.qualcomm.com>
On Mon, May 25, 2026 at 01:19:08AM +0530, Komal Bajaj wrote:
> From: Imran Shaik <imran.shaik@oss.qualcomm.com>
>
> Add cpufreq-hw node to support cpufreq scaling on Qualcomm Shikra SoCs.
>
> Co-developed-by: Aastha Pandey <aastha.pandey@oss.qualcomm.com>
> Signed-off-by: Aastha Pandey <aastha.pandey@oss.qualcomm.com>
> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 05/16] arm64: dts: qcom: shikra: Add DDR BWMON support
From: Dmitry Baryshkov @ 2026-05-25 9:19 UTC (permalink / raw)
To: Komal Bajaj
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Krzysztof Kozlowski, Georgi Djakov, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, dmaengine, devicetree, linux-kernel,
linux-pm, Sayantan Chakraborty
In-Reply-To: <20260525-shikra-dt-m1-v1-5-f51a9838dbaa@oss.qualcomm.com>
On Mon, May 25, 2026 at 01:19:09AM +0530, Komal Bajaj wrote:
> From: Sayantan Chakraborty <sayantan.chakraborty@oss.qualcomm.com>
>
> Add CPU-to-DDR BWMON nodes and their corresponding opp tables for
> Shikra SoC. This is necessary to enable power management and optimize
> system performance from the perspective of dynamically changing DDR
> frequencies.
>
> Signed-off-by: Sayantan Chakraborty <sayantan.chakraborty@oss.qualcomm.com>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 40 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v2 0/2] ASoC: nau8822: add support for supply regulators
From: Alexey Charkov @ 2026-05-25 9:20 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Lin, Jaroslav Kysela, Takashi Iwai
Cc: linux-sound, devicetree, linux-kernel, Alexey Charkov
The Nuvoton NAU8822 codec has four power supply pins: VDDA, VDDB, VDDC
and VDDSPK, which must be online and stable before the device can be
accessed over I2C. On boards where these rails are software-controlled,
probing the codec before the regulators are up results in -ENXIO errors
during register access.
This short series adds optional regulator support to both the device
tree binding and the driver, so platforms that need explicit power
sequencing can describe and enforce it:
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
Changes in v2:
- Added the regulators to the DT binding example (thanks Krzysztof)
- Switch to regulator_bulk_* APIs instead of "optional" (thanks Mark)
- Enable and disable the regulators at probe/remove and suspend/resume (thanks Sashiko)
- Include the required regulator header (thanks Sashiko)
- Add a power on reset stabilization delay before register access (thanks Sashiko)
- Link to v1: https://lore.kernel.org/r/20260513-nau8822-reg-v1-0-c532e18e92ad@flipper.net
---
Alexey Charkov (2):
ASoC: dt-bindings: nau8822: Add supply regulators
ASoC: codecs: nau8822: add support for supply regulators
.../devicetree/bindings/sound/nuvoton,nau8822.yaml | 18 +++++++++
sound/soc/codecs/nau8822.c | 46 ++++++++++++++++++++--
sound/soc/codecs/nau8822.h | 3 ++
3 files changed, 64 insertions(+), 3 deletions(-)
---
base-commit: c1ecb239fa3456529a32255359fc78b69eb9d847
change-id: 20260513-nau8822-reg-becf5b766d80
Best regards,
--
Alexey Charkov <alchark@flipper.net>
^ permalink raw reply
* [PATCH v2 1/2] ASoC: dt-bindings: nau8822: Add supply regulators
From: Alexey Charkov @ 2026-05-25 9:20 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Lin, Jaroslav Kysela, Takashi Iwai
Cc: linux-sound, devicetree, linux-kernel, Alexey Charkov
In-Reply-To: <20260525-nau8822-reg-v2-0-7d37ae393e46@flipper.net>
NAU8822 has 4 power supply pins: VDDA, VDDB, VDDC and VDDSPK, which need
to be online and stable before communication with the device is attempted.
List them (as optional) so that device tree users can ensure correct power
sequencing.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
.../devicetree/bindings/sound/nuvoton,nau8822.yaml | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
index cb8182bbc491..cf4c13038241 100644
--- a/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
+++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
@@ -30,6 +30,20 @@ properties:
clock-names:
const: mclk
+ vdda-supply:
+ description: Analog power supply
+
+ vddb-supply:
+ description: Digital buffer (input/output) supply
+
+ vddc-supply:
+ description: Digital core supply
+
+ vddspk-supply:
+ description:
+ Speaker supply (power supply pin for RSPKOUT, LSPKOUT, AUXOUT2 and
+ AUXTOUT1 output drivers)
+
nuvoton,spk-btl:
description:
If set, configure the two loudspeaker outputs as a Bridge Tied Load output
@@ -54,5 +68,9 @@ examples:
codec@1a {
compatible = "nuvoton,nau8822";
reg = <0x1a>;
+ vdda-supply = <&vcca_3v3_s0>;
+ vddb-supply = <&vcca_3v3_s0>;
+ vddc-supply = <&vcca_3v3_s0>;
+ vddspk-supply = <&vcca_3v3_s0>;
};
};
--
2.52.0
^ permalink raw reply related
* [PATCH v2 2/2] ASoC: codecs: nau8822: add support for supply regulators
From: Alexey Charkov @ 2026-05-25 9:20 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Lin, Jaroslav Kysela, Takashi Iwai
Cc: linux-sound, devicetree, linux-kernel, Alexey Charkov
In-Reply-To: <20260525-nau8822-reg-v2-0-7d37ae393e46@flipper.net>
NAU8822 has four power supply pins: VDDA, VDDB, VDDC, and VDDSPK, which
need to be online and stable before communication with the device is
attempted.
Request and enable these regulators at init time, if provided. Also wait
for 100 us after powering up the supply regulators before attempting to
access the device registers, as recommended by the datasheet.
This helps avoid -ENXIO errors when the codec is probed before the
regulators are ready.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
sound/soc/codecs/nau8822.c | 46 +++++++++++++++++++++++++++++++++++++++++++---
sound/soc/codecs/nau8822.h | 3 +++
2 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/nau8822.c b/sound/soc/codecs/nau8822.c
index 19fee5f4bf5f..830164e991a7 100644
--- a/sound/soc/codecs/nau8822.c
+++ b/sound/soc/codecs/nau8822.c
@@ -19,6 +19,7 @@
#include <linux/pm.h>
#include <linux/i2c.h>
#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
#include <linux/slab.h>
#include <sound/core.h>
#include <sound/pcm.h>
@@ -108,6 +109,10 @@ static const struct reg_default nau8822_reg_defaults[] = {
{ NAU8822_REG_OUTPUT_TIEOFF, 0x0000 },
};
+static const char * const nau8822_supply_names[NAU8822_NUM_SUPPLIES] = {
+ "vdda", "vddb", "vddc", "vddspk",
+};
+
static bool nau8822_readable_reg(struct device *dev, unsigned int reg)
{
switch (reg) {
@@ -1056,6 +1061,7 @@ static int nau8822_suspend(struct snd_soc_component *component)
struct snd_soc_dapm_context *dapm = snd_soc_component_to_dapm(component);
snd_soc_dapm_force_bias_level(dapm, SND_SOC_BIAS_OFF);
+ regulator_bulk_disable(NAU8822_NUM_SUPPLIES, nau8822->supplies);
regcache_mark_dirty(nau8822->regmap);
@@ -1066,6 +1072,15 @@ static int nau8822_resume(struct snd_soc_component *component)
{
struct nau8822 *nau8822 = snd_soc_component_get_drvdata(component);
struct snd_soc_dapm_context *dapm = snd_soc_component_to_dapm(component);
+ int ret = regulator_bulk_enable(NAU8822_NUM_SUPPLIES, nau8822->supplies);
+
+ if (ret) {
+ dev_err(component->dev,
+ "Failed to enable regulators: %d\n", ret);
+ return ret;
+ }
+
+ fsleep(100);
regcache_sync(nau8822->regmap);
@@ -1153,7 +1168,7 @@ static int nau8822_i2c_probe(struct i2c_client *i2c)
{
struct device *dev = &i2c->dev;
struct nau8822 *nau8822 = dev_get_platdata(dev);
- int ret;
+ int ret, i;
if (!nau8822) {
nau8822 = devm_kzalloc(dev, sizeof(*nau8822), GFP_KERNEL);
@@ -1167,6 +1182,13 @@ static int nau8822_i2c_probe(struct i2c_client *i2c)
return dev_err_probe(&i2c->dev, PTR_ERR(nau8822->mclk),
"Error getting mclk\n");
+ for (i = 0; i < NAU8822_NUM_SUPPLIES; i++)
+ nau8822->supplies[i].supply = nau8822_supply_names[i];
+
+ ret = devm_regulator_bulk_get(dev, NAU8822_NUM_SUPPLIES, nau8822->supplies);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to get regulators\n");
+
nau8822->regmap = devm_regmap_init_i2c(i2c, &nau8822_regmap_config);
if (IS_ERR(nau8822->regmap)) {
ret = PTR_ERR(nau8822->regmap);
@@ -1175,21 +1197,38 @@ static int nau8822_i2c_probe(struct i2c_client *i2c)
}
nau8822->dev = dev;
+ ret = regulator_bulk_enable(NAU8822_NUM_SUPPLIES, nau8822->supplies);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to enable regulators\n");
+
+ fsleep(100);
+
/* Reset the codec */
ret = regmap_write(nau8822->regmap, NAU8822_REG_RESET, 0x00);
if (ret != 0) {
dev_err(&i2c->dev, "Failed to issue reset: %d\n", ret);
- return ret;
+ goto err_reg;
}
ret = devm_snd_soc_register_component(dev, &soc_component_dev_nau8822,
&nau8822_dai, 1);
if (ret != 0) {
dev_err(&i2c->dev, "Failed to register CODEC: %d\n", ret);
- return ret;
+ goto err_reg;
}
return 0;
+
+err_reg:
+ regulator_bulk_disable(NAU8822_NUM_SUPPLIES, nau8822->supplies);
+ return ret;
+}
+
+static void nau8822_i2c_remove(struct i2c_client *i2c)
+{
+ struct nau8822 *nau8822 = i2c_get_clientdata(i2c);
+
+ regulator_bulk_disable(NAU8822_NUM_SUPPLIES, nau8822->supplies);
}
static const struct i2c_device_id nau8822_i2c_id[] = {
@@ -1212,6 +1251,7 @@ static struct i2c_driver nau8822_i2c_driver = {
.of_match_table = of_match_ptr(nau8822_of_match),
},
.probe = nau8822_i2c_probe,
+ .remove = nau8822_i2c_remove,
.id_table = nau8822_i2c_id,
};
module_i2c_driver(nau8822_i2c_driver);
diff --git a/sound/soc/codecs/nau8822.h b/sound/soc/codecs/nau8822.h
index 13fe0a091e9e..24799c7b5931 100644
--- a/sound/soc/codecs/nau8822.h
+++ b/sound/soc/codecs/nau8822.h
@@ -211,6 +211,8 @@ struct nau8822_pll {
int freq_out;
};
+#define NAU8822_NUM_SUPPLIES 4
+
/* Codec Private Data */
struct nau8822 {
struct device *dev;
@@ -219,6 +221,7 @@ struct nau8822 {
struct nau8822_pll pll;
int sysclk;
int div_id;
+ struct regulator_bulk_data supplies[NAU8822_NUM_SUPPLIES];
};
#endif /* __NAU8822_H__ */
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v14 02/17] powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()
From: sashiko-bot @ 2026-05-25 9:22 UTC (permalink / raw)
To: Jinjie Ruan; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260525084932.934910-3-ruanjinjie@huawei.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Missing NULL check on `rmem` before accessing `rmem->nr_ranges` causes a NULL pointer dereference in `kexec_extra_fdt_size_ppc64()`.
- [Critical] `__merge_memory_ranges()` incorrectly shrinks overlapping memory ranges, causing critical memory regions to be lost.
--
commit 4efbfe4b6923f71ffba2342131a0178fa07349c0
Author: Jinjie Ruan <ruanjinjie@huawei.com>
powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()
This commit fixes a memory leak in update_crash_elfcorehdr() by ensuring
allocated memory from get_crash_memory_ranges() is freed if an error occurs.
It updates the code to jump to the out label to properly free the memory.
> diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
> index e6539f213b3d1..a520f851c3a6b 100644
> --- a/arch/powerpc/kexec/crash.c
> +++ b/arch/powerpc/kexec/crash.c
> @@ -502,7 +502,7 @@ static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify *
> ret = get_crash_memory_ranges(&cmem);
> if (ret) {
> pr_err("Failed to get crash mem range\n");
> - return;
> + goto out;
> }
>
> /*
[Severity: Critical]
This is a pre-existing issue, but does kexec_extra_fdt_size_ppc64()
dereference a NULL pointer if rmem is NULL?
If get_reserved_memory_ranges(&rmem) returns 0 without allocating memory for
rmem (e.g., when there are no matching device tree nodes), rmem remains NULL
when passed to kexec_extra_fdt_size_ppc64():
arch/powerpc/kexec/elf_64.c:elf64_load() {
...
ret = get_reserved_memory_ranges(&rmem);
if (ret)
goto out;
fdt = of_kexec_alloc_and_setup_fdt(image, initrd_load_addr,
initrd_len, cmdline,
kexec_extra_fdt_size_ppc64(image, rmem));
...
}
Inside kexec_extra_fdt_size_ppc64(), there is no check before accessing
rmem->nr_ranges:
arch/powerpc/kexec/file_load_64.c:kexec_extra_fdt_size_ppc64() {
...
/* Consider extra space for reserved memory ranges if any */
if (rmem->nr_ranges > 0)
extra_size += (unsigned int)(rmem->nr_ranges * sizeof(u64));
...
}
Could this lead to a NULL pointer dereference and a kernel panic during
the kexec device tree preparation?
[Severity: Critical]
This isn't a bug introduced by this patch, but does __merge_memory_ranges()
incorrectly shrink overlapping memory ranges?
When merging memory ranges, the code unconditionally assigns ranges[i].end
to ranges[idx].end without using max(), and compares the start against
ranges[i-1].end rather than ranges[idx].end:
arch/powerpc/kexec/ranges.c:__merge_memory_ranges() {
...
for (i = 1; i < mem_rngs->nr_ranges; i++) {
if (ranges[i].start <= (ranges[i-1].end + 1))
ranges[idx].end = ranges[i].end;
else {
...
}
If a smaller memory range is completely subsumed by a larger one, could this
assignment shrink the end boundary of the merged range?
Would this truncate valid memory blocks from the kexec exclude lists,
potentially allowing the new kernel to overwrite the running kernel's memory
and causing data corruption or crashes?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260525084932.934910-1-ruanjinjie@huawei.com?part=2
^ permalink raw reply
* Re: [PATCH 4/9] dt-bindings: pinctrl: Add UltraRISC DP1000 pinctrl bindings
From: Linus Walleij @ 2026-05-25 9:23 UTC (permalink / raw)
To: wangjia
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Bartosz Golaszewski,
Samuel Holland, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
devicetree, linux-riscv, linux-kernel, linux-gpio
In-Reply-To: <20260515-ultrarisc-pinctrl-v1-4-bf559589ea8a@ultrarisc.com>
On Fri, May 15, 2026 at 3:18 AM Jia Wang via B4 Relay
<devnull+wangjia.ultrarisc.com@kernel.org> wrote:
> +++ b/include/dt-bindings/pinctrl/ultrarisc,dp1000-pinctrl.h
Move this to something like arch/*/dts/vendor/dp1000-pinctrl.dtsi
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 07/16] arm64: dts: qcom: shikra: Add CPU OPP tables to scale DDR/L3
From: Dmitry Baryshkov @ 2026-05-25 9:23 UTC (permalink / raw)
To: Komal Bajaj
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Krzysztof Kozlowski, Georgi Djakov, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, dmaengine, devicetree, linux-kernel,
linux-pm, Sayantan Chakraborty
In-Reply-To: <20260525-shikra-dt-m1-v1-7-f51a9838dbaa@oss.qualcomm.com>
On Mon, May 25, 2026 at 01:19:11AM +0530, Komal Bajaj wrote:
> From: Sayantan Chakraborty <sayantan.chakraborty@oss.qualcomm.com>
>
> Add OPP tables required to scale DDR and L3 per freq-domain on
> Shikra SoC.
>
> Signed-off-by: Sayantan Chakraborty <sayantan.chakraborty@oss.qualcomm.com>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 84 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 84 insertions(+)
Does it really make sense to split cpufreq_hw, EPSS and OPP tables into
three separate patches?
>
> @@ -144,6 +164,70 @@ memory@80000000 {
> /* We expect the bootloader to fill in the size */
> reg = <0x0 0x80000000 0x0 0x0>;
> };
> + cpu0_opp_table: opp-table-cpu0 {
Missing empty line.
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + cpu0_opp_768mhz: opp-768000000 {
Drop useless labels.
> + opp-hz = /bits/ 64 <768000000>;
> + opp-peak-kBps = <1200000 17817600>;
> + };
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/1] arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras
From: Robby Cai @ 2026-05-25 9:26 UTC (permalink / raw)
To: Frank Li
Cc: robh, krzk+dt, conor+dt, s.hauer, festevam,
sebastian.krzyszkowiak, kernel, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <ag8byj8ZavKyxWRR@lizhi-Precision-Tower-5810>
On Thu, May 21, 2026 at 10:50:50AM -0400, Frank Li wrote:
> On Thu, May 21, 2026 at 07:49:52PM +0800, Robby Cai wrote:
> > On Wed, May 20, 2026 at 02:52:24PM -0400, Frank Li wrote:
> > > On Wed, May 20, 2026 at 02:54:52PM +0800, Robby Cai wrote:
> > > > On Fri, May 15, 2026 at 10:01:47AM -0400, Frank Li wrote:
> > > > > On Fri, May 15, 2026 at 07:11:43PM +0800, Robby Cai wrote:
> > > > > > Enable the MIPI CSI bridges and corresponding CSI-2 host interfaces
> > > > > > on the i.MX8MQ EVK, and add two OV5640 camera sensors.
> > > > > >
> > > > > > The sensors are connected via I2C1 and I2C2, each with proper
> > > > > > endpoint descriptions to form complete media pipelines.
> > > > > >
> > > > > > The resulting pipelines are:
> > > > > >
> > > > > > - OV5640 (I2C2) -> MIPI CSI1 -> CSI1 bridge
> > > > > > - OV5640 (I2C1) -> MIPI CSI2 -> CSI2 bridge
> > > > > >
> > > > > > Both pipelines have been validated on the i.MX8MQ EVK using the
> > > > > > upstream OV5640 driver.
> > > > > >
> > > > > > Both OV5640 sensors share a single reset GPIO on this board,
> > > > > > which prevents independent hardware reset when both cameras
> > > > > > are enabled. As a result, the reset line is kept deasserted
> > > > > > via a GPIO hog, and sensor reset is performed via software.
> > > > >
> > > > > Does reset_control_get_shared() resolve this problem?
> > > > >
> > > >
> > > > No, reset_control_get_shared() does not really solve this issue.
> > > >
> > > > The problem here is not about software coordination, but about the
> > > > hardware topology: both sensors are physically tied to the same reset
> > > > line. This means any reset operation will always affect both devices
> > > > simultaneously, regardless of how the reset framework is used.
> > >
> > > Reset framework is resolve this problem. It is quite common that many devices
> > > shared one reset pin.
> >
> > okay, I'll try to switch to use this approach in next revision.
> >
> > Some devices require coordinated RESET and PWDN sequencing, but in this
> > case the device can be properly initialized with RESET held inactive and
> > controlled solely via the PWDN signal, which makes this approach viable.
>
> PWDN should go through regulator interface.
Thanks for the suggestion.
Modeling PWDN via the regulator framework makes sense, but it would require
changes across multiple platforms beyond NXP. To keep this series focused
and easier to review, I would prefer to address this in a follow-up patch set.
>
> >
> > >
> > > >
> > > > While reset_control_get_shared() introduces reference counting to avoid
> > > > unintended assertions, it does not allow independent reset control.
> > > > In particular:
> > > >
> > > > - A reset operation (assert) will still impact both sensors.
> > >
> > > yes, only when first devices toggle reset signal. Second device do nothing.
> > >
> > > > - It does not solve the requirement for per-device hardware reset.
> > >
> > > It is hardware limitation.
> > >
> > > >
> > > > Therefore, using a shared reset control does not provide true isolation
> > > > between the two OV5640 instances.
> > >
> > > It is not isolation. Just don't allow second device to toggle reset pin.
> > >
> > > >
> > > > Keeping the reset line permanently deasserted (e.g. via GPIO hog) and
> > > > handling initialization through software/power sequencing is a valid
> > > > and practical solution for this hardware design.
> > >
> > > If use i2c gpio, expandor driver may probe after sensor driver probe. So
> > > reset may happen after sensor driver probe.
> >
> >
> > Just to clarify, the reset GPIO in this design is provided by the SoC GPIO
> > controller (gpio1), not an external I2C GPIO expander.
>
> It is just special case. you touch ov5640 driver code, so need consider
> more general case.
Yes, agreed. I will take the more general use cases into account.
Regards,
Robby
>
> Frank
> >
> > Therefore, the "late reset" issue you mentioned does not apply here.
> >
> > Regards,
> > Robby
> > >
> > > Frank
> > > >
> > > > This matches the intention of the upstream changes as well, where GPIO-
> > > > based resets are treated as simple control signals rather than fully
> > > > isolated reset domains.
> > > >
> > > > In practice, using a shared reset here can even introduce subtle
> > > > interference between the two cameras during probe or power cycling,
> > > > so it is safer to avoid using reset for runtime control entirely.
> > > >
> > > > Regards,
> > > > Robby
> > > >
^ permalink raw reply
* [PATCH v7 2/5] clk: at91: sama7d65: add peripheral clock for I3C
From: Manikandan Muralidharan @ 2026-05-25 9:24 UTC (permalink / raw)
To: alexandre.belloni, Frank.Li, robh, krzk+dt, conor+dt,
nicolas.ferre, claudiu.beznea, linux, mturquette, sboyd, bmasney,
aubin.constans, Ryan.Wanner, romain.sioen, tytso, cristian.birsan,
adrian.hunter, npitre, linux-i3c, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
Cc: Durai Manickam KR, Manikandan Muralidharan
In-Reply-To: <20260525092405.1514213-1-manikandan.m@microchip.com>
From: Durai Manickam KR <durai.manickamkr@microchip.com>
Add peripheral clock description for I3C.
Signed-off-by: Durai Manickam KR <durai.manickamkr@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
Changes in v3:
- Fixed indentation issues in the clock table entry
drivers/clk/at91/sama7d65.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/at91/sama7d65.c b/drivers/clk/at91/sama7d65.c
index 7dee2b160ffb..ba8ff413fa2c 100644
--- a/drivers/clk/at91/sama7d65.c
+++ b/drivers/clk/at91/sama7d65.c
@@ -677,6 +677,7 @@ static struct {
{ .n = "uhphs_clk", .p = PCK_PARENT_HW_MCK5, .id = 101, },
{ .n = "dsi_clk", .p = PCK_PARENT_HW_MCK3, .id = 103, },
{ .n = "lvdsc_clk", .p = PCK_PARENT_HW_MCK3, .id = 104, },
+ { .n = "i3cc_clk", .p = PCK_PARENT_HW_MCK8, .id = 105, },
};
/*
--
2.25.1
^ permalink raw reply related
* [PATCH v7 3/5] i3c: mipi-i3c-hci: add microchip sama7d65 SoC compatible with the required quirk
From: Manikandan Muralidharan @ 2026-05-25 9:24 UTC (permalink / raw)
To: alexandre.belloni, Frank.Li, robh, krzk+dt, conor+dt,
nicolas.ferre, claudiu.beznea, linux, mturquette, sboyd, bmasney,
aubin.constans, Ryan.Wanner, romain.sioen, tytso, cristian.birsan,
adrian.hunter, npitre, linux-i3c, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
Cc: Manikandan Muralidharan
In-Reply-To: <20260525092405.1514213-1-manikandan.m@microchip.com>
Add support for microchip sama7d65 SoC I3C HCI master only IP
with additional clock support to enable bulk clock acquisition
and apply the required quirks.
Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
Changes in v7:
- Use (void *)(ulong) cast instead of direct (void *) cast in
of_device_id.data for pointer-size safety across architectures
- Update commit message body to explicitly mention quirk application
Changes in v6:
- Reorder local variable definitions in i3c_hci_probe in descending
order of line length
Changes in v5:
- Remove HCI_QUIRK_CLK_SUPPORT quirk and call
devm_clk_bulk_get_all_enabled unconditionally, eliminating the
need for a clock-specific quirk flag
Changes in v4:
- Remove the clock index variable MCHP_I3C_CLK_IDX as it is no
longer needed after switching to bulk clock handling
Changes in v3:
- Make use of existing HCI_QUIRK_* code base instead of introducing
separate MCHP_HCI_QUIRK_* flags
- Introduce HCI_QUIRK_CLK_SUPPORT to handle peripheral and system
generic clk in bulk
Changes in v2:
- Platform specific changes integrated in the existing mipi-i3c-hci
driver by introducing separate MCHP_HCI_QUIRK_* quirks and vendor
specific quirk files rather than a standalone driver
drivers/i3c/master/mipi-i3c-hci/core.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/i3c/master/mipi-i3c-hci/core.c b/drivers/i3c/master/mipi-i3c-hci/core.c
index b781dbed2165..4cdf2abd4219 100644
--- a/drivers/i3c/master/mipi-i3c-hci/core.c
+++ b/drivers/i3c/master/mipi-i3c-hci/core.c
@@ -8,6 +8,7 @@
*/
#include <linux/bitfield.h>
+#include <linux/clk.h>
#include <linux/device.h>
#include <linux/errno.h>
#include <linux/i3c/master.h>
@@ -969,6 +970,7 @@ static int i3c_hci_init(struct i3c_hci *hci)
static int i3c_hci_probe(struct platform_device *pdev)
{
const struct mipi_i3c_hci_platform_data *pdata = pdev->dev.platform_data;
+ struct clk_bulk_data *clks;
struct i3c_hci *hci;
int irq, ret;
@@ -1001,6 +1003,11 @@ static int i3c_hci_probe(struct platform_device *pdev)
if (!hci->quirks && platform_get_device_id(pdev))
hci->quirks = platform_get_device_id(pdev)->driver_data;
+ ret = devm_clk_bulk_get_all_enabled(&pdev->dev, &clks);
+ if (ret < 0)
+ return dev_err_probe(&pdev->dev, ret,
+ "Failed to get clocks\n");
+
ret = i3c_hci_init(hci);
if (ret)
return ret;
@@ -1031,6 +1038,9 @@ static void i3c_hci_remove(struct platform_device *pdev)
static const __maybe_unused struct of_device_id i3c_hci_of_match[] = {
{ .compatible = "mipi-i3c-hci", },
+ { .compatible = "microchip,sama7d65-i3c-hci",
+ .data = (void *)(ulong)(HCI_QUIRK_PIO_MODE | HCI_QUIRK_OD_PP_TIMING |
+ HCI_QUIRK_RESP_BUF_THLD) },
{},
};
MODULE_DEVICE_TABLE(of, i3c_hci_of_match);
--
2.25.1
^ permalink raw reply related
* [PATCH v7 4/5] ARM: dts: microchip: add I3C controller
From: Manikandan Muralidharan @ 2026-05-25 9:24 UTC (permalink / raw)
To: alexandre.belloni, Frank.Li, robh, krzk+dt, conor+dt,
nicolas.ferre, claudiu.beznea, linux, mturquette, sboyd, bmasney,
aubin.constans, Ryan.Wanner, romain.sioen, tytso, cristian.birsan,
adrian.hunter, npitre, linux-i3c, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
Cc: Durai Manickam KR, Manikandan Muralidharan
In-Reply-To: <20260525092405.1514213-1-manikandan.m@microchip.com>
From: Durai Manickam KR <durai.manickamkr@microchip.com>
Add I3C controller for sama7d65 SoC.
Signed-off-by: Durai Manickam KR <durai.manickamkr@microchip.com>
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
Changes in v3:
- Remove clock-names property as the driver acquires and enables
clocks in bulk using devm_clk_bulk_get_all_enabled
arch/arm/boot/dts/microchip/sama7d65.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/microchip/sama7d65.dtsi b/arch/arm/boot/dts/microchip/sama7d65.dtsi
index 67253bbc08df..ec200848c153 100644
--- a/arch/arm/boot/dts/microchip/sama7d65.dtsi
+++ b/arch/arm/boot/dts/microchip/sama7d65.dtsi
@@ -1055,5 +1055,13 @@ gic: interrupt-controller@e8c11000 {
#address-cells = <0>;
interrupt-controller;
};
+
+ i3c: i3c@e9000000 {
+ compatible = "microchip,sama7d65-i3c-hci";
+ reg = <0xe9000000 0x300>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 105>, <&pmc PMC_TYPE_GCK 105>;
+ status = "disabled";
+ };
};
};
--
2.25.1
^ permalink raw reply related
* [PATCH v7 5/5] ARM: configs: at91: sama7: add sama7d65 i3c-hci
From: Manikandan Muralidharan @ 2026-05-25 9:24 UTC (permalink / raw)
To: alexandre.belloni, Frank.Li, robh, krzk+dt, conor+dt,
nicolas.ferre, claudiu.beznea, linux, mturquette, sboyd, bmasney,
aubin.constans, Ryan.Wanner, romain.sioen, tytso, cristian.birsan,
adrian.hunter, npitre, linux-i3c, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
Cc: Manikandan Muralidharan, Durai Manickam KR
In-Reply-To: <20260525092405.1514213-1-manikandan.m@microchip.com>
Enable the configs needed for I3C framework and microchip
sama7d65 i3c-hci driver.
Signed-off-by: Durai Manickam KR <durai.manickamkr@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
arch/arm/configs/sama7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/sama7_defconfig b/arch/arm/configs/sama7_defconfig
index e52f671ccec4..6470c7d3fe8a 100644
--- a/arch/arm/configs/sama7_defconfig
+++ b/arch/arm/configs/sama7_defconfig
@@ -117,6 +117,8 @@ CONFIG_HW_RANDOM=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_AT91=y
+CONFIG_I3C=y
+CONFIG_MIPI_I3C_HCI=y
CONFIG_SPI=y
CONFIG_SPI_ATMEL=y
CONFIG_SPI_ATMEL_QUADSPI=y
--
2.25.1
^ permalink raw reply related
* [PATCH v7 0/5] Add microchip sama7d65 SoC I3C support
From: Manikandan Muralidharan @ 2026-05-25 9:24 UTC (permalink / raw)
To: alexandre.belloni, Frank.Li, robh, krzk+dt, conor+dt,
nicolas.ferre, claudiu.beznea, linux, mturquette, sboyd, bmasney,
aubin.constans, Ryan.Wanner, romain.sioen, tytso, cristian.birsan,
adrian.hunter, npitre, linux-i3c, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
Cc: Manikandan Muralidharan
Add support for microchip sama7d65 SoC I3C master only IP which is
based on mipi-i3c-hci from synopsys implementing version 1.0
specification. The platform specific changes are integrated in the
mipi-i3c-hci driver using existing quirks.
I3C in master mode supports up to 12.5MHz, SDR mode data transfer in
mixed bus mode (I2C and I3C target devices on same i3c bus).
Please refer to the individual patches for changelogs.
Durai Manickam KR (2):
clk: at91: sama7d65: add peripheral clock for I3C
ARM: dts: microchip: add I3C controller
Manikandan Muralidharan (3):
dt-bindings: i3c: mipi-i3c-hci: add Microchip SAMA7D65 compatible
i3c: mipi-i3c-hci: add microchip sama7d65 SoC compatible with the
required quirk
ARM: configs: at91: sama7: add sama7d65 i3c-hci
.../devicetree/bindings/i3c/mipi-i3c-hci.yaml | 27 ++++++++++++++++---
arch/arm/boot/dts/microchip/sama7d65.dtsi | 8 ++++++
arch/arm/configs/sama7_defconfig | 2 ++
drivers/clk/at91/sama7d65.c | 1 +
drivers/i3c/master/mipi-i3c-hci/core.c | 10 +++++++
5 files changed, 44 insertions(+), 4 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH v7 1/5] dt-bindings: i3c: mipi-i3c-hci: add Microchip SAMA7D65 compatible
From: Manikandan Muralidharan @ 2026-05-25 9:24 UTC (permalink / raw)
To: alexandre.belloni, Frank.Li, robh, krzk+dt, conor+dt,
nicolas.ferre, claudiu.beznea, linux, mturquette, sboyd, bmasney,
aubin.constans, Ryan.Wanner, romain.sioen, tytso, cristian.birsan,
adrian.hunter, npitre, linux-i3c, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
Cc: Manikandan Muralidharan, Conor Dooley
In-Reply-To: <20260525092405.1514213-1-manikandan.m@microchip.com>
Add the microchip,sama7d65-i3c-hci compatible string to the MIPI I3C
HCI binding. The Microchip SAMA7D65 I3C controller is based on the
MIPI HCI specification but requires two clocks, so add a conditional
constraint when this compatible is present.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
Changes in v5:
- drop min/maxItems around clock entries
- use if/then/else clause instead of separate allOf entry
- cosmetic fixes for indentation and formatting
Changes in v4:
- Define and describe the clock property in the top-level properties
section rather than inside the if/then conditional
.../devicetree/bindings/i3c/mipi-i3c-hci.yaml | 27 ++++++++++++++++---
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml b/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml
index 39bb1a1784c9..d488fb420945 100644
--- a/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml
+++ b/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml
@@ -9,9 +9,6 @@ title: MIPI I3C HCI
maintainers:
- Nicolas Pitre <npitre@baylibre.com>
-allOf:
- - $ref: /schemas/i3c/i3c.yaml#
-
description: |
MIPI I3C Host Controller Interface
@@ -28,9 +25,17 @@ description: |
properties:
compatible:
- const: mipi-i3c-hci
+ enum:
+ - mipi-i3c-hci
+ - microchip,sama7d65-i3c-hci
reg:
maxItems: 1
+
+ clocks:
+ items:
+ - description: Peripheral bus clock
+ - description: System Generic clock
+
interrupts:
maxItems: 1
@@ -39,6 +44,20 @@ required:
- reg
- interrupts
+allOf:
+ - $ref: /schemas/i3c/i3c.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: microchip,sama7d65-i3c-hci
+ then:
+ required:
+ - clocks
+ else:
+ properties:
+ clocks: false
+
unevaluatedProperties: false
examples:
--
2.25.1
^ permalink raw reply related
* Re: (subset) [PATCH v3 0/5] Initial Apple silicon M3 device trees and dt-bindings
From: Sven Peter @ 2026-05-25 9:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi,
Neal Gompa, Wim Van Sebroeck, Guenter Roeck, Mark Kettenis,
Sasha Finkelstein, Uwe Kleine-König, Janne Grunau
Cc: Sven Peter, devicetree, linux-kernel, asahi, linux-arm-kernel,
linux-watchdog, linux-pwm, Joshua Peisach, Michael Reeves
In-Reply-To: <20260507-apple-m3-initial-devicetrees-v3-0-ca07c81b5dc7@jannau.net>
On Thu, 07 May 2026 09:33:06 +0200, Janne Grunau wrote:
> Hej,
>
> This series adds initial device trees for M3 Apple silicon devices. The
> device trees contain only a minimal set of hardware not going much
> beyond the minimum required for booting kernel and initramfs and
> verify via serial console that the hardware and drivers work.
> The hardware with the exception of the interrupt controller is
> compatible with the M1 and M2 SoCs and the existing drivers.
> `make dtbs_check` depends on the already applied and dropped apple,i2c
> and apple,pmgr dt-binding changes.
> The watchdog load depends on stalled and forgotten addition of the
> "apple,t8103-wdt" compatible posted in [1]. I've replied to the thread
> to get the change merged.
>
> [...]
Applied to local tree (apple-soc/dt-7.2), thanks!
[1/5] dt-bindings: power: apple,pmgr-pwrstate: Add t8122 compatible
https://github.com/AsahiLinux/linux/commit/4d28a9a428f6
[3/5] dt-bindings: pwm: apple,s5l-fpwm: Add t8122 compatible
https://github.com/AsahiLinux/linux/commit/d0960529afbd
[4/5] dt-bindings: arm: apple: Add M3 based devices
https://github.com/AsahiLinux/linux/commit/5701af106b03
[5/5] arm64: dts: apple: Initial t8122 (M3) device trees
https://github.com/AsahiLinux/linux/commit/1dfa78533534
Best regards,
--
Sven Peter <sven@kernel.org>
^ permalink raw reply
* Re: [PATCH 09/16] arm64: dts: qcom: shikra: Add CDSP, LPAICP, MPSS remoteproc PAS nodes
From: Dmitry Baryshkov @ 2026-05-25 9:27 UTC (permalink / raw)
To: Komal Bajaj
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Krzysztof Kozlowski, Georgi Djakov, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, dmaengine, devicetree, linux-kernel,
linux-pm, Bibek Kumar Patro
In-Reply-To: <20260525-shikra-dt-m1-v1-9-f51a9838dbaa@oss.qualcomm.com>
On Mon, May 25, 2026 at 01:19:13AM +0530, Komal Bajaj wrote:
> From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>
> Add nodes for remoteproc PAS loader for CDSP, LPAICP, MPSS subsystem.
>
> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 164 +++++++++++++++++++++++++++++++++++
> 1 file changed, 164 insertions(+)
>
> +
> + remoteproc_lpaicp: remoteproc@b800000 {
> + compatible = "qcom,shikra-lpaicp-pas";
> + reg = <0x0 0x0b800000 0x0 0x200000>;
> +
> + interrupts-extended = <&intc GIC_SPI 257 IRQ_TYPE_EDGE_RISING 0>,
> + <&lmcu_smp2p_in 0 IRQ_TYPE_NONE>,
> + <&lmcu_smp2p_in 1 IRQ_TYPE_NONE>,
> + <&lmcu_smp2p_in 2 IRQ_TYPE_NONE>,
> + <&lmcu_smp2p_in 3 IRQ_TYPE_NONE>;
> +
> + interrupt-names = "wdog",
> + "fatal",
> + "ready",
> + "handover",
> + "stop-ack";
> +
> + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>;
> + clock-names = "xo";
> +
> + memory-region = <&lmcu_mem &lmcu_dtb_mem>;
> +
> + qcom,smem-states = <&lmcu_smp2p_out 0>;
> + qcom,smem-state-names = "stop";
> +
> + status = "disabled";
> +
> + glink-edge {
> + interrupts = <GIC_SPI 286 IRQ_TYPE_EDGE_RISING 0>;
> + mboxes = <&apcs_glb 9>;
> + qcom,remote-pid = <26>;
> + label = "lpaicp";
No FastRPC for LPAICP?
> + };
> + };
> +
> sram@c11e000 {
> compatible = "qcom,shikra-imem", "mmio-sram";
> reg = <0x0 0x0c11e000 0x0 0x1000>;
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 6/9] pinctrl: ultrarisc: Add UltraRISC DP1000 pinctrl driver
From: Linus Walleij @ 2026-05-25 9:28 UTC (permalink / raw)
To: wangjia
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Bartosz Golaszewski,
Samuel Holland, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
devicetree, linux-riscv, linux-kernel, linux-gpio
In-Reply-To: <20260515-ultrarisc-pinctrl-v1-6-bf559589ea8a@ultrarisc.com>
Hi Jia,
thanks for your patch!
On Fri, May 15, 2026 at 3:18 AM Jia Wang via B4 Relay
<devnull+wangjia.ultrarisc.com@kernel.org> wrote:
> From: Jia Wang <wangjia@ultrarisc.com>
>
> Add pinctrl driver for UltraRISC DP1000 pinctrl controller.
>
> Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
Please write an elaborate commit message with some details about
the hardware and it's history etc.
(...)
> +struct ur_legacy_prop_data {
> + struct ur_pin_val *pin_vals;
> + unsigned int *group_pins;
> + unsigned int num_pins;
> +};
> +static int ur_legacy_parse_prop(struct pinctrl_dev *pctldev,
> + struct device_node *np,
> + const char *propname,
> + struct ur_legacy_prop_data *prop)
> +static const char *ur_legacy_get_function_name(const struct ur_pinctrl_match_data *match_data,
> + u32 mode)
> +static int ur_legacy_conf_to_configs(struct pinctrl_dev *pctldev, u32 conf,
> + unsigned long **configs,
> + unsigned int *num_configs)
> +static int ur_legacy_add_pinconf_maps(struct pinctrl_dev *pctldev,
> + struct pinctrl_map **map,
> + unsigned int *reserved_maps,
> + unsigned int *num_maps,
> + const struct ur_legacy_prop_data *prop)
> +static int ur_legacy_dt_node_to_map(struct pinctrl_dev *pctldev,
> + struct device_node *np,
> + struct pinctrl_map **map,
> + unsigned int *num_maps)
What's up with all this legacy stuff?
What is this a legacy of?
I thought this was a *new* driver so how can it be "legacy"?
> +static int ur_generic_dt_node_to_map(struct pinctrl_dev *pctldev,
> + struct device_node *np_config,
> + struct pinctrl_map **map,
> + unsigned int *num_maps)
> +{
> + return pinconf_generic_dt_node_to_map(pctldev, np_config, map, num_maps,
> + PIN_MAP_TYPE_INVALID);
> +}
Hm I think Conor has new helpers for this so you don't need to wrap
it like this.
> +static void ur_dt_free_map(struct pinctrl_dev *pctldev,
> + struct pinctrl_map *map,
> + unsigned int num_maps)
> +{
> + pinctrl_utils_free_map(pctldev, map, num_maps);
> +}
Can't you just assign pinctrl_utils_free_map directly to ur_pinctrl_ops?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 10/16] arm64: dts: qcom: shikra-cqm: Enable CDSP, LPAICP and MPSS
From: Dmitry Baryshkov @ 2026-05-25 9:29 UTC (permalink / raw)
To: Komal Bajaj
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Krzysztof Kozlowski, Georgi Djakov, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, dmaengine, devicetree, linux-kernel,
linux-pm, Bibek Kumar Patro
In-Reply-To: <20260525-shikra-dt-m1-v1-10-f51a9838dbaa@oss.qualcomm.com>
On Mon, May 25, 2026 at 01:19:14AM +0530, Komal Bajaj wrote:
> From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>
> Enable CDSP, LPAICP and MPSS for Qualcomm's Shikra CQM EVK board.
>
> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
> index 0a52ab9b7a4c..b112b21b1d79 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
> @@ -23,6 +23,25 @@ chosen {
> };
> };
>
> +&remoteproc_cdsp {
> + firmware-name = "qcom/shikra/cdsp.mbn";
> +
> + status = "okay";
> +};
> +
> +&remoteproc_lpaicp {
> + firmware-name = "qcom/shikra/lpaicp.mbn",
> + "qcom/shikra/lpaicp_dtb.mbn";
When can we expect modem and LPAICP firmware in linux-firmware?
> +
> + status = "okay";
> +};
> +
> +&remoteproc_mpss {
> + firmware-name = "qcom/shikra/cqm/qdsp6sw.mbn";
> +
> + status = "okay";
> +};
> +
> &sdhc_1 {
> vmmc-supply = <&pm4125_l20>;
> vqmmc-supply = <&pm4125_l14>;
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox