* [PATCH RFC] dt-bindings: sound: Convert cirrus,cs35l36 to DT schema
From: David Heidelberg via B4 Relay @ 2026-06-18 14:33 UTC (permalink / raw)
To: David Rhodes, Richard Fitzgerald, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, patches,
Bjorn Helgaas
Cc: linux-sound, devicetree, linux-kernel, phone-devel,
David Heidelberg
From: David Heidelberg <david@ixit.cz>
Convert CS35L36 Speaker Amplifier.
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'
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.
---
.../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>
+
+description: |
+ 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
+ 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
+
+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 related
* Re: [PATCH v2 02/10] libfdt: Don't assume that a FDT_BEGIN_NODE tag is available at offset 0
From: David Gibson @ 2026-06-18 10:13 UTC (permalink / raw)
To: Herve Codina
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
In-Reply-To: <20260409115426.352214-3-herve.codina@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 2956 bytes --]
On Thu, Apr 09, 2026 at 01:54:18PM +0200, Herve Codina wrote:
> In several places, libfdt assumes that a FDT_BEGIN_NODE tag is present
> at the offset 0 of the structure block.
>
> This assumption is not correct. Indeed, a FDT_NOP can be present at the
> offset 0 and this is a legit case.
>
> fdt_first_node() has been introduced recently to get the offset of the
> first node (first FDT_BEGIN_NODE) in a fdt blob.
>
> Use this function to get the first node offset instead of looking for
> this node at offset 0.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
The problem is real, of course. But this approach to solving it with
a special case just for the root node is really ugly.
Granted, it's a problem of my own making - I chose not to create an
fdt_root_offset() function in the first place, instead making it part
of the API that offset 0 means the root node. Nonetheless, here we
are and the question is whether we can do better.
# Straightforward things first
- This patch should be folded with 1/10, they're both harder to
understand without the context of the other.
- If it must exist, the function should be fdt_root_offset(), not
fdt_first_node(), for at least three reasons:
* "first" in what sense?
* "first" amongst what set of nodes?
* We have a strong convention to always explicitly say "offset",
not just referring to offset values as "node" or "property".
This is deliberate: it's an attempt to discourage the otherwise
likely misunderstanding that a function getting a "node" gives
you some sort of persistent handle. "offset" makes it clearer
that the value will no longer be valid after a modification to
the tree.
- The situation described is subtle enough that this *really* needs a
testcase. It shouldn't be that hard: change the existing
'nopulate' test tool to add an FDT_NOP before the first tag, not
just after
# Is FDT_NOP before the root node actually legitimate?
Arguably the simplest solution here would be to explicitly ban this.
Yes, it would be a slightly odd restriction in the spec. However,
avoiding the mess in the library might be worth it. Note that this
situation can never arise from fdt_nop_node(), unless you apply it to
the root node, in which case there's no tree left.
# Less special casery
Even if we accept the need for FDT_NOP before the root node, I think
we can do better. The below implements this as a special case, just
for offset 0. Instead, we could allow all node operations on a
FDT_NOP offset, automatically advancing to the next FDT_BEGIN_NODE
tag. We may be able to do that in check_node_offset_() minimising
code duplication.
--
David Gibson (he or they) | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you, not the other way
| around.
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 03/10] tests: asm: Introduce treehdr_vers macro
From: David Gibson @ 2026-06-18 10:15 UTC (permalink / raw)
To: Herve Codina
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
In-Reply-To: <20260409115426.352214-4-herve.codina@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]
On Thu, Apr 09, 2026 at 01:54:19PM +0200, Herve Codina wrote:
> tree.S is used to generate custom dtbs. It uses the treehdr macro to
> build the header part.
>
> The current definition of this macro doesn't allow to set custom
> settings related to version fields.
>
> In order to easily generate some dtb with custom version values without
> duplicating the full header computation, introduce the treehdr_vers
> macro.
>
> The modification doesn't introduce any functional changes.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
I just killed the not-very-portable trees.S in the main git tree, so
this will need reworking for the new treegen.c system.
> ---
> tests/trees.S | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/tests/trees.S b/tests/trees.S
> index d69f7f1..4db2b9b 100644
> --- a/tests/trees.S
> +++ b/tests/trees.S
> @@ -8,7 +8,7 @@
> .byte (\val) & 0xff
> .endm
>
> - .macro treehdr tree
> + .macro treehdr_vers tree vers last_comp_vers
> .balign 8
> .globl \tree
> \tree :
> @@ -17,13 +17,17 @@
> fdtlong (\tree\()_struct - \tree)
> fdtlong (\tree\()_strings - \tree)
> fdtlong (\tree\()_rsvmap - \tree)
> - fdtlong 0x11
> - fdtlong 0x10
> + fdtlong \vers
> + fdtlong \last_comp_vers
> fdtlong 0
> fdtlong (\tree\()_strings_end - \tree\()_strings)
> fdtlong (\tree\()_struct_end - \tree\()_struct)
> .endm
>
> + .macro treehdr tree
> + treehdr_vers \tree 0x11 0x10
> + .endm
> +
> .macro rsvmape addrh, addrl, lenh, lenl
> fdtlong \addrh
> fdtlong \addrl
> --
> 2.53.0
>
>
--
David Gibson (he or they) | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you, not the other way
| around.
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: (subset) [PATCH v8 0/6] arm64: dts: qcom: Support AYN QCS8550 Devices
From: Neil Armstrong @ 2026-06-18 14:02 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Aaron Kling
Cc: linux-arm-msm, devicetree, linux-kernel, Xilin Wu,
Krzysztof Kozlowski, Teguh Sobirin, Konrad Dybcio
In-Reply-To: <178179131851.245596.10889069443600186081.b4-ty@b4>
On 6/18/26 16:01, Neil Armstrong wrote:
> Hi,
>
> On Sun, 03 May 2026 16:48:42 -0500, Aaron Kling wrote:
>> This specifically includes:
>> * Odin 2 Mini
>> * Odin 2 Portal
>> * Thor
>>
>> The original Odin 2 dts is not currently included as it has not yet
>> been verified.
>>
>> [...]
>
> Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next)
>
> [1/6] dt-bindings: vendor-prefixes: Add AYN Technologies
> https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/fc917a533da47a5d0fd2f3df9052ee6dc5e6adad
>
Applied it for the panel bindings,
Thanks
Neil
^ permalink raw reply
* Re: (subset) [PATCH v8 0/6] arm64: dts: qcom: Support AYN QCS8550 Devices
From: Neil Armstrong @ 2026-06-18 14:01 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Aaron Kling
Cc: linux-arm-msm, devicetree, linux-kernel, Xilin Wu,
Krzysztof Kozlowski, Teguh Sobirin, Konrad Dybcio
In-Reply-To: <20260503-ayn-qcs8550-v8-0-d733f5e57446@gmail.com>
Hi,
On Sun, 03 May 2026 16:48:42 -0500, Aaron Kling wrote:
> This specifically includes:
> * Odin 2 Mini
> * Odin 2 Portal
> * Thor
>
> The original Odin 2 dts is not currently included as it has not yet
> been verified.
>
> [...]
Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next)
[1/6] dt-bindings: vendor-prefixes: Add AYN Technologies
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/fc917a533da47a5d0fd2f3df9052ee6dc5e6adad
--
Neil
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: display: panel: himax,hx83121a: add optional bl supply
From: Neil Armstrong @ 2026-06-18 14:01 UTC (permalink / raw)
To: Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Pengyu Luo, Icenowy Zheng
Cc: Liam Girdwood, Mark Brown, dri-devel, devicetree, linux-kernel
In-Reply-To: <20260608162622.403713-1-zhengxingda@iscas.ac.cn>
Hi,
On Tue, 09 Jun 2026 00:26:20 +0800, Icenowy Zheng wrote:
> When the backlight is managed by the panel controller IC, an external
> power rail might be powering the backlight.
>
> Add an optional `bl-supply` property to describe such power rail, thus
> allow disabling the backlight.
>
>
> [...]
Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next)
[1/3] dt-bindings: display: panel: himax,hx83121a: add optional bl supply
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/b817a59c2afcfbf1594b9be6c4136d9d7d613eee
[2/3] drm/panel: himax-hx83121a: pass the panel pointer when creating BL
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/ae8dbbe8955d7470dd41e101b852fd1a70f62930
[3/3] drm/panel: himax-hx83121a: add backlight regulator support
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/98b46e693b912eef0e6d497327489113845cbd15
--
Neil
^ permalink raw reply
* Re: [PATCH v6 0/2] drm/panel: Add support for the FocusLCDs E35GH-I-MW800CB
From: Neil Armstrong @ 2026-06-18 14:01 UTC (permalink / raw)
To: Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Lad Prabhakar,
Manivannan Sadhasivam, Kael D'Alcamo, Kever Yang,
Igor Reznichenko
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260617143245.372182-1-igor@reznichenko.net>
Hi,
On Wed, 17 Jun 2026 07:32:43 -0700, Igor Reznichenko wrote:
> Add support for E35GH-I-MW800CB 320x480 MIPI DSI panel by FocusLCDs.
> The panel uses Ilitek ILI9488 driver IC in DSI mode specifically.
> ILI9488 also appears in DBI/SPI panels, but those require different bus drivers.
>
> This panel driver has been tested on STM32MP157D-DK1 in addition to TI AM62P EVK.
> The panel works in video mode on both platforms. Additional panels using
> ILI9488 DSI can be added later with their own timings.
>
> [...]
Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next)
[1/2] dt-bindings: display: panel: Add Ilitek ILI9488 panel controller
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/532701ad6e239f1b47bebaa597e159c282c6c6ac
[2/2] drm/panel: Add Ilitek ILI9488 controller driver
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/99e9aca83bfb867ae780f58d076bb89dd5c2681d
--
Neil
^ permalink raw reply
* Re: [PATCH v4 0/2] drm/panel: Add panel driver for Chipone ICNA35XX based panels
From: Neil Armstrong @ 2026-06-18 14:01 UTC (permalink / raw)
To: Jessica Zhang, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Aaron Kling
Cc: dri-devel, devicetree, linux-kernel, Krzysztof Kozlowski,
Teguh Sobirin
In-Reply-To: <20260607-icna35xx-v4-0-64de514add34@gmail.com>
Hi,
On Sun, 07 Jun 2026 15:11:43 -0500, Aaron Kling wrote:
> This driver is based on the one by Teguh Sobirin [0].
>
> Due to [1], the AYN vendor description patch has been folded into the
> AYN QCS8550 dt series. Which means this series depends on said series
> and it must be picked up before this.
>
> [0] https://github.com/AYNTechnologies/linux/commit/4c5e76e974db7cca853619ca138eecd8f004622f
> [1] https://lore.kernel.org/linux-arm-msm/c7fb3f89-6574-4761-9ef2-2fdf6d4801b5@kernel.org
>
> [...]
Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next)
[1/2] dt-bindings: display: panel: Add Chipone ICNA3512 OLED driver bindings
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/392313ce84a8498164137c6941d5c6a3f7740f1a
[2/2] drm/panel: Add panel driver for Chipone ICNA35XX based panels
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/f747473a838ecc25e842e3c60ea95a5175be932e
--
Neil
^ permalink raw reply
* Re: (subset) [PATCH V7 0/6] Add Anbernic RG Vita-Pro
From: Neil Armstrong @ 2026-06-18 14:01 UTC (permalink / raw)
To: linux-rockchip, Chris Morgan
Cc: devicetree, xsf, sre, simona, airlied, tzimmermann, mripard,
maarten.lankhorst, jesszhan0024, heiko, conor+dt, krzk+dt, robh,
Chris Morgan
In-Reply-To: <20260610144407.438846-1-macroalpha82@gmail.com>
Hi,
On Wed, 10 Jun 2026 09:44:01 -0500, Chris Morgan wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add support for the Anbernic RG Vita-Pro, based on the Rockchip RK3576 SoC.
>
> Changes Since V1:
> - Updated documentation filename to matche compatible string.
> - Corrected order of allocating IRQ in charger driver and switched
> to using devm managed function to allocate work queue.
> Changes Since V2:
> - Corrected issue with naming of panel binding document and added
> fallback compatible string.
> - Switched to devm helpers in panel driver. Note that
> devm_drm_panel_add() is currently only in the drm-next branch.
> - Optimized setting GPIOs for panel driver.
> Changes Since V3:
> - Fixed numerous issues identifed by Sashiko bot, mainly relating
> to unclamped or improperly clamped values from within the
> charger driver.
> - Corrected hard-coded values in the panel driver unprepare routine
> as well as correcting an improperly checked return condition.
> Changes Since V4:
> - Fixed errors identified by Sashiko bot on charger driver that could
> result in an improper value being written to the registers.
> - Corrected some error handling in the panel driver.
> Changes Since V5:
> - Corrected minor errors in documentation and added default values.
> - Further corrected clamping behavior in charger driver.
> Changes Since V6:
> - Additional corrections as suggested by Sashiko bot to fix potential
> edge cases during probe for sgm41542.
> - Corrected an improperly shifted value being written to register for
> sgm41542.
> - Changed a MV value to UV in sgm41542 driver to simplify function.
>
> [...]
Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next)
[3/6] dt-bindings: display: panel: Add Anbernic TD4310 panel
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/0fd6ead8270270d859a28d0196a4b47e7d6845b8
[4/6] drm/panel: anbernic-td4310: Add RG Vita Pro panel
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/a81b4fe69e7bd2667524182e76c635f04c1ead7e
--
Neil
^ permalink raw reply
* Re: [PATCH 2/2] media: i2c: og0va1b: Add OmniVision OG0VA1B camera sensor
From: Wenmeng Liu @ 2026-06-18 14:00 UTC (permalink / raw)
To: Kieran Bingham, Conor Dooley, Krzysztof Kozlowski,
Mauro Carvalho Chehab, Rob Herring, Sakari Ailus,
Vladimir Zapolskiy
Cc: linux-media, devicetree, linux-kernel
In-Reply-To: <178178854034.861173.9780571180496261859@ping.linuxembedded.co.uk>
On 6/18/2026 9:15 PM, Kieran Bingham wrote:
> Quoting Wenmeng Liu (2026-06-18 13:36:27)
>>
>>
>> On 6/18/2026 6:50 PM, Vladimir Zapolskiy wrote:
>>> Hello Wenmeng.
>>>
>>> On 6/18/26 13:37, Wenmeng Liu wrote:
>>>> Add V4L2 sub device driver for OmniVision OG0VA1B image sensor.
>>>> OmniVision OG0VA1B is an image sensor, which produces frames in 10-bit
>>>> raw output format (Y10) over a 1-lane MIPI CSI-2 interface and supports
>>>> the 640x480 (VGA) resolution.
>>>>
>>>> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
>>>> ---
>>>> MAINTAINERS | 1 +
>>>> drivers/media/i2c/Kconfig | 10 +
>>>> drivers/media/i2c/Makefile | 1 +
>>>> drivers/media/i2c/og0va1b.c | 867 ++++++++++++++++++++++++++++++++++
>>>> ++++++++++
>>>> 4 files changed, 879 insertions(+)
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index
>>>> 5aa846c8479b20651291d5bd2e316308310f826c..85a06eb9eacc410a565b80d56979eaa565515d0e 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -19891,6 +19891,7 @@ M: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
>>>> L: linux-media@vger.kernel.org
>>>> S: Maintained
>>>> F: Documentation/devicetree/bindings/media/i2c/ovti,og0va1b.yaml
>>>> +F: drivers/media/i2c/og0va1b.c
>>>> OMNIVISION OG0VE1B SENSOR DRIVER
>>>> M: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
>>>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>>>> index
>>>> 5d173e0ecf424f2f204f8d426be818e44357f8e4..56680772f5f47b4629c4e17f5a5feba08b1d94fc 100644
>>>> --- a/drivers/media/i2c/Kconfig
>>>> +++ b/drivers/media/i2c/Kconfig
>>>> @@ -363,6 +363,16 @@ config VIDEO_OG01A1B
>>>> To compile this driver as a module, choose M here: the
>>>> module will be called og01a1b.
>>>> +config VIDEO_OG0VA1B
>>>> + tristate "OmniVision OG0VA1B sensor support"
>>>> + select V4L2_CCI_I2C
>>>> + help
>>>> + This is a Video4Linux2 sensor driver for the OmniVision
>>>> + OG0VA1B camera.
>>>> +
>>>> + To compile this driver as a module, choose M here: the
>>>> + module will be called og0va1b.
>>>> +
>>>> config VIDEO_OG0VE1B
>>>> tristate "OmniVision OG0VE1B sensor support"
>>>> select V4L2_CCI_I2C
>>>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
>>>> index
>>>> e45359efe0e41e13e3c0869e5ead7d6cf4aca3a7..c60851c7fe07e3bdc511c5f482525ba7a044f48e 100644
>>>> --- a/drivers/media/i2c/Makefile
>>>> +++ b/drivers/media/i2c/Makefile
>>>> @@ -83,6 +83,7 @@ obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
>>>> obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
>>>> obj-$(CONFIG_VIDEO_MT9V111) += mt9v111.o
>>>> obj-$(CONFIG_VIDEO_OG01A1B) += og01a1b.o
>>>> +obj-$(CONFIG_VIDEO_OG0VA1B) += og0va1b.o
>>>> obj-$(CONFIG_VIDEO_OG0VE1B) += og0ve1b.o
>>>> obj-$(CONFIG_VIDEO_OS05B10) += os05b10.o
>>>> obj-$(CONFIG_VIDEO_OV01A10) += ov01a10.o
>>>> diff --git a/drivers/media/i2c/og0va1b.c b/drivers/media/i2c/og0va1b.c
>>>> new file mode 100644
>>>> index
>>>> 0000000000000000000000000000000000000000..f0505b7ba7f329ad57ffafa8f90a24204f002d3c
>>>> --- /dev/null
>>>> +++ b/drivers/media/i2c/og0va1b.c
>>>> @@ -0,0 +1,867 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * OmniVision OG0VA1B Camera Sensor Driver
>>>> + *
>>>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries
>>>> + */
>>>> +
>>>> +#include <linux/clk.h>
>>>> +#include <linux/delay.h>
>>>> +#include <linux/gpio/consumer.h>
>>>> +#include <linux/i2c.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/pm_runtime.h>
>>>> +#include <linux/regulator/consumer.h>
>>>> +
>>>> +#include <media/v4l2-cci.h>
>>>> +#include <media/v4l2-ctrls.h>
>>>> +#include <media/v4l2-device.h>
>>>> +#include <media/v4l2-fwnode.h>
>>>> +#include <media/v4l2-subdev.h>
>>>> +
>>>> +#define OG0VA1B_REG_CHIP_ID CCI_REG16(0x300a)
>>>> +#define OG0VA1B_CHIP_ID 0xC756
>>>
>>> This is the same chip id as of the OG0VE1B sensor device.
>>>
>>> What's the difference between these two sensors, and do you find it
>>> possible
>>> to add support of OG0VA1B sensor/modes into OG0VE1B sensor driver? Or is
>>> it just the same device?
>>>
>>> Hardware specifics described in dt changes also does not show a difference
>>> in comparison to ovti,og0ve1b.yaml.
>>>
>>
>>
>> Hi Vladimir,
>>
>>
>> Both OG0VE1B and OG0VA1B belong to the same OmniVision VGA monochrome
>> sensor family. They share the same resolution, power rails, reset GPIO
>> behavior and power management framework.
>>
>> But they are different:
>> OG0VE1B: 8-bit RAW, lower FPS
>> OG0VA1B: 10-bit RAW, higher FPS
>> and some registers are not same.
>
> Can you identify which registers are not the same?
>
For example, regarding the CHIP_ID,
OG0VE1B is 0xc75645, while OG0VA1B is 0xc75641, including the test
pattern registers.
Since I do not have the specification for OG0VE1B, I cannot perform a
detailed comparison. However, based on the current observations, OG0VA1B
can be integrated into the OG0VE1B driver.
> Mapping between 8bit and 10 bit or different frame rates could easily be
> managed in a single driver with exposing different capabilities based on
> the variant.
>
> We should really work towards reducing the huge duplication that is
> happening with copy/paste sensor drivers.
Indeed, will do so.
Thanks,
Wenmeng
^ permalink raw reply
* Re: [PATCH v6 14/16] iio: frequency: ad9910: show channel priority in debugfs
From: sashiko-bot @ 2026-06-18 13:45 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260618-ad9910-iio-driver-v6-14-79125ffbe430@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The parallel data port logic in the debugfs source attributes is dead code because the driver does not configure IIO buffers and omits `.scan_index` for the parallel channels.
--
commit 1430aa5467e635315d439ae21891376a98143557
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: frequency: ad9910: show channel priority in debugfs
Expose frequency_source, phase_source and amplitude_source attributes in
debugfs. The implementation follows the priority table found in the
datasheet.
> diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
> index 890499f67bd56..b39eeb8d9cd45 100644
> --- a/drivers/iio/frequency/ad9910.c
> +++ b/drivers/iio/frequency/ad9910.c
[ ... ]
> @@ -1960,6 +1974,158 @@ static int ad9910_setup(struct device *dev, struct ad9910_state *st,
> return ad9910_io_update(st);
> }
>
> +static inline const char *ad9910_frequency_source_get(struct iio_dev *indio_dev)
> +{
[ ... ]
> + /* Parallel data port enabled and data destination is frequency */
> + mode_en = FIELD_GET(AD9910_CFR2_PARALLEL_DATA_PORT_EN_MSK,
> + st->reg[AD9910_REG_CFR2].val32);
> + if (mode_en && indio_dev->active_scan_mask &&
> + test_bit(AD9910_SCAN_IDX_FREQ, indio_dev->active_scan_mask))
> + return ad9910_channel_str[AD9910_CHAN_IDX_PARALLEL_FREQ];
[Severity: Medium]
Is this logic effectively dead code?
The driver configures INDIO_DIRECT_MODE without setting up any IIO buffers,
so the IIO core will never allocate active_scan_mask. This means
indio_dev->active_scan_mask will permanently evaluate to NULL and the
condition will evaluate to false.
Furthermore, even if buffers were enabled, the channel specifications for
the parallel channels do not populate the .scan_index field, so the bits
would never be set by the IIO core anyway:
drivers/iio/frequency/ad9910.c:ad9910_channels[] = {
...
[AD9910_CHAN_IDX_PARALLEL_FREQ] = {
.type = IIO_FREQUENCY,
.indexed = 1,
.output = 1,
.channel = AD9910_CHANNEL_PARALLEL,
.address = AD9910_CHAN_IDX_PARALLEL_FREQ,
...
}
Could this debugfs output silently fail to report the parallel data port and
fall through to incorrect fallback states?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com?part=14
^ permalink raw reply
* Re: [PATCH v6 15/16] iio: ABI: add docs for ad9910 sysfs entries
From: sashiko-bot @ 2026-06-18 13:44 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260618-ad9910-iio-driver-v6-15-79125ffbe430@analog.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The device tree binding defines the hardware as a clock provider but omits `#clock-cells` from the `required` list.
- [Low] The newly added ABI documentation file is missing the mandatory 'Date:' field and has empty 'KernelVersion:' fields.
--
commit 87a63b1a571e4fe2e7cfbfd552bf448b474a11d0
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: ABI: add docs for ad9910 sysfs entries
Add custom ABI documentation file for the DDS AD9910 with sysfs entries to
control some parameters from the Digital Ramp Generator and OSK engine.
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9910 b/Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9910
> new file mode 100644
> index 0000000000000..a54afeb643029
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9910
> @@ -0,0 +1,27 @@
> +What: /sys/bus/iio/devices/iio:deviceX/out_altcurrentY_dwell_en
> +KernelVersion:
> +Contact: linux-iio@vger.kernel.org
[Severity: Low]
Does this new ABI documentation file omit the mandatory 'Date:' field?
According to Documentation/ABI/README, every file in the ABI directories
must contain a 'Date:' field specifying when the interface was created.
Additionally, the 'KernelVersion:' fields appear to be left empty, which
might trip automated ABI parsers.
[ ... ]
While reviewing this commit, I also noticed a related issue in the device
tree binding file introduced earlier in this series:
Documentation/devicetree/bindings/iio/frequency/adi,ad9910.yaml:
> required:
> - compatible
> - reg
> - clocks
> - dvdd-io33-supply
> - avdd33-supply
> - dvdd18-supply
> - avdd18-supply
[Severity: Medium]
Should '#clock-cells' be included in this required block?
Since the device tree binding defines the hardware as a clock provider with
'#clock-cells' and 'clock-output-names', omitting it from the required list
could allow incomplete device tree nodes to pass schema validation. This
might cause dependent subsystems or drivers to fail unexpectedly at runtime
when they attempt to use the undocumented functionality.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com?part=15
^ permalink raw reply
* Re: [PATCH v6 12/16] iio: frequency: ad9910: add RAM mode support
From: sashiko-bot @ 2026-06-18 13:43 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260618-ad9910-iio-driver-v6-12-79125ffbe430@analog.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Hardware and software profile states become permanently desynchronized if an error occurs while enabling or disabling the RAM channel.
- [High] Firmware upload cancellation requests can be silently ignored due to unconditionally resetting the cancel flag.
- [Low] Selecting the `FW_UPLOAD` boolean config symbol from a tristate driver causes an unmet dependency warning when built as a module.
--
commit 75d72698ebee0a7f4f951b2be1d393940055952b
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: frequency: ad9910: add RAM mode support
Add RAM control channel, which includes RAM data loading via firmware upload
interface and per-profile configuration.
> diff --git a/drivers/iio/frequency/Kconfig b/drivers/iio/frequency/Kconfig
> index 6033f9155b4f7..994d199080ebf 100644
> --- a/drivers/iio/frequency/Kconfig
> +++ b/drivers/iio/frequency/Kconfig
> @@ -29,6 +29,9 @@ config AD9910
> tristate "Analog Devices AD9910 Direct Digital Synthesizer"
> depends on SPI
> depends on GPIOLIB
> + select CRC32
> + select FW_LOADER
> + select FW_UPLOAD
[Severity: Low]
Does selecting FW_UPLOAD from a tristate driver trigger an unmet dependency
warning when built as a module?
Because FW_UPLOAD is a boolean symbol that depends on FW_LOADER, and
FW_LOADER can resolve to 'm', selecting FW_UPLOAD forces it to 'y'. Could
this be avoided by using "depends on FW_UPLOAD" instead?
> diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
> index 3fe97aa887c3a..c4e179dda715e 100644
> --- a/drivers/iio/frequency/ad9910.c
> +++ b/drivers/iio/frequency/ad9910.c
[ ... ]
> @@ -1066,6 +1167,41 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
> AD9910_CFR2_DRG_DEST_MSK |
> AD9910_CFR2_DRG_ENABLE_MSK,
> tmp32, true);
> + case AD9910_CHANNEL_RAM:
> + if (AD9910_RAM_ENABLED(st) == !!val)
> + return 0;
> +
> + /* swap profile configs */
> + for (i = 0; i < AD9910_NUM_PROFILES; i++) {
> + tmp64 = st->reg[AD9910_REG_PROFILE(i)].val64;
> + ret = ad9910_reg64_write(st,
> + AD9910_REG_PROFILE(i),
> + st->reg_profile[i],
> + false);
> + if (ret)
> + break;
> + st->reg_profile[i] = tmp64;
> + }
> +
> + if (ret) {
> + /*
> + * After the write failure, profiles 0..i-1 were
> + * already swapped in SW, but Hw registers are
> + * still pending an IO update, so swap them back
> + * in SW to keep the state consistent.
> + */
> + while (i--) {
> + tmp64 = st->reg[AD9910_REG_PROFILE(i)].val64;
> + st->reg[AD9910_REG_PROFILE(i)].val64 = st->reg_profile[i];
> + st->reg_profile[i] = tmp64;
> + }
> + return ret;
> + }
> +
> + tmp32 = FIELD_PREP(AD9910_CFR1_RAM_ENABLE_MSK, !!val);
> + return ad9910_reg32_update(st, AD9910_REG_CFR1,
> + AD9910_CFR1_RAM_ENABLE_MSK,
> + tmp32, true);
[Severity: High]
Can the hardware and software states become permanently desynchronized if an
error occurs during this transition?
If a write fails midway through the profile loop, the rollback loop restores
the software cache but doesn't seem to rewrite the original values to the
hardware SPI buffers. This leaves the successfully written swapped profiles
still pending in the hardware.
Additionally, if the entire profile swap completes but the subsequent
ad9910_reg32_update() for CFR1 fails, the function returns immediately
without any rollback.
Would the next unrelated operation that triggers an IO update unintentionally
commit these partially or completely swapped profiles to the active registers?
[ ... ]
> @@ -1335,6 +1506,126 @@ static int ad9910_read_label(struct iio_dev *indio_dev,
> return sysfs_emit(label, "%s\n", ad9910_channel_str[chan->address]);
> }
>
> +static enum fw_upload_err ad9910_ram_fwu_prepare(struct fw_upload *fw_upload,
> + const u8 *data, u32 size)
> +{
> + struct ad9910_state *st = fw_upload->dd_handle;
> + const struct ad9910_ram_fw *fw_data = (const struct ad9910_ram_fw *)data;
> + size_t wcount, bcount;
> +
> + if (size < sizeof(struct ad9910_ram_fw))
> + return FW_UPLOAD_ERR_INVALID_SIZE;
> +
> + if (get_unaligned_be32(&fw_data->magic) != AD9910_RAM_FW_MAGIC)
> + return FW_UPLOAD_ERR_FW_INVALID;
> +
> + if (get_unaligned_be16(&fw_data->version) != AD9910_RAM_FW_V1)
> + return FW_UPLOAD_ERR_FW_INVALID;
> +
> + wcount = get_unaligned_be16(&fw_data->wcount);
> + bcount = size - sizeof(struct ad9910_ram_fw);
> + if (wcount > AD9910_RAM_SIZE_MAX_WORDS ||
> + bcount != (wcount * AD9910_RAM_WORD_SIZE))
> + return FW_UPLOAD_ERR_INVALID_SIZE;
> +
> + bcount += sizeof(fw_data->cfr1) + sizeof(fw_data->profiles);
> + if (crc32(0, &fw_data->cfr1, bcount) != get_unaligned_be32(&fw_data->crc))
> + return FW_UPLOAD_ERR_FW_INVALID;
> +
> + guard(mutex)(&st->lock);
> + st->ram_fwu_cancel = false;
[Severity: High]
Does unconditionally clearing the cancellation flag here introduce a race
condition where cancellations requested prior to the worker thread starting
are lost?
If a user cancels the upload via sysfs immediately after triggering it, the
framework calls ad9910_ram_fwu_cancel(), which correctly sets
st->ram_fwu_cancel = true.
However, when the background worker thread begins and calls
ad9910_ram_fwu_prepare(), it will overwrite the cancellation state with
false. Could this allow the firmware upload to proceed and flash the device
instead of aborting?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com?part=12
^ permalink raw reply
* Re: [PATCH 5/7] riscv: dts: eswin: add hsp power domain
From: Pinkesh Vaghela @ 2026-06-18 13:42 UTC (permalink / raw)
To: sashiko-reviews@lists.linux.dev
Cc: conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20260615123122.A624D1F0155D@smtp.kernel.org>
Hi Sashiko,
Thanks for your time to review this patch.
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s)
> to consider:
> - [High] The HSP CFG clock will never be enabled, causing a hardware hang
> during register access, because `simple-pm-bus` requires children to use
> `pm_runtime` but `syscon` bypasses it.
> - [Medium] The node is labeled and described as a 'power domain' but is
> modeled as a simple bus without the ability to act as a power domain
> provider.
> --
>
> commit 0dad730760e600f73d118515b1907e14ac735dad
> Author: Pinkesh Vaghela <pinkesh.vaghela@einfochips.com>
>
> riscv: dts: eswin: add hsp power domain
>
> This commit adds an HSP power domain node to manage the HSP CFG clock,
> which is required to access the HSP CSR registers. The CSR is defined as a
> syscon child node within a simple-pm-bus.
>
> > diff --git a/arch/riscv/boot/dts/eswin/eic7700.dtsi
> > b/arch/riscv/boot/dts/eswin/eic7700.dtsi
> > --- a/arch/riscv/boot/dts/eswin/eic7700.dtsi
> > +++ b/arch/riscv/boot/dts/eswin/eic7700.dtsi
> > @@ -252,6 +252,19 @@ plic: interrupt-controller@c000000 {
> > #interrupt-cells = <1>;
> > };
> >
> > + hsp_power_domain: bus@50400000 {
> > + compatible = "simple-pm-bus";
>
> [Severity: Medium]
> The commit message and node label describe this as a power domain, but
> the node uses simple-pm-bus and lacks a #power-domain-cells property. Can
> other devices actually reference this as a power domain?
>
> simple-pm-bus acts as a transparent bus for managing clocks or resets for its
> direct children, rather than a genpd provider. If this is meant to act as a power
> domain that other IP blocks depend on via power-domains = <...>, does it
> need a dedicated driver and the #power-domain-cells property?
>
> If it is strictly meant to manage the syscon clock, should the wrapper be
> removed entirely?
This node is not intended to be a generic power domain (genpd) provider and is
Not expected to be referenced by other devices via a `power-domains` property.
The `simple-pm-bus` wrapper is used to manage the HSP CFG clock, which must
Be enabled before accessing the HSP CSR registers and the register spaces of
the HSP child devices.
The current label is misleading. To avoid confusion with a genpd provider,
we will rename it in v2:
hsp_power_domain: bus@50400000 to hsp: bus@50400000
>
> > + ranges = <0x0 0x50400000 0x0 0x50400000 0x0 0xa0000>;
> > + clocks = <&clk EIC7700_CLK_GATE_HSP_CFG_CLK>;
>
> [Severity: High]
> Since the child node uses the generic syscon compatible, will this clock ever
> be enabled?
>
> The syscon framework in drivers/mfd/syscon.c does not register a platform
> driver, does not probe a device, and does not invoke pm_runtime_get_sync().
> Because the child device is never probed or runtime-resumed, the parent
> simple-pm-bus will remain suspended.
>
> Would this cause a system hang when accessing the syscon registers since the
> clock would remain disabled?
>
> Additionally, of_syscon_register() natively expects the clocks property to be
> directly in the syscon node. Should the clocks property be moved to the
> hsp_sp_csr node and the simple-pm-bus wrapper removed?
The HSP CFG clock is required not only for accessing the HSP CSR registers, but
also for accessing the register spaces of all HSP peripherals.
In this series, we have not yet submitted the DTS patches for the HSP peripheral
devices. The intention is for all HSP peripherals to be placed under this
simple-pm-bus node so that the HSP CFG clock can be managed centrally.
A simplified example is shown below:
hsp: bus@50400000 {
compatible = "simple-pm-bus";
clocks = <&clk EIC7700_CLK_GATE_HSP_CFG_CLK>;
hsp_sp_csr: hsp-sp-top-csr@50440000 {
compatible = "eswin,eic7700-syscfg", "syscon";
reg = <0x0 0x50440000 0x0 0x2000>;
};
sdhci_emmc: mmc@50450000 {
...
};
};
The purpose of this node is not solely to provide access to the HSP CSR
registers but to act as the common parent bus for HSP peripherals that
depend on the HSP CFG clock.
The current commit message is misleading because it suggests that the node
exists only for the CSR access.
We will update the commit message in v2 as below:
riscv: dts: eswin: add HSP bus node
Add an HSP bus node to manage the HSP CFG clock used by HSP
peripherals. This clock is required for accessing both the HSP CSR
registers and the register spaces of HSP peripheral devices.
Is this acceptable?
Regards,
Pinkesh
>
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + hsp_sp_csr: hsp-sp-top-csr@50440000 {
> > + compatible = "eswin,eic7700-syscfg", "syscon";
> > + reg = <0x0 0x50440000 0x0 0x2000>;
> > + };
> > + };
> > +
> > uart0: serial@50900000 {
> > compatible = "snps,dw-apb-uart";
> > reg = <0x0 0x50900000 0x0 0x10000>;
>
> --
> Sashiko AI review *
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsashik
> o.dev%2F%23%2Fpatchset%2F20260615122016.1110206-1-
> pinkesh.vaghela%40einfochips.com%3Fpart%3D5&data=05%7C02%7Cpinkesh
> .vaghela%40einfochips.com%7Cd647a45fb159406b1be408decada02f7%7C0b
> eb0c359cbb4feb99e5589e415c7944%7C1%7C0%7C639171234888553198%7C
> Unknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA
> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
> 7C&sdata=zdGzcGOEAAOetK3OWTF5JjYPXpfvcIgMARFEP7DI39I%3D&reserved
> =0
^ permalink raw reply
* Re: [PATCH v6 11/16] iio: frequency: ad9910: add digital ramp generator support
From: sashiko-bot @ 2026-06-18 13:42 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260618-ad9910-iio-driver-v6-11-79125ffbe430@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Negative values written to DRG_RAMP_UP or DRG_RAMP_DOWN raw attributes are silently converted and clamped to U32_MAX instead of returning an error.
--
commit add95ac7476587b7d5eda18e659f33df4cc8cb31
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: frequency: ad9910: add digital ramp generator support
This patch adds support for Digital Ramp Generator channels to the AD9910
driver. It includes configuration for destination selection, dwell mode,
limits, step sizes, and step rates.
> diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
> index 262702b62738d..3fe97aa887c3a 100644
> --- a/drivers/iio/frequency/ad9910.c
> +++ b/drivers/iio/frequency/ad9910.c
[ ... ]
> @@ -831,22 +1108,62 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
> return -EINVAL;
> }
> case IIO_CHAN_INFO_RAW:
> - if (val < 0)
> - return -EINVAL;
> -
> switch (chan->channel) {
> case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
> + if (val < 0)
> + return -EINVAL;
> +
> tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
> tmp64 = FIELD_PREP(AD9910_PROFILE_ST_ASF_MSK,
> min_t(u64, val, AD9910_ASF_MAX));
> return ad9910_reg64_update(st, AD9910_REG_PROFILE(tmp32),
> AD9910_PROFILE_ST_ASF_MSK,
> tmp64, true);
> + case AD9910_CHANNEL_DRG_RAMP_UP:
> + tmp64 = iio_val_s64_compose(val, val2);
> + tmp64 = min_t(u64, tmp64, U32_MAX);
[Severity: Medium]
When a negative value is written to the DRG_RAMP_UP or DRG_RAMP_DOWN raw
attributes, does this bypass error checking?
Since iio_val_s64_compose() returns an s64, a negative input will be
implicitly cast to u64 when assigned to tmp64. This causes it to wrap to a
large positive number, which min_t() will then clamp to U32_MAX rather than
rejecting the invalid negative input.
Should we check for negative values before calling iio_val_s64_compose(),
similar to what is done for the profile channels?
> + tmp64 = FIELD_PREP(AD9910_DRG_LIMIT_UPPER_MSK, tmp64);
> + return ad9910_reg64_update(st, AD9910_REG_DRG_LIMIT,
> + AD9910_DRG_LIMIT_UPPER_MSK,
> + tmp64, true);
> + case AD9910_CHANNEL_DRG_RAMP_DOWN:
> + tmp64 = iio_val_s64_compose(val, val2);
> + tmp64 = min_t(u64, tmp64, U32_MAX);
> + tmp64 = FIELD_PREP(AD9910_DRG_LIMIT_LOWER_MSK, tmp64);
> + return ad9910_reg64_update(st, AD9910_REG_DRG_LIMIT,
> + AD9910_DRG_LIMIT_LOWER_MSK,
> + tmp64, true);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com?part=11
^ permalink raw reply
* Re: [PATCH v6 10/16] iio: frequency: ad9910: add basic parallel port support
From: sashiko-bot @ 2026-06-18 13:41 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260618-ad9910-iio-driver-v6-10-79125ffbe430@analog.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
New issues:
- [Medium] 32-bit truncation in the parallel frequency scale calculation causes incorrect readback.
- [Medium] 64-bit integer overflow in parallel frequency offset calculation circumvents U32_MAX capping.
- [Medium] `roundup_pow_of_two` truncates 64-bit scale calculation on 32-bit architectures.
- [Medium] Integer overflow when reading and writing the frequency offset for the parallel frequency channel.
Pre-existing issues:
- [High] Kernel panic due to division by zero if the reference clock rate is zero.
--
commit 5740831576c6dff0dd6ca6d5b5930978950cfff8
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: frequency: ad9910: add basic parallel port support
Add parallel port support with amplitude, phase and frequency channels.
Those will be buffered capable channels, but only basic control of offset
and scale are implemented at this point.
> diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
> index 95b01295e4a0a..262702b62738d 100644
> --- a/drivers/iio/frequency/ad9910.c
> +++ b/drivers/iio/frequency/ad9910.c
[ ... ]
> @@ -640,11 +702,60 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
> return -EINVAL;
> }
> case IIO_CHAN_INFO_SCALE:
> - tmp64 = (u64)st->data.output_current_uA *
> - AD9910_NANO_MILLIAMP_PER_MICROAMP;
> - *val = 0;
> - *val2 = tmp64 >> 14;
> - return IIO_VAL_INT_PLUS_NANO;
> + switch (chan->address) {
> + case AD9910_CHAN_IDX_PHY:
> + tmp64 = (u64)st->data.output_current_uA *
> + AD9910_NANO_MILLIAMP_PER_MICROAMP;
> + *val = 0;
> + *val2 = tmp64 >> 14;
> + return IIO_VAL_INT_PLUS_NANO;
> + case AD9910_CHAN_IDX_PARALLEL_PHASE:
> + *val = 0;
> + *val2 = AD9910_PI_NANORAD >> 15;
> + return IIO_VAL_INT_PLUS_NANO;
> + case AD9910_CHAN_IDX_PARALLEL_FREQ:
> + tmp32 = FIELD_GET(AD9910_CFR2_FM_GAIN_MSK,
> + st->reg[AD9910_REG_CFR2].val32);
> + tmp64 = st->data.sysclk_freq_hz << tmp32;
[Severity: Medium]
Will this 32-bit shift overflow before being assigned to the 64-bit tmp64?
Since sysclk_freq_hz is typically around 1 GHz and tmp32 can be up to 15,
this operation appears to be strictly 32-bit and could wrap around, resulting
in a corrupted readback.
> + tmp64 = ad9910_rational_scale(tmp64, NANO, BIT_ULL(32));
> + *val = div_s64_rem(tmp64, NANO, val2);
> + return IIO_VAL_INT_PLUS_NANO;
> + case AD9910_CHAN_IDX_PARALLEL_POLAR_AMP:
[ ... ]
> + case IIO_CHAN_INFO_OFFSET:
> + switch (chan->address) {
> + case AD9910_CHAN_IDX_PARALLEL_FREQ:
> + tmp64 = (u64)st->reg[AD9910_REG_FTW].val32 * MICRO;
> + tmp64 >>= FIELD_GET(AD9910_CFR2_FM_GAIN_MSK,
> + st->reg[AD9910_REG_CFR2].val32);
> + *val = div_s64_rem(tmp64, MICRO, val2);
[Severity: Medium]
Does this operation overflow the signed 32-bit pointer val?
The Frequency Tuning Word (FTW) is an unsigned 32-bit register capable of
holding values up to 4,294,967,295. If the offset exceeds INT_MAX, the
assignment could overflow, leading to a negative value on readback.
> + return IIO_VAL_INT_PLUS_MICRO;
> + case AD9910_CHAN_IDX_PARALLEL_POLAR_AMP:
[ ... ]
> @@ -737,12 +848,63 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
> case IIO_CHAN_INFO_SAMP_FREQ:
> return ad9910_set_sysclk_freq(st, val, true);
> case IIO_CHAN_INFO_SCALE:
> - if (val != 0 || val2 < 0)
> + switch (chan->address) {
> + case AD9910_CHAN_IDX_PHY:
> + if (val != 0 || val2 < 0)
> + return -EINVAL;
> +
> + tmp32 = DIV_U64_ROUND_CLOSEST((u64)val2 << 14,
> + AD9910_NANO_MILLIAMP_PER_MICROAMP);
> + return ad9910_set_dac_current(st, tmp32, true);
> + case AD9910_CHAN_IDX_PARALLEL_FREQ:
> + if (val < 0 || val2 < 0)
> + return -EINVAL;
> +
> + tmp64 = ad9910_rational_scale((u64)val * NANO + val2, BIT_ULL(32),
> + (u64)st->data.sysclk_freq_hz * NANO);
[Severity: High]
This is a pre-existing issue, but can sysclk_freq_hz be zero here? If the
reference clock returns 0 from clk_get_rate(), the driver initializes
sysclk_freq_hz to 0 without validation.
If sysclk_freq_hz is 0, the denominator passed to ad9910_rational_scale()
is 0:
drivers/iio/frequency/ad9910.c:ad9910_rational_scale() {
return mul_u64_add_u64_div_u64(input, scale, reference >> 1, reference);
}
This forwards the zero denominator into mul_u64_add_u64_div_u64(), leading
to a kernel panic from division by zero, which is now triggerable from user
space via the newly added parallel frequency scale attribute.
> + tmp64 = roundup_pow_of_two(max(tmp64, 1ULL));
[Severity: Medium]
Will roundup_pow_of_two() truncate the 64-bit tmp64 calculation on 32-bit
architectures?
The roundup_pow_of_two() macro explicitly casts its argument to unsigned
long. On 32-bit systems, this will drop the upper 32 bits, causing the scale
input to be incorrectly configured.
> + tmp32 = min_t(u32, ilog2(tmp64), FIELD_MAX(AD9910_CFR2_FM_GAIN_MSK));
> + tmp32 = FIELD_PREP(AD9910_CFR2_FM_GAIN_MSK, tmp32);
> + return ad9910_reg32_update(st, AD9910_REG_CFR2,
> + AD9910_CFR2_FM_GAIN_MSK,
> + tmp32, true);
> + default:
> + return -EINVAL;
> + }
> + case IIO_CHAN_INFO_OFFSET:
> + if (val < 0 || val2 < 0)
> return -EINVAL;
>
> - tmp32 = DIV_U64_ROUND_CLOSEST((u64)val2 << 14,
> - AD9910_NANO_MILLIAMP_PER_MICROAMP);
> - return ad9910_set_dac_current(st, tmp32, true);
> + switch (chan->address) {
> + case AD9910_CHAN_IDX_PARALLEL_FREQ:
> + tmp64 = (u64)val * MICRO + val2;
[Severity: Medium]
Is it possible to set the Frequency Tuning Word to its full unsigned 32-bit
range?
The IIO subsystem's parser restricts the val parameter to INT_MAX. This
limitation seems to prevent users from accessing or configuring the upper
half of the device's tuning word range when FM_GAIN is 0.
> + tmp64 <<= FIELD_GET(AD9910_CFR2_FM_GAIN_MSK,
> + st->reg[AD9910_REG_CFR2].val32);
[Severity: Medium]
Can this unbounded left shift trigger a 64-bit overflow?
If val is a large value up to INT_MAX, tmp64 can be around 5.63e14. Shifting
this left by an FM_GAIN of 15 would yield a value greater than UINT64_MAX,
which wraps around to a small positive value.
Because the wrapped value is small, it would bypass the subsequent U32_MAX
cap check below, resulting in arbitrary wrapped-around garbage being written
to the hardware.
> + tmp64 = min_t(u64, DIV_U64_ROUND_CLOSEST(tmp64, MICRO),
> + U32_MAX);
> + return ad9910_reg32_write(st, AD9910_REG_FTW, tmp64, true);
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com?part=10
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: power: supply: Add TI BQ25630 charger
From: Waqar Hameed @ 2026-06-18 13:37 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: kernel, linux-pm, devicetree, linux-kernel
In-Reply-To: <cover.1781789320.git.waqarh@axis.com>
Add devicetree bindings for the TI BQ25630 battery charger. It's I2C
controlled and sends interrupts.
Signed-off-by: Waqar Hameed <waqar.hameed@axis.com>
---
.../bindings/power/supply/ti,bq25630.yaml | 59 +++++++++++++++++++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/ti,bq25630.yaml
diff --git a/Documentation/devicetree/bindings/power/supply/ti,bq25630.yaml b/Documentation/devicetree/bindings/power/supply/ti,bq25630.yaml
new file mode 100644
index 0000000000000..1e2c7aacb26d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/ti,bq25630.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/ti,bq25630.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI BQ25630 battery charger
+
+maintainers:
+ - Waqar Hameed <waqar.hameed@axis.com>
+
+description: |
+ I2C controlled single cell Li-ion and Li-polymer 5A buck charger.
+ Datasheet: https://www.ti.com/lit/gpn/bq25630
+
+allOf:
+ - $ref: power-supply.yaml#
+
+properties:
+ compatible:
+ const: ti,bq25630
+
+ reg:
+ const: 0x6b
+ description:
+ Device I2C address.
+
+ interrupts:
+ maxItems: 1
+ description: |
+ Device sends active low 256 µs pulse. Type should therefore be
+ IRQ_TYPE_EDGE_FALLING.
+
+ monitored-battery: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - monitored-battery
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ charger@6b {
+ compatible = "ti,bq25630";
+ reg = <0x6b>;
+ interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
+ monitored-battery = <&bat>;
+ };
+ };
+...
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] Add driver for TI BQ25630 charger
From: Waqar Hameed @ 2026-06-18 13:37 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: kernel, linux-kernel, linux-pm, devicetree
This patch series contains a fully working driver for the basic
functionality for the new TI BQ25630 charger (see datasheet [1]). The
other "advanced" functionalities such as USB OTG, BATFET control and
liquid detection, will be handled in separate patches (after necessary
framework changes) according to the design discussions in the first RFC
version.
[1] https://www.ti.com/lit/gpn/bq25630
Changes in v2:
[power]
* Fix return value check for `data->regmap16be` initialization in probe
(check was wrongly for `data->regmap16le`).
* Remove TODO-comment about BATFET `sysfs` ABI (we will add a new sysfs
ABI entry in the framework for this).
* Check registers `BQ25630_REG_CHARGER_STATUS_X` as well in IRQ handler.
Because there might be changes that is not necessarily *only*
triggered from hardware faults. For example, manually
enabling/disabling with `echo 0 > /online`.
[dt-bindings]
* Rename file with `ti,` prefix.
* Remove battery-node in example.
Link to v1: https://lore.kernel.org/lkml/cover.1772201049.git.waqar.hameed@axis.com/
Waqar Hameed (2):
dt-bindings: power: supply: Add TI BQ25630 charger
power: supply: Add driver for TI BQ25630 charger
.../bindings/power/supply/ti,bq25630.yaml | 59 +
drivers/power/supply/Kconfig | 7 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/bq25630_charger.c | 1073 +++++++++++++++++
4 files changed, 1140 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/ti,bq25630.yaml
create mode 100644 drivers/power/supply/bq25630_charger.c
base-commit: e771677c937da5808f7b6c1f0e4a97ec1a84f8a8
prerequisite-patch-id: 7dfa938b45374a748d43880f3e8416e665134104
prerequisite-patch-id: c22d643d2a260a8dbcc92df0754cfdb480879578
prerequisite-patch-id: 12e94680b398a795657d3d2addcf55bed5ce62de
--
2.43.0
^ permalink raw reply
* Re: [PATCH v6 09/16] iio: frequency: ad9910: initial driver implementation
From: sashiko-bot @ 2026-06-18 13:37 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260618-ad9910-iio-driver-v6-9-79125ffbe430@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Hardware sequencing violation: reference clock and GPIO powerdown action are initialized before device regulators, causing backpowering.
--
commit 71fb9226243ea37baeab1cd6841703ff6cde346d
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
Subject: iio: frequency: ad9910: initial driver implementation
This commit adds the core AD9910 DDS driver infrastructure with single tone
mode support, including SPI register access, profile management via GPIO pins,
and PLL/DAC configuration from firmware properties.
> diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
> new file mode 100644
> index 0000000000000..95b01295e4a0a
> --- /dev/null
> +++ b/drivers/iio/frequency/ad9910.c
[ ... ]
> +static int ad9910_probe(struct spi_device *spi)
> +{
[ ... ]
> + st->refclk = devm_clk_get_enabled(dev, "ref_clk");
> + if (IS_ERR(st->refclk))
> + return dev_err_probe(dev, PTR_ERR(st->refclk),
> + "Failed to get reference clock\n");
[ ... ]
> + st->gpio_pwdown = devm_gpiod_get_optional(dev, "powerdown",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(st->gpio_pwdown))
> + return dev_err_probe(dev, PTR_ERR(st->gpio_pwdown),
> + "failed to get powerdown gpio\n");
> +
> + ret = devm_add_action_or_reset(dev, ad9910_hw_powerdown_action, st);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "failed to add hw powerdown action\n");
> +
> + ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(supplies), supplies);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to get regulators\n");
[Severity: High]
Could this initialization order cause the device to be backpowered?
In ad9910_probe(), the reference clock is enabled and the hardware powerdown
cleanup action is registered before the device's regulators are enabled. This
might drive an active clock signal into the unpowered IC during the probe
sequence.
Additionally, because devres executes cleanup actions in reverse order (LIFO),
if a probe failure occurs later or the driver unbinds, the regulators will be
turned off first. The powerdown GPIO would then be driven high and the
reference clock would continue to toggle into an unpowered chip until they
are subsequently disabled.
Driving active digital signals into an unpowered CMOS device forward-biases
its internal ESD protection diodes, which can lead to latch-up or permanent
hardware damage. Should the regulators be enabled prior to applying any
clock or active GPIO signals?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com?part=9
^ permalink raw reply
* Re: [PATCH v3 3/3] media: i2c: os02g10: implement crop handling with set_selection
From: Sakari Ailus @ 2026-06-18 13:36 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Elgin Perumbilly, Tarang Raval, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Hans Verkuil,
Hans de Goede, Vladimir Zapolskiy, Mehdi Djait, Sylvain Petinot,
Benjamin Mugnier, Bryan O'Donoghue, Heimir Thor Sverrisson,
Hardevsinh Palaniya, linux-media, devicetree, linux-kernel
In-Reply-To: <20260618130253.GF3345533@killaraus.ideasonboard.com>
Hi Laurent,
On Thu, Jun 18, 2026 at 04:02:53PM +0300, Laurent Pinchart wrote:
> On Thu, Jun 18, 2026 at 02:47:23PM +0300, Sakari Ailus wrote:
> > Hi Elgin,
> >
> > On Fri, Apr 24, 2026 at 02:55:47PM +0530, Elgin Perumbilly wrote:
> > > From: Tarang Raval <tarang.raval@siliconsignals.io>
> > >
> > > Add crop support to os02g10 by implementing .set_selection() and
> > > storing the crop rectangle in subdev state.
> > >
> > > Initialize the default crop to the active area, make set_fmt() use the
> > > current crop, and update the output format when the crop size changes.
> > > Also program the sensor window from the active crop/format state instead
> > > of using the fixed supported_modes entry.
> > >
> > > This allows userspace to configure the sensor crop window explicitly.
> >
> > Please wait for the Common Raw Sensor Model patches to be merged before
> > adding this -- we don't have an established way to configure cropping
> > before that. Some drivers might do something but it's all a bit haphazard.
>
> Does it mean we should wait for the raw sensor model to merge this
> driver ?
I only suggested this for the 3rd patch.
>
> Many existing drivers configure analog crop the same way, through the
> crop selection rectangle on the source pad. Is there harm in doing so
> already ? I wouldn't enable binning and skipping yet, that I agree with.
Which ones?
--
Regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v6 08/16] dt-bindings: iio: frequency: add ad9910
From: sashiko-bot @ 2026-06-18 13:35 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260618-ad9910-iio-driver-v6-8-79125ffbe430@analog.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The `#clock-cells` property is missing from the `required` list and the `examples` section, violating Device Tree subsystem guidelines.
- [Medium] The commit message claims to include 'DAC current' configurations, but no such property exists in the schema.
- [Low] The `reset-gpios` property is missing the `maxItems: 1` constraint.
--
commit 14de29fc570f7c4ee9b2e39250151ecb7c9edb56
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
dt-bindings: iio: frequency: add ad9910
DT-bindings for AD9910, a 1 GSPS DDS with 14-bit DAC. It includes
configurations for clocks, DAC current, reset and basic GPIO control.
> DT-bindings for AD9910, a 1 GSPS DDS with 14-bit DAC. It includes
> configurations for clocks, DAC current, reset and basic GPIO control.
[Severity: Medium]
The commit message states the binding includes configurations for
"DAC current". Does the schema actually define this property?
Looking at the schema, there is adi,charge-pump-current-microamp for the
PLL charge pump, but no property appears to configure the DAC current.
Could the commit message be updated to match the schema, or is the DAC current
property missing from the YAML?
> diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,ad9910.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,ad9910.yaml
> new file mode 100644
> index 0000000000000..a78fe33ba21f9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/frequency/adi,ad9910.yaml
[ ... ]
> + avdd18-supply:
> + description: 1.8V Analog Core supply.
> +
> + reset-gpios:
> + description:
> + GPIOs controlling the Main Device reset.
[Severity: Low]
Should reset-gpios have a maxItems: 1 constraint?
Unlike io-reset-gpios and powerdown-gpios below, this property lacks a
maxItems constraint. In dt-schema, properties ending in -gpios allow an
array of GPIOs unless explicitly constrained.
This omission allows invalid device tree configurations with multiple reset
GPIOs to pass schema validation.
> + io-reset-gpios:
> + maxItems: 1
> + description:
> + GPIO controlling the I/O_RESET pin.
[ ... ]
> +required:
> + - compatible
> + - reg
> + - clocks
> + - dvdd-io33-supply
> + - avdd33-supply
> + - dvdd18-supply
> + - avdd18-supply
[Severity: High]
Should #clock-cells be included in this required list?
According to the Device Tree Bindings subsystem guidelines, when hardware
defines provider capabilities (acting as a clock provider as indicated by
the #clock-cells: const: 1 property defined earlier in this schema), the
corresponding standard properties must be explicitly included in the
required list.
> +allOf:
> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + dds@0 {
> + compatible = "adi,ad9910";
> + reg = <0>;
[Severity: High]
Does this example need the #clock-cells property?
The example device tree node is missing the #clock-cells property.
Subsystem guidelines dictate that the examples section must demonstrate
all required properties to pass dt_binding_check validation.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com?part=8
^ permalink raw reply
* Re: [PATCH v6 07/16] iio: core: add hierarchical channel relationships
From: sashiko-bot @ 2026-06-18 13:33 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260618-ad9910-iio-driver-v6-7-79125ffbe430@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message claims the new attribute returns the 'parent channel label', but the implementation actually returns the parent channel's sysfs prefix.
--
commit 1d085ae0a672cb964aa54dcb759867393a24b06b
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: core: add hierarchical channel relationships
This commit adds a parent-child relationship between IIO channels. It
introduces a parent pointer field in the iio_chan_spec struct and exposes a
sysfs attribute for userspace to read the parent channel information.
> Add parent-child relationship between iio channels by creating a parent
> pointer field in iio_chan_spec struct and exposing a sysfs attribute that
> returns the parent channel label.
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 9373006235c87..3d12269f26f4a 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -854,6 +854,21 @@ static ssize_t iio_read_channel_label(struct device *dev,
> to_iio_dev_attr(attr)->c, buf);
> }
>
> +static ssize_t iio_read_channel_parent(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + const struct iio_chan_spec *parent = to_iio_dev_attr(attr)->c->parent;
> + int len;
> +
> + len = __iio_chan_prefix_emit(parent, IIO_SEPARATE, buf, PAGE_SIZE - 1);
[Severity: Medium]
Is the commit description accurate regarding what this attribute returns?
The commit message states it returns the parent channel label. However,
looking at iio_read_channel_parent() in drivers/iio/industrialio-core.c,
this implementation uses __iio_chan_prefix_emit() to return the parent
channel's sysfs prefix instead (e.g., in_voltage0).
While returning the sysfs prefix makes sense for userspace to locate the
parent channel, using the term label in the commit message breaks IIO API
terminology. Could the commit message be updated to state that it returns
the sysfs prefix rather than the label?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com?part=7
^ permalink raw reply
* Re: [RFC PATCH net-next v8 11/12] net: pcs: airoha: add PCS driver for Airoha AN7581 SoC
From: Benjamin Larsson @ 2026-06-18 13:30 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm, Maxime Chevallier
In-Reply-To: <20260618125752.1223-12-ansuelsmth@gmail.com>
Hi.
On 18/06/2026 14:57, Christian Marangi wrote:
> Add PCS driver for Airoha AN7581 SoC for Ethernet/PON/PCIe/USB SERDES
> and permit usage of external PHY or connected SFP cage. Supported modes
> are USXGMII, 10G-BASER, 2500BASE-X, 1000BASE-X and SGMII.
>
> The driver probe and register the various needed registers and register as
> a PCS provider for fwnode usage.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> drivers/net/pcs/Kconfig | 2 +
> drivers/net/pcs/Makefile | 2 +
> drivers/net/pcs/airoha/Kconfig | 12 +
> drivers/net/pcs/airoha/Makefile | 7 +
> drivers/net/pcs/airoha/pcs-airoha-common.c | 1324 +++++++++++++
> drivers/net/pcs/airoha/pcs-airoha.h | 1311 ++++++++++++
> drivers/net/pcs/airoha/pcs-an7581.c | 2093 ++++++++++++++++++++
> 7 files changed, 4751 insertions(+)
> create mode 100644 drivers/net/pcs/airoha/Kconfig
> create mode 100644 drivers/net/pcs/airoha/Makefile
> create mode 100644 drivers/net/pcs/airoha/pcs-airoha-common.c
> create mode 100644 drivers/net/pcs/airoha/pcs-airoha.h
> create mode 100644 drivers/net/pcs/airoha/pcs-an7581.c
My comment that the files should be renamed now instead of later when
support for other airoha platforms are added still stands. The common
code is not common among other platforms (EN7523 as example).
MvH
Benjamin Larsson
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sc8280xp: add missing QUP pinctrl states
From: Konrad Dybcio @ 2026-06-18 13:29 UTC (permalink / raw)
To: Xilin Wu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260507-sc8280xp-qup-pinctrl-v1-1-8950644af141@radxa.com>
On 5/7/26 4:44 PM, Xilin Wu wrote:
> Add the missing tlmm pinctrl states for the SC8280XP QUP engines so common
> I2C, SPI and UART pinmux definitions are available from the SoC dtsi.
> Populate all 24 engines using the SC8280XP lane-to-GPIO mapping, including
> the non-linear QUP instances, and keep the mux function names aligned with
> the driver-supported qup0..qup23 names.
>
> Move UART electrical settings out of the shared SoC pinctrl states and
> into the board dts files that need them. Update the boards that currently
> duplicate uart2 pinctrl definitions to reference qup_uart2_default and
> override only the required bias and drive properties locally, and do the
> same for Arcata's uart18 configuration. This reduces duplicated pinctrl
> data and keeps the shared SC8280XP states reusable for future QUP users.
>
> Signed-off-by: Xilin Wu <sophon@radxa.com>
> ---
[...]
> + qup_uart0_default: qup-uart0-default-state {
> + qup_uart0_cts: cts-pins {
> + pins = "gpio135";
> + function = "qup0";
> + };
> + qup_uart0_rts: rts-pins {
> + pins = "gpio136";
> + function = "qup0";
> + };
> + qup_uart0_tx: tx-pins {
> + pins = "gpio137";
> + function = "qup0";
> + };
> + qup_uart0_rx: rx-pins {
> + pins = "gpio138";
> + function = "qup0";
> + };
> + };
I find this overly verbose. Let's go for something like in glymur.dtsi,
where the common defaults are defined. I think we can even keep the
bluetooth/4way-uart configuration default as 99.999% boards will use
that
Konrad
^ permalink raw reply
* Re: [PATCH 12/12] rtc: rzn1: Add support for Renesas RZ/T2H and RZ/N2H SoCs
From: Lad, Prabhakar @ 2026-06-18 13:28 UTC (permalink / raw)
To: Wolfram Sang
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <ajKAqn1F074JJazF@shikoro>
Hi Wolfram,
Thank you for the review.
On Wed, Jun 17, 2026 at 12:10 PM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
>
> On Mon, Jun 15, 2026 at 04:48:05PM +0100, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > Add a new compatible string "renesas,r9a09g077-rtc" to the OF match table
> > to support the RTC IP variant found on the RZ/T2H and RZ/N2H SoCs.
> >
> > These newer SoCs integrate a closely related variant of the RZ/N1 RTC IP.
> > The RZ/T2H and RZ/N2H variants lack the RTCA0SUBU and RTCA0TCR registers,
>
> The RTCA0TCR is also not on RZ/N1.
>
Ah, right I missed "Not available in this LSI.", I will update the
description accordingly in v2.
Cheers,
Prabhakar
> > those registers are not accessed or used when operating under the
> > rzn1_rtc_ops_scmp configurations, making the current infrastructure
> > compatible.
> >
> > The RZ/T2H RTC variant also supports a 1 Hz output signal on the
> > RTCAT1HZ pin, controlled by the RTCA0CTL1[RTCA01HZE] bit. This bit is
> > marked as reserved in the RZ/N1 hardware manual, making RZ/T2H a
> > distinct RTC variant despite its overall compatibility with the RZ/N1
> > implementation.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> With that fixed:
>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
^ 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