* Re: [PATCH v3 3/3] regulator: qcom-refgen: add support for the IPQ9650 SoC
From: Kathiravan Thirumoorthy @ 2026-06-15 17:40 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, linux-arm-msm, linux-kernel, devicetree,
Dmitry Baryshkov
In-Reply-To: <f2e9f59c-3de7-41e4-92d9-88f91955175d@sirena.org.uk>
On 6/15/2026 11:01 PM, Mark Brown wrote:
> On Mon, Jun 15, 2026 at 10:54:26PM +0530, Kathiravan Thirumoorthy wrote:
>> On 6/15/2026 9:28 PM, Mark Brown wrote:
>>> This looks like a get_status() operation, not an enable operation? The
>>> enables and disables are pure clock operations.
>> Thanks, Mark for the review. If I understand correctly, I should track the
>> clock enable/disable operations and return that state in the is_enabled()
>> callback (as I did in v1). Please let me know if my understanding does not
>> align with your expectations.
> Yes. If as it seems the device can actually implement a get_status()
> operation the driver should do that as well.
Thanks Mark. I shall introduce get_status() with STATUS register read
back and update the is_enabled() to track the clock enable / disable
operation.
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: rtc: sun6i: Add Allwinner A733 support
From: Jerome Brunet @ 2026-06-15 17:46 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Junhui Liu, Michael Turquette, Stephen Boyd, Jernej Skrabec,
Samuel Holland, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Ripard, linux-clk,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-rtc,
devicetree
In-Reply-To: <CAGb2v67844OPwE6VJ0PAs5LsmCa2h0FvXOBUomZ50dM5tZ0Zow@mail.gmail.com>
On sam. 28 mars 2026 at 20:37, Chen-Yu Tsai <wens@kernel.org> wrote:
> On Wed, Jan 21, 2026 at 7:03 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
>>
>> The RTC module in the Allwinner A733 SoC is functionally compatible with
>> the sun6i RTC, but its internal Clock Control Unit (CCU) has significant
>> changes.
>>
>> The A733 supports selecting the oscillator between three frequencies:
>> 19.2MHz, 24MHz, and 26MHz. The RTC CCU relies on hardware to detect
>> which frequency is actually used on the board. By defining all three
>> frequencies as fixed-clocks in the device tree, the driver can identify
>> the hardware-detected frequency and expose it to the rest of the system.
>
> No. The board device tree shall have the exact and correct frequency
> defined in the external crystal device node. The operating system can
> use the hardware-detected frequency to "fix" the in-system representation
> if it is off.
>
>> Additionally, the A733 RTC CCU provides several new DCXO gate clocks for
>> specific modules, including SerDes, HDMI, and UFS.
>>
>> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
>> ---
>> .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 38 ++++++++++++++++++++--
>> include/dt-bindings/clock/sun60i-a733-rtc.h | 16 +++++++++
>> 2 files changed, 52 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>> index 9df5cdb6f63f..b18431955783 100644
>> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>> @@ -26,6 +26,7 @@ properties:
>> - allwinner,sun50i-h6-rtc
>> - allwinner,sun50i-h616-rtc
>> - allwinner,sun50i-r329-rtc
>> + - allwinner,sun60i-a733-rtc
>> - items:
>> - const: allwinner,sun50i-a64-rtc
>> - const: allwinner,sun8i-h3-rtc
>> @@ -46,11 +47,11 @@ properties:
>>
>> clocks:
>> minItems: 1
>> - maxItems: 4
>> + maxItems: 6
>>
>> clock-names:
>> minItems: 1
>> - maxItems: 4
>> + maxItems: 6
>>
>> clock-output-names:
>> minItems: 1
>> @@ -156,6 +157,38 @@ allOf:
>> - clocks
>> - clock-names
>>
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + const: allwinner,sun60i-a733-rtc
>> +
>> + then:
>> + properties:
>> + clocks:
>> + minItems: 5
>> + items:
>> + - description: Bus clock for register access
>
>> + - description: 19.2 MHz oscillator
>> + - description: 24 MHz oscillator
>> + - description: 26 MHz oscillator
>
> No. There is only one input. As in there is only one set of pins for the
> DCXO. The inputs are the same as on R329 / A523. Just use that list.
>
>> + - description: AHB parent for internal SPI clock
>> + - description: External 32768 Hz oscillator
>> +
>> + clock-names:
>> + minItems: 5
>> + items:
>> + - const: bus
>> + - const: osc19M
>> + - const: osc24M
>> + - const: osc26M
>> + - const: ahb
>> + - const: ext-osc32k
>> +
>> + required:
>> + - clocks
>> + - clock-names
>> +
>> - if:
>> properties:
>> compatible:
>> @@ -164,6 +197,7 @@ allOf:
>> - allwinner,sun8i-r40-rtc
>> - allwinner,sun50i-h616-rtc
>> - allwinner,sun50i-r329-rtc
>> + - allwinner,sun60i-a733-rtc
>>
>> then:
>> properties:
>> diff --git a/include/dt-bindings/clock/sun60i-a733-rtc.h b/include/dt-bindings/clock/sun60i-a733-rtc.h
>> new file mode 100644
>> index 000000000000..8a2b5facad73
>> --- /dev/null
>> +++ b/include/dt-bindings/clock/sun60i-a733-rtc.h
>> @@ -0,0 +1,16 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
>> +
>> +#ifndef _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_
>> +#define _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_
>> +
>> +#define CLK_IOSC 0
>> +#define CLK_OSC32K 1
>> +#define CLK_HOSC 2
>
> The DCXO enable control has been present since at least the H6. We just
> never added it, as we would never disable it anyway.
>
> If you compare the RTC clock trees of the A733 and A523, the only addition
> besides the new gates seems to be the LOSC auto selection. But even that
> is just an illusion, as the A523 has the same registers for that.
>
> One could say the A733 RTC is almost backward compatible to the A523, if
> not for the two fastboot registers the A523 has at 0x120 and 0x124.
>
> So I ask that you try to integrate the differences into the existing
> driver and bindings. You can tweak and export internal clks if you
> need.
I'd like to help with that. I think it is doable but I have a question
regarding the binding of the existing driver, more precisely their usage
here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c?h=v7.1#n370
Clock indexes are supposed to be stable in DT (AFAIK) but with the code
linked the external 32k is at:
* "ext-32k" - so index 3 - if "clock-names" is present
* index 0 if clock names is not present
... but index 0 is supposed to be the bus clock according the binding
doc, whether "clock-names" is there or not :/
So what are those old r329 bindings ? is there a documentation defining
them somewhere ?
Cleaning that part would help with A733 addition in the existing driver
I think
>
>> +#define CLK_RTC_32K 3
>
> AFAICT besides being an internal clock, this is also fed to GPIO for
> debounce? We probably need to expose this on the A523 as well.
>
>
> Thanks
> ChenYu
>
>
>> +#define CLK_OSC32K_FANOUT 4
>> +#define CLK_HOSC_SERDES1 5
>> +#define CLK_HOSC_SERDES0 6
>> +#define CLK_HOSC_HDMI 7
>> +#define CLK_HOSC_UFS 8
>> +
>> +#endif /* _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_ */
>>
>> --
>> 2.52.0
>>
>>
--
Jerome
^ permalink raw reply
* Re: [PATCH V13 5/9] iio: imu: inv_icm42607: Add PM support for icm42607
From: sashiko-bot @ 2026-06-15 17:50 UTC (permalink / raw)
To: Chris Morgan; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260615172554.160910-6-macroalpha82@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Missing synchronous suspend during driver unbind leaves hardware sensors powered on and leaking power.
- [Medium] Unconditional 45ms sleep during gyro power-off injects unnecessary delay on every suspend transition.
- [Low] Incorrect constant used for defining the autosuspend delay.
--
commit c053e5ed4a86d71f412c402ec80e9602b6677c2a
Author: Chris Morgan <macromorgan@hotmail.com>
iio: imu: inv_icm42607: Add PM support for icm42607
Add power management support for the ICM42607 device driver.
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
[ ... ]
> @@ -334,11 +345,18 @@ struct inv_icm42607_state {
> #define INV_ICM42607_GYRO_STOP_TIME_MS 45
> #define INV_ICM42607_TEMP_STARTUP_TIME_MS 77
>
> +/*
> + * Suspend delay assumed from other icm42600 series device, not
> + * documented in datasheet.
> + */
> +#define INV_ICM42607_SUSPEND_DELAY_MS (2 * USEC_PER_MSEC)
[Severity: Low]
Is this using the correct conversion macro? While (2 * USEC_PER_MSEC)
evaluates to 2000, USEC_PER_MSEC means microseconds per millisecond. Using
it to convert seconds to milliseconds is semantically confusing. Should this be
2 * MSEC_PER_SEC or just the literal 2000?
> +
> typedef int (*inv_icm42607_bus_setup)(struct inv_icm42607_state *);
>
> extern const struct regmap_config inv_icm42607_regmap_config;
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
[ ... ]
> @@ -103,6 +105,63 @@ const struct inv_icm42607_hw inv_icm42607p_hw_data = {
> };
> EXPORT_SYMBOL_NS_GPL(inv_icm42607p_hw_data, "IIO_ICM42607");
>
> +static int inv_icm42607_set_pwr_mgmt0(struct inv_icm42607_state *st,
> + enum inv_icm42607_sensor_mode gyro,
> + enum inv_icm42607_sensor_mode accel,
> + bool temp, unsigned int *sleep_ms)
> +{
> + enum inv_icm42607_sensor_mode oldaccel = st->conf.accel.mode;
> + enum inv_icm42607_sensor_mode oldgyro = st->conf.gyro.mode;
> + bool oldtemp = st->conf.temp_en;
> + unsigned int sleepval_ms;
> + unsigned int val;
> + int ret;
> +
> + if (gyro == oldgyro && accel == oldaccel && temp == oldtemp)
> + return 0;
> +
> + /*
> + * Datasheet on page 14.26 says we need to ensure the gyro sensor is on
> + * for a minimum of 45ms. So if we transition from an on state to an
> + * off state wait 45ms to ensure a sufficient pause before power off.
> + */
> + if (!gyro && oldgyro)
> + fsleep(INV_ICM42607_GYRO_STOP_TIME_MS * USEC_PER_MSEC);
[Severity: Medium]
Does this inject a 45ms delay into every runtime suspend transition?
The code unconditionally sleeps for 45ms when turning off the gyro.
If the datasheet requires the gyro to remain ON for a minimum of 45ms
after power-on, wouldn't it be better to track the power-on timestamp
instead of delaying every power-off sequence, even if the gyro has
been active for hours?
> +
> + val = FIELD_PREP(INV_ICM42607_PWR_MGMT0_GYRO_MODE_MASK, gyro);
> + val |= FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_MODE_MASK, accel);
[ ... ]
> @@ -271,10 +342,78 @@ int inv_icm42607_core_probe(struct regmap *regmap,
> if (ret)
> return ret;
>
> + ret = devm_pm_runtime_set_active_enabled(dev);
> + if (ret)
> + return ret;
> +
> + pm_runtime_set_autosuspend_delay(dev, INV_ICM42607_SUSPEND_DELAY_MS);
> + pm_runtime_use_autosuspend(dev);
> +
> return 0;
> }
[Severity: High]
Does this code leak power on unbind?
Since autosuspend is used, the device doesn't suspend synchronously when
pm_runtime_put_sync() is called by the driver core on removal. Instead, an
async autosuspend is queued.
When the devres cleanup action invokes pm_runtime_disable(), the pending
autosuspend work is cancelled, meaning inv_icm42607_runtime_suspend() is
never executed.
If the sensors remain fully powered on in the PWR_MGMT0 register, and the
vddio regulator is shared with other devices, will this cause a permanent
power leak? Would adding a driver remove callback that calls
pm_runtime_dont_use_autosuspend() or pm_runtime_put_sync_suspend()
ensure the device powers down synchronously?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615172554.160910-1-macroalpha82@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH V13 6/9] iio: imu: inv_icm42607: Add Temp Support in icm42607
From: sashiko-bot @ 2026-06-15 17:51 UTC (permalink / raw)
To: Chris Morgan; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260615172554.160910-7-macroalpha82@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] Prematurely mutating the temperature software state before calling the power management configuration bypasses state change detection, skipping the mandatory startup delay and causing reads of uninitialized data.
Pre-existing issues:
- [High] The temperature sensor read fails (returns -EINVAL) when the gyroscope and accelerometer are off because the device is placed in Sleep mode instead of Idle mode, disabling the internal RC oscillator.
--
commit d36f0c461ef9d5076de90b75b6238be45c35148d
Author: Chris Morgan <macromorgan@hotmail.com>
Subject: iio: imu: inv_icm42607: Add Temp Support in icm42607
Add functions for reading temperature sensor data.
[ ... ]
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> index 64f5d263de4f2..644cd7f821b92 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
[ ... ]
> @@ -162,6 +162,24 @@ static int inv_icm42607_set_pwr_mgmt0(struct inv_icm42607_state *st,
> return 0;
> }
>
> +int inv_icm42607_set_temp_conf(struct inv_icm42607_state *st, bool enable,
> + unsigned int *sleep_ms)
> +{
> + unsigned int val;
> + int ret;
> +
> + val = FIELD_PREP(INV_ICM42607_TEMP_CONFIG0_FILTER_MASK,
> + INV_ICM42607_FILTER_BW_34HZ);
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_TEMP_CONFIG0,
> + INV_ICM42607_TEMP_CONFIG0_FILTER_MASK, val);
> + if (ret)
> + return ret;
> +
> + return inv_icm42607_set_pwr_mgmt0(st, st->conf.gyro.mode,
> + st->conf.accel.mode, enable,
> + sleep_ms);
[Severity: High]
This is a pre-existing issue, but will this temperature read fail with -EINVAL
if the gyroscope and accelerometer are off?
Looking at inv_icm42607_set_pwr_mgmt0(), it constructs the PWR_MGMT0 register
value using only the gyro and accel mode masks:
val = FIELD_PREP(INV_ICM42607_PWR_MGMT0_GYRO_MODE_MASK, gyro);
val |= FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_MODE_MASK, accel);
ret = regmap_write(st->map, INV_ICM42607_REG_PWR_MGMT0, val);
If both gyro and accel are off, val is 0, which places the device in Sleep mode
instead of Idle mode. The internal RC oscillator required for temperature reads
is disabled, causing the data register to return 0x8000
(INV_ICM42607_DATA_INVALID).
Should the IDLE bit be set when temp is true and the other sensors are
inactive?
> +}
> +
[ ... ]
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
> new file mode 100644
> index 0000000000000..9a60e1a478b08
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
[ ... ]
> +static int inv_icm42607_temp_read(struct inv_icm42607_state *st, s16 *temp)
> +{
> + struct device *dev = regmap_get_device(st->map);
> + u8 raw[2];
> + int ret;
> +
> + PM_RUNTIME_ACQUIRE_AUTOSUSPEND(dev, pm);
> + ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
> + if (ret)
> + return ret;
> +
> + guard(mutex)(&st->lock);
> +
> + st->conf.temp_en = true;
> + ret = inv_icm42607_set_temp_conf(st, st->conf.temp_en, NULL);
[Severity: High]
Does setting st->conf.temp_en to true before this call bypass the hardware
configuration and startup delay?
Because st->conf.temp_en is mutated before the call, when
inv_icm42607_set_temp_conf() calls inv_icm42607_set_pwr_mgmt0(), it will
evaluate the state transition like this:
bool oldtemp = st->conf.temp_en;
...
if (gyro == oldgyro && accel == oldaccel && temp == oldtemp)
return 0;
Since temp and oldtemp are now both true, the function returns early without
writing to the power management register or waiting for the startup delay.
Could this lead to reading uninitialized or desynchronized data?
> + st->conf.temp_en = false;
> + if (ret)
> + return ret;
> +
> + ret = regmap_bulk_read(st->map, INV_ICM42607_REG_TEMP_DATA1,
> + raw, sizeof(raw));
> + if (ret)
> + return ret;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615172554.160910-1-macroalpha82@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v4 04/16] media: iris: Introduce interrupt_init as a vpu_op
From: Vishnu Reddy @ 2026-06-15 17:55 UTC (permalink / raw)
To: Dmitry Baryshkov, Vikash Garodia, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260612-iris-ar50lt-v4-4-0abfb74d5b3c@oss.qualcomm.com>
On 6/12/2026 2:55 PM, Dmitry Baryshkov wrote:
> From: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>
> The interrupt_init sequence is currently shared across all supported
> devices. Starting with Qualcomm QCM2290 (AR50LT), the register
> programming would differ.
>
> Move interrupt_init into a vpu_op to allow per-device customization.
>
> This change prepares the driver for upcoming hardware variants.
> No functional change so far for existing devices.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_vpu2.c | 1 +
> drivers/media/platform/qcom/iris/iris_vpu3x.c | 3 +++
> drivers/media/platform/qcom/iris/iris_vpu4x.c | 1 +
> drivers/media/platform/qcom/iris/iris_vpu_common.c | 4 ++--
> drivers/media/platform/qcom/iris/iris_vpu_common.h | 2 ++
> 5 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu2.c b/drivers/media/platform/qcom/iris/iris_vpu2.c
> index 2dc121a3f5e8..dd2eeae0d9eb 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu2.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu2.c
> @@ -46,4 +46,5 @@ const struct vpu_ops iris_vpu2_ops = {
> .calc_freq = iris_vpu2_calc_freq,
> .set_hwmode = iris_vpu_set_hwmode,
> .set_preset_registers = iris_vpu_set_preset_registers,
> + .interrupt_init = iris_vpu_interrupt_init,
> };
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu3x.c b/drivers/media/platform/qcom/iris/iris_vpu3x.c
> index dc02ced1b931..c3b760730c98 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu3x.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu3x.c
> @@ -262,6 +262,7 @@ const struct vpu_ops iris_vpu3_ops = {
> .calc_freq = iris_vpu3x_vpu4x_calculate_frequency,
> .set_hwmode = iris_vpu_set_hwmode,
> .set_preset_registers = iris_vpu_set_preset_registers,
> + .interrupt_init = iris_vpu_interrupt_init,
> };
>
> const struct vpu_ops iris_vpu33_ops = {
> @@ -272,6 +273,7 @@ const struct vpu_ops iris_vpu33_ops = {
> .calc_freq = iris_vpu3x_vpu4x_calculate_frequency,
> .set_hwmode = iris_vpu_set_hwmode,
> .set_preset_registers = iris_vpu_set_preset_registers,
> + .interrupt_init = iris_vpu_interrupt_init,
> };
>
> const struct vpu_ops iris_vpu35_ops = {
> @@ -283,4 +285,5 @@ const struct vpu_ops iris_vpu35_ops = {
> .calc_freq = iris_vpu3x_vpu4x_calculate_frequency,
> .set_hwmode = iris_vpu_set_hwmode,
> .set_preset_registers = iris_vpu_set_preset_registers,
> + .interrupt_init = iris_vpu_interrupt_init,
> };
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu4x.c b/drivers/media/platform/qcom/iris/iris_vpu4x.c
> index f608a297d4a3..90ccdc0d2a07 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu4x.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu4x.c
> @@ -369,4 +369,5 @@ const struct vpu_ops iris_vpu4x_ops = {
> .calc_freq = iris_vpu3x_vpu4x_calculate_frequency,
> .set_hwmode = iris_vpu4x_set_hwmode,
> .set_preset_registers = iris_vpu_set_preset_registers,
> + .interrupt_init = iris_vpu_interrupt_init,
> };
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.c b/drivers/media/platform/qcom/iris/iris_vpu_common.c
> index a49113b0da23..375bcd923476 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu_common.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu_common.c
> @@ -31,7 +31,7 @@
> #define UC_REGION_ADDR (CPU_CS_BASE_OFFS + 0x64)
> #define UC_REGION_SIZE (CPU_CS_BASE_OFFS + 0x68)
>
> -static void iris_vpu_interrupt_init(struct iris_core *core)
> +void iris_vpu_interrupt_init(struct iris_core *core)
> {
> u32 mask_val;
>
> @@ -485,7 +485,7 @@ int iris_vpu_power_on(struct iris_core *core)
>
> core->iris_platform_data->vpu_ops->set_preset_registers(core);
>
> - iris_vpu_interrupt_init(core);
> + core->iris_platform_data->vpu_ops->interrupt_init(core);
> core->intr_status = 0;
> enable_irq(core->irq);
>
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.h b/drivers/media/platform/qcom/iris/iris_vpu_common.h
> index 21ed4c9bd5e3..9151545065cd 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu_common.h
> +++ b/drivers/media/platform/qcom/iris/iris_vpu_common.h
> @@ -23,6 +23,7 @@ struct vpu_ops {
> u64 (*calc_freq)(struct iris_inst *inst, size_t data_size);
> int (*set_hwmode)(struct iris_core *core);
> void (*set_preset_registers)(struct iris_core *core);
> + void (*interrupt_init)(struct iris_core *core);
> };
>
> int iris_vpu_boot_firmware(struct iris_core *core);
> @@ -44,5 +45,6 @@ void iris_vpu35_vpu4x_program_bootup_registers(struct iris_core *core);
> u64 iris_vpu3x_vpu4x_calculate_frequency(struct iris_inst *inst, size_t data_size);
>
> void iris_vpu_set_preset_registers(struct iris_core *core);
> +void iris_vpu_interrupt_init(struct iris_core *core);
>
> #endif
Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 09/12] rtc: rzn1: Use temporary variable for struct device
From: sashiko-bot @ 2026-06-15 17:56 UTC (permalink / raw)
To: Prabhakar; +Cc: devicetree, robh, conor+dt, wsa+renesas
In-Reply-To: <20260615154805.1619693-10-prabhakar.mahadev-lad.rj@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] Asynchronous pm_runtime_put() is used instead of pm_runtime_put_sync() before runtime PM is disabled, potentially leaving the device powered on.
- [High] If the optional 'xtal' clock is missing, readl_poll_timeout() loops forever with a 0 timeout, risking a boot hang.
- [High] The driver's `remove` callback prematurely disables hardware interrupts and drops the runtime PM reference while the RTC device is still fully registered.
--
commit b7f73c7d0932a6e78b12419c5912ad3243637b8f
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
rtc: rzn1: Use temporary variable for struct device
This patch simplifies the rzn1_rtc_probe function by using a local temporary
variable for the struct device pointer. This avoids repeated dereferences of
pdev->dev throughout the function.
> diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> index bc6af59744e48..25cad9213147d 100644
> --- a/drivers/rtc/rtc-rzn1.c
> +++ b/drivers/rtc/rtc-rzn1.c
[ ... ]
> @@ -415,15 +416,15 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
[ ... ]
> /* Only switch to scmp if we have an xtal clock with a valid rate and != 32768 */
> - xtal = devm_clk_get_optional(&pdev->dev, "xtal");
> + xtal = devm_clk_get_optional(dev, "xtal");
[Severity: High]
This is a pre-existing issue, but if the optional xtal clock is not present,
devm_clk_get_optional() sets xtal to NULL. In this scenario, rtc->sync_time
remains uninitialized and defaults to 0.
Further down in rzn1_rtc_probe(), readl_poll_timeout() is called:
ret = readl_poll_timeout(rtc->base + RZN1_RTC_CTL0, val,
!(val & RZN1_RTC_CTL0_CEST), rtc->sync_time,
rtc->sync_time * 2);
With rtc->sync_time at 0, the timeout evaluation becomes 0. Does this cause
readl_poll_timeout() to loop indefinitely and hang the boot if the hardware
fails to clear the RZN1_RTC_CTL0_CEST bit?
> if (IS_ERR(xtal)) {
> ret = PTR_ERR(xtal);
> goto dis_runtime_pm;
[ ... ]
> @@ -486,18 +487,18 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
[ ... ]
> device_init_wakeup(dev, true);
>
> ret = devm_rtc_register_device(rtc->rtcdev);
[Severity: High]
This isn't a bug introduced by this patch, but does registering the RTC
device using devm_rtc_register_device() create a race condition during
teardown?
In rzn1_rtc_remove(), the driver manually disables interrupts and calls
pm_runtime_put() before devres has unregistered the RTC device:
writel(0, rtc->base + RZN1_RTC_CTL1);
pm_runtime_put(&pdev->dev);
Could userspace still interact with the RTC during this window via ioctls
or sysfs, potentially causing synchronous bus faults since the hardware is
already suspended? Should teardown be bound using
devm_add_action_or_reset() to guarantee correct reverse execution order?
> if (ret)
> @@ -506,7 +507,7 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
> return 0;
>
> dis_runtime_pm:
> - pm_runtime_put(&pdev->dev);
> + pm_runtime_put(dev);
[Severity: High]
This is a pre-existing issue, but does using pm_runtime_put() here (and in
rzn1_rtc_remove) leave the device powered on indefinitely?
Since devm_pm_runtime_enable(dev) schedules pm_runtime_disable() to
execute during devres cleanup, calling pm_runtime_put() only queues an
asynchronous idle check. The immediate return triggers devres cleanup,
which executes a barrier that explicitly cancels pending async operations.
Should this use pm_runtime_put_sync() instead to ensure the device is
synchronously suspended before teardown?
> return ret;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=9
^ permalink raw reply
* Re: [PATCH 7/7] clk: sunxi-ng: Add Allwinner A733 RTC CCU support
From: Jerome Brunet @ 2026-06-15 17:56 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Junhui Liu, Michael Turquette, Stephen Boyd, Jernej Skrabec,
Samuel Holland, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Ripard, linux-clk,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-rtc,
devicetree, André Przywara
In-Reply-To: <CAGb2v64euL+QNXiJdTn0JygYLXg0WoguPSprKT4sKGZGVZbwug@mail.gmail.com>
On sam. 28 mars 2026 at 22:41, Chen-Yu Tsai <wens@kernel.org> wrote:
> On Wed, Jan 21, 2026 at 7:04 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
>>
>> Add support for the internal CCU found in the RTC module of the Allwinner
>> A733 SoC. While the basic 16MHz (IOSC) and 32kHz logic remains compatible
>> with older SoCs like the sun6i, the A733 introduces several new features.
>>
>> The A733 RTC CCU supports choosing one of three external crystal
>> frequencies: 19.2MHz, 24MHz, and 26MHz. It features hardware detection
>> logic to automatically identify the frequency used on the board and
>> exports this DCXO signal as the "hosc" clock.
>>
>> Furthermore, the driver implements logic to derive a 32kHz reference
>> from the HOSC. This is achieved through a muxed clock path using fixed
>> pre-dividers to normalize the different crystal frequencies to ~32kHz.
>
> Have you tested whether the actually normalizes the frequency, i.e.
> selects a different divider based on the DCXO frequency? Otherwise
> we're just lying about the frequency.
>
>> This path reuses the same hardware mux registers as the HOSC clock.
>>
>> Additionally, this CCU provides several gate clocks for specific
>> peripherals, including SerDes, HDMI, and UFS. The driver is implemented
>> as an auxiliary driver to be bound to the sun6i-rtc driver.
>>
>> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
>> ---
[...]
>> +};
>> +
>> +static const struct clk_parent_data hosc_parents[] = {
>> + { .fw_name = "osc24M" },
>> + { .fw_name = "osc19M" },
>> + { .fw_name = "osc26M" },
>> + { .fw_name = "osc24M" },
>> +};
>
> As mentioned in my reply to the binding, this is wrong. There is only
> one input.
>
> The most you can do is check the rate of the parent clock against the
> detected one, and _scream_ that the DT is wrong. And maybe override
> the reported frequency.
>
> If you want to do the latter, you could add a new fixed rate gated
> clock type to our library. You would fill in the rate before the
> clocks get registered. I probably wouldn't go that far. We want people
> to have correct hardware descriptions.
>
> Funnily enough Allwinner's BSP actually implements a fixed rate gate
> for the next 24M-to-32k divider clock.
What about implementing the register bellow as a read-only (and
non-cached) divider using the factors provided by Junhui ? That would be
an accurate description of the HW I think.
The oscillator gets set in DT and if the output reported past the
divider is not 32728Hz, you know you've got a problem (bad DT or HW gone
bad)
With a fixed-rate gate, you may actually end up lying about what
actually happen, if the HW does not behave as expected.
Do you prefer a fixed-rate gate still or should I try the RO divider
approach ?
>
>> +
>> +struct ccu_mux hosc_clk = {
>> + .enable = DCXO_CTRL_DCXO_EN,
>> + .mux = _SUNXI_CCU_MUX(14, 2),
>> + .common = {
>> + .reg = DCXO_CTRL_REG,
>> + .hw.init = CLK_HW_INIT_PARENTS_DATA("hosc",
>> + hosc_parents,
>> + &ccu_mux_ro_ops,
>> + 0),
>> + },
>> +};
>
> So this is wrong.
>
>> +
>> +static const struct ccu_mux_fixed_prediv hosc_32k_predivs[] = {
>> + { .index = 0, .div = 732 },
>
> Why is it 732 instead of 750?
>
>> + { .index = 1, .div = 586 },
>> + { .index = 2, .div = 793 },
>> + { .index = 3, .div = 732 },
>> +};
>> +
>> +static struct ccu_mux hosc_32k_mux_clk = {
>> + .enable = DCXO_CTRL_DCXO_EN,
>
^ permalink raw reply
* [PATCH v2] dt-bindings: display: Add Solomon SSD1351 OLED controller
From: Amit Barzilai @ 2026-06-15 17:56 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, javierm
Cc: devicetree, dri-devel, linux-kernel, airlied, maarten.lankhorst,
mripard, simona, tzimmermann, Amit Barzilai
Add a device tree binding for the Solomon SSD1351, a 128x128 65k-color
RGB OLED display controller driven over a 4-wire SPI bus. The binding
builds on the shared solomon,ssd-common.yaml properties already used by
the other Solomon display controllers.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com>
---
Changes since v1:
- Drop solomon,width / solomon,height: both are deducible from the
compatible and are already declared (as optional) by the referenced
solomon,ssd-common.yaml, so a local override is unnecessary.
- Drop the rotation property: it has no consumer (rotation is being removed from the driver).
- Use dt-bindings/gpio/gpio.h flag defines in the example
(reset-gpios active-low, dc-gpios active-high).
.../bindings/display/solomon,ssd1351.yaml | 41 +++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/solomon,ssd1351.yaml
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1351.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1351.yaml
new file mode 100644
index 000000000000..39622d74a41d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/solomon,ssd1351.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/solomon,ssd1351.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Solomon SSD1351 OLED Display Controller
+
+maintainers:
+ - Amit Barzilai <amit.barzilai22@gmail.com>
+
+allOf:
+ - $ref: solomon,ssd-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - solomon,ssd1351
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ oled@0 {
+ compatible = "solomon,ssd1351";
+ reg = <0x0>;
+ reset-gpios = <&gpio2 7 GPIO_ACTIVE_LOW>;
+ dc-gpios = <&gpio2 8 GPIO_ACTIVE_HIGH>;
+ spi-max-frequency = <10000000>;
+ };
+ };
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 2/2] of/fdt: make early_init_dt_scan_chosen() return void
From: Sang-Heon Jeon @ 2026-06-15 17:59 UTC (permalink / raw)
To: Rob Herring
Cc: maddy, mpe, npiggin, chleroy, saravanak, linuxppc-dev, devicetree
In-Reply-To: <20260601220346.GB54006-robh@kernel.org>
Hello,
On Tue, Jun 2, 2026 at 7:03 AM Rob Herring <robh@kernel.org> wrote:
>
> On Mon, May 11, 2026 at 02:13:53AM +0900, Sang-Heon Jeon wrote:
> > Since commit 064e32dc5b03 ("of: fdt: Honor CONFIG_CMDLINE* even
> > without /chosen node, take 2"), early_init_dt_scan_chosen() always
> > returns 0, so the return value checks at its callers have become
> > dead code.
> >
> > Drop the return value, change the function to return void, and
> > update its declaration and callers accordingly. No functional
> > change.
> >
> > Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
> > ---
> > dt-test result
> >
> > [ 0.684136] ### dt-test ### start of unittest - you will see error messages
> > [ 0.685849] ### dt-test ### EXPECT \ : Duplicate name in testcase-data, renamed to "duplicate-name#1"
> > [ 0.685870] Duplicate name in testcase-data, renamed to "duplicate-name#1"
> > [ 0.689496] ### dt-test ### EXPECT / : Duplicate name in testcase-data, renamed to "duplicate-name#1"
> >
> > ...
> >
> > [ 1.693384] ### dt-test ### EXPECT / : OF: resolver: overlay phandle fixup failed: -22
> > [ 1.693386] ### dt-test ### EXPECT / : OF: resolver: node label 'this_label_does_not_exist' not found in live devicetree symbols table
> > [ 1.694968] ### dt-test ### end of unittest - 405 passed, 0 failed
> > ---
> > drivers/of/fdt.c | 10 ++--------
> > include/linux/of_fdt.h | 2 +-
> > 2 files changed, 3 insertions(+), 9 deletions(-)
>
> Looks like this is dependent on patch 1, so I'm assuming the PPC folks
> will take the series.
>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Thanks for reviewing, Rob :)
The merge window is now open. PPC folks, could you take a look and
pick this series up for 7.2?
Best Regards,
Sang-Heon Jeon
^ permalink raw reply
* Re: [PATCH v4 06/16] media: iris: Add platform data field for watchdog interrupt mask
From: Vishnu Reddy @ 2026-06-15 17:59 UTC (permalink / raw)
To: Dmitry Baryshkov, Vikash Garodia, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260612-iris-ar50lt-v4-6-0abfb74d5b3c@oss.qualcomm.com>
On 6/12/2026 2:55 PM, Dmitry Baryshkov wrote:
> From: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>
> For AR50LT core, the value of WRAPPER_INTR_STATUS_A2HWD_BMASK differs
> from the currently supported VPUs. In preparation for adding AR50LT
> support in subsequent patches, introduce a platform data field,
> wd_intr_mask, to capture the watchdog interrupt bitmask per platform.
>
> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_platform_common.h | 1 +
> drivers/media/platform/qcom/iris/iris_platform_vpu2.c | 4 ++++
> drivers/media/platform/qcom/iris/iris_platform_vpu3x.c | 6 ++++++
> drivers/media/platform/qcom/iris/iris_vpu_common.c | 8 +++++---
> drivers/media/platform/qcom/iris/iris_vpu_register_defines.h | 1 -
> 5 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
> index 55a4fa356985..81fcb2854772 100644
> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
> @@ -315,6 +315,7 @@ struct iris_platform_data {
> u32 tz_cp_config_data_size;
> u32 num_vpp_pipe;
> bool no_aon;
> + u32 wd_intr_mask;
> u32 max_session_count;
> /* max number of macroblocks per frame supported */
> u32 max_core_mbpf;
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_vpu2.c b/drivers/media/platform/qcom/iris/iris_platform_vpu2.c
> index 961dce2e6aa9..eeef453c583f 100644
> --- a/drivers/media/platform/qcom/iris/iris_platform_vpu2.c
> +++ b/drivers/media/platform/qcom/iris/iris_platform_vpu2.c
> @@ -16,6 +16,8 @@
> #include "iris_platform_sc7280.h"
> #include "iris_platform_sm8250.h"
>
> +#define WRAPPER_INTR_STATUS_A2HWD_BMSK BIT(3)
> +
> static const struct iris_firmware_desc iris_vpu20_p1_gen1_desc = {
> .firmware_data = &iris_hfi_gen1_data,
> .get_vpu_buffer_size = iris_vpu_buf_size,
> @@ -94,6 +96,7 @@ const struct iris_platform_data sc7280_data = {
> .tz_cp_config_data_size = ARRAY_SIZE(tz_cp_config_vpu2),
> .num_vpp_pipe = 1,
> .no_aon = true,
> + .wd_intr_mask = WRAPPER_INTR_STATUS_A2HWD_BMSK,
> .max_session_count = 16,
> .max_core_mbpf = 4096 * 2176 / 256 * 2 + 1920 * 1088 / 256,
> /* max spec for SC7280 is 4096x2176@60fps */
> @@ -124,6 +127,7 @@ const struct iris_platform_data sm8250_data = {
> .tz_cp_config_data = tz_cp_config_vpu2,
> .tz_cp_config_data_size = ARRAY_SIZE(tz_cp_config_vpu2),
> .num_vpp_pipe = 4,
> + .wd_intr_mask = WRAPPER_INTR_STATUS_A2HWD_BMSK,
> .max_session_count = 16,
> .max_core_mbpf = NUM_MBS_8K,
> .max_core_mbps = ((7680 * 4320) / 256) * 60,
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c b/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c
> index 74626b35d9cb..261db38a013b 100644
> --- a/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c
> +++ b/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c
> @@ -18,6 +18,8 @@
> #include "iris_platform_sm8750.h"
> #include "iris_platform_x1p42100.h"
>
> +#define WRAPPER_INTR_STATUS_A2HWD_BMSK BIT(3)
> +
> static const struct iris_firmware_desc iris_vpu30_p4_s6_gen2_desc = {
> .firmware_data = &iris_hfi_gen2_data,
> .get_vpu_buffer_size = iris_vpu_buf_size,
> @@ -113,6 +115,7 @@ const struct iris_platform_data qcs8300_data = {
> .tz_cp_config_data = tz_cp_config_vpu3,
> .tz_cp_config_data_size = ARRAY_SIZE(tz_cp_config_vpu3),
> .num_vpp_pipe = 2,
> + .wd_intr_mask = WRAPPER_INTR_STATUS_A2HWD_BMSK,
> .max_session_count = 16,
> .max_core_mbpf = ((4096 * 2176) / 256) * 4,
> .max_core_mbps = (((3840 * 2176) / 256) * 120),
> @@ -142,6 +145,7 @@ const struct iris_platform_data sm8550_data = {
> .tz_cp_config_data = tz_cp_config_vpu3,
> .tz_cp_config_data_size = ARRAY_SIZE(tz_cp_config_vpu3),
> .num_vpp_pipe = 4,
> + .wd_intr_mask = WRAPPER_INTR_STATUS_A2HWD_BMSK,
> .max_session_count = 16,
> .max_core_mbpf = NUM_MBS_8K * 2,
> .max_core_mbps = ((7680 * 4320) / 256) * 60,
> @@ -179,6 +183,7 @@ const struct iris_platform_data sm8650_data = {
> .tz_cp_config_data = tz_cp_config_vpu3,
> .tz_cp_config_data_size = ARRAY_SIZE(tz_cp_config_vpu3),
> .num_vpp_pipe = 4,
> + .wd_intr_mask = WRAPPER_INTR_STATUS_A2HWD_BMSK,
> .max_session_count = 16,
> .max_core_mbpf = NUM_MBS_8K * 2,
> .max_core_mbps = ((7680 * 4320) / 256) * 60,
> @@ -208,6 +213,7 @@ const struct iris_platform_data sm8750_data = {
> .tz_cp_config_data = tz_cp_config_vpu3,
> .tz_cp_config_data_size = ARRAY_SIZE(tz_cp_config_vpu3),
> .num_vpp_pipe = 4,
> + .wd_intr_mask = WRAPPER_INTR_STATUS_A2HWD_BMSK,
> .max_session_count = 16,
> .max_core_mbpf = NUM_MBS_8K * 2,
> .max_core_mbps = ((7680 * 4320) / 256) * 60,
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.c b/drivers/media/platform/qcom/iris/iris_vpu_common.c
> index 375bcd923476..41498f94480e 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu_common.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu_common.c
> @@ -109,11 +109,11 @@ void iris_vpu_raise_interrupt(struct iris_core *core)
>
> void iris_vpu_clear_interrupt(struct iris_core *core)
> {
> + u32 wd_intr_mask = core->iris_platform_data->wd_intr_mask;
> u32 intr_status, mask;
>
> intr_status = readl(core->reg_base + WRAPPER_INTR_STATUS);
> - mask = (WRAPPER_INTR_STATUS_A2H_BMSK |
> - WRAPPER_INTR_STATUS_A2HWD_BMSK |
> + mask = (WRAPPER_INTR_STATUS_A2H_BMSK | wd_intr_mask |
> CTRL_INIT_IDLE_MSG_BMSK);
>
> if (intr_status & mask)
> @@ -124,7 +124,9 @@ void iris_vpu_clear_interrupt(struct iris_core *core)
>
> int iris_vpu_watchdog(struct iris_core *core, u32 intr_status)
> {
> - if (intr_status & WRAPPER_INTR_STATUS_A2HWD_BMSK) {
> + u32 wd_intr_mask = core->iris_platform_data->wd_intr_mask;
> +
> + if (intr_status & wd_intr_mask) {
> dev_err(core->dev, "received watchdog interrupt\n");
> return -ETIME;
> }
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_register_defines.h b/drivers/media/platform/qcom/iris/iris_vpu_register_defines.h
> index 72168b9ffa73..4fffa094c52f 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu_register_defines.h
> +++ b/drivers/media/platform/qcom/iris/iris_vpu_register_defines.h
> @@ -41,7 +41,6 @@
> #define MSK_CORE_POWER_ON BIT(1)
>
> #define WRAPPER_INTR_STATUS (WRAPPER_BASE_OFFS + 0x0C)
> -#define WRAPPER_INTR_STATUS_A2HWD_BMSK BIT(3)
> #define WRAPPER_INTR_STATUS_A2H_BMSK BIT(2)
>
> #define WRAPPER_INTR_MASK (WRAPPER_BASE_OFFS + 0x10)
Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH V13 8/9] iio: imu: inv_icm42607: Add Gyroscope to icm42607
From: sashiko-bot @ 2026-06-15 18:03 UTC (permalink / raw)
To: Chris Morgan; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260615172554.160910-9-macroalpha82@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The gyro sensor state is not reverted after a raw read, causing it to remain permanently enabled during all future active PM states.
--
commit 608315b9e755ed3de8730d6f1fc3e2dc0c68b7a5
Author: Chris Morgan <macromorgan@hotmail.com>
iio: imu: inv_icm42607: Add Gyroscope to icm42607
This commit adds gyroscope functions and IIO device registration to the
icm42607 driver.
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
> new file mode 100644
> index 0000000000000..ef73560b39d73
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
[ ... ]
> +static int inv_icm42607_gyro_read_sensor(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + s16 *val)
> +{
> + struct inv_icm42607_sensor_conf conf = INV_ICM42607_SENSOR_CONF_INIT;
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> + struct inv_icm42607_sensor_state *gyro_st = iio_priv(indio_dev);
> + struct device *dev = regmap_get_device(st->map);
> + unsigned int reg;
> + u8 data[2];
> + int ret;
[ ... ]
> + PM_RUNTIME_ACQUIRE_AUTOSUSPEND(dev, pm);
> + ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
> + if (ret)
> + return ret;
> +
> + guard(mutex)(&st->lock);
> +
> + /* enable gyro sensor */
> + conf.mode = gyro_st->power_mode;
> + conf.filter = gyro_st->filter;
> + ret = inv_icm42607_set_gyro_conf(st, &conf, NULL);
> + if (ret)
> + return ret;
> +
> + /* read gyro register data */
> + ret = regmap_bulk_read(st->map, reg, data, sizeof(data));
> + if (ret)
> + return ret;
> +
> + *val = get_unaligned_be16(data);
> + if (*val == INV_ICM42607_DATA_INVALID)
> + return -EINVAL;
> +
> + return 0;
> +}
[Severity: Medium]
Does this leave the gyroscope permanently enabled after a raw read?
The function enables the gyro by setting conf.mode = gyro_st->power_mode
and calling inv_icm42607_set_gyro_conf(), but does not appear to revert it
to an off state before returning.
When the device later autosuspends, inv_icm42607_runtime_suspend() saves this
active state into st->suspended.gyro. On every subsequent PM resume,
inv_icm42607_runtime_resume() will restore the gyro to ON.
Could this cause an unnecessary 45ms startup delay and waste power during all
future active PM states?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615172554.160910-1-macroalpha82@gmail.com?part=8
^ permalink raw reply
* Re: [PATCH v4 07/16] media: iris: Add platform flag for instantaneous bandwidth voting
From: Vishnu Reddy @ 2026-06-15 18:09 UTC (permalink / raw)
To: Dmitry Baryshkov, Vikash Garodia, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260612-iris-ar50lt-v4-7-0abfb74d5b3c@oss.qualcomm.com>
On 6/12/2026 2:55 PM, Dmitry Baryshkov wrote:
> From: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>
> AR50LT require explicit instantaneous bandwidth (IB) voting in addition
> to average bandwidth (AB) when configuring interconnect QoS. This
> requirement is due to QSB (Qualcomm System Bus) 128b to
> QNS ( Qualcomm Network Switch) 256b conversion at video noc in AR50LT
> which is not needed for other IRIS cores.
>
> In preparation of adding support for AR50LT core, introduce
> platform-configurable IB multiplier and enable IB voting for all SoCs.
> Existing platforms default to IB == AB, while AR50LT requires 2x peak
> bandwidth.
>
> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_platform_common.h | 1 +
> drivers/media/platform/qcom/iris/iris_platform_vpu2.c | 2 ++
> drivers/media/platform/qcom/iris/iris_platform_vpu3x.c | 4 ++++
> drivers/media/platform/qcom/iris/iris_resources.c | 2 ++
> 4 files changed, 9 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
> index 81fcb2854772..accc1627defd 100644
> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
> @@ -316,6 +316,7 @@ struct iris_platform_data {
> u32 num_vpp_pipe;
> bool no_aon;
> u32 wd_intr_mask;
> + u32 icc_ib_multiplier;
> u32 max_session_count;
> /* max number of macroblocks per frame supported */
> u32 max_core_mbpf;
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_vpu2.c b/drivers/media/platform/qcom/iris/iris_platform_vpu2.c
> index eeef453c583f..e2fddc29abc7 100644
> --- a/drivers/media/platform/qcom/iris/iris_platform_vpu2.c
> +++ b/drivers/media/platform/qcom/iris/iris_platform_vpu2.c
> @@ -97,6 +97,7 @@ const struct iris_platform_data sc7280_data = {
> .num_vpp_pipe = 1,
> .no_aon = true,
> .wd_intr_mask = WRAPPER_INTR_STATUS_A2HWD_BMSK,
> + .icc_ib_multiplier = 1,
> .max_session_count = 16,
> .max_core_mbpf = 4096 * 2176 / 256 * 2 + 1920 * 1088 / 256,
> /* max spec for SC7280 is 4096x2176@60fps */
> @@ -128,6 +129,7 @@ const struct iris_platform_data sm8250_data = {
> .tz_cp_config_data_size = ARRAY_SIZE(tz_cp_config_vpu2),
> .num_vpp_pipe = 4,
> .wd_intr_mask = WRAPPER_INTR_STATUS_A2HWD_BMSK,
> + .icc_ib_multiplier = 1,
> .max_session_count = 16,
> .max_core_mbpf = NUM_MBS_8K,
> .max_core_mbps = ((7680 * 4320) / 256) * 60,
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c b/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c
> index 261db38a013b..64cf182d67cc 100644
> --- a/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c
> +++ b/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c
> @@ -116,6 +116,7 @@ const struct iris_platform_data qcs8300_data = {
> .tz_cp_config_data_size = ARRAY_SIZE(tz_cp_config_vpu3),
> .num_vpp_pipe = 2,
> .wd_intr_mask = WRAPPER_INTR_STATUS_A2HWD_BMSK,
> + .icc_ib_multiplier = 1,
> .max_session_count = 16,
> .max_core_mbpf = ((4096 * 2176) / 256) * 4,
> .max_core_mbps = (((3840 * 2176) / 256) * 120),
> @@ -146,6 +147,7 @@ const struct iris_platform_data sm8550_data = {
> .tz_cp_config_data_size = ARRAY_SIZE(tz_cp_config_vpu3),
> .num_vpp_pipe = 4,
> .wd_intr_mask = WRAPPER_INTR_STATUS_A2HWD_BMSK,
> + .icc_ib_multiplier = 1,
> .max_session_count = 16,
> .max_core_mbpf = NUM_MBS_8K * 2,
> .max_core_mbps = ((7680 * 4320) / 256) * 60,
> @@ -184,6 +186,7 @@ const struct iris_platform_data sm8650_data = {
> .tz_cp_config_data_size = ARRAY_SIZE(tz_cp_config_vpu3),
> .num_vpp_pipe = 4,
> .wd_intr_mask = WRAPPER_INTR_STATUS_A2HWD_BMSK,
> + .icc_ib_multiplier = 1,
> .max_session_count = 16,
> .max_core_mbpf = NUM_MBS_8K * 2,
> .max_core_mbps = ((7680 * 4320) / 256) * 60,
> @@ -214,6 +217,7 @@ const struct iris_platform_data sm8750_data = {
> .tz_cp_config_data_size = ARRAY_SIZE(tz_cp_config_vpu3),
> .num_vpp_pipe = 4,
> .wd_intr_mask = WRAPPER_INTR_STATUS_A2HWD_BMSK,
> + .icc_ib_multiplier = 1,
> .max_session_count = 16,
> .max_core_mbpf = NUM_MBS_8K * 2,
> .max_core_mbps = ((7680 * 4320) / 256) * 60,
> diff --git a/drivers/media/platform/qcom/iris/iris_resources.c b/drivers/media/platform/qcom/iris/iris_resources.c
> index 773f6548370a..caeaf199cef7 100644
> --- a/drivers/media/platform/qcom/iris/iris_resources.c
> +++ b/drivers/media/platform/qcom/iris/iris_resources.c
> @@ -18,6 +18,7 @@
>
> int iris_set_icc_bw(struct iris_core *core, unsigned long icc_bw)
> {
> + u32 icc_ib_multiplier = core->iris_platform_data->icc_ib_multiplier;
> unsigned long bw_kbps = 0, bw_prev = 0;
> const struct icc_info *icc_tbl;
> int ret = 0, i;
> @@ -36,6 +37,7 @@ int iris_set_icc_bw(struct iris_core *core, unsigned long icc_bw)
> return ret;
>
> core->icc_tbl[i].avg_bw = bw_kbps;
> + core->icc_tbl[i].peak_bw = bw_kbps * icc_ib_multiplier;
>
> core->power.icc_bw = bw_kbps;
> break;
Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: display: Add Solomon SSD1351 OLED controller
From: Amit Barzilai @ 2026-06-15 18:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Amit Barzilai, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, javierm, robh, krzk+dt, conor+dt, dri-devel, devicetree,
linux-kernel
In-Reply-To: <20260611-psychedelic-funky-foxhound-a8e39d@quoll>
Hi Krzysztof,
Thanks for the review.
> > + solomon,width:
> > + default: 128
> > +
> > + solomon,height:
> > + default: 128
>
> Drop both - deducible from the compatible.
Done. Both are dropped in v2; solomon,ssd-common.yaml already declares them
(as optional) and the driver supplies the 128x128 default from its
device_info.
> > + rotation: true
>
> Either drop or reference panel-common (if this is a panel) or at least
> reference that property:
> $ref: /schemas/display/panel/panel-common.yaml#/properties/rotation
Dropped in v2. Rotation is being removed from the driver, so the property has
no consumer.
> > + reset-gpios = <&gpio2 7>;
> > + dc-gpios = <&gpio2 8>;
>
> Use proper defines for GPIO flags
Done. v2 includes <dt-bindings/gpio/gpio.h> and uses GPIO_ACTIVE_LOW for
reset-gpios (the SSD1351 reset is active-low) and GPIO_ACTIVE_HIGH for
dc-gpios.
I'm sending v2 as a standalone binding patch so it can land independently of
the driver, which is being reworked separately. dt_binding_check passes
cleanly.
Thanks,
Amit
^ permalink raw reply
* Re: [PATCH] dt-bindings: vendor-prefixes: add Gira
From: Rob Herring @ 2026-06-15 18:12 UTC (permalink / raw)
To: Lucas Stach; +Cc: Krzysztof Kozlowski, Conor Dooley, devicetree, kernel
In-Reply-To: <20260610213047.500701-1-l.stach@pengutronix.de>
On Wed, Jun 10, 2026 at 11:30:47PM +0200, Lucas Stach wrote:
> Add vendor prefix for Gira Giersiepen GmbH & Co. KG
> Link: https://www.gira.de/
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Applied, thanks.
Rob
^ permalink raw reply
* Re: [PATCH 0/2] drm: Add driver for the Solomon SSD1351 OLED controller
From: Amit Barzilai @ 2026-06-15 18:12 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Amit Barzilai, airlied, conor+dt, devicetree, dri-devel, krzk+dt,
linux-kernel, maarten.lankhorst, mripard, robh, simona,
tzimmermann
In-Reply-To: <877bo576o1.fsf@ocarina.mail-host-address-is-not-set>
Hi Javier,
Thanks you for the detailed review and for the Reviewed-by on the binding.
I agree with folding the SSD1351 into ssd130x rather than keeping it
standalone. My plan for the v2 driver series follows your two steps:
1. Add RGB565 support to the existing SSD133X family (so the SSD1331 gains
65k color), gating the format on a per-variant flag in device_info so the
existing RGB332 path is untouched.
2. Add a new SSD135X family for the SSD1351 on top of that, reusing the
ssd133x data path (the update_rect window logic is already
format-agnostic) and adding only the SSD1351-specific bits - the 0x5c
write-RAM command and its init sequence.
I'm deferring step 3 (native 256k color) for now since, as you suspected,
there's no matching DRM fourcc, and I'm dropping the 0/180 rotation support
to keep the series focused; it can come back later.
Two things I'd like to confirm before I send the series:
- I have an SSD1331 panel, but it is currently unsoldered and I don't have
the means to solder it myself. I'm trying to arrange testing through
someone else - I can't promise it will work out. If it doesn't, the
SSD1331 RGB565 change would be compile-tested only (I do have SSD1351
hardware to test the new family). Is compile-tested-only acceptable for
the SSD1331 part, or would you prefer I hold that piece until it can be
verified on hardware?
- Could you confirm the RGB565 byte order the SSD1331 expects? The
standalone SSD1351 code used big-endian (drm_fb_xrgb8888_to_rgb565be);
I want the shared conversion helper to match the SSD1331 datasheet.
Separately, I've sent the DT binding as a standalone v2. Since I dropped the
width/height and rotation properties per Krzysztof's review, I did not carry
your Reviewed-by forward - please re-review at your convenience.
Thanks,
Amit
^ permalink raw reply
* Re: [PATCH v4 09/16] media: iris: Add framework support for AR50_LITE video core
From: Vishnu Reddy @ 2026-06-15 18:17 UTC (permalink / raw)
To: Dmitry Baryshkov, Vikash Garodia, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260612-iris-ar50lt-v4-9-0abfb74d5b3c@oss.qualcomm.com>
On 6/12/2026 2:55 PM, Dmitry Baryshkov wrote:
> From: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>
> Add power sequence for ar5lt core.
> Add register handling for ar50lt by hooking up vpu op with ar50lt
> specific implemtation or resue from earlier generation wherever
> feasible.
>
> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/Makefile | 1 +
> .../platform/qcom/iris/iris_platform_common.h | 2 +
> drivers/media/platform/qcom/iris/iris_vpu_ar50lt.c | 156 +++++++++++++++++++++
> drivers/media/platform/qcom/iris/iris_vpu_common.c | 3 +-
> drivers/media/platform/qcom/iris/iris_vpu_common.h | 1 +
> 5 files changed, 162 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
> index 48e415cbc439..f1b204b95694 100644
> --- a/drivers/media/platform/qcom/iris/Makefile
> +++ b/drivers/media/platform/qcom/iris/Makefile
> @@ -26,6 +26,7 @@ qcom-iris-objs += iris_buffer.o \
> iris_vpu2.o \
> iris_vpu3x.o \
> iris_vpu4x.o \
> + iris_vpu_ar50lt.o \
> iris_vpu_buffer.o \
> iris_vpu_common.o \
>
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
> index accc1627defd..6a189489369f 100644
> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
> @@ -74,6 +74,7 @@ enum platform_clk_type {
> IRIS_VPP0_HW_CLK,
> IRIS_VPP1_HW_CLK,
> IRIS_APV_HW_CLK,
> + IRIS_THROTTLE_CLK,
> };
>
> struct platform_clk_data {
> @@ -315,6 +316,7 @@ struct iris_platform_data {
> u32 tz_cp_config_data_size;
> u32 num_vpp_pipe;
> bool no_aon;
> + bool no_rpmh;
> u32 wd_intr_mask;
> u32 icc_ib_multiplier;
> u32 max_session_count;
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_ar50lt.c b/drivers/media/platform/qcom/iris/iris_vpu_ar50lt.c
> new file mode 100644
> index 000000000000..1af20b067c03
> --- /dev/null
> +++ b/drivers/media/platform/qcom/iris/iris_vpu_ar50lt.c
> @@ -0,0 +1,156 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2026 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include <linux/bits.h>
> +#include <linux/iopoll.h>
> +#include <linux/reset.h>
> +
> +#include "iris_instance.h"
> +#include "iris_vpu_common.h"
> +
> +#include "iris_vpu_register_defines.h"
> +
> +#define WRAPPER_INTR_MASK_A2HVCODEC_BMSK_AR50LT BIT(3)
> +
> +#define WRAPPER_VCODEC0_CLOCK_CONFIG_AR50LT 0xb0080
> +
> +#define CPU_CS_VCICMD 0xa0020
> +#define CPU_CS_VCICMD_ARP_OFF 0x1
> +
> +static void iris_vpu_ar50lt_set_preset_registers(struct iris_core *core)
> +{
> + writel(0x0, core->reg_base + WRAPPER_VCODEC0_CLOCK_CONFIG_AR50LT);
> +}
> +
> +static void iris_vpu_ar50lt_interrupt_init(struct iris_core *core)
> +{
> + writel(WRAPPER_INTR_MASK_A2HVCODEC_BMSK_AR50LT, core->reg_base + WRAPPER_INTR_MASK);
> +}
> +
> +static void iris_vpu_ar50lt_disable_arp(struct iris_core *core)
> +{
> + writel(CPU_CS_VCICMD_ARP_OFF, core->reg_base + CPU_CS_VCICMD);
> +}
> +
> +static int iris_vpu_ar50lt_power_off_controller(struct iris_core *core)
> +{
> + iris_disable_unprepare_clock(core, IRIS_AHB_CLK);
> + iris_disable_unprepare_clock(core, IRIS_AXI_CLK);
> + iris_disable_unprepare_clock(core, IRIS_CTRL_CLK);
> + iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_CTRL_POWER_DOMAIN]);
> +
> + return 0;
> +}
> +
> +static void iris_vpu_ar50lt_power_off_hw(struct iris_core *core)
> +{
> + dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN], false);
> + iris_disable_unprepare_clock(core, IRIS_THROTTLE_CLK);
> + iris_disable_unprepare_clock(core, IRIS_HW_AHB_CLK);
> + iris_disable_unprepare_clock(core, IRIS_HW_CLK);
> + iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
> +}
> +
> +static int iris_vpu_ar50lt_power_on_controller(struct iris_core *core)
> +{
> + int ret;
> +
> + ret = iris_enable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_CTRL_POWER_DOMAIN]);
> + if (ret)
> + return ret;
> +
> + ret = iris_prepare_enable_clock(core, IRIS_CTRL_CLK);
> + if (ret)
> + goto err_disable_power;
> +
> + ret = iris_prepare_enable_clock(core, IRIS_AXI_CLK);
> + if (ret && ret != -ENOENT)
> + goto err_disable_ctrl_clock;
> +
> + ret = iris_prepare_enable_clock(core, IRIS_AHB_CLK);
> + if (ret)
> + goto err_disable_axi_clock;
> +
> + return 0;
> +
> +err_disable_axi_clock:
> + iris_disable_unprepare_clock(core, IRIS_AXI_CLK);
> +err_disable_ctrl_clock:
> + iris_disable_unprepare_clock(core, IRIS_CTRL_CLK);
> +err_disable_power:
> + iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_CTRL_POWER_DOMAIN]);
> +
> + return ret;
> +}
> +
> +static int iris_vpu_ar50lt_power_on_hw(struct iris_core *core)
> +{
> + int ret;
> +
> + ret = iris_enable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
> + if (ret)
> + return ret;
> +
> + ret = iris_prepare_enable_clock(core, IRIS_HW_CLK);
> + if (ret)
> + goto err_disable_power;
> +
> + ret = iris_prepare_enable_clock(core, IRIS_HW_AHB_CLK);
> + if (ret)
> + goto err_disable_hw_clock;
> +
> + ret = iris_prepare_enable_clock(core, IRIS_THROTTLE_CLK);
> + if (ret)
> + goto err_disable_hw_ahb_clock;
> +
> + return 0;
> +
> +err_disable_hw_ahb_clock:
> + iris_disable_unprepare_clock(core, IRIS_HW_AHB_CLK);
> +err_disable_hw_clock:
> + iris_disable_unprepare_clock(core, IRIS_HW_CLK);
> +err_disable_power:
> + iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
> +
> + return ret;
> +}
> +
> +static u64 iris_vpu_ar50lt_calc_freq(struct iris_inst *inst, size_t data_size)
> +{
> + struct platform_inst_caps *caps = inst->core->iris_platform_data->inst_caps;
> + struct v4l2_format *inp_f = inst->fmt_src;
> + u32 mbs_per_second, mbpf, height, width;
> + unsigned long vpp_freq, vsp_freq;
> + u32 fps = DEFAULT_FPS;
fps = inst->frame_rate;
> +
> + width = max(inp_f->fmt.pix_mp.width, inst->crop.width);
> + height = max(inp_f->fmt.pix_mp.height, inst->crop.height);
> +
> + mbpf = NUM_MBS_PER_FRAME(height, width);
> + mbs_per_second = mbpf * fps;
> +
> + vpp_freq = mbs_per_second * caps->mb_cycles_vpp;
> +
> + /* 21 / 20 is overhead factor */
> + vpp_freq += vpp_freq / 20;
> + vsp_freq = mbs_per_second * caps->mb_cycles_vsp;
> +
> + /* 10 / 7 is overhead factor */
> + vsp_freq += ((fps * data_size * 8) * 10) / 7;
> +
> + return max(vpp_freq, vsp_freq);
> +}
> +
> +const struct vpu_ops iris_vpu_ar50lt_ops = {
> + .power_off_hw = iris_vpu_ar50lt_power_off_hw,
> + .power_on_hw = iris_vpu_ar50lt_power_on_hw,
> + .power_off_controller = iris_vpu_ar50lt_power_off_controller,
> + .power_on_controller = iris_vpu_ar50lt_power_on_controller,
> + .calc_freq = iris_vpu_ar50lt_calc_freq,
> + .set_hwmode = iris_vpu_set_hwmode,
> + .set_preset_registers = iris_vpu_ar50lt_set_preset_registers,
> + .interrupt_init = iris_vpu_ar50lt_interrupt_init,
> + .disable_arp = iris_vpu_ar50lt_disable_arp,
> +};
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.c b/drivers/media/platform/qcom/iris/iris_vpu_common.c
> index 41498f94480e..75dc051cc6cb 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu_common.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu_common.c
> @@ -97,7 +97,8 @@ int iris_vpu_boot_firmware(struct iris_core *core)
> }
>
> writel(HOST2XTENSA_INTR_ENABLE, core->reg_base + CPU_CS_H2XSOFTINTEN);
> - writel(0x0, core->reg_base + CPU_CS_X2RPMH);
> + if (!core->iris_platform_data->no_rpmh)
> + writel(0x0, core->reg_base + CPU_CS_X2RPMH);
>
> return 0;
> }
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.h b/drivers/media/platform/qcom/iris/iris_vpu_common.h
> index 71d96921ed37..f00e2de5fa53 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu_common.h
> +++ b/drivers/media/platform/qcom/iris/iris_vpu_common.h
> @@ -13,6 +13,7 @@ extern const struct vpu_ops iris_vpu3_ops;
> extern const struct vpu_ops iris_vpu33_ops;
> extern const struct vpu_ops iris_vpu35_ops;
> extern const struct vpu_ops iris_vpu4x_ops;
> +extern const struct vpu_ops iris_vpu_ar50lt_ops;
>
> struct vpu_ops {
> void (*power_off_hw)(struct iris_core *core);
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: i2c: i2c-mux-pinctrl: change maintainer
From: Thierry Reding @ 2026-06-15 18:38 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-i2c, Thierry Reding, Peter Rosin, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <20260611122704.7559-2-wsa+renesas@sang-engineering.com>
[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]
On Thu, Jun 11, 2026 at 02:26:24PM +0200, Wolfram Sang wrote:
> The YAML conversion added me as maintainer but I can't recall being
> asked nor do I want to maintain it. Thierry has created the YAML file
> and works for the company which contributed the driver.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>
> @Thierry: are you okay with this change?
>
> Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.yaml
> index 2e3d555eb96c..f7502da71909 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.yaml
> +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.yaml
> @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
> title: Pinctrl-based I2C Bus Mux
>
> maintainers:
> - - Wolfram Sang <wsa@kernel.org>
> + - Thierry Reding <treding@nvidia.com>
>
> description: |
> This binding describes an I2C bus multiplexer that uses pin multiplexing to route the I2C
By default I used to list the subsystem maintainer as the bindings
maintainer if the binding wasn't Tegra-specific, or in this case the
original author wasn't active anymore.
I'm fine being listed as the maintainer for this if you don't want to,
but I prefer to use the thierry.reding@kernel.org email address for
communication.
With that:
Acked-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: soc: imx: fsl,imx93-media-blk-ctrl: Allow LVDS Display Bridge child node
From: Rob Herring (Arm) @ 2026-06-15 18:47 UTC (permalink / raw)
To: Liu Ying
Cc: Frank Li, imx, Conor Dooley, linux-arm-kernel, linux-kernel,
Fabio Estevam, devicetree, Marco Felsch, Pengutronix Kernel Team,
Sascha Hauer, Krzysztof Kozlowski, Peng Fan
In-Reply-To: <20260610-imx93-ldb-v3-1-c9b65d742753@nxp.com>
On Wed, 10 Jun 2026 17:26:21 +0800, Liu Ying wrote:
> i.MX93 SoC mediamix blk-ctrl contains one LDB_CTRL register and one LVDS
> register which control video output through a LVDS interface. Allow the
> LVDS Display Bridge(LDB) child node and add the child node to example.
>
> i.MX93 LDB child node(bridge@20) is an addressable node, while i.MX93
> Parallel Display Format Configuration(PDFC) child node(dpi-bridge) is a
> non-addressable node. Mixing the addressable and non-addressable child
> nodes is allowed according to discussion [1].
>
> Link: https://lore.kernel.org/all/n6akxiayi3g6gxcqhreb4iaohmeokoalnqup6h5r2fwdt4zijt@u2wyps55ayqm/ [1]
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> ---
> .../bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml | 39 ++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: qcom,spmi-pmic: Add Qualcomm PMK7750
From: Rob Herring (Arm) @ 2026-06-15 18:47 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Conor Dooley, devicetree, Lee Jones, Krzysztof Kozlowski,
Abel Vesa, linux-kernel, linux-arm-msm, Stephen Boyd
In-Reply-To: <20260610124119.253456-2-krzysztof.kozlowski@oss.qualcomm.com>
On Wed, 10 Jun 2026 14:41:20 +0200, Krzysztof Kozlowski wrote:
> Document Qualcomm PMK7750 used with Eliza SoC. PMIC is almost the same
> as (and compatible with) PMK8550.
>
> Cc: Abel Vesa <abel.vesa@oss.qualcomm.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v11 4/6] dt-bindings: pinctrl: s32g2-siul2: describe GPIO and EIRQ resources
From: Rob Herring (Arm) @ 2026-06-15 18:49 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Linus Walleij, Rafael J. Wysocki, Eric Chanudet, Christophe Lizzi,
NXP S32 Linux Team, Larisa Grigore, Vincent Guittot,
Pengutronix Kernel Team, linux-kernel, Alberto Ruiz,
Matthias Brugger, Sascha Hauer, linux-arm-kernel,
Greg Kroah-Hartman, Fabio Estevam, Krzysztof Kozlowski,
Ghennadi Procopciuc, Dong Aisheng, Chester Lin, imx, Lee Jones,
linux-gpio, Enric Balletbo, Shawn Guo, Bartosz Golaszewski,
devicetree, Conor Dooley, Jacky Bai, Srinivas Kandagatla
In-Reply-To: <20260610132116.1998140-5-khristineandreea.barbulescu@oss.nxp.com>
On Wed, 10 Jun 2026 15:21:14 +0200, Khristine Andreea Barbulescu wrote:
> Extend the S32G2 SIUL2 pinctrl binding to describe the GPIO data and
> external interrupt resources present in the same SIUL2 hardware block.
>
> Besides the MSCR and IMCR registers used for pin multiplexing and pad
> configuration, SIUL2 also contains PGPDO and PGPDI registers
> for GPIO data and EIRQ registers for external interrupt control.
>
> Add GPIO controller properties because the SIUL2 block also provides
> GPIO functionality, and gpio-ranges are needed to describe the
> mapping between GPIO lines and pin controller pins.
>
> Document the interrupt controller properties. The SIUL2 block
> contains EIRQ hardware as part of the same register space. IRQ support
> itself will be added in a follow-up patch series.
>
> Update the example accordingly to show the complete SIUL2 register
> layout, including the GPIO data and EIRQ register windows.
>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
> ---
> .../pinctrl/nxp,s32g2-siul2-pinctrl.yaml | 90 +++++++++++++++++--
> 1 file changed, 84 insertions(+), 6 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH v4] ASoC: dt-bindings: mtk-btcvsd-snd: Convert to DT Schema
From: Luca Leonardo Scorcia @ 2026-06-15 18:57 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-sound, devicetree, linux-kernel,
linux-arm-kernel
Convert the mtk-btcvsd-snd.txt DT binding to DT Schema format.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
Changes in v4:
- Removed minItems, maxItems properties from reg node
- Removed the reg-names property
- Adjusted the example
Changes in v3 [3]:
Sorry about the spam. A second round of dt_binding_check + dtbs_check
led me to additional improvements:
- Use reg-names in place of a non-informative description property
- Simplify the reg property in the example
Changes in v2 [2]:
- Fixed issues from make dt_binding_check
- Set myself as maintainer for the binding
Initial version [1].
[1] https://lore.kernel.org/20260420204514.1640995-1-l.scorcia@gmail.com/
[2] https://lore.kernel.org/20260421154619.227039-1-l.scorcia@gmail.com/
[3] https://lore.kernel.org/linux-mediatek/20260421193858.347258-1-l.scorcia@gmail.com/
.../sound/mediatek,mtk-btcvsd-snd.yaml | 59 +++++++++++++++++++
.../bindings/sound/mtk-btcvsd-snd.txt | 24 --------
2 files changed, 59 insertions(+), 24 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mtk-btcvsd-snd.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/mtk-btcvsd-snd.txt
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mtk-btcvsd-snd.yaml b/Documentation/devicetree/bindings/sound/mediatek,mtk-btcvsd-snd.yaml
new file mode 100644
index 000000000000..1b7451655476
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mtk-btcvsd-snd.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mtk-btcvsd-snd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek ALSA BT SCO CVSD/MSBC
+
+maintainers:
+ - Luca Leonardo Scorcia <l.scorcia@gmail.com>
+
+properties:
+ compatible:
+ const: mediatek,mtk-btcvsd-snd
+
+ reg:
+ items:
+ - description: PKV region
+ - description: SRAM_BANK2 region
+
+ interrupts:
+ items:
+ - description: BT-SCO interrupt
+
+ mediatek,infracfg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the infracfg controller
+
+ mediatek,offset:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: Array of register offsets and masks
+ items:
+ - description: infra_misc_offset
+ - description: infra_conn_bt_cvsd_mask
+ - description: cvsd_mcu_read_offset
+ - description: cvsd_mcu_write_offset
+ - description: cvsd_packet_indicator_offset
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - mediatek,infracfg
+ - mediatek,offset
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ mtk-btcvsd-snd@18000000 {
+ compatible = "mediatek,mtk-btcvsd-snd";
+ reg = <0x18000000 0x1000>,
+ <0x18080000 0x8000>;
+ interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_LOW>;
+ mediatek,infracfg = <&infrasys>;
+ mediatek,offset = <0xf00 0x800 0xfd0 0xfd4 0xfd8>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/mtk-btcvsd-snd.txt b/Documentation/devicetree/bindings/sound/mtk-btcvsd-snd.txt
deleted file mode 100644
index 679e44839b48..000000000000
--- a/Documentation/devicetree/bindings/sound/mtk-btcvsd-snd.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Mediatek ALSA BT SCO CVSD/MSBC Driver
-
-Required properties:
-- compatible = "mediatek,mtk-btcvsd-snd";
-- reg: register location and size of PKV and SRAM_BANK2
-- interrupts: should contain BTSCO interrupt
-- mediatek,infracfg: the phandles of INFRASYS
-- mediatek,offset: Array contains of register offset and mask
- infra_misc_offset,
- infra_conn_bt_cvsd_mask,
- cvsd_mcu_read_offset,
- cvsd_mcu_write_offset,
- cvsd_packet_indicator_offset
-
-Example:
-
- mtk-btcvsd-snd@18000000 {
- compatible = "mediatek,mtk-btcvsd-snd";
- reg=<0 0x18000000 0 0x1000>,
- <0 0x18080000 0 0x8000>;
- interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_LOW>;
- mediatek,infracfg = <&infrasys>;
- mediatek,offset = <0xf00 0x800 0xfd0 0xfd4 0xfd8>;
- };
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 1/6] dt-bindings: clock: qcom: gcc-sm8450: Add missing power-domains property
From: sashiko-bot @ 2026-06-15 19:02 UTC (permalink / raw)
To: Neil Armstrong; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260615-topic-sm8x50-tie-gcc-to-cx-v2-1-6b5752dd4747@linaro.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Missing `#include <dt-bindings/power/qcom,rpmhpd.h>` in the DT binding example block leads to `make dt_binding_check` syntax error.
--
commit d4a5f7a86b8e17c69572dda7a1449210ed6871bc
Author: Neil Armstrong <neil.armstrong@linaro.org>
dt-bindings: clock: qcom: gcc-sm8450: Add missing power-domains property
This commit adds the missing power-domains property to the SM8450 GCC clock
binding schema. It declares CX as a power domain of the GCC so that votes on
provided GDSCs can be correctly propagated to CX.
> diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml
> index 3169ac05e1d8a..7e3713cfd4985 100644
> --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml
> +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml
[ ... ]
> @@ -66,6 +71,7 @@ examples:
> reg = <0x00100000 0x001f4200>;
> clocks = <&rpmhcc RPMH_CXO_CLK>, <&sleep_clk>;
> clock-names = "bi_tcxo", "sleep_clk";
> + power-domains = <&rpmhpd RPMHPD_CX>;
[Severity: Low]
Does this example need an include for dt-bindings/power/qcom,rpmhpd.h added
to the file so the RPMHPD_CX macro is properly defined?
Without the header, the C preprocessor cannot expand the macro. When the
generated device tree source is passed to dtc during make dt_binding_check,
the unexpanded token will cause a syntax error and break the validation build.
> #clock-cells = <1>;
> #reset-cells = <1>;
> #power-domain-cells = <1>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-topic-sm8x50-tie-gcc-to-cx-v2-0-6b5752dd4747@linaro.org?part=1
^ permalink raw reply
* Re: [PATCH v3 2/4] dt-bindings: phy: qcom,qcs615-qmp-usb3-dp-phy: Add support for Shikra
From: Krishna Kurapati @ 2026-06-15 19:02 UTC (permalink / raw)
To: Krzysztof Kozlowski, Pratham Pratap
Cc: Neil Armstrong, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Xiangxu Yin,
Johan Hovold, Loic Poulain, Kathiravan Thirumoorthy,
Dmitry Baryshkov, Abel Vesa, linux-arm-msm, linux-phy, devicetree,
linux-kernel
In-Reply-To: <20260527-lucky-porcelain-bullfrog-185f1d@quoll>
On 5/27/2026 3:16 PM, Krzysztof Kozlowski wrote:
> On Wed, May 27, 2026 at 12:13:59AM +0530, Pratham Pratap wrote:
>> From: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
>>
>> Declare the USB QMP Phy present on Shikra SoC. On this SoC, although
>> there are DP registers, the required internal pins have been removed
>> and hence DP wouldn't be operational.
>>
>> Shikra needs 3 resets (dp/ phy/ phy_phy) to be asserted and de-asserted
>> as per hardware recommendation. Extend the bindings to accommodate the
>> additional reset.
>>
>> Use QCS615 as a fallback since the software interface is compatible with
>> Shikra.
>>
>> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
>> Signed-off-by: Pratham Pratap <pratham.pratap@oss.qualcomm.com>
>> ---
>> .../bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml | 13 ++++++++++---
>> 1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml
>> index efb465c71c1b..65ae4c6e09db 100644
>> --- a/Documentation/devicetree/bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml
>> +++ b/Documentation/devicetree/bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml
>> @@ -16,8 +16,12 @@ description:
>>
>> properties:
>> compatible:
>> - enum:
>> - - qcom,qcs615-qmp-usb3-dp-phy
>> + oneOf:
>> + - items:
>> + - enum:
>> + - qcom,shikra-qmp-usb3-dp-phy
>> + - const: qcom,qcs615-qmp-usb3-dp-phy
>> + - const: qcom,qcs615-qmp-usb3-dp-phy
>>
>> reg:
>> maxItems: 1
>> @@ -33,12 +37,15 @@ properties:
>> - const: pipe
>>
>> resets:
>> - maxItems: 2
>> + minItems: 2
>> + maxItems: 3
>
> So QCS615 has three resets now? This needs to be explained in the commit
> msg. Or fixed with constraints, see writing bindings.
>
Ok, will separate out for Shikra and keep only two for Talos.
>>
>> reset-names:
>> + minItems: 2
>> items:
>> - const: phy_phy
>> - const: dp_phy
>> + - const: phy
>
> Not phy_phy_phy? Joking aside, you already have a phy - "phy_phy" - so
> this is not correct name. I don't know what is the correct name, though.
> Please consult device manual.
>
The resets needed on Shikra are:
GCC_USB3PHY_PHY_PRIM_SP0_BCR
GCC_USB3_DP_PHY_PRIM_BCR
GCC_USB3_PHY_PRIM_SP0_BCR
Hence named the third one as "phy".
Regards,
Krishna,
^ permalink raw reply
* Re: [PATCH v3 4/4] phy: qcom: qmp-usbc: Add support for "phy" reset used on Shikra
From: Krishna Kurapati @ 2026-06-15 19:03 UTC (permalink / raw)
To: Xiangxu Yin
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Pratham Pratap, Neil Armstrong, Vinod Koul, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Johan Hovold, Loic Poulain, Kathiravan Thirumoorthy,
Dmitry Baryshkov, Abel Vesa
In-Reply-To: <d2098b36-c514-44e8-99b9-2213c4d52752@oss.qualcomm.com>
On 5/27/2026 11:57 AM, Xiangxu Yin wrote:
>
> On 5/27/2026 2:44 AM, Pratham Pratap wrote:
>> From: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
>>
>> Shikra uses three resets (dp/ phy/ phy_phy). Add the extra "phy" reset
>> needed for operation of QMP Phy on Shikra.
>>
>> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
>> Signed-off-by: Pratham Pratap <pratham.pratap@oss.qualcomm.com>
>> ---
>> drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
>> index c342479a3798..067e7f6e5642 100644
>> --- a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
>> @@ -513,7 +513,7 @@ static const char * const usb3phy_reset_l[] = {
>> };
>>
>> static const char * const usb3dpphy_reset_l[] = {
>> - "phy_phy", "dp_phy",
>> + "phy_phy", "dp_phy", "phy",
>> };
>>
>
>
> usb3dpphy_reset_l is shared with qcs615_usb3dp_phy_cfg, but I didn't find any optional-reset handling in qmp_usbc_reset_init().
> talos.dtsi only defines two resets for qcom,qcs615-qmp-usb3-dp-phy, so adding "phy" here unconditionally will break probe on QCS615.
> Please create a separate reset list for Shikra instead.
>
>
ACK, will create a new match_data cfg for Shikra instead of reusing the
talos one.
Regards,
Krishna,
>> static const struct regulator_bulk_data qmp_phy_msm8998_vreg_l[] = {
^ permalink raw reply
* Re: [PATCH] hw_random: timeriomem-rng: add configurable read width and data mask
From: sashiko-bot @ 2026-06-15 19:25 UTC (permalink / raw)
To: Jad Keskes; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260615170922.1132642-1-inasj268@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [Medium] The patch introduces a new device tree binding schema file but leaves the old schema intact, causing validation conflicts.
- [Low] Using the modulo operator `%` on a `resource_size_t` variable causes an undefined reference link error on 32-bit platforms.
Pre-existing issues:
- [High] The driver cancels the timer in `remove()` but relies on `devm` cleanup to unregister the hwrng device, creating a teardown race condition that leads to use-after-free or deadlock.
--
commit 57d226c081fc616a1deb344ec82199ee7e9c1059
Author: Jad Keskes <inasj268@gmail.com>
hw_random: timeriomem-rng: add configurable read width and data mask
The TODO for supporting read sizes other than 32 bits and masking has
been sitting in this driver since 2009. Implement it.
> diff --git a/Documentation/devicetree/bindings/rng/timeriomem-rng.yaml b/Documentation/devicetree/bindings/rng/timeriomem-rng.yaml
> new file mode 100644
> index 0000000000000..0d8460e9f9163
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rng/timeriomem-rng.yaml
> @@ -0,0 +1,76 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/rng/timeriomem-rng.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Timer IOMEM Hardware Random Number Generator
[Severity: Medium]
Will this new device tree binding schema file conflict with the existing
schema?
The patch introduces this new schema but does not appear to replace or remove
the existing timeriomem_rng.yaml file. Since both schemas match the same
compatible = "timeriomem_rng" string and the old schema specifies
additionalProperties: false, any device tree node including the newly added
width or mask properties might pass this new schema but fail the old schema's
validation, which would break dt_binding_check.
> diff --git a/drivers/char/hw_random/timeriomem-rng.c b/drivers/char/hw_random/timeriomem-rng.c
> index e61f063932090..9308988521473 100644
> --- a/drivers/char/hw_random/timeriomem-rng.c
> +++ b/drivers/char/hw_random/timeriomem-rng.c
[ ... ]
> @@ -71,11 +76,28 @@ static int timeriomem_rng_read(struct hwrng *hwrng, void *data,
> usleep_range(period_us,
> period_us + max(1, period_us / 100));
>
> - *(u32 *)data = readl(priv->io_base);
> - retval += sizeof(u32);
> - data += sizeof(u32);
> - max -= sizeof(u32);
> - } while (wait && max > sizeof(u32));
> + switch (priv->width) {
> + case 8: {
> + u8 val = readb(priv->io_base) & priv->mask;
> + *(u8 *)data = val;
> + break;
> + }
> + case 16: {
> + u16 val = readw(priv->io_base) & priv->mask;
> + *(u16 *)data = val;
> + break;
> + }
> + case 32: {
> + u32 val = readl(priv->io_base) & priv->mask;
> + *(u32 *)data = val;
> + break;
> + }
> + }
> +
> + retval += chunk;
> + data += chunk;
> + max -= chunk;
> + } while (wait && max > chunk);
[Severity: High]
This is a pre-existing issue, but does the driver have a teardown race
condition between remove() and devres cleanup?
In timeriomem_rng_remove(), hrtimer_cancel() is explicitly called to stop the
timer. However, because the RNG device was registered with
devm_hwrng_register() during probe, it remains accessible to userspace and the
hwrng core until the devres cleanups run strictly after remove() returns.
If a concurrent read is blocked on wait_for_completion() when the timer is
cancelled, it could hang indefinitely, deadlocking the reader thread and the
subsequent hwrng_unregister() call in devres cleanup.
Alternatively, if a reader completes its wait and unconditionally calls
hrtimer_restart() in timeriomem_rng_read() after the cancellation, the timer
might be re-armed:
drivers/char/hw_random/timeriomem-rng.c:timeriomem_rng_read() {
...
priv->present = 0;
reinit_completion(&priv->completion);
hrtimer_forward_now(&priv->timer, priv->period);
hrtimer_restart(&priv->timer);
...
}
When the devres cleanup later unregisters the RNG and frees the priv
structure, this re-armed timer will eventually fire, potentially dereferencing
a freed pointer.
[ ... ]
> @@ -145,9 +164,42 @@ static int timeriomem_rng_probe(struct platform_device *pdev)
> if (!of_property_read_u32(pdev->dev.of_node,
> "quality", &i))
> priv->rng_ops.quality = i;
> +
> + of_property_read_u32(pdev->dev.of_node,
> + "width", &priv->width);
> + of_property_read_u32(pdev->dev.of_node,
> + "mask", &priv->mask);
> } else {
> period = pdata->period;
> priv->rng_ops.quality = pdata->quality;
> +
> + if (pdata->width_set)
> + priv->width = pdata->width;
> + if (pdata->mask_set)
> + priv->mask = pdata->mask;
> + }
> +
> + if (priv->width == 0)
> + priv->width = 32;
> +
> + switch (priv->width) {
> + case 8:
> + case 16:
> + case 32:
> + break;
> + default:
> + dev_err(&pdev->dev, "invalid width %u, must be 8, 16, or 32\n",
> + priv->width);
> + return -EINVAL;
> + }
> +
> + if (res->start % (priv->width / 8) != 0 ||
> + resource_size(res) < priv->width / 8) {
[Severity: Low]
Does using the modulo operator here cause an undefined reference to __umoddi3
on 32-bit platforms?
The variable res->start is of type resource_size_t, which can be a 64-bit
integer on 32-bit platforms with PAE enabled (CONFIG_PHYS_ADDR_T_64BIT=y).
Since the divisor (priv->width / 8) is a runtime value rather than a
compile-time constant, the compiler might emit a call to __umoddi3 for the
64-bit division, which leads to a linker error on 32-bit architectures.
Could IS_ALIGNED() or div_u64() be used instead?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615170922.1132642-1-inasj268@gmail.com?part=1
^ 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