* Re: [PATCH v2 2/2] software node: Fix software_node_get_reference_args() with index -1
From: sashiko-bot @ 2026-06-18 15:31 UTC (permalink / raw)
To: Alban Bedel; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260618152035.1600436-2-alban.bedel@lht.dlh.de>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Use-after-free vulnerability in software node reference resolution.
- [High] Data race and linked list corruption in software node children management.
--
commit 3b564802f7102505002d84b52abe9e6a26646a5d
Author: Alban Bedel <alban.bedel@lht.dlh.de>
software node: Fix software_node_get_reference_args() with index -1
This patch corrects an out-of-bounds access check in
software_node_get_reference_args() by ensuring the bounds check correctly
handles UINT_MAX as an index.
Closes: https://lore.kernel.org/linux-devicetree/20260611103904.7CB131F00893@smtp.kernel.org/
> diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
> index a19f8f722bc8e..e76f7c36f19e6 100644
> --- a/drivers/base/swnode.c
> +++ b/drivers/base/swnode.c
> @@ -529,7 +529,7 @@ software_node_get_reference_args(const struct fwnode_handle *fwnode,
> if (prop->is_inline)
> return -EINVAL;
>
> - if ((index + 1) * sizeof(*ref) > prop->length)
> + if (index >= prop->length / sizeof(*ref))
> return -ENOENT;
>
> ref_array = prop->pointer;
[Severity: High]
This isn't a bug introduced by this patch, but it looks like there's a
pre-existing use-after-free risk later in this function.
When we resolve the reference here:
if (ref->swnode)
refnode = software_node_fwnode(ref->swnode);
...
args->fwnode = fwnode_handle_get(refnode);
software_node_fwnode() calls software_node_to_swnode(), which drops the
swnode_kset->list_lock and returns the swnode pointer without elevating its
reference count via kobject_get():
drivers/base/swnode.c:software_node_to_swnode() {
...
list_for_each_entry(k, &swnode_kset->list, entry) {
swnode = kobj_to_swnode(k);
if (swnode->node == node)
break;
swnode = NULL;
}
spin_unlock(&swnode_kset->list_lock);
return swnode;
}
Since the pointer is unreferenced, could it be concurrently unregistered
and freed (e.g., by software_node_unregister()) before we call
fwnode_handle_get() on it?
[Severity: High]
This is also a pre-existing issue, but I noticed a potential data race and
linked list corruption in the software node children management in
drivers/base/swnode.c.
In swnode_register(), child nodes are added to the parent's list without
a lock:
drivers/base/swnode.c:swnode_register() {
...
if (parent)
list_add_tail(&swnode->entry, &parent->children);
...
}
And in software_node_release(), they are removed without synchronization:
drivers/base/swnode.c:software_node_release() {
...
if (swnode->parent) {
ida_free(&swnode->parent->child_ids, swnode->id);
list_del(&swnode->entry);
}
...
}
If multiple child nodes are concurrently registered or unregistered under the
same parent (e.g., dynamically by drivers calling
fwnode_create_software_node()), could this corrupt the doubly linked list and
crash the kernel?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618152035.1600436-1-alban.bedel@lht.dlh.de?part=2
^ permalink raw reply
* Re: [PATCH RFC] dt-bindings: sound: Convert cirrus,cs35l36 to DT schema
From: Mark Brown @ 2026-06-18 15:22 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: <20260618-dt-cirrus-cs35l36-v1-1-1a43515666ad@ixit.cz>
[-- Attachment #1: Type: text/plain, Size: 501 bytes --]
On Thu, Jun 18, 2026 at 04:33:28PM +0200, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> Convert CS35L36 Speaker Amplifier.
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v2 2/2] software node: Fix software_node_get_reference_args() with index -1
From: Alban Bedel @ 2026-06-18 15:20 UTC (permalink / raw)
To: driver-core, devicetree
Cc: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Rob Herring, Saravana Kannan, Zijun Hu, linux-kernel, Alban Bedel,
Sashiko
In-Reply-To: <20260618152035.1600436-1-alban.bedel@lht.dlh.de>
The bounds check for the index passed to
software_node_get_reference_args() was failing when passed UINT_MAX,
this in turn would lead to an out of bound access in the property
array. Fix the bound check to also cover the UINT_MAX case.
Fixes: 31e4e12e0e960 ("software node: Correct a OOB check in software_node_get_reference_args()")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-devicetree/20260611103904.7CB131F00893@smtp.kernel.org/
Signed-off-by: Alban Bedel <alban.bedel@lht.dlh.de>
--
v2: No changes. Only submit this patch along with the patch that
triggered the Sashiko report, to hopefully avoid another useless
report.
---
drivers/base/swnode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 869228a65cb36..2bc76f01eb77d 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -537,7 +537,7 @@ software_node_get_reference_args(const struct fwnode_handle *fwnode,
if (prop->is_inline)
return -EINVAL;
- if ((index + 1) * sizeof(*ref) > prop->length)
+ if (index >= prop->length / sizeof(*ref))
return -ENOENT;
ref_array = prop->pointer;
--
2.39.5
^ permalink raw reply related
* [PATCH v2 1/2] of: property: Fix of_fwnode_get_reference_args() with negative index
From: Alban Bedel @ 2026-06-18 15:20 UTC (permalink / raw)
To: driver-core, devicetree
Cc: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Rob Herring, Saravana Kannan, Zijun Hu, linux-kernel, Alban Bedel,
Tommaso Merciai, Krzysztof Kozlowski
fwnode_property_get_reference_args() should return -ENOENT when an out
of bound index is passed. An issue arised with the OF backend because
the OF API use signed indexes while the fwnode API use unsigned ones.
When an index value greater the INT_MAX was passed to the OF backend
it got casted to a negative value and it returned -EINVAL instead of
-ENOENT. This patch add a check to of_fwnode_get_reference_args() to
catch negative index before they are passed to the OF API and return
-ENOENT right away.
This issue appeared when the following pattern was used in the LED
subsystem:
index = fwnode_property_match_string(fwnode, "led-names", name)
led_node = fwnode_find_reference(fwnode, "leds", index);
Unlike the same pattern with the OF API, this pattern implicitly cast
the signed return value of fwnode_property_match_string() to an
unsigned index leading to the above issue with the OF backend. It can
be argued that the return value of fwnode_property_match_string()
should be checked separately, but I think there is value in supporting
such simple and straight to the point patterns.
Link: https://lore.kernel.org/linux-leds/aimVRwJPhlGxsIUj@tom-desktop/T/#mc43cbf7e0599991b56dd0d9680714d28d145fbc8
Cc: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Alban Bedel <alban.bedel@lht.dlh.de>
---
v2: Fixed comment block to follow linux coding style.
---
drivers/of/property.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 136946f8b746f..a4e9ffe1a4121 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1157,6 +1157,14 @@ of_fwnode_get_reference_args(const struct fwnode_handle *fwnode,
unsigned int i;
int ret;
+ /*
+ * This function should return -ENOENT for out of bound indexes,
+ * but the OF API uses signed indexes and consider negative indexes
+ * as invalid. Catch them here to correctly implement the fwnode API.
+ */
+ if ((int)index < 0)
+ return -ENOENT;
+
if (nargs_prop)
ret = of_parse_phandle_with_args(to_of_node(fwnode), prop,
nargs_prop, index, &of_args);
--
2.39.5
^ permalink raw reply related
* Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices
From: Jason Gunthorpe @ 2026-06-18 15:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Vishnu Reddy, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, Vikash Garodia, Robin Murphy, joro, will,
m.szyprowski, iommu, linux-kernel, dikshita.agarwal
In-Reply-To: <e9e76c9f-b3b1-4ffd-9547-183556f6bb60@kernel.org>
On Thu, Jun 18, 2026 at 01:57:40PM +0200, Krzysztof Kozlowski wrote:
> Same with interrupt-map.
> There are PCIe controller nodes which have interrupt-map and no
> interrupts property ever uses them.
PCIe is quite a different situation because we expect Linux to
dynamically create the child nodes based on PCIe discovery, and the
various maps are all searched based on the PCI BDF based on HW
properties of real discovered child devices.
Here they created "vpu_bus" and create a bunch of devices for some
reason, but they are all hard coded in the driver. It is not a dynamic
discovery, and it is not creating "real" child devices.
> Because DT person - me - told that creating child device nodes just to
> configure iommus is abuse of DT. There are no child devices in terms of
> hardware or firmware. The iommu ranges here are no real hardware.
That doesn't seem to be what Vishnu is saying. Review the earlier two
emails explaining what the HW issue is here:
https://lore.kernel.org/all/bb59f07e-ca7e-f012-6a4b-0a148350b69c@oss.qualcomm.com/
https://lore.kernel.org/all/cb37e7cc-4fb0-4c24-8f89-f6f9eb08a107@oss.qualcomm.com/
The VPU HW diagram with different IOVA requirements for different
stream IDs seems to be an entirely HW based thing: "each context bank
enforces a different IOVA range"
The original patches just created a 0 based IOVA space per stream and
justified that by increasing the IOVA address space (make sense). The
email above now says some of the streams only function with a limited
range of IOVA because the HW uses the IOVA itself to select the
streams (insane!)
IOW this entire device is completely mis-designed if it is going to
easially support the Linux DMA API :( That's all HW mess, which is
motivating hacks to try to make the Linux DMA API do something usable
by this device.
Anyhow..
In Linux if you use DT iommus the SW sets things up so every stream
shares the same translation. If your driver/device doesn't like that
there is no SW way to opt out of sharing. I think that is the first
core issue that VPU was struggling with.
If you have one "device" then I would argue the DT should describe all
its streams using iommus in the normal way. The introduction of
iommu-map for VPU is only being done because that is a convenient hack
to allow Linux to unbundle the streams. It would be much harder to
unbunble the streams directly from the DT iommus property, but that
would probably be the cleanest, software agnostic, DT modeling.
So, if we are going to do a hack in DT to accomodate Linux, I argue to
choose explicit child devices so VPU does not need to create a special
bus, call of_dma_configue, or hack in new DMA API things that only it
will ever use. Then the explicit children can properly describe how
the HW decodes IOVA into each streams in the DT (which sounds very
much like a HW property to me) so that Linux produces IOVA that the HW
mangling properly routes to the expected stream.
Then the VPU driver just has to assemble itself from many struct
devices, which I admit is also a troublesome task.
> However, said all this, since I pushed folks to come with the iommu-map
> approach, I will revoke my disagreement to child device nodes in DT, if
> you really believe that is the approach. IOW, I will agree to device
> nodes in DT representing fake hardware-children, just for the sake of
> Linux driver model limitations.
I would wait for Robin, he knows this better, but I belive this was
broadly his point in the original email..
Jason
^ permalink raw reply
* [PATCH v5 2/2] arm/xen: Update DT binding documentation reference
From: Tejas Mutalikdesai @ 2026-06-18 15:11 UTC (permalink / raw)
To: devicetree; +Cc: robh, krzk+dt, conor+dt, sstabellini, Tejas Mutalikdesai
In-Reply-To: <20260618151147.9438-1-tejasmutalikdesai@gmail.com>
Update the comment in xen_early_init() to reference the new xen.yaml
schema after xen.txt was converted to the DT schema format.
Signed-off-by: Tejas Mutalikdesai <tejasmutalikdesai@gmail.com>
---
Split from patch 1/2 since v4 to keep the binding conversion separate
from the driver comment fix.
arch/arm/xen/enlighten.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 25a0ce3b4584..0b7b7e3417e3 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -251,7 +251,7 @@ static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
}
/*
- * see Documentation/devicetree/bindings/arm/xen.txt for the
+ * see Documentation/devicetree/bindings/arm/xen.yaml for the
* documentation of the Xen Device Tree format.
*/
void __init xen_early_init(void)
--
2.54.0
^ permalink raw reply related
* [PATCH v5 1/2] dt-bindings: arm: xen: Convert to DT schema
From: Tejas Mutalikdesai @ 2026-06-18 15:11 UTC (permalink / raw)
To: devicetree; +Cc: robh, krzk+dt, conor+dt, sstabellini, Tejas Mutalikdesai
Convert the Xen ARM device tree binding documentation from the legacy
plain-text format (Documentation/devicetree/bindings/arm/xen.txt) to
the DT schema format, as required by the modern DT binding process.
The "hypervisor" node is named without a unit-address. The name is part
of the Xen ABI and is matched verbatim by the kernel using strcmp() in
arch/arm/xen/enlighten.c and arch/arm64/kernel/acpi.c, so $nodename uses
'const: hypervisor'. The node has a reg but no unit-address, so dtc emits
a non-fatal unit_address_vs_reg warning on the example; this is inherent
to the existing binding and is not introduced by the conversion.
Signed-off-by: Tejas Mutalikdesai <tejasmutalikdesai@gmail.com>
---
The bare node name "hypervisor" (no unit-address) is deliberate:
1. The legacy binding (xen.txt, commit c43cdfbc4ceb, authored by the Xen
ARM maintainer in 2012) documents the node and its example as a bare
"hypervisor".
2. The kernel locates the node by exact name, not by unit-address:
arch/arm/xen/enlighten.c: strcmp(uname, "hypervisor")
arch/arm64/kernel/acpi.c: strcmp(name, "hypervisor")
fdt_get_name() returns the full name including any "@unit", so a
"hypervisor@..." node would fail these comparisons and Xen init would
silently not find the node.
3. The in-tree template arch/arm/boot/dts/xen/xenvm-4.2.dts uses a bare
"hypervisor" node and has done so since it was added.
4. The dtc unit_address_vs_reg warning is pre-existing: compiling
xenvm-4.2.dts today already emits it. Mandating a unit-address in the
schema would instead regress dtbs_check for that in-tree DTB and
describe a node form the kernel cannot consume.
Per the DT spec a unit-address is grammatically permitted (node-name is
the part before '@'), but making it mandatory is not viable until the
kernel matchers and the Xen-generated FDT are updated in lockstep, which
is out of scope for this binding conversion.
Changes since v4:
- Revert the v4 $nodename unit-address requirement to 'const: hypervisor'
(see rationale above).
Changes since v2:
- s/YAML schema/DT schema/ in the commit text
- Drop unnecessary '|' block scalars from descriptions
- Split the arch/arm/xen/enlighten.c doc-reference update into patch 2/2
Documentation/devicetree/bindings/arm/xen.txt | 62 ----------
.../devicetree/bindings/arm/xen.yaml | 109 ++++++++++++++++++
2 files changed, 109 insertions(+), 62 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/xen.txt
create mode 100644 Documentation/devicetree/bindings/arm/xen.yaml
diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
deleted file mode 100644
index f925290d4641..000000000000
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-* Xen hypervisor device tree bindings
-
-Xen ARM virtual platforms shall have a top-level "hypervisor" node with
-the following properties:
-
-- compatible:
- compatible = "xen,xen-<version>", "xen,xen";
- where <version> is the version of the Xen ABI of the platform.
-
-- reg: specifies the base physical address and size of the regions in memory
- where the special resources should be mapped to, using an HYPERVISOR_memory_op
- hypercall.
- Region 0 is reserved for mapping grant table, it must be always present.
- The memory region is large enough to map the whole grant table (it is larger
- or equal to gnttab_max_grant_frames()).
- Regions 1...N are extended regions (unused address space) for mapping foreign
- GFNs and grants, they might be absent if there is nothing to expose.
-
-- interrupts: the interrupt used by Xen to inject event notifications.
- A GIC node is also required.
-
-To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
-under /hypervisor with following parameters:
-
-________________________________________________________________________________
-Name | Size | Description
-================================================================================
-xen,uefi-system-table | 64-bit | Guest physical address of the UEFI System
- | | Table.
---------------------------------------------------------------------------------
-xen,uefi-mmap-start | 64-bit | Guest physical address of the UEFI memory
- | | map.
---------------------------------------------------------------------------------
-xen,uefi-mmap-size | 32-bit | Size in bytes of the UEFI memory map
- | | pointed to in previous entry.
---------------------------------------------------------------------------------
-xen,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI
- | | memory map.
---------------------------------------------------------------------------------
-xen,uefi-mmap-desc-ver | 32-bit | Version of the mmap descriptor format.
---------------------------------------------------------------------------------
-
-Example (assuming #address-cells = <2> and #size-cells = <2>):
-
-hypervisor {
- compatible = "xen,xen-4.3", "xen,xen";
- reg = <0 0xb0000000 0 0x20000>;
- interrupts = <1 15 0xf08>;
- uefi {
- xen,uefi-system-table = <0xXXXXXXXX>;
- xen,uefi-mmap-start = <0xXXXXXXXX>;
- xen,uefi-mmap-size = <0xXXXXXXXX>;
- xen,uefi-mmap-desc-size = <0xXXXXXXXX>;
- xen,uefi-mmap-desc-ver = <0xXXXXXXXX>;
- };
-};
-
-The format and meaning of the "xen,uefi-*" parameters are similar to those in
-Documentation/arch/arm/uefi.rst, which are provided by the regular UEFI stub. However
-they differ because they are provided by the Xen hypervisor, together with a set
-of UEFI runtime services implemented via hypercalls, see
-http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
diff --git a/Documentation/devicetree/bindings/arm/xen.yaml b/Documentation/devicetree/bindings/arm/xen.yaml
new file mode 100644
index 000000000000..4eeadb8ae106
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/xen.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/xen.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xen hypervisor
+
+maintainers:
+ - Stefano Stabellini <sstabellini@kernel.org>
+
+description:
+ Xen ARM virtual platforms shall have a top-level "hypervisor" node with
+ the properties defined below.
+
+properties:
+ $nodename:
+ const: hypervisor
+
+ compatible:
+ description:
+ Specifies the Xen hypervisor. The version of the Xen ABI is encoded
+ in the first item as "xen,xen-<version>", followed by the generic
+ "xen,xen" string.
+ items:
+ - pattern: "^xen,xen-[0-9]+\\.[0-9]+$"
+ - const: xen,xen
+
+ reg:
+ description: |
+ Base physical address and size of the regions in memory where special
+ resources should be mapped to, using a HYPERVISOR_memory_op hypercall.
+
+ Region 0 is reserved for mapping the grant table and must always be
+ present. The memory region must be large enough to map the whole grant
+ table (it is larger or equal to gnttab_max_grant_frames()).
+
+ Regions 1...N are extended regions (unused address space) for mapping
+ foreign GFNs and grants. They might be absent if there is nothing to
+ expose.
+ minItems: 1
+
+ interrupts:
+ description:
+ The interrupt used by Xen to inject event notifications.
+ A GIC node is also required.
+ maxItems: 1
+
+ uefi:
+ type: object
+ description:
+ Node populated by Xen to support UEFI on Xen ARM virtual platforms.
+ The format and meaning of the "xen,uefi-*" parameters are similar to
+ those in Documentation/arch/arm/uefi.rst, but are provided by the Xen
+ hypervisor together with a set of UEFI runtime services implemented via
+ hypercalls.
+ properties:
+ xen,uefi-system-table:
+ description: Guest physical address of the UEFI System Table.
+ $ref: /schemas/types.yaml#/definitions/uint64
+
+ xen,uefi-mmap-start:
+ description: Guest physical address of the UEFI memory map.
+ $ref: /schemas/types.yaml#/definitions/uint64
+
+ xen,uefi-mmap-size:
+ description: Size in bytes of the UEFI memory map pointed to by xen,uefi-mmap-start.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ xen,uefi-mmap-desc-size:
+ description: Size in bytes of each entry in the UEFI memory map.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ xen,uefi-mmap-desc-ver:
+ description: Version of the mmap descriptor format.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ required:
+ - xen,uefi-system-table
+ - xen,uefi-mmap-start
+ - xen,uefi-mmap-size
+ - xen,uefi-mmap-desc-size
+ - xen,uefi-mmap-desc-ver
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ hypervisor {
+ compatible = "xen,xen-4.3", "xen,xen";
+ reg = <0xb0000000 0x20000>;
+ interrupts = <1 15 0xf08>;
+
+ uefi {
+ xen,uefi-system-table = /bits/ 64 <0x1301415>;
+ xen,uefi-mmap-start = /bits/ 64 <0x7591400>;
+ xen,uefi-mmap-size = <0x1800>;
+ xen,uefi-mmap-desc-size = <0x30>;
+ xen,uefi-mmap-desc-ver = <1>;
+ };
+ };
+...
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v6 06/16] iio: core: create local __iio_chan_prefix_emit() for reuse
From: Nuno Sá @ 2026-06-18 15:06 UTC (permalink / raw)
To: rodrigo.alencar
Cc: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening,
Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
In-Reply-To: <20260618-ad9910-iio-driver-v6-6-79125ffbe430@analog.com>
On Thu, Jun 18, 2026 at 02:27:22PM +0100, Rodrigo Alencar via B4 Relay wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Move logic to create a channel prefix for naming attribute files into a
> separate __iio_chan_prefix_emit() function for reuse.
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> ---
> drivers/iio/industrialio-core.c | 167 ++++++++++++++++------------------------
> 1 file changed, 68 insertions(+), 99 deletions(-)
>
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 03019bf9327b..9373006235c8 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -26,6 +26,7 @@
> #include <linux/property.h>
> #include <linux/sched.h>
> #include <linux/slab.h>
> +#include <linux/sprintf.h>
> #include <linux/wait.h>
>
> #include <linux/iio/buffer.h>
> @@ -199,6 +200,64 @@ static const char * const iio_chan_info_postfix[] = {
> [IIO_CHAN_INFO_CONVDELAY] = "convdelay",
> [IIO_CHAN_INFO_POWERFACTOR] = "powerfactor",
> };
> +
> +static int __iio_chan_prefix_emit(const struct iio_chan_spec *chan,
> + enum iio_shared_by shared_by,
> + char *buf, size_t len)
> +{
> + const char *dir = iio_direction[chan->output];
> + const char *type = iio_chan_type_name_spec[chan->type];
> + int n = 0;
> +
> + switch (shared_by) {
> + case IIO_SHARED_BY_ALL:
> + buf[0] = '\0'; /* empty channel prefix */
> + break;
> + case IIO_SHARED_BY_DIR:
> + n = scnprintf(buf, len, "%s", dir);
> + break;
> + case IIO_SHARED_BY_TYPE:
> + n = scnprintf(buf, len, "%s_%s", dir, type);
> + if (chan->differential)
> + n += scnprintf(buf + n, len - n, "-%s", type);
> + break;
> + case IIO_SEPARATE:
> + if (chan->indexed) {
> + n = scnprintf(buf, len, "%s_%s%d", dir, type,
> + chan->channel);
> + if (chan->differential)
> + n += scnprintf(buf + n, len - n, "-%s%d", type,
> + chan->channel2);
> + } else {
> + if (chan->differential) {
> + WARN(1, "Differential channels must be indexed\n");
> + return -EINVAL;
> + }
> + n = scnprintf(buf, len, "%s_%s", dir, type);
> + }
> +
> + if (chan->modified) {
> + if (chan->differential) {
> + WARN(1, "Differential channels can not have modifier\n");
> + return -EINVAL;
WARN() looks too much to me. dev_error() as we're treating it as such. I
guess you don't want to pass struct device but not really an issue IMHO.
> + }
> + n += scnprintf(buf + n, len - n, "_%s",
> + iio_modifier_names[chan->channel2]);
> + }
> +
> + if (chan->extend_name)
> + n += scnprintf(buf + n, len - n, "_%s", chan->extend_name);
> + break;
> + }
> +
> + if (n > 0 && n < len - 1) { /* prefix termination if not empty */
> + buf[n++] = '_';
> + buf[n] = '\0';
> + }
> +
Can't we handle the above in the caller on kasprintf()? Then we could
simplify and return in place.
> + return n;
> +}
> +
> /**
> * iio_device_id() - query the unique ID for the device
> * @indio_dev: Device structure whose ID is being queried
> @@ -1100,106 +1159,19 @@ int __iio_device_attr_init(struct device_attribute *dev_attr,
> size_t len),
> enum iio_shared_by shared_by)
> {
> - int ret = 0;
> - char *name = NULL;
> - char *full_postfix;
> + char prefix[NAME_MAX + 1];
> + int ret;
>
> sysfs_attr_init(&dev_attr->attr);
>
> - /* Build up postfix of <extend_name>_<modifier>_postfix */
> - if (chan->modified && (shared_by == IIO_SEPARATE)) {
> - if (chan->extend_name)
> - full_postfix = kasprintf(GFP_KERNEL, "%s_%s_%s",
> - iio_modifier_names[chan->channel2],
> - chan->extend_name,
> - postfix);
> - else
> - full_postfix = kasprintf(GFP_KERNEL, "%s_%s",
> - iio_modifier_names[chan->channel2],
> - postfix);
> - } else {
> - if (chan->extend_name == NULL || shared_by != IIO_SEPARATE)
> - full_postfix = kstrdup(postfix, GFP_KERNEL);
> - else
> - full_postfix = kasprintf(GFP_KERNEL,
> - "%s_%s",
> - chan->extend_name,
> - postfix);
> - }
> - if (full_postfix == NULL)
> + ret = __iio_chan_prefix_emit(chan, shared_by, prefix, sizeof(prefix));
> + if (ret < 0)
> + return ret;
> +
> + dev_attr->attr.name = kasprintf(GFP_KERNEL, "%s%s", prefix, postfix);
> + if (!dev_attr->attr.name)
> return -ENOMEM;
I don't oppose the change. Looks like a nice cleanup. But bear in mind
this very sensible as any subtle mistake means ABI breakage.
- Nuno Sá
>
> - if (chan->differential) { /* Differential can not have modifier */
> - switch (shared_by) {
> - case IIO_SHARED_BY_ALL:
> - name = kasprintf(GFP_KERNEL, "%s", full_postfix);
> - break;
> - case IIO_SHARED_BY_DIR:
> - name = kasprintf(GFP_KERNEL, "%s_%s",
> - iio_direction[chan->output],
> - full_postfix);
> - break;
> - case IIO_SHARED_BY_TYPE:
> - name = kasprintf(GFP_KERNEL, "%s_%s-%s_%s",
> - iio_direction[chan->output],
> - iio_chan_type_name_spec[chan->type],
> - iio_chan_type_name_spec[chan->type],
> - full_postfix);
> - break;
> - case IIO_SEPARATE:
> - if (!chan->indexed) {
> - WARN(1, "Differential channels must be indexed\n");
> - ret = -EINVAL;
> - goto error_free_full_postfix;
> - }
> - name = kasprintf(GFP_KERNEL,
> - "%s_%s%d-%s%d_%s",
> - iio_direction[chan->output],
> - iio_chan_type_name_spec[chan->type],
> - chan->channel,
> - iio_chan_type_name_spec[chan->type],
> - chan->channel2,
> - full_postfix);
> - break;
> - }
> - } else { /* Single ended */
> - switch (shared_by) {
> - case IIO_SHARED_BY_ALL:
> - name = kasprintf(GFP_KERNEL, "%s", full_postfix);
> - break;
> - case IIO_SHARED_BY_DIR:
> - name = kasprintf(GFP_KERNEL, "%s_%s",
> - iio_direction[chan->output],
> - full_postfix);
> - break;
> - case IIO_SHARED_BY_TYPE:
> - name = kasprintf(GFP_KERNEL, "%s_%s_%s",
> - iio_direction[chan->output],
> - iio_chan_type_name_spec[chan->type],
> - full_postfix);
> - break;
> -
> - case IIO_SEPARATE:
> - if (chan->indexed)
> - name = kasprintf(GFP_KERNEL, "%s_%s%d_%s",
> - iio_direction[chan->output],
> - iio_chan_type_name_spec[chan->type],
> - chan->channel,
> - full_postfix);
> - else
> - name = kasprintf(GFP_KERNEL, "%s_%s_%s",
> - iio_direction[chan->output],
> - iio_chan_type_name_spec[chan->type],
> - full_postfix);
> - break;
> - }
> - }
> - if (name == NULL) {
> - ret = -ENOMEM;
> - goto error_free_full_postfix;
> - }
> - dev_attr->attr.name = name;
> -
> if (readfunc) {
> dev_attr->attr.mode |= 0444;
> dev_attr->show = readfunc;
> @@ -1210,10 +1182,7 @@ int __iio_device_attr_init(struct device_attribute *dev_attr,
> dev_attr->store = writefunc;
> }
>
> -error_free_full_postfix:
> - kfree(full_postfix);
> -
> - return ret;
> + return 0;
> }
>
> static void __iio_device_attr_deinit(struct device_attribute *dev_attr)
>
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: (subset) [PATCH v2 0/3] 88PM886 Vbus regulator support
From: Lee Jones @ 2026-06-18 14:46 UTC (permalink / raw)
To: Karel Balej, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown, Duje Mihanović
Cc: devicetree, phone-devel, ~postmarketos/upstreaming, linux-kernel,
Duje Mihanović, Conor Dooley
In-Reply-To: <20260613-88pm886-vbus-v2-0-021dfb02c6bb@dujemihanovic.xyz>
On Sat, 13 Jun 2026 16:20:52 +0200, Duje Mihanović wrote:
> This series adds support for the USB Vbus regulator found on Marvell's
> 88PM886 PMIC. The regulator enables USB role switching on boards using
> the PMIC.
Applied, thanks!
[1/3] dt-bindings: mfd: 88pm886: Allow vbus regulator
commit: a5026999e04d92ec0cf539731ecc56c85f843b3d
[2/3] mfd: 88pm886: Initialize the battery page
commit: a7c4cc8109c386bff04dc3567d92edc0a69d29c2
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v6 05/16] iio: core: support 64-bit register through debugfs
From: Nuno Sá @ 2026-06-18 14:45 UTC (permalink / raw)
To: rodrigo.alencar
Cc: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening,
Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
In-Reply-To: <20260618-ad9910-iio-driver-v6-5-79125ffbe430@analog.com>
On Thu, Jun 18, 2026 at 02:27:21PM +0100, Rodrigo Alencar via B4 Relay wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Add debugfs_reg64_access function pointer field into iio_info and modify
> file operation callbacks to favor 64-bit variant when it is available.
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> ---
> drivers/iio/industrialio-core.c | 33 ++++++++++++++++++++++++---------
> include/linux/iio/iio-opaque.h | 2 +-
> include/linux/iio/iio.h | 4 ++++
> 3 files changed, 29 insertions(+), 10 deletions(-)
>
> @@ -471,7 +485,8 @@ static void iio_device_register_debugfs(struct iio_dev *indio_dev)
> {
> struct iio_dev_opaque *iio_dev_opaque;
>
> - if (indio_dev->info->debugfs_reg_access == NULL)
> + if (!indio_dev->info->debugfs_reg_access &&
> + !indio_dev->info->debugfs_reg64_access)
> return;
Not really that important but should dev_warn() in case someone gives
both callbacks? Can't use both anyways.
(We now have agentic help reviewing the code so maybe even if someone
does it for some reason it won't pass review :))
- Nuno Sá
>
> if (!iio_debugfs_dentry)
> diff --git a/include/linux/iio/iio-opaque.h b/include/linux/iio/iio-opaque.h
> index b87841a355f8..98330385e08d 100644
> --- a/include/linux/iio/iio-opaque.h
> +++ b/include/linux/iio/iio-opaque.h
> @@ -73,7 +73,7 @@ struct iio_dev_opaque {
> #if defined(CONFIG_DEBUG_FS)
> struct dentry *debugfs_dentry;
> unsigned int cached_reg_addr;
> - char read_buf[20];
> + char read_buf[24];
> unsigned int read_buf_len;
> #endif
> };
> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
> index 711c00f67371..1c7d12af22da 100644
> --- a/include/linux/iio/iio.h
> +++ b/include/linux/iio/iio.h
> @@ -484,6 +484,7 @@ struct iio_trigger; /* forward declaration */
> * @update_scan_mode: function to configure device and scan buffer when
> * channels have changed
> * @debugfs_reg_access: function to read or write register value of device
> + * @debugfs_reg64_access: function to read or write 64-bit register value of device
> * @fwnode_xlate: fwnode based function pointer to obtain channel specifier index.
> * @hwfifo_set_watermark: function pointer to set the current hardware
> * fifo watermark level; see hwfifo_* entries in
> @@ -572,6 +573,9 @@ struct iio_info {
> int (*debugfs_reg_access)(struct iio_dev *indio_dev,
> unsigned int reg, unsigned int writeval,
> unsigned int *readval);
> + int (*debugfs_reg64_access)(struct iio_dev *indio_dev,
> + unsigned int reg, u64 writeval,
> + u64 *readval);
> int (*fwnode_xlate)(struct iio_dev *indio_dev,
> const struct fwnode_reference_args *iiospec);
> int (*hwfifo_set_watermark)(struct iio_dev *indio_dev, unsigned int val);
>
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH RFC] dt-bindings: sound: Convert cirrus,cs35l36 to DT schema
From: sashiko-bot @ 2026-06-18 14:43 UTC (permalink / raw)
To: David Heidelberg via B4 Relay; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260618-dt-cirrus-cs35l36-v1-1-1a43515666ad@ixit.cz>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Low] The `$id` field in the YAML schema omits the `sound/` subdirectory component, which breaks the schema cross-reference system.
- [Low] The `dt_binding_check` validation will fail because the example uses properties that are not defined in the schema.
- [Low] The default value for `cirrus,classh-wk-fet-delay` is set to `100`, which violates the property's own enum constraints.
- [Low] An incorrect and completely unrelated maintainer (Bjorn Helgaas) is listed for this Cirrus Logic audio codec binding.
--
commit 6ae17828fc1b1804817814b5209c4fcb2dc8b463
Author: David Heidelberg <david@ixit.cz>
dt-bindings: sound: Convert cirrus,cs35l36 to DT schema
Converts the CS35L36 Speaker Amplifier from a text binding to a DT schema.
It updates the maintainer to the generic Cirrus email, makes VP-supply
optional based on datasheet behavior, and incorporates dai-common.yaml.
> 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#
[Severity: Low]
Does this `$id` path need to include the `sound/` subdirectory? Without it,
the schema cross-reference system might break.
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Cirrus Logic CS35L36 Speaker Amplifier
> +
> +maintainers:
> + - patches@opensource.cirrus.com
> + - Bjorn Helgaas <bhelgaas@google.com>
[Severity: Low]
Is Bjorn Helgaas the correct maintainer to list here for this Cirrus Logic
audio codec? Since he typically maintains PCI, listing him here might
misdirect queries and patches.
[ ... ]
> + cirrus,classh-wk-fet-delay:
> + description: Weak-FET entry delay in ms
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 100
[Severity: Low]
Will this default value of 100 cause schema validation to fail? The enum
below only allows values from 0 to 7, where 4 seems to map to 100ms.
> + enum:
> + - 0 # 0
> + - 1 # 5
> + - 2 # 10
> + - 3 # 50
> + - 4 # 100
> + - 5 # 200
> + - 6 # 500
> + - 7 # 1000
[ ... ]
> + 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>;
[Severity: Low]
Could this example cause `dt_binding_check` to fail? It uses
`cirrus,weak-fet-delay` and `cirrus,weak-fet-thld`, but the schema actually
defines these properties as `cirrus,classh-wk-fet-delay` and
`cirrus,classh-weak-fet-thld-millivolt` respectively. With
`unevaluatedProperties: false` set, undocumented properties will trigger a
fatal schema error.
> + cirrus,temp-warn-threshold = <1>;
> + cirrus,multi-amp-mode;
> + cirrus,irq-drive-select = <1>;
> + cirrus,irq-gpio-select = <0x01>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-dt-cirrus-cs35l36-v1-1-1a43515666ad@ixit.cz?part=1
^ permalink raw reply
* Re: [PATCH 3/4] mfd: Add support for UGREEN NASync DH2300 MCU
From: Alexey Charkov @ 2026-06-18 14:39 UTC (permalink / raw)
To: Lee Jones
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Liam Girdwood, Mark Brown, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20260618124034.GI1672911@google.com>
On Thu, Jun 18, 2026 at 4:40 PM Lee Jones <lee@kernel.org> wrote:
>
> On Fri, 12 Jun 2026, Alexey Charkov wrote:
>
> > Add a driver for the HC32F005 MCU used as an embedded controller on the
> > UGREEN NASync DH2300 NAS.
> >
> > This part provides the shared I2C regmap to be used by function-specific
> > sub-devices, and instantiates the SATA drive-bay power gate regulator.
> > Implemented as an MFD to allow for other functions of the MCU to be added
> > later: vendor binaries imply that it also provides a hardware watchdog
> > and somehow serves as a wake source, but so far only the SATA power gating
> > function has been confirmed in absence of documentation and sources for the
> > vendor firmware.
> >
> > Signed-off-by: Alexey Charkov <alchark@flipper.net>
> > ---
> > MAINTAINERS | 1 +
> > drivers/mfd/Kconfig | 16 +++++++++++
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/ugreen-dh2300-mcu.c | 60 +++++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 78 insertions(+)
>
> Did you see: drivers/mfd/simple-mfd-i2c.c ?
Oh. Now I did :-D
It's exactly what I needed, thanks a lot for the pointer. Will drop
the boilerplate in v2 and instead instantiate my tiny child device
from there.
Best regards,
Alexey
^ permalink raw reply
* [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
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