* [PATCH V14 0/9] Add Invensense ICM42607
From: Chris Morgan @ 2026-06-24 18:23 UTC (permalink / raw)
To: linux-iio
Cc: andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
From: Chris Morgan <macromorgan@hotmail.com>
Add support for the ICM42607 IMU. This sensor shares the same
functionality but a different register layout with the existing
ICM42600.
This driver should work with the ICM42607 and ICM42607P over both I2C
and SPI, however only the ICM42607P over I2C could be tested.
Changes Since V1:
- Instead of creating a new driver, merged with the existing inv_icm42600
driver. This necessitated adding some code to the existing driver to
permit using a different register layout for the same functionality.
- Split changes up a bit more to decrease the size of the individual
patches. Note that patch 0004 is still pretty hefty; if I need to split
further I may need to create some temporary stub functions.
- Used guard() and PM_RUNTIME_ACQUIRE_AUTOSUSPEND() on the new functions
per Jonathan's recommendations.
Changes Since V2:
- Went back to using a new driver on advice from Invensense engineer.
- Further split changes up into smaller chunks of functionality. Note
still that the largest patch is approximately 900 lines, and that while
the driver compiles cleanly at each commit it is not able to drive the
hardware until the commit that adds the Interrupt (as it also adds the
Makefile).
- Change the error to a warning when the devicetree binding does not match
the hardware ID.
- Dropped the ack on the devicetree bindings, as I am creating a new file
(for a new driver) instead of modifying the existing one.
Changes Since V3:
- Numerous small fixes (too many to list here). Thank you to everyone who
provided feedback.
- Split power management additions into an additional commit to break
things up further.
- Consolidated devicetree documentation in existing
invensense,icm42600.yaml file.
- Removed most of the FIELD_PREP from header file to c files to make code
easier to read.
- Changed scale values to 2D arrays for Gyro and Accelerometer.
- Removed IIO_CHAN_INFO_CALIBBIAS attribute.
Changes Since V4:
- Additional numerous small fixes, thank you again for all the feedback.
- Dropped power control API and instead run device in low noise mode.
- Split devicetree bindings into two distinct changes.
- Reordered adding of enums and structs to main header file so that they
are only brought in when needed.
- Stopped using enum for driver data and instead am using pointer to
device specific driver data.
Changes Since V5:
- Corrected use of "dev_warn_probe" to just "dev_warn".
- Fixed some return scenarios which would unconditionally return 0
when an error was present.
- Corrected use of max() to min() for bounds checking. max() was
incorrect.
- Fixed using "st->conf.accel.odr" in the gyroscope function. It
should have been "st->conf.gyro.odr" which it now is.
- Additional small fixes suggested by "sashiko.dev".
- Added a regmap cache. I used the datasheet to try and determine
which registers might change without explicit writes.
Changes Since V6:
- Corrected additional errors identified by sashiko.dev, mostly
fixing potential deadlocks, missing calls for pm runtime, and
potential overflow issues.
Changes Since V7:
- Dropped Wake on Movement patches, since some of the functionality
was only available for a device on which I cannot test.
- Dropped support for SPI 3-Wire mode, since it complicated the
bus setup (and I lack the hardware to test such features anyway).
- Fixed a few additional bugs identified by sashiko.dev bot.
Changes Since V8:
- Added back IRQ dropped accidentally when dropping wake on movement
patches.
- Dropped "Reviewed-By" tag on patch 2 because of substantial changes
made to devicetree binding documentation.
- Additional small fixes as suggested.
Changes Since V9:
- Removed interrupts (and buffers) from the driver. I previously was
unable to detect deadlocks because it turns out my IRQ was not even
wired correctly in my device.
- Updated devicetree binding commits to make interrupts optional for
users of the icm42607 driver.
Changes Since V10:
- Explicitly specified enum values in header file.
- Removed additional dead code for buffer handling.
- Cleaned up headers.
- Added additional locks as requested by sashiko.dev bot.
Changes Since V11:
- Since driver has shrunk in size considerably, moved i2c bits into
first code commit. This ensures that the very first commit with code
can now be compiled. The commit after that adds SPI support as it
was in the previous versions.
- Used pahole to optimize inv_icm42607_state. Reordering elements
reduced size in memory from 384 bytes to 256 bytes.
- Added a map of all readable registers and all writeable registers
according to the datasheet.
- Added back some missing headers pointed out by the maintainers.
- Added FIELD_PREP in a few more places to make the code more
obvious on what it's doing.
- Added a comment to the power management code to note that
temperature sensor being enabled doesn't matter as the clocks
are off by default when the gyro and accel channels are off.
- Removed iio_device_claim_direct() calls since it was no longer
needed.
- Fixed shared_by_all attributes for temperature sensor.
- Additional miscellanous fixes as requested.
Changes Since V12:
- Removed aligned buffer from inv_icm42607_state struct as we do not
currently have the need for it.
- Corrected the order of the odr values in the accel and gyro files
as the values were out of order (the place in the array corresponds
to the register value).
- Stopped setting the clock value depending upon the temp config. The
datasheet advised to keep using the default value.
- Corrected logic when changing between states. We only need to pause
when a sensor changes from off to an on state or when the gyro
changes from an on state to off.
- Added missing includes for several files.
Changes Since V13:
- Refactored inv_icm42607_set_accel_conf() and
inv_icm42607_set_gyro_conf() into a single function.
- Refactored inv_icm42607_accel_read_sensor() and
inv_icm42607_gyro_read_sensor() into a single function.
- Merged inv_icm42607_set_temp_conf() into initial init function
since it only really needs to be called once.
- Saved adding temp sensor for last and updated
inv_icm42607_temp_read() to either confirm other sensors are already
enabled or enable the accelerometer so it can get a reading.
- Updated inv_icm42607_set_pwr_mgmt0() so that it does not update the
sensor mode and forcibly keep the sensor enabled.
- Added inv_icm42607_temp_filter_bw enums since it appears to use
different values than the accel or gyro sensor.
- Set the temp startup time from 77ms to 77us, as I previously misread
the datasheet.
- Additional minor fixes.
Chris Morgan (9):
dt-bindings: iio: imu: icm42600: Add mount-matrix
dt-bindings: iio: imu: icm42600: Add icm42607
iio: imu: inv_icm42607: Add inv_icm42607 Core Driver
iio: imu: inv_icm42607: Add SPI For icm42607
iio: imu: inv_icm42607: Add PM support for icm42607
iio: imu: inv_icm42607: Add Accelerometer for icm42607
iio: imu: inv_icm42607: Add Gyroscope to icm42607
iio: imu: inv_icm42607: Add Temp Support in icm42607
arm64: dts: rockchip: Add icm42607p IMU for RG-DS
.../bindings/iio/imu/invensense,icm42600.yaml | 20 +-
.../dts/rockchip/rk3568-anbernic-rg-ds.dts | 8 +-
drivers/iio/imu/Kconfig | 1 +
drivers/iio/imu/Makefile | 1 +
drivers/iio/imu/inv_icm42607/Kconfig | 30 +
drivers/iio/imu/inv_icm42607/Makefile | 13 +
drivers/iio/imu/inv_icm42607/inv_icm42607.h | 423 ++++++++++++
.../iio/imu/inv_icm42607/inv_icm42607_accel.c | 317 +++++++++
.../iio/imu/inv_icm42607/inv_icm42607_core.c | 606 ++++++++++++++++++
.../iio/imu/inv_icm42607/inv_icm42607_gyro.c | 313 +++++++++
.../iio/imu/inv_icm42607/inv_icm42607_i2c.c | 98 +++
.../iio/imu/inv_icm42607/inv_icm42607_spi.c | 108 ++++
.../iio/imu/inv_icm42607/inv_icm42607_temp.c | 99 +++
.../iio/imu/inv_icm42607/inv_icm42607_temp.h | 37 ++
14 files changed, 2072 insertions(+), 2 deletions(-)
create mode 100644 drivers/iio/imu/inv_icm42607/Kconfig
create mode 100644 drivers/iio/imu/inv_icm42607/Makefile
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607.h
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
--
2.43.0
^ permalink raw reply
* Re: [PATCH] dt-bindings: mediatek: hdmi-ddc: Correct the compatibles for mt7623-mt8167
From: Krzysztof Kozlowski @ 2026-06-24 18:20 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Chun-Kuang Hu, Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, CK Hu, Jitao shi, dri-devel,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260624173514.19752-1-l.scorcia@gmail.com>
On 24/06/2026 19:34, Luca Leonardo Scorcia wrote:
> The HDMI DDC driver for both mt7623 and mt8167 is actually the same as
> mt8173-hdmi-ddc and the mt7623n.dtsi board include file already uses
> mt8173-hdmi-ddc compatible as a fallback, but the documentation lists
> them as separate entries. Correct the binding by adding the correct
> fallback.
>
> This change fixes the following dtbs_check errors:
>
> DTC [C] arch/arm/boot/dts/mediatek/mt7623n-rfb-emmc.dtb
This you can drop, not relevant and such redundant logs only make it
more difficult to understand the error message. I asked only to paste
here the error.
Anyway,
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: Convert cirrus,cs35l36 to DT schema
From: Rob Herring @ 2026-06-24 18:17 UTC (permalink / raw)
To: david
Cc: David Rhodes, Richard Fitzgerald, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, patches, Bjorn Helgaas,
linux-sound, devicetree, linux-kernel, phone-devel
In-Reply-To: <20260624-dt-cirrus-cs35l36-v2-1-74eccdbd8fe4@ixit.cz>
On Wed, Jun 24, 2026 at 11:02 AM David Heidelberg via B4 Relay
<devnull+david.ixit.cz@kernel.org> wrote:
>
> From: David Heidelberg <david@ixit.cz>
>
> Convert CS35L36 Speaker Amplifier to yaml.
>
> Changes:
> - maintainers email to the generic Cirrus email
> - Both the codec and downstream worked just fine without
> VP-supply provided. Align with datasheet for similar models.
> - add dai-common.yaml to cover for '#sound-dai-cells',
> 'sound-name-prefix'
>
> Reviewed-by: David Rhodes <David.Rhodes@cirrus.com>
If you are going to take stuff I haven't fixed:
Assisted-by: OpenAI:gpt-4
(I don't remember the exact flavor I used)
> Co-developed-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> Relevant for Pixel 3 / 3XL / 4.
> ---
> Changes in v2:
> - Rename the commit. (Mark)
> - Link to v1: https://lore.kernel.org/r/20260618-dt-cirrus-cs35l36-v1-1-1a43515666ad@ixit.cz
> ---
> .../devicetree/bindings/sound/cirrus,cs35l36.yaml | 224 +++++++++++++++++++++
> .../devicetree/bindings/sound/cs35l36.txt | 168 ----------------
> 2 files changed, 224 insertions(+), 168 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
> new file mode 100644
> index 0000000000000..af0acaaefb68e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
> @@ -0,0 +1,224 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/cirrus,cs35l36.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Cirrus Logic CS35L36 Speaker Amplifier
> +
> +maintainers:
> + - patches@opensource.cirrus.com
> + - Bjorn Helgaas <bhelgaas@google.com>
Bjorn is not correct. Generally we want a person, not a company list.
> +
> +description: |
Don't need '|'.
> + CS35L36 is a boosted mono Class D amplifier
> +
> +allOf:
> + - $ref: /schemas/sound/dai-common.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - cirrus,cs35l36
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + VA-supply:
> + description: Voltage regulator of analog internal section
> +
> + VP-supply:
> + description: Voltage regulator of boost converter
> +
> + reset-gpios:
> + maxItems: 1
> +
> + cirrus,boost-ctl-millivolt:
> + description: Boost converter output voltage in millivolts (step 50)
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 2550
> + maximum: 12000
> +
> + cirrus,boost-peak-milliamp:
> + description: Boost-converter peak current limit in mA (step 50)
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 4500
> + minimum: 1600
> + maximum: 4500
> +
> + cirrus,boost-ind-nanohenry:
> + description: Initial inductor estimation reference value in nanohenry (1000=1μH, 1200=1.2μH)
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 1000
> +
> + cirrus,multi-amp-mode:
> + description: Hi-Z ASP port when more than one amplifier in system.
> + type: boolean
> +
> + cirrus,boost-ctl-select:
> + description: Boost converter control source selection
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 0x01
> + enum:
> + - 0x00 # Control Port
> + - 0x01 # Class
> + - 0x10 # Sync
> +
> + cirrus,amp-pcm-inv:
> + description: Invert incoming PCM data when true.
> + type: boolean
> +
> + cirrus,imon-pol-inv:
> + description: Invert polarity of outbound IMON feedback when true.
> + type: boolean
> +
> + cirrus,vmon-pol-inv:
> + description: Invert polarity of outbound VMON feedback when true.
> + type: boolean
> +
> + cirrus,dcm-mode-enable:
> + description: Enable boost converter automatic Discontinuous Conduction Mode.
> + type: boolean
> +
> + cirrus,weak-fet-disable:
> + description: Reduce output driver strength in Weak-FET Drive Mode when true.
> + type: boolean
> +
> + cirrus,classh-wk-fet-delay:
> + description: Weak-FET entry delay in ms
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 100
How? Range is 0-7.
> + enum:
> + - 0 # 0
> + - 1 # 5
> + - 2 # 10
> + - 3 # 50
> + - 4 # 100
> + - 5 # 200
> + - 6 # 500
> + - 7 # 1000
> +
> + cirrus,classh-weak-fet-thld-millivolt:
> + description: Weak-FET drive threshold in mV
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [50, 100, 150, 200, 250, 300, 350, 400, 450, 500, 550, 600, 650, 700]
> +
> + cirrus,temp-warn-threshold:
> + description: Overtemperature warning threshold
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 2
> + enum:
> + - 0 # 105°C
> + - 1 # 115°C
> + - 2 # 125°C
> + - 3 # 135°C
> +
> + cirrus,irq-drive-select:
> + description: Interrupt output driver type
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 1
> + enum:
> + - 0 # open-drain
> + - 1 # push-pull
> +
> + cirrus,irq-gpio-select:
> + description: Programmable IRQ pin selection
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum:
> + - 0 # PDM_DATA/SWIRE_SD/INT
> + - 1 # GPIO
> +
> + cirrus,vpbr-config:
> + description: Brownout prevention configuration sub-node
> + type: object
> + additionalProperties: false
> +
> + properties:
> + cirrus,vpbr-en:
> + description: VBST brownout prevention enable
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 0
> + enum:
> + - 0 # disabled
> + - 1 # enabled
> +
> + cirrus,vpbr-thld:
> + description: Initial VPBR threshold voltage
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + cirrus,vpbr-atk-rate:
> + description: Attenuation attack step rate
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + cirrus,vpbr-atk-vol:
> + description: VP brownout prevention step size
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + cirrus,vpbr-max-attn:
> + description: Maximum attenuation during VP brownout prevention
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + cirrus,vpbr-wait:
> + description: Delay between brownout clearance and attenuation release
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + cirrus,vpbr-rel-rate:
> + description: Attenuation release step rate
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + cirrus,vpbr-mute-en:
> + description: Mute audio if maximum attenuation reached
> + $ref: /schemas/types.yaml#/definitions/uint32
Constraints on any of these?
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - VA-supply
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + codec@40 {
> + compatible = "cirrus,cs35l36";
> + reg = <0x40>;
> + VA-supply = <&dummy_vreg>;
> + VP-supply = <&dummy_vreg>;
> + reset-gpios = <&gpio0 54 GPIO_ACTIVE_HIGH>;
> + interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> +
> + cirrus,boost-ind-nanohenry = <1000>;
> + cirrus,boost-ctl-millivolt = <10000>;
> + cirrus,boost-peak-milliamp = <4500>;
> + cirrus,boost-ctl-select = <0x00>;
> + cirrus,weak-fet-delay = <4>;
> + cirrus,weak-fet-thld = <0x01>;
> + cirrus,temp-warn-threshold = <1>;
> + cirrus,multi-amp-mode;
> + cirrus,irq-drive-select = <1>;
> + cirrus,irq-gpio-select = <0x01>;
> +
> + cirrus,vpbr-config {
> + cirrus,vpbr-en = <0>;
> + cirrus,vpbr-thld = <0x05>;
> + cirrus,vpbr-atk-rate = <0x02>;
> + cirrus,vpbr-atk-vol = <0x01>;
> + cirrus,vpbr-max-attn = <0x09>;
> + cirrus,vpbr-wait = <0x01>;
> + cirrus,vpbr-rel-rate = <0x05>;
> + cirrus,vpbr-mute-en = <0x00>;
> + };
> + };
> + };
> +...
> diff --git a/Documentation/devicetree/bindings/sound/cs35l36.txt b/Documentation/devicetree/bindings/sound/cs35l36.txt
> deleted file mode 100644
> index d34117b8558e5..0000000000000
> --- a/Documentation/devicetree/bindings/sound/cs35l36.txt
> +++ /dev/null
> @@ -1,168 +0,0 @@
> -CS35L36 Speaker Amplifier
> -
> -Required properties:
> -
> - - compatible : "cirrus,cs35l36"
> -
> - - reg : the I2C address of the device for I2C
> -
> - - VA-supply, VP-supply : power supplies for the device,
> - as covered in
> - Documentation/devicetree/bindings/regulator/regulator.txt.
> -
> - - cirrus,boost-ctl-millivolt : Boost Voltage Value. Configures the boost
> - converter's output voltage in mV. The range is from 2550mV to 12000mV with
> - increments of 50mV.
> - (Default) VP
> -
> - - cirrus,boost-peak-milliamp : Boost-converter peak current limit in mA.
> - Configures the peak current by monitoring the current through the boost FET.
> - Range starts at 1600mA and goes to a maximum of 4500mA with increments of
> - 50mA.
> - (Default) 4.50 Amps
> -
> - - cirrus,boost-ind-nanohenry : Inductor estimation LBST reference value.
> - Seeds the digital boost converter's inductor estimation block with the initial
> - inductance value to reference.
> -
> - 1000 = 1uH (Default)
> - 1200 = 1.2uH
> -
> -Optional properties:
> - - cirrus,multi-amp-mode : Boolean to determine if there are more than
> - one amplifier in the system. If more than one it is best to Hi-Z the ASP
> - port to prevent bus contention on the output signal
> -
> - - cirrus,boost-ctl-select : Boost converter control source selection.
> - Selects the source of the BST_CTL target VBST voltage for the boost
> - converter to generate.
> - 0x00 - Control Port Value
> - 0x01 - Class H Tracking (Default)
> - 0x10 - MultiDevice Sync Value
> -
> - - cirrus,amp-pcm-inv : Boolean to determine Amplifier will invert incoming
> - PCM data
> -
> - - cirrus,imon-pol-inv : Boolean to determine Amplifier will invert the
> - polarity of outbound IMON feedback data
> -
> - - cirrus,vmon-pol-inv : Boolean to determine Amplifier will invert the
> - polarity of outbound VMON feedback data
> -
> - - cirrus,dcm-mode-enable : Boost converter automatic DCM Mode enable.
> - This enables the digital boost converter to operate in a low power
> - (Discontinuous Conduction) mode during low loading conditions.
> -
> - - cirrus,weak-fet-disable : Boolean : The strength of the output drivers is
> - reduced when operating in a Weak-FET Drive Mode and must not be used to drive
> - a large load.
> -
> - - cirrus,classh-wk-fet-delay : Weak-FET entry delay. Controls the delay
> - (in ms) before the Class H algorithm switches to the weak-FET voltage
> - (after the audio falls and remains below the value specified in WKFET_AMP_THLD).
> -
> - 0 = 0ms
> - 1 = 5ms
> - 2 = 10ms
> - 3 = 50ms
> - 4 = 100ms (Default)
> - 5 = 200ms
> - 6 = 500ms
> - 7 = 1000ms
> -
> - - cirrus,classh-weak-fet-thld-millivolt : Weak-FET amplifier drive threshold.
> - Configures the signal threshold at which the PWM output stage enters
> - weak-FET operation. The range is 50mV to 700mV in 50mV increments.
> -
> - - cirrus,temp-warn-threshold : Amplifier overtemperature warning threshold.
> - Configures the threshold at which the overtemperature warning condition occurs.
> - When the threshold is met, the overtemperature warning attenuation is applied
> - and the TEMP_WARN_EINT interrupt status bit is set.
> - If TEMP_WARN_MASK = 0, INTb is asserted.
> -
> - 0 = 105C
> - 1 = 115C
> - 2 = 125C (Default)
> - 3 = 135C
> -
> - - cirrus,irq-drive-select : Selects the driver type of the selected interrupt
> - output.
> -
> - 0 = Open-drain
> - 1 = Push-pull (Default)
> -
> - - cirrus,irq-gpio-select : Selects the pin to serve as the programmable
> - interrupt output.
> -
> - 0 = PDM_DATA / SWIRE_SD / INT (Default)
> - 1 = GPIO
> -
> -Optional properties for the "cirrus,vpbr-config" Sub-node
> -
> - - cirrus,vpbr-en : VBST brownout prevention enable. Configures whether the
> - VBST brownout prevention algorithm is enabled or disabled.
> -
> - 0 = VBST brownout prevention disabled (default)
> - 1 = VBST brownout prevention enabled
> -
> - See Section 7.31.1 VPBR Config for configuration options & further details
> -
> - - cirrus,vpbr-thld : Initial VPBR threshold. Configures the VP brownout
> - threshold voltage
> -
> - - cirrus,cirrus,vpbr-atk-rate : Attenuation attack step rate. Configures the
> - amount delay between consecutive volume attenuation steps when a brownout
> - condition is present and the VP brownout condition is in an attacking state.
> -
> - - cirrus,vpbr-atk-vol : VP brownout prevention step size. Configures the VP
> - brownout prevention attacking attenuation step size when operating in either
> - digital volume or analog gain modes.
> -
> - - cirrus,vpbr-max-attn : Maximum attenuation that the VP brownout prevention
> - can apply to the audio signal.
> -
> - - cirrus,vpbr-wait : Configures the delay time between a brownout condition
> - no longer being present and the VP brownout prevention entering an attenuation
> - release state.
> -
> - - cirrus,vpbr-rel-rate : Attenuation release step rate. Configures the delay
> - between consecutive volume attenuation release steps when a brownout condition
> - is not longer present and the VP brownout is in an attenuation release state.
> -
> - - cirrus,vpbr-mute-en : During the attack state, if the vpbr-max-attn value
> - is reached, the error condition still remains, and this bit is set, the audio
> - is muted.
> -
> -Example:
> -
> -cs35l36: cs35l36@40 {
> - compatible = "cirrus,cs35l36";
> - reg = <0x40>;
> - VA-supply = <&dummy_vreg>;
> - VP-supply = <&dummy_vreg>;
> - reset-gpios = <&gpio0 54 0>;
> - interrupt-parent = <&gpio8>;
> - interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> -
> - cirrus,boost-ind-nanohenry = <1000>;
> - cirrus,boost-ctl-millivolt = <10000>;
> - cirrus,boost-peak-milliamp = <4500>;
> - cirrus,boost-ctl-select = <0x00>;
> - cirrus,weak-fet-delay = <0x04>;
> - cirrus,weak-fet-thld = <0x01>;
> - cirrus,temp-warn-threshold = <0x01>;
> - cirrus,multi-amp-mode;
> - cirrus,irq-drive-select = <0x01>;
> - cirrus,irq-gpio-select = <0x01>;
> -
> - cirrus,vpbr-config {
> - cirrus,vpbr-en = <0x00>;
> - cirrus,vpbr-thld = <0x05>;
> - cirrus,vpbr-atk-rate = <0x02>;
> - cirrus,vpbr-atk-vol = <0x01>;
> - cirrus,vpbr-max-attn = <0x09>;
> - cirrus,vpbr-wait = <0x01>;
> - cirrus,vpbr-rel-rate = <0x05>;
> - cirrus,vpbr-mute-en = <0x00>;
> - };
> -};
>
> ---
> base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
> change-id: 20260618-dt-cirrus-cs35l36-99c466fb13fd
>
> Best regards,
> --
> David Heidelberg <david@ixit.cz>
>
>
>
^ permalink raw reply
* Re: [PATCH v5 08/12] i3c: dw-i3c-master: Add ACPI core clock frequency quirk
From: Frank Li @ 2026-06-24 18:09 UTC (permalink / raw)
To: Akhil R
Cc: Alexandre Belloni, Frank Li, Miquel Raynal, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Guenter Roeck, Philipp Zabel,
Jon Hunter, Thierry Reding, linux-i3c, devicetree, linux-hwmon,
linux-tegra, linux-kernel
In-Reply-To: <20260624102153.1770072-9-akhilrajeev@nvidia.com>
On Wed, Jun 24, 2026 at 10:21:02AM +0000, Akhil R wrote:
> Some ACPI-enumerated devices like Tegra410 do not expose the controller
> core clock through the clk framework. Unlike device tree, ACPI on Arm does
> not model clock providers. The hardware is expected to have its clocks
> enabled by firmware before the OS takes over.
>
> Make the core clock optional and allow selected ACPI devices to provide the
> core clock rate through the "clock-frequency" _DSD property when the core
> clock is absent.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/i3c/master/dw-i3c-master.c | 27 ++++++++++++++++++++++++---
> 1 file changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
> index 29030fd9594a..8e40d178d500 100644
> --- a/drivers/i3c/master/dw-i3c-master.c
> +++ b/drivers/i3c/master/dw-i3c-master.c
> @@ -242,6 +242,7 @@
> /* List of quirks */
> #define AMD_I3C_OD_PP_TIMING BIT(1)
> #define DW_I3C_DISABLE_RUNTIME_PM_QUIRK BIT(2)
> +#define DW_I3C_ACPI_SKIP_CLK_RST BIT(3)
>
> struct dw_i3c_cmd {
> u32 cmd_lo;
> @@ -556,13 +557,33 @@ static void dw_i3c_master_set_intr_regs(struct dw_i3c_master *master)
> writel(IBI_REQ_REJECT_ALL, master->regs + IBI_MR_REQ_REJECT);
> }
>
> +static unsigned long dw_i3c_master_get_core_rate(struct dw_i3c_master *master)
> +{
> + unsigned int core_rate_prop;
> +
> + if (master->core_clk)
> + return clk_get_rate(master->core_clk);
> +
> + if (!(master->quirks & DW_I3C_ACPI_SKIP_CLK_RST))
> + dev_err(master->dev, "missing core clock\n");
> + return 0;
> + }
> +
> + if (device_property_read_u32(master->dev, "clock-frequency", &core_rate_prop)) {
> + dev_err(master->dev, "missing clock-frequency property\n");
> + return 0;
> + }
> +
> + return core_rate_prop;
> +}
> +
> static int dw_i3c_clk_cfg(struct dw_i3c_master *master)
> {
> unsigned long core_rate, core_period;
> u32 scl_timing;
> u8 hcnt, lcnt;
>
> - core_rate = clk_get_rate(master->core_clk);
> + core_rate = dw_i3c_master_get_core_rate(master);
> if (!core_rate)
> return -EINVAL;
>
> @@ -615,7 +636,7 @@ static int dw_i2c_clk_cfg(struct dw_i3c_master *master)
> u16 hcnt, lcnt;
> u32 scl_timing;
>
> - core_rate = clk_get_rate(master->core_clk);
> + core_rate = dw_i3c_master_get_core_rate(master);
> if (!core_rate)
> return -EINVAL;
>
> @@ -1577,7 +1598,7 @@ int dw_i3c_common_probe(struct dw_i3c_master *master,
> if (IS_ERR(master->regs))
> return PTR_ERR(master->regs);
>
> - master->core_clk = devm_clk_get_enabled(&pdev->dev, NULL);
> + master->core_clk = devm_clk_get_optional_enabled(&pdev->dev, NULL);
> if (IS_ERR(master->core_clk))
> return PTR_ERR(master->core_clk);
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH net] dt-bindings: net: renesas,ether: Drop example "ethernet-phy-ieee802.3-c22" fallback
From: Niklas Söderlund @ 2026-06-24 18:07 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Sergei Shtylyov, netdev,
linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <20260624150250.131966-2-robh@kernel.org>
Hi Rob,
Thanks for your patch.
On 2026-06-24 10:02:50 -0500, Rob Herring (Arm) wrote:
> Fix the Micrel PHY in the example which shouldn't have the
> fallback "ethernet-phy-ieee802.3-c22" compatible:
>
> Documentation/devicetree/bindings/net/renesas,ether.example.dtb: ethernet-phy@1 \
> (ethernet-phy-id0022.1537): compatible: ['ethernet-phy-id0022.1537', 'ethernet-phy-ieee802.3-c22'] is too long
> from schema $id: http://devicetree.org/schemas/net/micrel.yaml
>
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> ---
> Documentation/devicetree/bindings/net/renesas,ether.yaml | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/renesas,ether.yaml b/Documentation/devicetree/bindings/net/renesas,ether.yaml
> index f0a52f47f95a..dd7187f12a67 100644
> --- a/Documentation/devicetree/bindings/net/renesas,ether.yaml
> +++ b/Documentation/devicetree/bindings/net/renesas,ether.yaml
> @@ -121,8 +121,7 @@ examples:
> #size-cells = <0>;
>
> phy1: ethernet-phy@1 {
> - compatible = "ethernet-phy-id0022.1537",
> - "ethernet-phy-ieee802.3-c22";
> + compatible = "ethernet-phy-id0022.1537";
> reg = <1>;
> interrupt-parent = <&irqc0>;
> interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> --
> 2.53.0
>
--
Kind Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH v5 04/12] i3c: master: Add support for devices using SETAASA
From: Frank Li @ 2026-06-24 17:57 UTC (permalink / raw)
To: sashiko-reviews
Cc: Akhil R, linux-hwmon, devicetree, robh, linux-i3c, conor+dt,
Frank.Li
In-Reply-To: <20260624104326.AE6C81F000E9@smtp.kernel.org>
On Wed, Jun 24, 2026 at 10:43:26AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
>
> New issues:
> - [High] SETAASA broadcast is sent before SETDASA direct assignments, which breaks initialization for devices that natively support SETAASA but are configured for SETDASA.
>
> Pre-existing issues:
> - [High] Missing RSTDAA on error path due to premature address slot clearing leads to bus address collision.
> - [High] Double free and Use-After-Free of `desc->dev` when `device_register()` fails.
> --
>
> commit 08b7cd00b36fcaa4fe6292af27e273df6dc64b5a
> Author: Akhil R <akhilrajeev@nvidia.com>
>
> i3c: master: Add support for devices using SETAASA
>
> Add support for devices using SETAASA attached to DDR5 memory modules that
> do not support ENTDAA. Devices using SETAASA assign their pre-defined static
> addresses as dynamic addresses during DAA.
>
> > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> > index 4bba2bad897a7..3deae8cdae525 100644
> > --- a/drivers/i3c/master.c
> > +++ b/drivers/i3c/master.c
>
> [ ... ]
>
> > @@ -1878,6 +1924,22 @@ static int i3c_master_early_i3c_dev_add(struct i3c_master_controller *master,
> > if (ret)
> > goto err_free_dev;
> >
> > + /*
> > + * For devices using SETAASA instead of ENTDAA, the address is statically
> > + * assigned. Update the dynamic address to the provided static address.
> > + * Reattach the I3C device after updating the dynamic address with the same
> > + * static address. It is not mandatory for such devices to implement CCC
> > + * commands like GETPID, GETDCR etc. Hence, we can return after reattaching.
> > + */
> > + if (i3cdev->boardinfo->static_addr_method & I3C_ADDR_METHOD_SETAASA) {
> > + i3cdev->info.dyn_addr = i3cdev->boardinfo->static_addr;
> > + ret = i3c_master_reattach_i3c_dev_locked(i3cdev, 0);
> > + if (ret)
> > + goto err_rstdaa;
> > +
> > + return 0;
> > + }
> > +
>
> [Severity: High]
> This is a pre-existing issue, but missing RSTDAA on the error path due to
> premature address slot clearing can lead to bus address collisions.
>
> In i3c_master_early_i3c_dev_add(), the driver assigns the dynamic address
> with SETDASA and reattaches the device. If reattaching fails, the error
> path internally calls i3c_master_put_i3c_addrs(), which clears the
> init_dyn_addr slot status back to I3C_ADDR_SLOT_FREE.
>
> When the code jumps to err_rstdaa:
>
> err_rstdaa:
> i3c_master_rstdaa_locked(master, i3cdev->boardinfo->init_dyn_addr);
>
> It calls i3c_master_rstdaa_locked() to reset the device's dynamic address.
> However, i3c_master_rstdaa_locked() verifies the slot status:
>
> drivers/i3c/master.c:i3c_master_rstdaa_locked() {
> ...
> if (addr != I3C_BROADCAST_ADDR && addrstat != I3C_ADDR_SLOT_I3C_DEV)
> return -EINVAL;
> ...
> }
>
> Because the slot was just freed, the function silently returns without
> sending the RSTDAA CCC command.
>
> Will this allow the hardware device to continue squatting on the dynamic
> address while the master considers the slot free, causing collisions later?
>
> > ret = i3c_master_setdasa_locked(master, i3cdev->info.static_addr,
> > i3cdev->boardinfo->init_dyn_addr);
>
> [ ... ]
>
> > @@ -2232,6 +2294,12 @@ static int i3c_master_bus_init(struct i3c_master_controller *master)
> > if (ret)
> > goto err_bus_cleanup;
> >
> > + if (master->addr_method & I3C_ADDR_METHOD_SETAASA) {
> > + ret = i3c_master_setaasa_locked(master);
> > + if (ret)
> > + goto err_bus_cleanup;
> > + }
> > +
>
> [Severity: High]
> Is it possible that sending the SETAASA broadcast before direct SETDASA
> assignments breaks initialization for devices that natively support SETAASA
> but are configured for SETDASA?
>
> According to the I3C specification, any device on the bus natively supporting
> SETAASA will respond to this broadcast by adopting its static address as its
> dynamic address.
>
> After this broadcast, the driver iterates through devices and attempts to
> assign custom dynamic addresses via direct SETDASA commands:
>
> drivers/i3c/master.c:i3c_master_early_i3c_dev_add() {
> ...
> ret = i3c_master_setdasa_locked(master, i3cdev->info.static_addr,
> i3cdev->boardinfo->init_dyn_addr);
> ...
> }
>
> Since the target device already adopted its dynamic address during the
> SETAASA broadcast, it is no longer in the unassigned state and will NACK
> the subsequent SETDASA command.
Look like correct, but I am not sure if target will NACK SETDASA. Or should
use SETNEWDA for SETAASA method.
Frank
>
> Could this cause device initialization to abort entirely?
>
> Should SETDASA direct assignments be executed before broadcasting SETAASA?
>
> > /*
> > * Reserve init_dyn_addr first, and then try to pre-assign dynamic
> > * address and retrieve device information if needed.
>
> [ ... ]
>
> [Severity: High]
> This isn't a bug introduced by this patch, but there is a potential double
> free and use-after-free of desc->dev when device_register() fails.
>
> In i3c_master_register_new_i3c_devs(), if device_register() fails,
> put_device() is called:
>
> drivers/i3c/master.c:i3c_master_register_new_i3c_devs() {
> ...
> ret = device_register(&desc->dev->dev);
> if (ret) {
> dev_err(&master->dev, "Failed to add I3C device (err = %d)\n", ret);
> put_device(&desc->dev->dev);
> }
> ...
> }
>
> This drops the reference count to 0 and triggers i3c_device_release(), which
> frees desc->dev via kfree(i3cdev). However, the pointer desc->dev is not set
> to NULL and remains dangling in the master->bus.devs.i3c list.
>
> Later, when the master module is unloaded or unregistered, the cleanup
> iterates over the list:
>
> drivers/i3c/master.c:i3c_master_unregister_i3c_devs() {
> ...
> if (!i3cdev->dev)
> continue;
>
> i3cdev->dev->desc = NULL;
> if (device_is_registered(&i3cdev->dev->dev))
> device_unregister(&i3cdev->dev->dev);
> else
> put_device(&i3cdev->dev->dev);
> i3cdev->dev = NULL;
> ...
> }
>
> Because i3cdev->dev is a dangling pointer, the check passes. This leads to
> writing to i3cdev->dev->desc (use-after-free) and calling put_device() again
> (double free).
>
> Could we set desc->dev to NULL after put_device() in the registration error
> path?
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260624102153.1770072-1-akhilrajeev@nvidia.com?part=4
^ permalink raw reply
* [PATCH v2] dt-bindings: mediatek: cec: Correct the compatibles for mt7623-mt8167
From: Luca Leonardo Scorcia @ 2026-06-24 17:36 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, CK Hu, Jitao shi,
dri-devel, devicetree, linux-kernel, linux-arm-kernel
The HDMI CEC driver for both mt7623 and mt8167 is actually the same as
mt8173-cec and the mt7623n.dtsi board include file already uses mt8173-cec
compatible as a fallback, but the documentation lists them as separate
entries. Correct the binding by adding the correct fallback.
This change fixes the following dtbs_check errors:
DTC [C] arch/arm/boot/dts/mediatek/mt7623n-rfb-emmc.dtb
cec@10012000 (mediatek,mt7623-cec): compatible: ['mediatek,mt7623-cec',
'mediatek,mt8173-cec'] is too long
DTC [C] arch/arm/boot/dts/mediatek/mt7623n-bananapi-bpi-r2.dtb
cec@10012000 (mediatek,mt7623-cec): compatible: ['mediatek,mt7623-cec',
'mediatek,mt8173-cec'] is too long
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
Changes in v2:
* Fixed yaml indent (sorry about that, I ran checks multiple times but
it did not show anything - I had to clean everything and run them again
to get them to show...).
* Added details about the errors that are fixed with this patch.
Initial version: [1]
[1] https://lore.kernel.org/linux-mediatek/20260623135757.5111-1-l.scorcia@gmail.com/
.../bindings/display/mediatek/mediatek,cec.yaml | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
index 080cf321209e..bc288b1c6f07 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
@@ -15,10 +15,13 @@ description: |
properties:
compatible:
- enum:
- - mediatek,mt7623-cec
- - mediatek,mt8167-cec
- - mediatek,mt8173-cec
+ oneOf:
+ - const: mediatek,mt8173-cec
+ - items:
+ - enum:
+ - mediatek,mt7623-cec
+ - mediatek,mt8167-cec
+ - const: mediatek,mt8173-cec
reg:
maxItems: 1
--
2.43.0
^ permalink raw reply related
* [PATCH] dt-bindings: mediatek: hdmi-ddc: Correct the compatibles for mt7623-mt8167
From: Luca Leonardo Scorcia @ 2026-06-24 17:34 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Chun-Kuang Hu, Philipp Zabel,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, CK Hu, Jitao shi,
dri-devel, devicetree, linux-kernel, linux-arm-kernel
The HDMI DDC driver for both mt7623 and mt8167 is actually the same as
mt8173-hdmi-ddc and the mt7623n.dtsi board include file already uses
mt8173-hdmi-ddc compatible as a fallback, but the documentation lists
them as separate entries. Correct the binding by adding the correct
fallback.
This change fixes the following dtbs_check errors:
DTC [C] arch/arm/boot/dts/mediatek/mt7623n-rfb-emmc.dtb
i2c@11013000 (mediatek,mt7623-hdmi-ddc): compatible:
['mediatek,mt7623-hdmi-ddc', 'mediatek,mt8173-hdmi-ddc'] is too long
DTC [C] arch/arm/boot/dts/mediatek/mt7623n-bananapi-bpi-r2.dtb
i2c@11013000 (mediatek,mt7623-hdmi-ddc): compatible:
['mediatek,mt7623-hdmi-ddc', 'mediatek,mt8173-hdmi-ddc'] is too long
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
.../bindings/display/mediatek/mediatek,hdmi-ddc.yaml | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
index bd8f7b8ae0ff..966127e1ee63 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
@@ -15,10 +15,13 @@ description: |
properties:
compatible:
- enum:
- - mediatek,mt7623-hdmi-ddc
- - mediatek,mt8167-hdmi-ddc
- - mediatek,mt8173-hdmi-ddc
+ oneOf:
+ - const: mediatek,mt8173-hdmi-ddc
+ - items:
+ - enum:
+ - mediatek,mt7623-hdmi-ddc
+ - mediatek,mt8167-hdmi-ddc
+ - const: mediatek,mt8173-hdmi-ddc
reg:
maxItems: 1
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] ASoC: dt-bindings: Convert cirrus,cs35l36 to DT schema
From: Rob Herring (Arm) @ 2026-06-24 17:30 UTC (permalink / raw)
To: David Heidelberg
Cc: David Rhodes, linux-sound, Bjorn Helgaas, devicetree,
linux-kernel, Conor Dooley, Krzysztof Kozlowski, phone-devel,
Mark Brown, patches, Richard Fitzgerald, David Rhodes,
Liam Girdwood
In-Reply-To: <20260624-dt-cirrus-cs35l36-v2-1-74eccdbd8fe4@ixit.cz>
On Wed, 24 Jun 2026 18:02:25 +0200, David Heidelberg wrote:
> Convert CS35L36 Speaker Amplifier to yaml.
>
> Changes:
> - maintainers email to the generic Cirrus email
> - Both the codec and downstream worked just fine without
> VP-supply provided. Align with datasheet for similar models.
> - add dai-common.yaml to cover for '#sound-dai-cells',
> 'sound-name-prefix'
>
> Reviewed-by: David Rhodes <David.Rhodes@cirrus.com>
> Co-developed-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> Relevant for Pixel 3 / 3XL / 4.
> ---
> Changes in v2:
> - Rename the commit. (Mark)
> - Link to v1: https://lore.kernel.org/r/20260618-dt-cirrus-cs35l36-v1-1-1a43515666ad@ixit.cz
> ---
> .../devicetree/bindings/sound/cirrus,cs35l36.yaml | 224 +++++++++++++++++++++
> .../devicetree/bindings/sound/cs35l36.txt | 168 ----------------
> 2 files changed, 224 insertions(+), 168 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml: properties:cirrus,vpbr-config:type: 'boolean' was expected
hint: A vendor boolean property can use "type: boolean"
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml: Unresolvable reference: /schemas/sound/dai-common.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/sound/cirrus,cs35l36.example.dtb: codec@40 (cirrus,cs35l36): Unevaluated properties are not allowed ('cirrus,weak-fet-delay', 'cirrus,weak-fet-thld' were unexpected)
from schema $id: http://devicetree.org/schemas/cirrus,cs35l36.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260624-dt-cirrus-cs35l36-v2-1-74eccdbd8fe4@ixit.cz
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Frank Li @ 2026-06-24 17:07 UTC (permalink / raw)
To: Sherry Sun
Cc: Sherry Sun (OSS), robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Frank Li, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, Amitkumar Karwar,
Neeraj Sanjay Kale, marcel@holtmann.org, luiz.dentz@gmail.com,
Hongxing Zhu, l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, bhelgaas@google.com,
brgl@kernel.org, imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-pm@vger.kernel.org
In-Reply-To: <VI0PR04MB121147C305022511469FB603A92ED2@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Wed, Jun 24, 2026 at 07:09:26AM +0000, Sherry Sun wrote:
> > Subject: Re: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
> >
> > On Tue, Jun 23, 2026 at 11:07:28AM +0800, Sherry Sun (OSS) wrote:
> > > From: Sherry Sun <sherry.sun@nxp.com>
> > >
> > > Use dw_pcie_rp::skip_pwrctrl_off to avoid powering off devices during
> > > suspend to preserve wakeup capability of the devices and also not to
> > > power on the devices in the init path.
> > > This allows controller power-off to be skipped when some devices(e.g.
> > > M.2 cards key E without auxiliary power) required to support PCIe L2
> > > link state and wake-up mechanisms.
> > >
> > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > ---
> > > drivers/pci/controller/dwc/pci-imx6.c | 36
> > > +++++++++++++++++----------
> > > 1 file changed, 23 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > index 0fa716d1ed75..ff5a9565dbbf 100644
> > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > @@ -1382,16 +1382,20 @@ static int imx_pcie_host_init(struct dw_pcie_rp
> > *pp)
> > > }
> > > }
> > >
> > > - ret = pci_pwrctrl_create_devices(dev);
> > > - if (ret) {
> > > - dev_err(dev, "failed to create pwrctrl devices\n");
> > > - goto err_reg_disable;
> > > + if (!pci->suspended) {
> > > + ret = pci_pwrctrl_create_devices(dev);
> >
> > Is possible move pci_pwrctrl_create_devices() of pci_pwrctrl_create_devices
> >
> > and call it direct at probe() function, like other regulator_get function.
> >
>
> Hi Frank,
> That makes sense. However, if we move pci_pwrctrl_create_devices () to
> probe(), we may need to add the following goto err_pwrctrl_destroy path
> in imx_pcie_probe() to properly handle errors from
> pci_pwrctrl_power_on_devices(), is that acceptable?
Can you add a API devm_pci_pwrctrl_create_devices() ?
Frank
>
> @@ -1960,11 +1949,15 @@ static int imx_pcie_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + ret = pci_pwrctrl_create_devices(dev);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to create pwrctrl devices\n");
> +
> pci->use_parent_dt_ranges = true;
> if (imx_pcie->drvdata->mode == DW_PCIE_EP_TYPE) {
> ret = imx_add_pcie_ep(imx_pcie, pdev);
> if (ret < 0)
> - return ret;
> + goto err_pwrctrl_destroy;
>
> /*
> * FIXME: Only single Device (EPF) is supported due to the
> @@ -1979,7 +1972,7 @@ static int imx_pcie_probe(struct platform_device *pdev)
> pci->pp.use_atu_msg = true;
> ret = dw_pcie_host_init(&pci->pp);
> if (ret < 0)
> - return ret;
> + goto err_pwrctrl_destroy;
>
> if (pci_msi_enabled()) {
> u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_MSI);
> @@ -1991,6 +1984,11 @@ static int imx_pcie_probe(struct platform_device *pdev)
> }
>
> return 0;
> +
> +err_pwrctrl_destroy:
> + if (ret != -EPROBE_DEFER)
> + pci_pwrctrl_destroy_devices(dev);
> + return ret;
> }
>
> Best Regards
> Sherry
>
> >
> > > + if (ret) {
> > > + dev_err(dev, "failed to create pwrctrl devices\n");
> > > + goto err_reg_disable;
> > > + }
> > > }
> > >
> > > - ret = pci_pwrctrl_power_on_devices(dev);
> > > - if (ret) {
> > > - dev_err(dev, "failed to power on pwrctrl devices\n");
> > > - goto err_pwrctrl_destroy;
> > > + if (!pp->skip_pwrctrl_off) {
> > > + ret = pci_pwrctrl_power_on_devices(dev);
> > > + if (ret) {
> > > + dev_err(dev, "failed to power on pwrctrl devices\n");
> > > + goto err_pwrctrl_destroy;
> > > + }
> > > }
> > >
> > > ret = imx_pcie_clk_enable(imx_pcie); @@ -1460,9 +1464,10 @@
> > static
> > > int imx_pcie_host_init(struct dw_pcie_rp *pp)
> > > err_clk_disable:
> > > imx_pcie_clk_disable(imx_pcie);
> > > err_pwrctrl_power_off:
> > > - pci_pwrctrl_power_off_devices(dev);
> > > + if (!pp->skip_pwrctrl_off)
> > > + pci_pwrctrl_power_off_devices(dev);
> > > err_pwrctrl_destroy:
> > > - if (ret != -EPROBE_DEFER)
> > > + if (ret != -EPROBE_DEFER && !pci->suspended)
> > > pci_pwrctrl_destroy_devices(dev);
> > > err_reg_disable:
> > > if (imx_pcie->vpcie)
> > > @@ -1482,7 +1487,8 @@ static void imx_pcie_host_exit(struct dw_pcie_rp
> > *pp)
> > > }
> > > imx_pcie_clk_disable(imx_pcie);
> > >
> > > - pci_pwrctrl_power_off_devices(pci->dev);
> > > + if (!pci->pp.skip_pwrctrl_off)
> > > + pci_pwrctrl_power_off_devices(pci->dev);
> > > if (imx_pcie->vpcie)
> > > regulator_disable(imx_pcie->vpcie);
> > > }
> > > @@ -1990,12 +1996,16 @@ static int imx_pcie_probe(struct
> > > platform_device *pdev) static void imx_pcie_shutdown(struct
> > > platform_device *pdev) {
> > > struct imx_pcie *imx_pcie = platform_get_drvdata(pdev);
> > > + struct dw_pcie *pci = imx_pcie->pci;
> > > + struct dw_pcie_rp *pp = &pci->pp;
> > >
> > > /* bring down link, so bootloader gets clean state in case of reboot */
> > > imx_pcie_assert_core_reset(imx_pcie);
> > > imx_pcie_assert_perst(imx_pcie, true);
> > > - pci_pwrctrl_power_off_devices(&pdev->dev);
> > > - pci_pwrctrl_destroy_devices(&pdev->dev);
> > > + if (!pp->skip_pwrctrl_off)
> > > + pci_pwrctrl_power_off_devices(&pdev->dev);
> > > + if (!pci->suspended)
> > > + pci_pwrctrl_destroy_devices(&pdev->dev);
> > > }
> > >
> > > static const struct imx_pcie_drvdata drvdata[] = {
> > > --
> > > 2.50.1
> > >
> > >
^ permalink raw reply
* Re: [PATCH V13 5/9] iio: imu: inv_icm42607: Add PM support for icm42607
From: Chris Morgan @ 2026-06-24 17:04 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, andriy.shevchenko
In-Reply-To: <20260624160651.03645da7@jic23-huawei>
On Wed, Jun 24, 2026 at 04:06:51PM +0100, Jonathan Cameron wrote:
> On Tue, 23 Jun 2026 13:08:02 -0500
> Chris Morgan <macromorgan@hotmail.com> wrote:
>
> > On Mon, Jun 22, 2026 at 09:34:10PM -0500, Chris Morgan wrote:
> > > On Sun, Jun 21, 2026 at 06:19:48PM +0100, Jonathan Cameron wrote:
> > > > On Mon, 15 Jun 2026 12:25:48 -0500
> > > > Chris Morgan <macroalpha82@gmail.com> wrote:
> > > >
> > > > > From: Chris Morgan <macromorgan@hotmail.com>
> > > > >
> > > > > Add power management support for the ICM42607 device driver.
> > > > >
> > > > > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> > > > A few things from taking a look at the sashiko report:
> > > > https://sashiko.dev/#/patchset/20260615172554.160910-1-macroalpha82%40gmail.com
> > > >
> > > > > ---
> > > > > drivers/iio/imu/inv_icm42607/inv_icm42607.h | 18 +++
> > > > > .../iio/imu/inv_icm42607/inv_icm42607_core.c | 139 ++++++++++++++++++
> > > > > .../iio/imu/inv_icm42607/inv_icm42607_i2c.c | 1 +
> > > > > .../iio/imu/inv_icm42607/inv_icm42607_spi.c | 1 +
> > > > > 4 files changed, 159 insertions(+)
> > > > >
> > > > > diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> > > > > index a6a58571935f..4f4f541027dc 100644
> > > > > --- 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)
> > > >
> > > > Sashiko had a valid comment on this. MSEC_PER_SEC seems more
> > > > appropriate given this is 2 seconds in milli seconds.
> > > >
> > > > > +
> > > > > typedef int (*inv_icm42607_bus_setup)(struct inv_icm42607_state *);
> > > > >
> > > > > extern const struct regmap_config inv_icm42607_regmap_config;
> > > > > extern const struct inv_icm42607_hw inv_icm42607_hw_data;
> > > > > extern const struct inv_icm42607_hw inv_icm42607p_hw_data;
> > > > > +extern const struct dev_pm_ops inv_icm42607_pm_ops;
> > > > >
> > > > > int inv_icm42607_core_probe(struct regmap *regmap,
> > > > > const struct inv_icm42607_hw *hw,
> > > > > diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> > > > > index 4b8e19091786..64f5d263de4f 100644
> > > > > --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> > > > > +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> > > > > @@ -4,6 +4,7 @@
> > > > > */
> > > > >
> > > > > #include <linux/bitfield.h>
> > > > > +#include <linux/cleanup.h>
> > > > > #include <linux/delay.h>
> > > > > #include <linux/dev_printk.h>
> > > > > #include <linux/device/devres.h>
> > > > > @@ -11,6 +12,7 @@
> > > > > #include <linux/iio/iio.h>
> > > > > #include <linux/module.h>
> > > > > #include <linux/mutex.h>
> > > > > +#include <linux/pm_runtime.h>
> > > > > #include <linux/regmap.h>
> > > > > #include <linux/regulator/consumer.h>
> > > > > #include <linux/time.h>
> > > > > @@ -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.
> > > >
> > > > Sashiko commented on this.. I think what we could do with adding to the
> > > > comment is what the path is that didn't pass through this function which would
> > > > ensure we have been on for 30 of this msecs already.
> > >
> > > I'm going to track whatever time the gyro started, and then if less
> > > than 45ms has elapsed just pause the remaining amount of time.
> > >
> > > >
> > > > > + */
> > > > > + if (!gyro && oldgyro)
> > > > > + fsleep(INV_ICM42607_GYRO_STOP_TIME_MS * USEC_PER_MSEC);
> > > > > +
> > > > > + 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 (ret)
> > > > > + return ret;
> > > > > +
> > > > > + st->conf.gyro.mode = gyro;
> > > > > + st->conf.accel.mode = accel;
> > > > > + st->conf.temp_en = temp;
> > > > > +
> > > > > + /*
> > > > > + * If a state change occurs from off to on, sleep for the startup
> > > > > + * time of the sensor, unless a sleep_ms is specified. Since more
> > > > > + * than one sensor can be transitioned from off to on, select the
> > > > > + * maximum time from each of the sensors changing from off to on.
> > > > > + */
> > > > > + sleepval_ms = 0;
> > > > > + if (temp && !oldtemp)
> > > > > + sleepval_ms = max(sleepval_ms, INV_ICM42607_TEMP_STARTUP_TIME_MS);
> > > > > +
> > > > > + if (accel && !oldaccel)
> > > > > + sleepval_ms = max(sleepval_ms, INV_ICM42607_ACCEL_STARTUP_TIME_MS);
> > > > > +
> > > > > + if (gyro && !oldgyro)
> > > > > + sleepval_ms = max(sleepval_ms, INV_ICM42607_GYRO_STARTUP_TIME_MS);
> > > > > +
> > > > > + if (sleep_ms)
> > > > > + *sleep_ms = sleepval_ms;
> > > > > + else if (sleepval_ms)
> > > > > + fsleep(sleepval_ms * USEC_PER_MSEC);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > >
> > > > >
> > > > > int inv_icm42607_core_probe(struct regmap *regmap,
> > > > > @@ -236,6 +305,8 @@ int inv_icm42607_core_probe(struct regmap *regmap,
> > > > > if (!st)
> > > > > return -ENOMEM;
> > > > >
> > > > > + dev_set_drvdata(dev, st);
> > > > > +
> > > > > ret = devm_mutex_init(dev, &st->lock);
> > > > > if (ret)
> > > > > return ret;
> > > > > @@ -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);
> > > > Sashiko does put out some stuff here. Please take a look and work out or
> > > > test if it is right (I think not but haven't checked that carefully!)
> > > > From a quick look I think that the auto disabling of autosuspend does a
> > > > rpm_idle() that should result in it suspending...
> > > >
> > >
> > > I see a few other drivers adding one more call to
> > > devm_pm_runtime_enable() so I'm going to see how that works out.
> >
> > Obviously that didn't work, but digging in much deeper into the PM code
> > I see that devm_pm_runtime_set_active_enabled() returns
> > devm_pm_runtime_enable(), which sets devm_add_action_or_reset() on
> > pm_runtime_disable_action(), which calls
> > pm_runtime_dont_use_autosuspend() and pm_runtime_disable(). Shouldn't
> > this work, or am I missing something? Basically when the driver
> > detaches shouldn't this chain end up calling
> > pm_runtime_dont_use_autosuspend()?
> Agreed. That was how I read things. The only thing I didn't entirely
> confirm (states involved were fiddly enough I'd want to check it
> with the actual driver!) was that pm_runtime_dont_use_autosuspend()
> ends up calling rpm_idle() in this case.
>
> Jonathan
I dropped in a dev_warn on the rpm_idle() and can confirm when I
unbound the driver it called rpm_idle(). So... yes?
Chris
>
> >
> > Thank you,
> > Chris
> >
> > >
> > > >
> > > > > +
> > > > > return 0;
> > > > > }
> > > > > EXPORT_SYMBOL_NS_GPL(inv_icm42607_core_probe, "IIO_ICM42607");
> > >
> > > Thank you,
> > > Chris
>
^ permalink raw reply
* Re: [PATCH] spi: dt-bindings: microchip,pic32mzda-sqi: Convert to DT schema
From: Conor Dooley @ 2026-06-24 16:48 UTC (permalink / raw)
To: Udaya Kiran Challa
Cc: tsbogend, robh, krzk+dt, conor+dt, skhan, me, linux-rtc,
devicetree, linux-kernel
In-Reply-To: <20260624061329.130468-1-challauday369@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 774 bytes --]
On Wed, Jun 24, 2026 at 11:43:29AM +0530, Udaya Kiran Challa wrote:
> + clocks:
> + maxItems: 2
Please make this an items list too (and drop the maxItems while you're
doing so).
pw-bot: changes-requested
> +
> + clock-names:
> + items:
> + - const: spi_ck
> + - const: reg_ck
> +examples:
> + - |
> + #include <dt-bindings/clock/microchip,pic32-clock.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + sqi1: spi@1f8e2000 {
And remove the unused label here.
Thanks,
Conor.
> + compatible = "microchip,pic32mzda-sqi";
> + reg = <0x1f8e2000 0x200>;
> + interrupts = <169 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&rootclk REF2CLK>, <&rootclk PB5CLK>;
> + clock-names = "spi_ck", "reg_ck";
> + };
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm: altera: Add Agilex72 SoCFPGA compatible strings
From: Conor Dooley @ 2026-06-24 16:42 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade
Cc: dinguyen, robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260624055644.7508-2-muhammad.nazim.amirul.nazle.asmade@altera.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v6 2/9] dt-bindings: media: nxp: Add Wave6 video codec device
From: Conor Dooley @ 2026-06-24 16:41 UTC (permalink / raw)
To: Nas Chung
Cc: mchehab, hverkuil, robh, krzk+dt, conor+dt, shawnguo, s.hauer,
linux-media, devicetree, linux-kernel, linux-imx,
linux-arm-kernel, jackson.lee, lafley.kim, marek.vasut
In-Reply-To: <20260624072043.238-3-nas.chung@chipsnmedia.com>
[-- Attachment #1: Type: text/plain, Size: 6900 bytes --]
On Wed, Jun 24, 2026 at 04:20:36PM +0900, Nas Chung wrote:
> Add documentation for the Chips&Media Wave6 video codec on NXP i.MX SoCs.
>
> The hardware contains one control register region and four interface
> register regions for a shared video processing engine. The control region
> manages shared resources such as firmware memory, while each interface
> region has its own MMIO range and interrupt.
>
> The control region and each interface region are distinct DMA requesters
> and can be associated with separate IOMMU stream IDs. Represent the
> control region as the parent node and the interface register regions as
> child nodes to describe these resources.
>
> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
> ---
> .../bindings/media/nxp,imx95-vpu.yaml | 163 ++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 170 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml b/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
> new file mode 100644
> index 000000000000..9a5ca53e15a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
> @@ -0,0 +1,163 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/nxp,imx95-vpu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Chips&Media Wave6 Series multi-standard codec IP on NXP i.MX SoCs
> +
> +maintainers:
> + - Nas Chung <nas.chung@chipsnmedia.com>
> + - Jackson Lee <jackson.lee@chipsnmedia.com>
> +
> +description:
> + The Chips&Media Wave6 codec IP is a multi-standard video encoder/decoder.
> + On NXP i.MX SoCs, the Wave6 codec IP exposes one control register region and
> + four interface register regions for a shared video processing engine.
> + The parent node describes the control region, which has its own MMIO range and
> + manages shared resources such as firmware memory. The child nodes describe the
> + interface register regions. Each interface region has its own MMIO range and
> + interrupt.
> + The control region and the interface regions are distinct DMA requesters.
> + The control region and each interface region can be associated with separate
> + IOMMU stream IDs, allowing DMA isolation between them.
> +
> +properties:
> + compatible:
> + enum:
> + - nxp,imx95-vpu
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: VPU core clock
> + - description: VPU associated block clock
> +
> + clock-names:
> + items:
> + - const: core
> + - const: vpublk
> +
> + power-domains:
> + items:
> + - description: Main VPU power domain
> + - description: Performance power domain
> +
> + power-domain-names:
> + items:
> + - const: vpu
> + - const: perf
> +
> + memory-region:
> + maxItems: 1
> +
> + sram:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + phandle to the SRAM node used to store reference data, reducing DMA
> + memory bandwidth.
> +
> + iommus:
> + maxItems: 1
> +
> + "#cooling-cells":
> + const: 2
> +
> + "#address-cells":
> + const: 2
> +
> + "#size-cells":
> + const: 2
> +
> + ranges: true
> +
> +patternProperties:
> + "^interface@[0-9a-f]+$":
I have to wonder if this interface business is required at all.
Why can this not go into the parent, with each region fetchable via
reg-names, interrupt-names and iommu-names?
Cheers,
Conor.
> + type: object
> + description:
> + An interface register region within the Chips&Media Wave6 codec IP.
> + Each region has its own MMIO range and interrupt and can be associated
> + with a separate IOMMU stream ID for DMA isolation.
> + additionalProperties: false
> +
> + properties:
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + iommus:
> + maxItems: 1
> +
> + required:
> + - reg
> + - interrupts
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - power-domains
> + - power-domain-names
> + - memory-region
> + - "#address-cells"
> + - "#size-cells"
> + - ranges
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/nxp,imx95-clock.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + video-codec@4c4c0000 {
> + compatible = "nxp,imx95-vpu";
> + reg = <0x0 0x4c4c0000 0x0 0x10000>;
> + clocks = <&scmi_clk 115>,
> + <&vpu_blk_ctrl IMX95_CLK_VPUBLK_WAVE>;
> + clock-names = "core", "vpublk";
> + power-domains = <&scmi_devpd 21>,
> + <&scmi_perf 10>;
> + power-domain-names = "vpu", "perf";
> + memory-region = <&vpu_boot>;
> + sram = <&sram1>;
> + iommus = <&smmu 0x32>;
> + #cooling-cells = <2>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + interface@4c480000 {
> + reg = <0x0 0x4c480000 0x0 0x10000>;
> + interrupts = <GIC_SPI 299 IRQ_TYPE_LEVEL_HIGH>;
> + iommus = <&smmu 0x33>;
> + };
> +
> + interface@4c490000 {
> + reg = <0x0 0x4c490000 0x0 0x10000>;
> + interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
> + iommus = <&smmu 0x34>;
> + };
> +
> + interface@4c4a0000 {
> + reg = <0x0 0x4c4a0000 0x0 0x10000>;
> + interrupts = <GIC_SPI 301 IRQ_TYPE_LEVEL_HIGH>;
> + iommus = <&smmu 0x35>;
> + };
> +
> + interface@4c4b0000 {
> + reg = <0x0 0x4c4b0000 0x0 0x10000>;
> + interrupts = <GIC_SPI 302 IRQ_TYPE_LEVEL_HIGH>;
> + iommus = <&smmu 0x36>;
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index efbf808063e5..77ea3a1a966b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -28688,6 +28688,13 @@ S: Maintained
> F: Documentation/devicetree/bindings/media/cnm,wave521c.yaml
> F: drivers/media/platform/chips-media/wave5/
>
> +WAVE6 VPU CODEC DRIVER
> +M: Nas Chung <nas.chung@chipsnmedia.com>
> +M: Jackson Lee <jackson.lee@chipsnmedia.com>
> +L: linux-media@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
> +
> WHISKEYCOVE PMIC GPIO DRIVER
> M: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> L: linux-gpio@vger.kernel.org
> --
> 2.31.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: Convert cirrus,cs35l36 to DT schema
From: Mark Brown @ 2026-06-24 16:41 UTC (permalink / raw)
To: david
Cc: David Rhodes, Richard Fitzgerald, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, patches, Bjorn Helgaas,
linux-sound, devicetree, linux-kernel, phone-devel
In-Reply-To: <20260624-dt-cirrus-cs35l36-v2-1-74eccdbd8fe4@ixit.cz>
[-- Attachment #1: Type: text/plain, Size: 183 bytes --]
On Wed, Jun 24, 2026 at 06:02:25PM +0200, David Heidelberg via B4 Relay wrote:
> +$id: http://devicetree.org/schemas/cirrus,cs35l36.yaml#
Other bindings include sound/ in the path.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: vendor-prefixes: add alientek
From: Conor Dooley @ 2026-06-24 16:38 UTC (permalink / raw)
To: Yanan He
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-1-5aef608a3f64@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: mmc: Convert TI OMAP2420 MMC to DT schema
From: sashiko-bot @ 2026-06-24 16:38 UTC (permalink / raw)
To: Eduard Bostina; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260624163112.535237-1-egbostina@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `ti,hwmods` property was omitted from the `required` list during the conversion to YAML.
--
commit 2529eee822cb54c2e574fedc2f1d4933627359c5
Author: Eduard Bostina <egbostina@gmail.com>
dt-bindings: mmc: Convert TI OMAP2420 MMC to DT schema
This commit converts the Texas Instruments MMC host controller bindings
for OMAP1 and 2420 from a text format to DT schema.
> diff --git a/Documentation/devicetree/bindings/mmc/ti,omap2420-mmc.yaml b/Documentation/devicetree/bindings/mmc/ti,omap2420-mmc.yaml
> new file mode 100644
> index 0000000000000..794d5ec0b58e6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/ti,omap2420-mmc.yaml
[ ... ]
> +required:
> + - compatible
> + - reg
> + - interrupts
[Severity: Medium]
Should ti,hwmods be included in this required properties list?
The original text binding in ti-omap.txt listed ti,hwmods under its
Required properties. By omitting it here, device trees missing the property
will pass validation, but could fail to probe at runtime since the legacy
OMAP platform code relies on the hwmod framework for clock and power domain
configuration.
> +
> +unevaluatedProperties: false
[ ... ]
> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap.txt b/Documentation/devicetree/bindings/mmc/ti-omap.txt
> deleted file mode 100644
> index 02fd31cf361d6..0000000000000
> --- a/Documentation/devicetree/bindings/mmc/ti-omap.txt
> +++ /dev/null
[ ... ]
> -Required properties:
> -- compatible: Must be "ti,omap2420-mmc", for OMAP2420 controllers
> -- ti,hwmods: For 2420, must be "msdi<n>", where n is controller
> - instance starting 1
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624163112.535237-1-egbostina@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH 2/7] dt-bindings: arm: rockchip: Add Alientek DLRV1126
From: Conor Dooley @ 2026-06-24 16:37 UTC (permalink / raw)
To: Yanan He
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-2-5aef608a3f64@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 3/7] dt-bindings: net: rockchip-dwmac: Allow 9 clocks
From: Conor Dooley @ 2026-06-24 16:37 UTC (permalink / raw)
To: Yanan He
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-3-5aef608a3f64@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 64 bytes --]
Per Heiko's comments,
pw-bot: changes-requested
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: axiado: add AX3005 EVK
From: Conor Dooley @ 2026-06-24 16:36 UTC (permalink / raw)
To: Swark Yang
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Harshit Shah,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260624-upstream-axiado-ax3005-upstream-v1-1-c05bd0bc9124@axiado.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net] dt-bindings: net: renesas,ether: Drop example "ethernet-phy-ieee802.3-c22" fallback
From: Conor Dooley @ 2026-06-24 16:35 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Niklas Söderlund, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Sergei Shtylyov, netdev,
linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <20260624150250.131966-2-robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 52 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Conor Dooley @ 2026-06-24 16:35 UTC (permalink / raw)
To: Janani Sunil
Cc: Jonathan Cameron, Rodrigo Alencar, Nuno Sá, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <20260624-decrease-protector-6c883bd1ac47@spud>
[-- Attachment #1: Type: text/plain, Size: 974 bytes --]
On Wed, Jun 24, 2026 at 05:32:26PM +0100, Conor Dooley wrote:
> > dac@0 {
> > compatible = "adi,ad5529r-16";
> > reg = <0>;
> > adi,device-addrs = <0 1>;
>
> I think this should be put in the channel itself and made generic.
I guess I should expand on that, putting it in the channel means it's
not tied to some device-specific knowledge about when each device
address is used.
It should be generic because there are at least 3 devices, from 2
different vendors, that we know of, using the exact same scheme.
> > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > vdd-supply = <&vdd_reg>;
> > hvdd-supply = <&hvdd_reg>;
> >
> > channel@0 { reg = <0>; adi,output-range-microvolt = <0 5000000>; };
> > channel@16 { reg = <16>; adi,output-range-microvolt = <0 40000000>; };
> > };
> >
> > Does this look reasonable to everyone?
> >
> > Regards,
> > Janani Sunil
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Conor Dooley @ 2026-06-24 16:32 UTC (permalink / raw)
To: Janani Sunil
Cc: Jonathan Cameron, Rodrigo Alencar, Nuno Sá, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <9abc53d0-432f-48fc-9e21-4d9a3c5e129f@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 22849 bytes --]
On Wed, Jun 24, 2026 at 05:01:18PM +0200, Janani Sunil wrote:
>
> On 6/23/26 16:57, Jonathan Cameron wrote:
> > On Tue, 23 Jun 2026 09:09:14 +0100
> > Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
> >
> > > On 22/06/26 13:20, Nuno Sá wrote:
> > > > On Mon, Jun 22, 2026 at 12:51:20PM +0100, Rodrigo Alencar wrote:
> > > > > On 22/06/26 11:29, Nuno Sá wrote:
> > > > > > On Mon, Jun 22, 2026 at 10:24:05AM +0100, Rodrigo Alencar wrote:
> > > > > > > On 21/06/26 15:33, Jonathan Cameron wrote:
> > > > > > > > On Fri, 19 Jun 2026 16:54:11 +0100
> > > > > > > > Nuno Sá <noname.nuno@gmail.com> wrote:
> > > > > > > > > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > > > > > > > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > > > > > > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > > > > > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > > > > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > > > > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > > > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > > > > > > > > integrated precision reference.
> > > > > > > > > > > > > > > > > ...
> > > > > > > > > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > +patternProperties:
> > > > > > > > > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > > > > > > > > + type: object
> > > > > > > > > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > + properties:
> > > > > > > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > > > > > > > > + minimum: 0
> > > > > > > > > > > > > > > > > > + maximum: 15
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > > > > > > > > + description: |
> > > > > > > > > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > > > > > > > > + oneOf:
> > > > > > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > > > > > + - const: 0
> > > > > > > > > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > + required:
> > > > > > > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > +required:
> > > > > > > > > > > > > > > > > > + - compatible
> > > > > > > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > +dependencies:
> > > > > > > > > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > +allOf:
> > > > > > > > > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > +examples:
> > > > > > > > > > > > > > > > > > + - |
> > > > > > > > > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > + spi {
> > > > > > > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > + dac@0 {
> > > > > > > > > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > + channel@0 {
> > > > > > > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > + channel@1 {
> > > > > > > > > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > > > + channel@2 {
> > > > > > > > > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > > > > ...
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > spi {
> > > > > > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > multi-dac@0 {
> > > > > > > > > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > dac@0 {
> > > > > > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > > > > > };
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > > > > > };
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > channel@2 {
> > > > > > > > > > > > > > > > > reg = <2>;
> > > > > > > > > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > > > > > };
> > > > > > > > > > > > > > > > > }
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > dac@1 {
> > > > > > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > > > > > };
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > > > > > };
> > > > > > > > > > > > > > > > > }
> > > > > > > > > > > > > > > > > };
> > > > > > > > > > > > > > > > > };
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > then you might need something like:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > patternProperties:
> > > > > > > > > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > > > > > > > > Hi Rodrigo,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thank you for looking at this.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > > > > > > > > speculatively without a validating use case.
> > > > > > > > > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > > > > > > > > longer term how to support it cleanly in SPI.
> > > > > > > > > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > > > > > > > > see if I can find what I am thinking of...
> > > > > > > > > > > >
> > > > > > > > > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > > > > > > > > slightly different properties.
> > > > > > > > > > > >
> > > > > > > > > > > > microchip,device-addr:
> > > > > > > > > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > > > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > > > > > > enum: [0, 1, 2, 3]
> > > > > > > > > > > > default: 0
> > > > > > > > > > > >
> > > > > > > > > > > > and
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > microchip,hw-device-address:
> > > > > > > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > > > > > > minimum: 0
> > > > > > > > > > > > maximum: 3
> > > > > > > > > > > > description:
> > > > > > > > > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > > > > > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > > > > > > > > The device address is part of the device markings to avoid
> > > > > > > > > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > > > > > > > > addresses are available when multiple devices are present on the same
> > > > > > > > > > > > SPI bus with only one Chip Select line for all devices.
> > > > > > > > > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > > > > > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > > > > > > > > which is first one on the wire).
> > > > > > > > > > > >
> > > > > > > > > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > > > > > > > > here?
> > > > > > > > > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > > > > > > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > > > > > > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > > > > > > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > > > > > > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > > > > > > > > about solving this at the spi level.
> > > > > > > > > > >
> > > > > > > > > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > > > > > > > > together in the same bus.
> > > > > > > > > > I'm definitely missing something, because that property for the
> > > > > > > > > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > > > > > > > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > > > > > > > > are completely different devices with different drivers. They have
> > > > > > > > > > individual device nodes and their own supplies etc etc. These aren't
> > > > > > > > > > per-channel properties on an adc or dac, they're per child device on a
> > > > > > > > > > spi bus.
> > > > > > > > > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > > > > > > > > devices on the same CS right? Because for this chip we would need
> > > > > > > > > something like:
> > > > > > > > >
> > > > > > > > > spi {
> > > > > > > > > dac@0 {
> > > > > > > > > reg = <0>;
> > > > > > > > > adi,pin-id = <0>;
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > dac@1 {
> > > > > > > > > reg = <0>; // which seems already problematic?
> > > > > > > > > adi,pin-id <1>;
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > ...
> > > > > > > > >
> > > > > > > > > //up to 4
> > > > > > > > > };
> > > > > > > > Yeah. It's not clear to me how that works for the microchip devices
> > > > > > > > (I suspect it doesn't!)
> > > > > > > >
> > > > > > > > Just thinking as I type, but could we do something a bit nasty with
> > > > > > > > a gpio mux that doesn't actually switch but represents the GPIO being
> > > > > > > > shared? Given this is all tied to the spi bus that should all happen
> > > > > > > > under serializing locks.
> > > > > > > >
> > > > > > > > Agreed though that this would be nicer as an SPI thing that let
> > > > > > > > us specify that a single CS is share by multiple devices and their
> > > > > > > > is some other signal acting to select which one we are talking to.
> > > > > > > If the device-addressing on the same chip-select is to be handled
> > > > > > > by the spi framework, wouldn't we lose device-specific features?
> > > > > > >
> > > > > > > I understand that this multi-device feature is there mostly to extend the
> > > > > > > channel count from 16 to 32, 48 or 64. I suppose the command:
> > > > > > >
> > > > > > > "MULTI DEVICE SW LDAC MODE"
> > > > > > >
> > > > > > > exists so that software can update channel values accross multiple devices.
> > > > > > Right! You do have a point! I agree the main driver for a feature like
> > > > > > this is likely to extend the channel count and effectively "aggregate"
> > > > > > devices.
> > > > > >
> > > > > > But I would say that even with the spi solution the MULTI DEVICE stuff
> > > > > > should be doable (as we still need a sort of adi,pin-id property).
> > > > > I don't think we can have something like an IIO buffer shared by multiple
> > > > > devices. Synchronizing separate devices would be doable with proper hardware
> > > > > support for this (probably involving an FGPA).
> > > > True!
> > > > > > But yes, I do feel that the whole feature is for aggregation so seeing
> > > > > > one device with 32 channels is the expectation here? Rather than seeing
> > > > > > two devices with 16 channels.
> > > > > Yes, I think aggregation is the whole point there... so that the IIO driver
> > > > > is multi-device-aware.
> > > > Which makes me feel that different pins per device might be possible
> > > > from an HW point of view but does not make much sense. For example, for
> > > > the buffer example I would expect LDAC to be shared between all the
> > > > devices.
> > > That is why I would still suggest the multi-dac node in the middle...
> > > the parent node can hold shared resources, while the dac children can
> > > have their own, overriding or inheriting stuff.
> > >
> > Before going down that path I'd want confirmation this is something we
> > actually think anyone will build.
> >
> > Jonathan
>
> To directly answer your question- we currently do not have a platform that supports multi device topology with independent supplies or reset lines.
> Given that, I agree to start with the parallel wiring assumption and defer per chip resource variation under there is a solid use case. I will also drop the "adi,resolution" proposal and proceed with "adi,device-addrs" in the AD5529R binding.
> With all of the above, the proposed binding for the multi-device follow up series would look like:
>
>
> dac@0 {
> compatible = "adi,ad5529r-16";
> reg = <0>;
> adi,device-addrs = <0 1>;
I think this should be put in the channel itself and made generic.
> reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> vdd-supply = <&vdd_reg>;
> hvdd-supply = <&hvdd_reg>;
>
> channel@0 { reg = <0>; adi,output-range-microvolt = <0 5000000>; };
> channel@16 { reg = <16>; adi,output-range-microvolt = <0 40000000>; };
> };
>
> Does this look reasonable to everyone?
>
> Regards,
> Janani Sunil
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v2] dt-bindings: mmc: Convert TI OMAP2420 MMC to DT schema
From: Eduard Bostina @ 2026-06-24 16:31 UTC (permalink / raw)
To: daniel.baluta, simona.toaca, goledhruva, m-chawdhry, egbostina,
Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-mmc, devicetree, linux-kernel
Convert the Texas Instruments MMC host controller bindings
to DT schema.
Note that the OMAP2420 driver will not work with OMAP2430 or later omaps.
Please see the OMAP HSMMC driver for current OMAPs.
Signed-off-by: Eduard Bostina <egbostina@gmail.com>
---
Changes in v2:
- Changed ti,hwmods type reference from string-array to string
- Updated ti,hwmods regex pattern to "^msdi([1-9]|[1-9][0-9]+)$"
---
.../bindings/mmc/ti,omap2420-mmc.yaml | 60 +++++++++++++++++++
.../devicetree/bindings/mmc/ti-omap.txt | 26 --------
2 files changed, 60 insertions(+), 26 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/ti,omap2420-mmc.yaml
delete mode 100644 Documentation/devicetree/bindings/mmc/ti-omap.txt
diff --git a/Documentation/devicetree/bindings/mmc/ti,omap2420-mmc.yaml b/Documentation/devicetree/bindings/mmc/ti,omap2420-mmc.yaml
new file mode 100644
index 000000000000..794d5ec0b58e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti,omap2420-mmc.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/ti,omap2420-mmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments MMC host controller for OMAP1 and 2420
+
+maintainers:
+ - Eduard Bostina <egbostina@gmail.com>
+
+description: |
+ The MMC Host Controller on TI OMAP1 and 2420 family provides
+ an interface for MMC, SD, and SDIO types of memory cards.
+
+allOf:
+ - $ref: /schemas/mmc/mmc-controller.yaml#
+
+properties:
+ compatible:
+ const: ti,omap2420-mmc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ ti,hwmods:
+ description: |
+ Name of the hwmod associated to the MMC controller. Must be
+ "msdi<n>" where n is the controller instance starting from 1.
+ $ref: /schemas/types.yaml#/definitions/string
+ pattern: "^msdi([1-9]|[1-9][0-9]+)$"
+
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mmc@4809c000 {
+ compatible = "ti,omap2420-mmc";
+ ti,hwmods = "msdi1";
+ reg = <0x4809c000 0x80>;
+ interrupts = <83>;
+ dmas = <&sdma 61 &sdma 62>;
+ dma-names = "tx", "rx";
+ };
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap.txt b/Documentation/devicetree/bindings/mmc/ti-omap.txt
deleted file mode 100644
index 02fd31cf361d..000000000000
--- a/Documentation/devicetree/bindings/mmc/ti-omap.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-* TI MMC host controller for OMAP1 and 2420
-
-The MMC Host Controller on TI OMAP1 and 2420 family provides
-an interface for MMC, SD, and SDIO types of memory cards.
-
-This file documents differences between the core properties described
-by mmc.txt and the properties used by the omap mmc driver.
-
-Note that this driver will not work with omap2430 or later omaps,
-please see the omap hsmmc driver for the current omaps.
-
-Required properties:
-- compatible: Must be "ti,omap2420-mmc", for OMAP2420 controllers
-- ti,hwmods: For 2420, must be "msdi<n>", where n is controller
- instance starting 1
-
-Examples:
-
- msdi1: mmc@4809c000 {
- compatible = "ti,omap2420-mmc";
- ti,hwmods = "msdi1";
- reg = <0x4809c000 0x80>;
- interrupts = <83>;
- dmas = <&sdma 61 &sdma 62>;
- dma-names = "tx", "rx";
- };
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: clock: ast2700: add PECI clock
From: Conor Dooley @ 2026-06-24 16:29 UTC (permalink / raw)
To: Ryan Chen
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
linux-clk, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20260624-peci_clk-v1-1-ee28b92e22e9@aspeedtech.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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