* Re: [PATCH 5/13] ASoC: qcom: Add QAIF shared data structures and variant interface
From: Srinivas Kandagatla @ 2026-06-16 20:28 UTC (permalink / raw)
To: Harendra Gautam, Srinivas Kandagatla
Cc: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-sound, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260605103739.3557573-6-harendra.gautam@oss.qualcomm.com>
On 6/5/26 11:37 AM, Harendra Gautam wrote:
>
> + struct reg_field cif_rddma_shram_wm;
> + struct reg_field cif_rddma_active_ch_en;
> + struct reg_field cif_rddma_fs_sel;
> + struct reg_field cif_rddma_fs_delay;
> + struct reg_field cif_rddma_fs_out_gate;
> + struct reg_field cif_rddma_intf_dyncclk;
> + struct reg_field cif_rddma_en_16bit_unpack;
> +
Why do we need to use reg_field?, currently this patchset only supports
one SoC. reg_field makes sense only when there is change in bit
positions across SoCs and if we want to leverage from existing driver.
--srini
^ permalink raw reply
* Re: [PATCH v5 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Dmitry Torokhov @ 2026-06-16 20:30 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-input, devicetree, linux-kernel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij
In-Reply-To: <CAPVz0n26H2t=pi_C+t8jP_cWXGSa5pk=1cpTZtkBh3=RQsUk2g@mail.gmail.com>
On Tue, Jun 16, 2026 at 09:45:25AM +0300, Svyatoslav Ryhel wrote:
>
> I have tested your code on my P895 and it works perfectly fine. Should
> I resend with these changes or you can integrate them while picking
> patchset?
I think there was an update requested by Rob for the bindings?
>
> Thank you for your suggestions and efforts!
Thank you for your patience.
--
Dmitry
^ permalink raw reply
* Re: [PATCH RFC v4 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings
From: sashiko-bot @ 2026-06-16 20:32 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260616-zx29clk-v4-1-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The newly added file pattern in MAINTAINERS does not match the created dt-bindings file path.
--
commit ab1e6a61e65e8f9fc9215bf930c7a45ed74a798a
Author: Stefan Dösinger <stefandoesinger@gmail.com>
dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings
This commit introduces the device tree bindings and clock definitions for
the ZTE zx297520v3 SoC top clock and reset controller. It details the
hardware separation of clocks, PLLs, and documents the available clocks.
[ ... ]
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 069b4aa6b523c..96a5f3bcfc06a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3869,8 +3869,10 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S: Odd fixes
> F: Documentation/arch/arm/zte/
> F: Documentation/devicetree/bindings/arm/zte.yaml
> +F: Documentation/devicetree/zte,zx297520v3-*
[Severity: Low]
Does this MAINTAINERS pattern accurately match the new binding?
The newly added file pattern is missing the bindings/clock/ directory
components, so it will not match the created file at
Documentation/devicetree/bindings/clock/zte,zx297520v3-topclk.yaml.
> F: arch/arm/boot/dts/zte/
> F: arch/arm/mach-zte/
> +F: include/dt-bindings/clock/zte,zx297520v3-clk.h
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH RFC v4 03/12] dt-bindings: clk: zte: Add zx297520v3 LSP clock and reset bindings
From: sashiko-bot @ 2026-06-16 20:34 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260616-zx29clk-v4-3-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The device tree example contains undefined phandle references (`&osc26m`, `&osc32k`, `&topclk`), which will cause `dtc` and `make dt_binding_check` to fail with a compilation error.
--
commit 58efa7efa64df52a18f1832747a61ff0688b9833
Author: Stefan Dösinger <stefandoesinger@gmail.com>
dt-bindings: clk: zte: Add zx297520v3 LSP clock and reset bindings
This commit adds device tree bindings for the ZTE zx297520v3 SoC LSP
clock and reset controller. It introduces the YAML schema documenting
the required properties and provides the corresponding clock and reset
macros in a new header file.
> diff --git a/Documentation/devicetree/bindings/clock/zte,zx297520v3-lspclk.yaml b/Documentation/devicetree/bindings/clock/zte,zx297520v3-lspclk.yaml
> new file mode 100644
> index 0000000000000..096295edb6e26
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/zte,zx297520v3-lspclk.yaml
[ ... ]
> +examples:
> + - |
> + #include <dt-bindings/clock/zte,zx297520v3-clk.h>
> +
> + matrixclk: clock-controller@1306000 {
> + compatible = "zte,zx297520v3-matrixclk", "syscon";
> + reg = <0x01306000 0x400>;
> + clocks = <&osc26m>, <&osc32k>,
> + <&topclk ZX297520V3_MPLL>, <&topclk ZX297520V3_MPLL_D2>,
[Severity: Low]
Will this cause a dtc compilation failure during make dt_binding_check?
The phandles &osc26m, &osc32k, and &topclk do not appear to be defined
as nodes anywhere within this example block. Does this example need dummy
nodes defined for these clocks so the labels can resolve and the example
can compile successfully?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH RFC v4 08/12] clk: zte: Introduce a driver for zx297520v3 matrix clocks
From: sashiko-bot @ 2026-06-16 20:37 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260616-zx29clk-v4-8-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Incorrect case used for parent clock name "AHB_wclk" for the "gmac_ahb" gate.
--
commit cf4f2a13a47e51fe8fab640925ef1ac3aa154e9d
Author: Stefan Dösinger <stefandoesinger@gmail.com>
clk: zte: Introduce a driver for zx297520v3 matrix clocks
This commit introduces the clock driver for the ZTE zx297520v3 matrix
clocks, covering high-speed devices like CPU, DMA, RAM, SDIO, and Ethernet.
It maps out the multiplexers and gate clocks consumed by these devices
based on the available PLL inputs.
> diff --git a/drivers/clk/zte/clk-zx297520v3.c b/drivers/clk/zte/clk-zx297520v3.c
> index 50263bca6e087..d90aadf180269 100644
> --- a/drivers/clk/zte/clk-zx297520v3.c
> +++ b/drivers/clk/zte/clk-zx297520v3.c
[ ... ]
> +static const struct zx_gate_desc zx297520v3_matrix_gates[] = {
[ ... ]
> + GATE(ZX297520V3_GMAC_WCLK, "gmac_wclk", clk_main[0], 0x110, 0, 0),
> + GATE(ZX297520V3_GMAC_PCLK, "gmac_pclk", clk_main[0], 0x110, 1, 0),
> + GATE(ZX297520V3_GMAC_AHB, "gmac_ahb", "AHB_wclk", 0x110, 2, 0),
[Severity: Medium]
Will this string mismatch result in gmac_ahb becoming an orphaned clock?
The Common Clock Framework resolves clock parents using exact case-sensitive
string matching. If the actual clock registered in zx297520v3_top_gates
is named "ahb_wclk", using "AHB_wclk" here will fail to link.
Even if an immediate system crash is averted because the parent clock is
marked with CLK_IS_CRITICAL and permanently enabled by the framework,
does this incorrect parent name break the clock tree topology and tracking
for the GMAC driver?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=8
^ permalink raw reply
* Re: [PATCH RFC v4 11/12] ARM: dts: zte: Declare zx297520v3 clock device nodes
From: sashiko-bot @ 2026-06-16 20:38 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260616-zx29clk-v4-11-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The `interrupts` property for the `uart2` device node was unintentionally deleted during the clock updates.
--
commit 59fdf05791fcf663705de912314c4a81bdabedae
Author: Stefan Dösinger <stefandoesinger@gmail.com>
ARM: dts: zte: Declare zx297520v3 clock device nodes
This commit introduces clock device nodes for zx297520v3, wires up the UART
clocks and resets, and replaces the placeholder uartclk node.
> diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
> index a16c30a164bb9..a2b6909e7434d 100644
> --- a/arch/arm/boot/dts/zte/zx297520v3.dtsi
> +++ b/arch/arm/boot/dts/zte/zx297520v3.dtsi
[ ... ]
> @@ -94,9 +166,9 @@ uart2: serial@140d000 {
> compatible = "arm,pl011", "arm,primecell";
> arm,primecell-periphid = <0x0018c011>;
> reg = <0x0140d000 0x1000>;
> - interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&uartclk>, <&uartclk>;
> + clocks = <&lspclk ZX297520V3_UART2_WCLK>, <&lspclk ZX297520V3_UART2_PCLK>;
[Severity: High]
Was the interrupts property unintentionally deleted here during the clock
updates for the uart2 node?
The PL011 UART driver requires the interrupts property per its device tree
schema binding to handle rx/tx operations. Removing this property breaks
device tree validation and prevents hardware interrupt assignment for uart2.
This could cause the driver to fail during probing or completely break
interrupt-driven serial communication, rendering uart2 unusable.
> clock-names = "uartclk", "apb_pclk";
> + resets = <&lspclk ZX297520V3_UART2_RESET>;
> status = "disabled";
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=11
^ permalink raw reply
* Re: [PATCH RFC v4 04/12] clk: zte: Add Clock registration infrastructure.
From: sashiko-bot @ 2026-06-16 20:38 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260616-zx29clk-v4-4-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Use-After-Free Vulnerability due to tying `struct auxiliary_device` memory lifetime to devres.
- [High] Invalid pointer dereference due to incorrect error checking of `device_node_to_regmap()`.
--
commit d5b040629c9146bc0aaf0162d247a5520ba7ab60
Author: Stefan Dösinger <stefandoesinger@gmail.com>
clk: zte: Add Clock registration infrastructure.
The next patches will implement the regmap clocks and PLL driver. The
actual hardware specific clock listing will live in a separate module.
> diff --git a/drivers/clk/zte/clk-zx.c b/drivers/clk/zte/clk-zx.c
> new file mode 100644
> index 0000000000000..6e21c4a82a46c
> --- /dev/null
> +++ b/drivers/clk/zte/clk-zx.c
> @@ -0,0 +1,157 @@
[ ... ]
> +static void zx_adev_release(struct device *dev)
> +{
> + dev_info(dev, "Aux device released.\n");
> +}
[Severity: High]
Does this release callback need to free the memory for the auxiliary device?
If struct auxiliary_device is allocated with devres, its memory is freed
when devres triggers during unbind. This might happen before this callback
is invoked if other subsystems hold a reference to the device, potentially
causing a use-after-free.
> +
> +static void zx_adev_unregister(void *data)
> +{
> + struct auxiliary_device *adev = data;
> +
> + auxiliary_device_delete(adev);
> + auxiliary_device_uninit(adev);
> +}
[Severity: High]
While this devres action decreases the device reference count, does devres
unconditionally free the adev memory right after this action returns? This
could lead to a use-after-free if lingering references are held.
> +
> +int zx_clk_probe(struct platform_device *pdev)
> +{
> + unsigned int public_clk_count = 1, highest_id = 0;
> + struct clk_hw_onecell_data *clocks;
> + struct device *dev = &pdev->dev;
> + const struct zx_clk_data *data;
> + struct auxiliary_device *adev;
> + struct regmap *map;
> + struct clk *clk;
> + unsigned int i;
> + int res;
> +
> + data = device_get_match_data(dev);
> + if (!data)
> + return -EINVAL;
> +
> + map = device_node_to_regmap(dev->of_node);
> + if (!map)
[Severity: High]
Since device_node_to_regmap() returns an ERR_PTR on failure rather than
NULL, should this check use IS_ERR(map)? Treating an error pointer as a
valid pointer could lead to a kernel panic when it is later dereferenced by
the clock framework.
> + return -EINVAL;
> +
[ ... ]
> + res = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get, clocks);
> + if (res)
> + return res;
> +
> + adev = devm_kzalloc(dev, sizeof(*adev), GFP_KERNEL);
[Severity: High]
Does allocating adev with devm_kzalloc() improperly tie the lifetime of
the embedded struct device to devres?
Since struct device is reference counted, could an external reference
outlive the devres unbind phase, resulting in a use-after-free when
zx_adev_release() is finally called on the freed memory?
> + if (!adev)
> + return -ENOMEM;
> +
> + adev->name = data->reset_auxdev_name;
> + adev->dev.parent = dev;
> + adev->dev.release = zx_adev_release;
> + adev->dev.of_node = dev->of_node;
> +
> + res = auxiliary_device_init(adev);
> + if (res)
> + return dev_err_probe(dev, res, "Failed to init aux dev %s\n", adev->name);
> +
> + res = auxiliary_device_add(adev);
> + if (res) {
> + auxiliary_device_uninit(adev);
> + return dev_err_probe(dev, res, "Failed to add aux dev %s\n", adev->name);
> + }
> +
> + return devm_add_action_or_reset(dev, zx_adev_unregister, adev);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH RFC v4 09/12] clk: zte: Introduce a driver for zx297520v3 LSP clocks
From: sashiko-bot @ 2026-06-16 20:38 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260616-zx29clk-v4-9-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] The static array `tdm_lsp_sel` is defined but never used, causing an unused-const-variable compiler warning.
- [Low] Multiple internal data structures contain a typo in their name: `zx297529v3_` instead of `zx297520v3_`.
--
commit 62ece0243f8a2453a83a724365246a3a8447995d
Author: Stefan Dösinger <stefandoesinger@gmail.com>
clk: zte: Introduce a driver for zx297520v3 LSP clocks
This commit introduces a clock driver for the "LSP" (low speed peripherals)
block of the ZTE ZX297520v3 SoC. It adds support for various peripherals
including UART, I2C, SPI, timers, and I2S.
> diff --git a/drivers/clk/zte/clk-zx297520v3.c b/drivers/clk/zte/clk-zx297520v3.c
> index d90aadf180269..26b05f2bf97ae 100644
> --- a/drivers/clk/zte/clk-zx297520v3.c
> +++ b/drivers/clk/zte/clk-zx297520v3.c
[ ... ]
> +static const char * const i2s_lsp_sel[] = {
> + "lsp_osc26m",
> + "lsp_dpll_d4",
> + "lsp_mpll_d6",
> + /* Unknown */
> +};
> +
> +static const char * const tdm_lsp_sel[] = {
> + "lsp_tdm_wclk",
> +};
[Severity: Low]
Is this array intended to be used somewhere? It appears to be defined but
never referenced in the file, which might trigger a -Wunused-const-variable
compiler warning.
> +
> +static const char * const spi_lsp_sel[] = {
> + "lsp_osc26m",
[ ... ]
> + GATE(ZX297520V3_TDM_WCLK, "tdm_wclk", "tdm_div", 0x50, 0, 0),
> + GATE(ZX297520V3_TDM_PCLK, "tdm_pclk", "lsp_pclk", 0x50, 1, 0),
> +};
> +
> +static const char * const zx297529v3_lsp_inputs[] = {
> + "mpll_d5", "mpll_d4", "mpll_d6", "mpll_d8", "mpll_d12",
> + "osc26m", "osc32k", "tdm_wclk", "dpll_d4"
> +};
> +
> +static const char * const zx297529v3_lsp_inputs_enable[] = {
> + "pclk"
> +};
[Severity: Low]
This isn't a bug, but should these arrays be named zx297520v3_lsp_inputs
instead of zx297529v3_lsp_inputs? It looks like there's a typo in the
numbering (9 instead of 0) compared to the other structures and the SoC
device name.
> +
> +static const struct zx_clk_data zx297520v3_lspclk_data = {
> + .inputs_enable = zx297529v3_lsp_inputs_enable,
> + .num_inputs_enable = ARRAY_SIZE(zx297529v3_lsp_inputs_enable),
> + .inputs = zx297529v3_lsp_inputs,
> + .num_inputs = ARRAY_SIZE(zx297529v3_lsp_inputs),
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=9
^ permalink raw reply
* Re: [PATCH RFC v4 06/12] clk: zte: Add regmap based clocks
From: sashiko-bot @ 2026-06-16 20:39 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260616-zx29clk-v4-6-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] In `zte_clk_regmap_gate_is_enabled`, the result of `regmap_read` is ignored and the read value is not properly masked, leading to uninitialized memory use and incorrect clock state reporting.
Pre-existing issues:
- [High] Allocating `struct auxiliary_device` with `devm_kzalloc` causes a Use-After-Free when the parent device is removed while external references still exist.
--
commit 4134682feec28075c68eddb683db94b9fb9b761a
Author: Stefan Dösinger <stefandoesinger@gmail.com>
clk: zte: Add regmap based clocks
This commit adds regmap based clocks for ZTE, simplifying the implementation
based on the meson clock regmap code.
> diff --git a/drivers/clk/zte/clk-regmap.c b/drivers/clk/zte/clk-regmap.c
> index 7908f1562f639..d9459417d17dd 100644
> --- a/drivers/clk/zte/clk-regmap.c
> +++ b/drivers/clk/zte/clk-regmap.c
[ ... ]
> +static int zte_clk_regmap_gate_is_enabled(struct clk_hw *hw)
> +{
> + struct zte_clk_regmap *clk = to_zte_clk_regmap(hw);
> + u32 val;
> +
> + regmap_read(clk->map, clk->reg, &val);
> + return !!val;
> +}
[Severity: High]
Does this code properly mask the specific gate bit? Since clock gates commonly
share registers, returning !!val might erroneously report this specific gate
as enabled whenever any other bit in the register is active, rather than using
BIT(clk->shift) to evaluate the correct bit.
Also, should the return value of regmap_read() be checked here? If the read
fails, val remains uninitialized, which could lead to evaluating stack
garbage.
[ ... ]
In drivers/clk/zte/clk-zx.c:
[Severity: High]
This is a pre-existing issue, but does allocating the auxiliary_device with
devm_kzalloc() in zx_clk_probe() create a use-after-free risk?
If the parent device is unbound, devres will automatically free the memory
for the auxiliary_device. However, if external references to the embedded
device still exist, the memory will be freed while it is still in use.
When the final reference is eventually dropped, the kernel will attempt to
call the release callback on the freed memory:
zx_adev_release() {
dev_info(dev, "Aux device released.\n");
}
Should the structure be allocated with kzalloc() instead, and explicitly
freed inside the release callback?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: hamoa: Fix xbl_tmp_buffer_mem size
From: Hans de Goede @ 2026-06-16 20:40 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, devicetree
In-Reply-To: <21a97c4b-293f-435c-91fe-ca7394b5a2b0@oss.qualcomm.com>
Hi konrad,
On 16-Jun-26 1:04 PM, Konrad Dybcio wrote:
> On 5/25/26 2:46 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 25-May-26 14:29, Konrad Dybcio wrote:
>>> On 5/25/26 1:47 PM, Hans de Goede wrote:
>>>> The EFI memtable (shown when booting with efi=debug) shows that the
>>>> xbl_tmp_buffer_mem region size is 0x1c0000 bytes large not 0xc00000 bytes:
>>>>
>>>> efi: 0x000082800000-0x0000829bffff [Reserved |
>>>> efi: 0x0000829c0000-0x000083efffff [Conventional|
>>>>
>>>> This fix aligns the size with the EFI reported size and makes /proc/iomem
>>>> correctly show mem blocks matching the EFI memmap:
>>>>
>>>> 82800000-829bffff : reserved
>>>> 829c0000-83efffff : System RAM
>>>>
>>>> Instead of:
>>>>
>>>> 82800000-833fffff : reserved
>>>> 83400000-83efffff : System RAM
>>>>
>>>> before this change
>>>>
>>>> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/hamoa.dtsi | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>>>> index de0f2346cb38..5a2e84365901 100644
>>>> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>>>> @@ -582,7 +582,7 @@ tz_stat_mem: tz-stat@82700000 {
>>>> };
>>>>
>>>> xbl_tmp_buffer_mem: xbl-tmp-buffer@82800000 {
>>>> - reg = <0x0 0x82800000 0x0 0xc00000>;
>>>> + reg = <0x0 0x82800000 0x0 0x1c0000>;
>>>
>>> FWIW the reference memory map shows a contiguous block of:
>>>
>>> 0x8280_0000 -> "no reclaim XBL scratch_buffer2"
>>> 0x829c_0000 -> "reclaimable XBL scratch_buffer"
>>> 0x83f0_0000-0x8400_0000 -> "no reclaim xbl scratch_buffer1"
>>
>> Thanks, so the first part here 0x8280_0000 - 0x829c_0000
>> aligns with the EFI reservation and with the dts reservation
>> after my patch.
>>
>> 0x829c_0000 - 0x83f0_0000 being reclaimable matches with
>> both EFI + the dts (old and new with a different start)
>> having this as usable RAM.
>>
>> The 0x83f0_0000-0x8400_0000 area seems to be marked as
>> reserved by neither EFI nor the current dts...
>>
>> With the first part of the reference memory map aligning
>> with what EFI shows, I think this patch is correct.
>>
>> I wonder if we should do anything about the 0x83f0_0000-0x8400_0000
>> range though ?
>
> The logs in your commit message suggest the UEFI ahd already taken care
> of reserving that bit
>
> Could you post the full output of `memmap` in uefi shell on your device?
I find just booting with efi=debug easier. Here is the EFI memmap as
seen/printed by Linux when booting with efi=debug:
[ 0.000000] efi: Processing EFI memory map:
[ 0.000000] efi: 0x000080800000-0x000080dfffff [Reserved | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000815a0000-0x0000819fffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000081a00000-0x000081a3ffff [Reserved | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000081d00000-0x000081dfffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000081f20000-0x000081f2ffff [Reserved | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000081f38000-0x0000826fffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000829c0000-0x000083efffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000084000000-0x000084afffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000085380000-0x0000866bffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000091480000-0x0000a67fffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000a6800000-0x0000a7f00fff [Boot Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000a7f01000-0x0000a7f01fff [Runtime Data|RUN| | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000a7f02000-0x0000a7f04fff [Boot Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000a7f05000-0x0000a7f0cfff [Runtime Data|RUN| | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000a7f0d000-0x0000a7f18fff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000a7f19000-0x0000a7ffffff [Boot Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000a8000000-0x0000bbc0ffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000bbc10000-0x0000c177ffff [Loader Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c1780000-0x0000c178afff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c178b000-0x0000c3933fff [Loader Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c3934000-0x0000c4c76fff [Loader Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c4c77000-0x0000c50aafff [Loader Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c50ab000-0x0000c54fcfff [Loader Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c54fd000-0x0000c5b12fff [Boot Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c5b13000-0x0000c5b21fff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c5b22000-0x0000c5b23fff [Loader Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c5b24000-0x0000c5b34fff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c5b35000-0x0000c62e3fff [Boot Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c62e4000-0x0000c62e4fff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c62e5000-0x0000c62edfff [Loader Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c62ee000-0x0000c65f6fff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c65f7000-0x0000c66d5fff [Loader Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000c66d6000-0x0000cf6ecfff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000cf6ed000-0x0000cfbb9fff [Boot Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000cfbba000-0x0000d0020fff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d0021000-0x0000d5135fff [Boot Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d5136000-0x0000d5136fff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d5137000-0x0000d5cedfff [Boot Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d5cee000-0x0000d5e7dfff [Runtime Code|RUN| | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d5e7e000-0x0000d6c8dfff [Runtime Data|RUN| | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d6c8e000-0x0000d6c9dfff [Reserved | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d6c9e000-0x0000d6d02fff [ACPI Mem NVS| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d6d03000-0x0000d6ddefff [ACPI Reclaim| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d6ddf000-0x0000d6ddffff [Boot Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d6de0000-0x0000d6e0ffff [Boot Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000d6e10000-0x0000d7ffffff [Boot Data | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000de5b0000-0x0000e46fffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000e69c0000-0x0000f84fffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000880000000-0x000cc236ffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000cc2370000-0x000cc6bdffff [Loader Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000cc6be0000-0x000ffdffffff [Conventional| | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000ffe000000-0x000fffffffff [Loader Code | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x00000c264000-0x00000c264fff [MMIO |RUN| | | | | | | | | | | | | |UC]
[ 0.000000] efi: 0x000081a40000-0x000081cfffff [Reserved | | | | | | | | | | | | | | |UC]
[ 0.000000] efi: 0x000081e00000-0x000081efffff [Reserved | | | | | | | | | | | | | | |UC]
[ 0.000000] efi: 0x000081f00000-0x000081f1ffff [Reserved | | | | | | | | | | | | | |WC| ]
[ 0.000000] efi: 0x000081f30000-0x000081f37fff [Reserved | | | | | | | | | | | | | |WC| ]
[ 0.000000] efi: 0x000082700000-0x0000827fffff [Reserved | | | | | | | | | | | | | | |UC]
[ 0.000000] efi: 0x000082800000-0x0000829bffff [Reserved | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000083f00000-0x000083ffffff [Reserved | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000084b00000-0x00008537ffff [Reserved | | | | | | | | | | | | | | |UC]
[ 0.000000] efi: 0x0000866c0000-0x00009137ffff [Reserved | | | | | | | | | | | | | | |UC]
[ 0.000000] efi: 0x0000e4700000-0x0000e47fffff [Reserved | | | | | | | | | | | | | |WC| ]
[ 0.000000] efi: 0x0000e4800000-0x0000e69bffff [Reserved | | | | | | | | |WP| | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000ff800000-0x0000ffffffff [Reserved | | | | | | | | | | | | | | |UC]
Let me know if you want the efi shell output instead of this.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH RFC v4 12/12] ARM: dts: zte: Add a syscon-reboot for zx297520v3 boards
From: sashiko-bot @ 2026-06-16 20:42 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260616-zx29clk-v4-12-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The `syscon-reboot` node is incorrectly defined at the root level using the explicitly deprecated `regmap` property.
--
commit afa99cf55be8056135e61b54fc719550822bda85
Author: Stefan Dösinger <stefandoesinger@gmail.com>
ARM: dts: zte: Add a syscon-reboot for zx297520v3 boards
This commit adds a syscon-reboot node to the zx297520v3 device tree. It allows
resetting the board by writing a value to a register exposed by the topclk
syscon.
> diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
> index a2b6909e7434d..013ece51c2a09 100644
> --- a/arch/arm/boot/dts/zte/zx297520v3.dtsi
> +++ b/arch/arm/boot/dts/zte/zx297520v3.dtsi
> @@ -33,6 +33,13 @@ osc32k: osc32k {
> #clock-cells = <0>;
> };
>
> + syscon-reboot {
> + compatible = "syscon-reboot";
> + regmap = <&topclk>;
[Severity: Low]
Does this use a deprecated property? According to the syscon-reboot device
tree bindings, the regmap property is explicitly deprecated.
The documented modern requirement is to define the syscon-reboot node as a
child of the system controller node. Introducing new nodes using deprecated
bindings can trigger make dtbs_check warnings.
To resolve this, the syscon-reboot node could be moved to be a child of topclk,
and topclk's compatible string could be updated to include "simple-mfd" to
ensure the driver core automatically probes the child node.
> + offset = <0x0>;
> + mask = <0x1>;
> + };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=12
^ permalink raw reply
* Re: [PATCH RFC v4 07/12] clk: zte: Introduce a driver for zx297520v3 top clocks
From: sashiko-bot @ 2026-06-16 20:43 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260616-zx29clk-v4-7-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] The 'dpll' and 'unknownpll' clocks are incorrectly configured with a single parent, leading to incorrect rate calculations and potential clock orphaning.
Pre-existing issues:
- [High] The `struct auxiliary_device` is allocated with `devm_kzalloc`, decoupling its memory lifecycle from its embedded kobject reference count.
- [High] The driver fails to properly validate the return value of `device_node_to_regmap()`, resulting in an invalid pointer dereference if the regmap cannot be obtained.
--
commit 41eccb5b69bddbf772e343c7bf76be8415a468bc
Author: Stefan Dösinger <stefandoesinger@gmail.com>
clk: zte: Introduce a driver for zx297520v3 top clocks
This commit introduces a new clock driver for the ZTE zx297520v3 SoC.
It adds support for the top clocks, including various PLLs, AHB, timers,
and USB controllers. The patch wires up the clock configuration structures
and registers the driver via the zx_clk_probe framework.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
> diff --git a/drivers/clk/zte/clk-zx297520v3.c b/drivers/clk/zte/clk-zx297520v3.c
> new file mode 100644
> index 0000000000000..50263bca6e087
> --- /dev/null
> +++ b/drivers/clk/zte/clk-zx297520v3.c
[ ... ]
> + /* Default value 0x4834902d. Feeds dpll. 46.08 MHz. Bit 25 can be set, so two parents are
> + * possible. It looks like both values select the 26 MHz oscillator though.
> + */
> + {
> + .id = 0,
> + .name = "unknownpll",
> + .parents = clk_main,
> + .num_parents = ARRAY_SIZE(clk_main),
[Severity: High]
The documentation block here states this PLL has two possible parents, but it
is restricted to the single parent in clk_main. Does hardcoding a single parent
cause an out-of-bounds index lookup if the hardware selects a parent index > 0?
> + .rate = 0,
> + .postdivs = unknownpll_postdivs,
> + .num_postdivs = ARRAY_SIZE(unknownpll_postdivs),
> + .reg = 0x100,
> + },
> +
> + /* The documentation says 491.52 MHz and measurement with the LSP TDM device supports this.
> + * The default value is 0x480c2011, but not all boot loaders set it up. To get to 491.52
> + * with these settings it needs a 23.04 MHz reference clock, which matches unknownpll_d2.
> + * If unknownpll is disabled, dpll loses its lock. We set the frequency on this PLL if we
> + * find it is not enabled by the boot loader.
> + *
> + * The proprietary LTE driver or coproc enables and disables it. TDM and I2S can use it.
> + *
> + * It accepts parent values 0, 1, 2 and 3. Parent 0 is unknownpll_d2. The others look like
> + * osc26m. With a parent != 0 dpll never loses its lock even when all other PLLs are off
> + * and the TDM counter register increases at a rate consistent with a 26.0/23.04 clock
> + * increase.
> + */
> + {
> + .id = ZX297520V3_DPLL,
> + .name = "dpll",
> + .parents = clk_main,
> + .num_parents = ARRAY_SIZE(clk_main),
[Severity: High]
Similarly, the comment states this PLL accepts parent values 0, 1, 2, and 3,
with parent 0 being unknownpll_d2. Since clk_main only contains osc26m, does
restricting this to a single parent cause the clock framework to erroneously
compute all DPLL-derived frequencies using 26 MHz instead of 23.04 MHz?
> + .rate = 491520000,
> + .postdivs = pll_postdivs,
> + .num_postdivs = ARRAY_SIZE(pll_postdivs),
> + .reg = 0x18,
> + },
[ ... ]
> +static struct platform_driver clk_zx297520v3 = {
> + .probe = zx_clk_probe,
[Severity: High]
This is a pre-existing issue, but I noticed two concerns in zx_clk_probe()
located in clk-zx.c:
First, zx_clk_probe() calls device_node_to_regmap(dev->of_node) which
returns an ERR_PTR on failure. The code checks for failure using:
if (!map)
return -EINVAL;
Since an error pointer is non-null, will this check evaluate to false and
allow an invalid pointer to be dereferenced later?
Second, zx_clk_probe() allocates the auxiliary device using devm_kzalloc().
When the driver unbinds, devres executes zx_adev_unregister() to uninitialize
the device before freeing the devm-managed memory.
If an external entity holds an active reference to the auxiliary device,
the reference count will remain non-zero. Could this result in a
use-after-free when the external reference is dropped and put_device() tries
to access the already-freed memory?
> + .driver = {
> + .name = "clk-zx297520v3",
> + .of_match_table = of_match_zx297520v3,
> + },
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=7
^ permalink raw reply
* Re: [PATCH RFC v4 05/12] clk: zte: Add zx PLL support infrastructure
From: sashiko-bot @ 2026-06-16 20:43 UTC (permalink / raw)
To: Stefan Dösinger; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260616-zx29clk-v4-5-ca994bd22e9d@gmail.com>
Thank you for your contribution! Sashiko AI review found 7 potential issue(s) to consider:
- [High] Calling `clk_set_rate` inside the `.init` callback fails silently or deterministically due to unestablished clock topology.
- [High] `zx29_pll_determine_rate` dereferences NULL for orphan clocks and ignores the dynamic rate propagation requested by the framework.
- [High] `zx29_pll_recalc_rate` returns a negative error code cast to a massive `unsigned long` on regmap read failure.
- [High] Use-After-Free of `struct auxiliary_device` due to `devm_kzalloc` allocation.
- [Medium] If `zx29_pll_prepare` fails to lock the PLL, it returns an error but leaves the hardware permanently enabled.
- [Low] Excessive `dev_warn` and `dev_err` logging during standard rate calculation queries will spam the kernel log.
- [Low] The `pll->dev` pointer is never initialized, causing all driver logging functions to use a NULL device.
--
commit 374687dfee47dfcb141c2ae13759333d3bad3cde
Author: Stefan Dösinger <stefandoesinger@gmail.com>
clk: zte: Add zx PLL support infrastructure
This patch implements the core PLL infrastructure for ZTE zx platforms.
It provides functions for clock calculation, setting parent rates, and
registering the PLL operations with the Common Clock Framework.
> diff --git a/drivers/clk/zte/pll-zx.c b/drivers/clk/zte/pll-zx.c
> index c0475d5441fbc..f077b6b56841e 100644
> --- a/drivers/clk/zte/pll-zx.c
> +++ b/drivers/clk/zte/pll-zx.c
[ ... ]
> +static int zx29_pll_prepare(struct clk_hw *hw)
> +{
> + struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
> + u32 val;
> + int res;
> +
> + res = regmap_clear_bits(pll->map, pll->reg, ZX29_PLL_DISABLE);
> + if (res < 0)
> + return res;
> +
> + /* Lock duration is usually between 300us to 500us */
> + res = regmap_read_poll_timeout(pll->map, pll->reg, val, val & ZX29_PLL_LOCKED, 50, 2000);
> + dev_dbg(pll->dev, "%s: Enable result %u val 0x%08x\n", clk_hw_get_name(&pll->hw), res, val);
> + return res;
[Severity: Medium]
If regmap_read_poll_timeout() times out waiting for the lock bit, does this
leave the hardware permanently enabled? The ZX29_PLL_DISABLE bit is cleared
above, but it does not appear to be restored on this error path. The core
will treat the clock as unprepared and won't call the unprepare operation,
which could leak power and leave the hardware in an unlocked state.
> +}
[ ... ]
> +static unsigned long zx29_pll_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
> +{
> + struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
> + u32 val;
> + int res;
> +
> + res = regmap_read(pll->map, pll->reg, &val);
> + if (res < 0)
> + return res;
[Severity: High]
Could this return a massive fake clock rate? Because this function returns
unsigned long, if regmap_read() fails and returns a negative error code
like -EINVAL, the negative integer gets implicitly cast to a very large
unsigned value. Should this return 0 on failure to prevent corrupting rate
calculations across the clock tree?
> +
> + return zx29_pll_get_rate(pll, parent_rate, val);
> +}
[ ... ]
> +static u32 zx29_pll_calc_values(const struct zx29_clk_pll *pll, unsigned long parent_rate,
> + unsigned long rate)
> +{
[ ... ]
> +search_done:
> +
> + if (!postdiv1) {
> + dev_err(pll->dev, "Did not find a setting for %lu Hz, parent %lu Hz\n",
> + rate, parent_rate);
> + return 0;
> + }
[Severity: Low]
Will this dev_err() flood the kernel log with false positives? The Common
Clock Framework frequently performs exploratory rate queries during normal
tree traversal, so unachievable out-of-bounds rates might be a normal part
of clock negotiation rather than a true device error.
> +
> + dev_dbg(pll->dev, "%s: parent rate %lu\n", name, parent_rate);
[ ... ]
> +static int zx29_pll_determine_rate(struct clk_hw *hw, struct clk_rate_request *req)
> +{
> + struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
> + unsigned long new_rate, parent_rate = clk_hw_get_rate(clk_hw_get_parent(&pll->hw));
[Severity: High]
Is there a risk of a NULL pointer dereference here? If the clock is an
orphan and has no parent attached yet, clk_hw_get_parent() returns NULL.
Passing NULL into clk_hw_get_rate() will panic when it dereferences hw->core.
Also, shouldn't this use req->best_parent_rate instead to properly support
dynamic rate propagation?
> + u32 setting;
> +
> + setting = zx29_pll_calc_values(pll, parent_rate, req->rate);
> + if (!setting)
> + return -EINVAL;
> +
> + new_rate = zx29_pll_get_rate(pll, parent_rate, setting);
> + if (new_rate != req->rate) {
> + dev_warn(pll->dev, "Did not find an exact match. Want %lu, got %lu\n",
> + req->rate, new_rate);
[Severity: Low]
Is it safe to log a warning here? The framework routinely requests inexact
rates during clock rounding operations, so this could also cause excessive
console spam during normal execution.
> + req->rate = new_rate;
> + }
> +
> + return 0;
> +}
[ ... ]
> +static int zx29_pll_init(struct clk_hw *hw)
> +{
[ ... ]
> + if (regmap_test_bits(pll->map, pll->reg, ZX29_PLL_DISABLE) > 0) {
> + if (pll->init_rate) {
> + dev_dbg(pll->dev, "%s: Setting to %lu Hz\n", name, pll->init_rate);
> + res = clk_set_rate(pll->hw.clk, pll->init_rate);
[Severity: High]
Does this rate change silently fail? At the time the init callback runs
during device registration, the clock topology is not fully established and
pll->hw.clk is often NULL. Calling clk_set_rate() with a NULL clock will
simply return 0 without applying the expected initial rate to the hardware.
> + if (res) {
> + dev_err(pll->dev, "%s: Failed to set rate.\n", name);
> + return res;
> + }
> + }
[ ... ]
> +int zx_clk_register_plls(struct device *dev, struct regmap *regmap,
> + const struct zx_pll_desc *desc, unsigned int num,
> + struct clk_hw_onecell_data *clocks)
> +{
> + struct zx29_clk_pll *pll;
> + unsigned int i, f;
> + struct clk_hw *hw;
> + char plldiv[32];
> + int res;
> +
> + for (i = 0; i < num; ++i) {
> + struct clk_init_data init = {};
> +
> + pll = devm_kzalloc(dev, sizeof(*pll), GFP_KERNEL);
> + if (!pll)
> + return -ENOMEM;
> +
> + init.name = desc[i].name;
> + init.ops = &zx29_pll_ops;
[Severity: Low]
Are we missing an assignment to pll->dev here? Since devm_kzalloc() zeroes
the memory and the dev pointer is never explicitly mapped to pll->dev,
won't all subsequent calls to dev_dbg(), dev_err(), and dev_warn() end up
using a NULL device pointer and breaking debug message filtering?
> + init.parent_names = desc[i].parents;
> + init.num_parents = desc[i].num_parents;
[ ... ]
While reviewing the broader changes in this driver series, I noticed a
regression in zx_clk_probe() inside drivers/clk/zte/clk-zx.c:
[Severity: High]
Can the use of devm_kzalloc() to allocate the auxiliary device (adev) lead
to a Use-After-Free? The devm framework might abruptly free the memory
during unbind, breaking standard device lifetime rules. If another
subsystem is holding a reference to the device, this memory will be freed
out from under it before the core drops the final reference and calls the
proper release callback.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: iio: adc: add ti,ads122c14
From: Conor Dooley @ 2026-06-16 20:50 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kurt Borja, Nguyen Minh Tien,
linux-iio, devicetree, linux-kernel
In-Reply-To: <4bc99611-4bf1-4797-ba31-6f1d7dee1e1e@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 4761 bytes --]
On Tue, Jun 16, 2026 at 02:54:55PM -0500, David Lechner wrote:
> On 6/16/26 11:07 AM, Conor Dooley wrote:
> > On Mon, Jun 15, 2026 at 04:59:59PM -0500, David Lechner (TI) wrote:
> >> Add new bindings for ti,ads122c14 and similar devices.
> >>
> >> This is an ADC that is primarily intended for use with temperature
> >> sensors. There are a few unusual properties because of this. In
> >> particular, the reference voltage source and current output requirements
> >> can be different for each measurement, so these are included in the
> >> channel bindings.
> >>
> >> The REFP/REFN reference voltage is usually just connected to a resistor
> >> that is being driven by the ADC's current outputs, so there is special
> >> property for this case rather than requiring a regulator to be defined
> >> to represent that.
> >>
> >> ti,vref-source is reused from ti,tlv320adcx140.yaml (otherwise might
> >> have preferred an enum of strings).
> >>
> >> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
> >> ---
> >> .../devicetree/bindings/iio/adc/ti,ads112c14.yaml | 224 +++++++++++++++++++++
> >> MAINTAINERS | 7 +
> >> include/dt-bindings/iio/adc/ti,ads112c14.h | 11 +
> >> 3 files changed, 242 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> >> new file mode 100644
> >> index 000000000000..dc7f37cad772
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> >> @@ -0,0 +1,224 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/iio/adc/ti,ads112c14.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Texas Instruments' ADS112C14 and similar ADC chips
> >> +
> >> +description: |
> >> + Supports the following Texas Instruments' ADC chips:
> >> + - ADS112C14 (16-bit)
> >> + - ADS122C14 (24-bit)
> >> +
> >> + https://www.ti.com/lit/ds/symlink/ads122c14.pdf
> >> +
> >> + These chips are primarily designed for use with temperature sensors such as
> >> + RTDs and thermocouples. The channel bindings reflect this in that each channel
> >> + represents the conditions required to make a measurement rather than strictly
> >> + just the physical input channels.
> >> +
> >> +maintainers:
> >> + - David Lechner <dlechner@baylibre.com>
> >> +
> >> +unevaluatedProperties: false
> >
> > Weird positioning of this.
>
> IIRC, Rob asked that I do it in this order on another binding a while
> ago (the reasoning being that it was too far away from properties:
> otherwise), so I've done it like this on a few bindings now. It doesn't
> make much difference to me though.
Too far away because it refers to properties in the "main" node, but
appears conventionally after a rake of properties belonging to the
children?
>
> >
> >> +
> >> +properties:
> >> + compatible:
> >> + enum:
> >> + - ti,ads112c14
> >> + - ti,ads122c14
> >> +
> >> + reg:
> >> + items:
> >> + - minimum: 0x40
> >> + maximum: 0x47
> >> +
> >> + clocks:
> >> + maxItems: 1
> >> + description: Optional external clock connected to GPIO3 pin.
> >> +
> >> + avdd-supply: true
> >> + dvdd-supply: true
> >> +
> >> + refp-supply: true
> >> + refn-supply: true
> >> +
> >> + refp-refn-resistor-ohms:
> >
> > Missing prefix here and elsewhere.
>
> I thought we didn't need a prefix when using standard units.
You don't need a ref to a typedef, but you still need a prefix if it is
some random resistor that's specific to this device etc.
> >> + ti,vref-source:
> >> + description: |
> >> + Indicates the source for the reference voltage for this channel.
> >> + 0 - Internal 2.5V reference
> >> + 1 - Internal 1.25V reference
> >> + 2 - External reference (REFP-REFN)
> >> + 3 - AVDD as reference
> >
> > My usual complaint here about things you have to make macros for, could
> > these just be strings from the get-go?
>
> As in the commit message, this is an existing property name, so I didn't want
> to change the type. But I agree that strings are better for this kind of thing
> so perhaps I should just use a different property name instead so we can do
> it better.
I wouldn't get too hung up on that sound adc, particularly since it
seems to have been added without an ack from a devicetree maintainer.
If you were trying to share a driver or something then I'd consider it
differently but these seem to be unrelated devices.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: iio: adc: add ti,ads122c14
From: David Lechner @ 2026-06-16 21:04 UTC (permalink / raw)
To: Conor Dooley
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kurt Borja, Nguyen Minh Tien,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20260616-livable-muster-d268af11dcc8@spud>
On 6/16/26 3:50 PM, Conor Dooley wrote:
> On Tue, Jun 16, 2026 at 02:54:55PM -0500, David Lechner wrote:
>> On 6/16/26 11:07 AM, Conor Dooley wrote:
>>> On Mon, Jun 15, 2026 at 04:59:59PM -0500, David Lechner (TI) wrote:
>>>> Add new bindings for ti,ads122c14 and similar devices.
>>>>
>>>> This is an ADC that is primarily intended for use with temperature
>>>> sensors. There are a few unusual properties because of this. In
>>>> particular, the reference voltage source and current output requirements
>>>> can be different for each measurement, so these are included in the
>>>> channel bindings.
>>>>
>>>> The REFP/REFN reference voltage is usually just connected to a resistor
>>>> that is being driven by the ADC's current outputs, so there is special
>>>> property for this case rather than requiring a regulator to be defined
>>>> to represent that.
>>>>
>>>> ti,vref-source is reused from ti,tlv320adcx140.yaml (otherwise might
>>>> have preferred an enum of strings).
>>>>
>>>> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
>>>> ---
>>>> .../devicetree/bindings/iio/adc/ti,ads112c14.yaml | 224 +++++++++++++++++++++
>>>> MAINTAINERS | 7 +
>>>> include/dt-bindings/iio/adc/ti,ads112c14.h | 11 +
>>>> 3 files changed, 242 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
>>>> new file mode 100644
>>>> index 000000000000..dc7f37cad772
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
>>>> @@ -0,0 +1,224 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/iio/adc/ti,ads112c14.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Texas Instruments' ADS112C14 and similar ADC chips
>>>> +
>>>> +description: |
>>>> + Supports the following Texas Instruments' ADC chips:
>>>> + - ADS112C14 (16-bit)
>>>> + - ADS122C14 (24-bit)
>>>> +
>>>> + https://www.ti.com/lit/ds/symlink/ads122c14.pdf
>>>> +
>>>> + These chips are primarily designed for use with temperature sensors such as
>>>> + RTDs and thermocouples. The channel bindings reflect this in that each channel
>>>> + represents the conditions required to make a measurement rather than strictly
>>>> + just the physical input channels.
>>>> +
>>>> +maintainers:
>>>> + - David Lechner <dlechner@baylibre.com>
>>>> +
>>>> +unevaluatedProperties: false
>>>
>>> Weird positioning of this.
>>
>> IIRC, Rob asked that I do it in this order on another binding a while
>> ago (the reasoning being that it was too far away from properties:
>> otherwise), so I've done it like this on a few bindings now. It doesn't
>> make much difference to me though.
>
> Too far away because it refers to properties in the "main" node, but
> appears conventionally after a rake of properties belonging to the
> children?
>
I found the original request:
https://lore.kernel.org/all/20241022204312.GA1524310-robh@kernel.org/
"Easier to read the indented cases that way."
Reading it again, it sounds like the request was just for the indented
additionalProperties to be moved.
^ permalink raw reply
* Re: [PATCH v2 0/2] ASoC: simple-card-utils: support system-clock-id DT property
From: Wang, Sen @ 2026-06-16 21:14 UTC (permalink / raw)
To: Andreas Kemnade
Cc: Mark Brown, Kuninori Morimoto, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
linux-sound, devicetree, linux-kernel
In-Reply-To: <20260607163845.652bcc73@kemnade.info>
On 6/7/2026 9:38 AM, Andreas Kemnade wrote:
> Hi,
>
> On Fri, 15 May 2026 11:13:56 -0500
> Sen Wang <sen@ti.com> wrote:
>
>> Adding an optional, u32 system-clock-id DT property into the generic machine
>> driver so clocking topology info can be exposed in DT.
>>
> while having this binding would solve some of my problem. I am wondering
> whether is the right approach. What about modelling the clocks involved
> using the clk framework, so let some more codecs/dais be clock provider.
> So things can be configured that way.
> E.g. tlv320aic32x4-clk.c
>
> Same for set_div() which is also unavailable in these generic cards.
>
Hi Andreas, just got back from break, sorry for the delayed message.
I agree with you, in retrospect, this patch is indeed a hasty patch that
only covers up the legacy clk-id scheme rather than adapting the modern
clk framework.
Modeling individual cpu/codec DAI clocks does seem to be the way to go,
not the one patch fix-all solution I'd hope for, but I still wanted to
see if I can reuse the existing CCF patterns for drivers with
clk-id/div-id as an alternative.
Best,
Sen Wang
^ permalink raw reply
* Re: [PATCH v8 4/7] input: keyboard: Add driver for ASUS Transformer dock multimedia keys
From: Dmitry Torokhov @ 2026-06-16 21:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Pavel Machek, Sebastian Reichel, Ion Agorria,
Michał Mirosław, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <CAPVz0n2fnM6zYtP9bCtsY9mcLdce_R+1UPmMo0o4JRgjnhuhKA@mail.gmail.com>
On Tue, Jun 16, 2026 at 09:25:25AM +0300, Svyatoslav Ryhel wrote:
> вт, 16 черв. 2026 р. о 07:26 Dmitry Torokhov <dmitry.torokhov@gmail.com> пише:
> >
> > Hi Svyatoslav,
> >
> > On Thu, May 28, 2026 at 08:32:00AM +0300, Svyatoslav Ryhel wrote:
> > > From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > >
> > > Add support for multimedia top button row of ASUS Transformer's Mobile
> > > Dock keyboard. Driver is made that function keys (F1-F12) are used by
> > > default which suits average Linux use better and with pressing
> > > ScreenLock + AltGr function keys layout is switched to multimedia keys.
> > > Since this only modifies codes sent by asus-ec-keys it doesn't affect
> > > normal keyboards at all.
> >
> > I think using input handler to intercept ScreenLock + AltGr is quite
> > awkward. I think this also passes the original key events (unless you
> > make it a filter not a regular handler).
> >
> > I do not see benefit for reacting to AltGr+ScreenLock on other keyboards
> > to activate the special mode on this one. So given the fact that you
> > already mange the data stream when you split it into "serio" ports,
> > maybe just intercept this key combo right there and create the input
> > device and signal input events right there?
> >
>
> Though it seems awkward at a first glance, media keys are integrated
> with a standard keyboard in a detachable dock. It is highly unlikely
> that media keys will be used with a different keyboard then the one
> that is integrated with dock. Additionally, the ScreenLock key has a
> code specific to this driver and is not in general use, so even if any
> standard keyboard has AltGr but none has ScreenLock specific to this
> driver except the dock itself. Handler is also set as observer so it
> should not interfere with work of other input devices.
I am not concerned about it interfering with other drivers, I am
concerned about it unnecessarily connecting to unrelated devices
(anything that declares EV_KEY).
Again, I think having input handler is not appropriate here. I would
fold this patch into the patch that introduces the 2 serio ports,
enhanced the data stream analysis to detect your key combo, and then
report through this new input device. You do not need to have the round
trip through atkbd and the new input handler for this.
Thanks.
--
Dmitry
^ permalink raw reply
* [GIT PULL] Devicetree updates for v7.2
From: Rob Herring @ 2026-06-16 21:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: Saravana Kannan, Krzysztof Kozlowski, Conor Dooley, linux-kernel,
devicetree
Linus,
Please pull DT updates for 7.2.
Rob
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/robh/linux.git tags/devicetree-for-7.2
for you to fetch changes up to faa25db0892135c97a0bfd48d79173db0dd25ab2:
dt-bindings: interrupt-controller: qcom,pdc: Add Maili compatible string (2026-06-16 08:53:12 -0500)
----------------------------------------------------------------
Devicetree updates for v7.2:
DT core:
- Add support for handling multiple cells in "iommu-map" entries.
- Support only 1 entry in /reserved-memory "reg" entries. Support for
more than 1 entry has been broken.
- Fix a UAF on alloc_reserved_mem_array() failure
- Make "ibm,phandle" handling logic specific to PPC
- Use memcpy() instead of strcpy() for known length strings
- Ensure __of_find_n_match_cpu_property() handles malformed "reg"
entries
- Add various checks that expected strings are strings before accessing
them
- Drop redundant memset() when unflattening DT
DT bindings:
- Add a DTS style checker. Currently hooked up to dt_binding_check to
check examples.
- Convert st,nomadik platform, ti,omap-dmm, and ti,irq-crossbar
bindings to DT schema
- Add Apple System Management Controller hwmon, Qualcomm Hamoa Embedded
Controller, Qualcomm IPQ6018 PWM controller, fsl,mc1323, Samsung
SOFEF01-M DDIC panel, Freescale i.MX53 Television Encoder, Samsung S2M
series PMIC extcon, and MT6365 PMIC AuxADC schemas
- Extend bindings for QCom Maili and Nord PDC, QCom Hali fastrpc,
qcom,eliza-imem, qcom,oryon-1-5 CPU, and MT6365 Keys
- Consolidate "sram" property definitions
- Fix constraints on "nvmem" properties which only contain phandles and
no arg cells
- Another pass of fixing "phandle-array" constraints
- Add Gira vendor prefix
----------------------------------------------------------------
Alexander Koskovich (1):
dt-bindings: sram: Document qcom,eliza-imem
Andrew Rembrandt (1):
dt-bindings: arm: st,nomadik: Convert to DT schema
Bhargav Joshi (2):
dt-bindings: soc: ti,omap-dmm: Convert to DT schema
dt-bindings: interrupt-controller: ti,irq-crossbar: Convert to DT schema
Charan Teja Kalla (1):
of: Factor arguments passed to of_map_id() into a struct
Daniel Golle (6):
dt-bindings: misc: fsl,qoriq-mc: drop trailing whitespace
dt-bindings: drop tab characters from DTS examples
dt-bindings: add DTS style checker
scripts/jobserver-exec: propagate child exit status
dt-bindings: wire style checker into dt_binding_check
dt-bindings: add self-test fixtures for style checker
Daniel Palmer (1):
drivers/of: fdt: Make ibm,phandle logic only happen on pseries
David Laight (1):
drivers/of/overlay: Use memcpy() to copy known length strings
Devi Priya (1):
dt-bindings: pwm: add IPQ6018 binding
Frank Li (3):
dt-bindings: display: imx: add deprecated property 'port' and 'display-timings'
dt-bindings: display: imx: Add television encoder (TVE) for imx53
dt-bindings: trivial-devices: add fsl,mc1323
Geert Uytterhoeven (2):
dt-bindings: interrupt-controller: renesas,r9a09g077-icu: Fix reg size in example
dt-bindings: cache: l2c2x0: Add missing power-domains
James Calligeros (1):
dt-bindings: hwmon: Add Apple System Management Controller hwmon schema
Kaustabh Chakraborty (1):
dt-bindings: extcon: document Samsung S2M series PMIC extcon device
Konrad Dybcio (1):
dt-bindings: nvmem: consumer: Make 'nvmem' an array of one-item entries
Krzysztof Kozlowski (4):
docs: dt: writing-bindings: Extend compatible fallbacks guideline
docs: dt: submitting-patches: Remove possible confusion of combining DTS
media: dt-bindings: mediatek: Constrain iommus
docs: dt: writing-schema: Clarify what is required in a schema
Louis-Alexis Eyraud (2):
dt-bindings: input: mediatek,pmic-keys: Add MT6365 support
dt-bindings: iio: adc: mt6359: Add MT6365 PMIC AuxADC
Lucas Stach (1):
dt-bindings: vendor-prefixes: add Gira
Marijn Suijten (1):
dt-bindings: display: panel: Describe Samsung SOFEF01-M DDIC
Maya Matuszczyk (1):
dt-bindings: embedded-controller: Add Qualcomm reference device EC description
Mukesh Ojha (1):
dt-bindings: misc: qcom,fastrpc: Add compatible for Hawi SoC
Pengpeng Hou (2):
drivers/of: validate live-tree string properties before string use
drivers/of: validate status properties in reconfig state changes
Rob Herring (Arm) (2):
dt-bindings: Fix phandle-array constraints, again
dt-bindings: Consolidate "sram" property definition
Robin Murphy (2):
of: Add convenience wrappers for of_map_id()
of: Respect #{iommu,msi}-cells in maps
Sang-Heon Jeon (1):
of/fdt: remove redundant memset in __unflatten_device_tree()
Sergey Shtylyov (1):
of: cpu: add check in __of_find_n_match_cpu_property()
Shawn Guo (2):
dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5
dt-bindings: interrupt-controller: Document PDC for Qualcomm Nord SoC
Svyatoslav Ryhel (2):
dt-bindings: display: bridge: ssd2825: inherit dsi-controller properties
dt-bindings: media: mt9m114: document common video device properties
Wandun Chen (4):
of: reserved_mem: only support one <base size> entry in reg property
of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array() fails
of: reserved_mem: handle NULL name in of_reserved_mem_lookup()
of: reserved_mem: zero total_reserved_mem_cnt if no valid /reserved-memory entry
Yijie Yang (1):
dt-bindings: interrupt-controller: qcom,pdc: Add Maili compatible string
bui duc phuc (1):
dt-bindings: Remove the redundant 'type: boolean'
Documentation/devicetree/bindings/Makefile | 19 +-
Documentation/devicetree/bindings/arm/cpus.yaml | 1 +
.../devicetree/bindings/arm/omap/crossbar.txt | 55 -
Documentation/devicetree/bindings/arm/omap/dmm.txt | 22 -
.../devicetree/bindings/arm/st,nomadik.yaml | 23 +
.../devicetree/bindings/arm/ste-nomadik.txt | 38 -
.../devicetree/bindings/cache/l2c2x0.yaml | 3 +
.../bindings/display/bridge/solomon,ssd2825.yaml | 3 +-
.../display/imx/fsl,imx-parallel-display.yaml | 11 +
.../bindings/display/imx/fsl,imx53-tve.yaml | 104 ++
.../imx/fsl,imx8qxp-dc-command-sequencer.yaml | 2 +-
.../bindings/display/mediatek/mediatek,ovl-2l.yaml | 5 +-
.../bindings/display/mediatek/mediatek,ovl.yaml | 5 +-
.../bindings/display/mediatek/mediatek,rdma.yaml | 4 +-
.../bindings/display/mediatek/mediatek,wdma.yaml | 4 +-
.../devicetree/bindings/display/msm/gpu.yaml | 6 +-
.../bindings/display/panel/samsung,sofef01-m.yaml | 94 ++
.../display/rockchip/rockchip,rk3399-cdn-dp.yaml | 2 +
.../devicetree/bindings/dma/stericsson,dma40.yaml | 8 +-
.../embedded-controller/qcom,hamoa-crd-ec.yaml | 56 +
.../bindings/extcon/samsung,s2mu005-muic.yaml | 40 +
.../devicetree/bindings/hwmon/apple,smc-hwmon.yaml | 85 ++
.../devicetree/bindings/i2c/i2c-demux-pinctrl.yaml | 1 +
.../bindings/i2c/opencores,i2c-ocores.yaml | 8 +-
.../bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 17 +-
.../bindings/iio/adc/st,spear600-adc.yaml | 2 +-
.../devicetree/bindings/input/atmel,maxtouch.yaml | 3 +-
.../devicetree/bindings/input/imx-keypad.yaml | 32 +-
.../bindings/input/mediatek,pmic-keys.yaml | 21 +-
.../bindings/input/microchip,cap11xx.yaml | 12 +-
.../bindings/input/touchscreen/ti,ads7843.yaml | 4 +-
.../bindings/interrupt-controller/qcom,pdc.yaml | 2 +
.../renesas,r9a09g077-icu.yaml | 2 +-
.../interrupt-controller/ti,irq-crossbar.yaml | 96 ++
.../devicetree/bindings/leds/leds-lp55xx.yaml | 2 +-
.../devicetree/bindings/media/cnm,wave521c.yaml | 2 +-
.../bindings/media/i2c/onnn,mt9m114.yaml | 5 +-
.../bindings/media/mediatek,vcodec-encoder.yaml | 2 +-
.../media/mediatek,vcodec-subdev-decoder.yaml | 2 +-
.../devicetree/bindings/media/nxp,imx8-jpeg.yaml | 6 +-
.../devicetree/bindings/media/rockchip,vdec.yaml | 5 +-
.../devicetree/bindings/media/st,stm32-dcmi.yaml | 6 +-
.../memory-controllers/nvidia,tegra20-mc.yaml | 4 +-
.../memory-controllers/samsung,exynos5422-dmc.yaml | 2 +-
.../devicetree/bindings/mfd/apple,smc.yaml | 36 +
.../devicetree/bindings/mfd/rockchip,rk816.yaml | 3 +-
.../devicetree/bindings/misc/fsl,qoriq-mc.yaml | 2 +-
.../devicetree/bindings/misc/qcom,fastrpc.yaml | 1 +
.../mmc/hisilicon,hi3798cv200-dw-mshc.yaml | 7 +-
.../devicetree/bindings/net/mediatek,net.yaml | 3 +-
.../devicetree/bindings/net/qcom,bam-dmux.yaml | 12 +
.../devicetree/bindings/net/qcom,ipa.yaml | 12 +
.../devicetree/bindings/net/ti,icssg-prueth.yaml | 2 +-
.../devicetree/bindings/net/ti,icssm-prueth.yaml | 2 +-
.../bindings/net/wireless/qcom,ath10k.yaml | 8 +-
.../bindings/net/wireless/qcom,ath11k.yaml | 8 +-
.../bindings/net/wireless/qcom,ipq5332-wifi.yaml | 18 +
.../devicetree/bindings/nvmem/nvmem-consumer.yaml | 2 +
.../bindings/pci/mediatek-pcie-mt7623.yaml | 4 +-
.../bindings/pci/samsung,exynos-pcie.yaml | 2 +-
.../devicetree/bindings/pci/toshiba,tc9563.yaml | 5 +-
.../devicetree/bindings/pwm/qcom,ipq6018-pwm.yaml | 51 +
.../remoteproc/amlogic,meson-mx-ao-arc.yaml | 7 +-
.../bindings/remoteproc/qcom,msm8916-mss-pil.yaml | 6 +
.../bindings/remoteproc/qcom,msm8996-mss-pil.yaml | 7 +
.../bindings/remoteproc/qcom,pas-common.yaml | 6 +
.../bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml | 6 +
.../bindings/remoteproc/qcom,sc7180-mss-pil.yaml | 6 +
.../bindings/remoteproc/qcom,sc7280-adsp-pil.yaml | 6 +
.../bindings/remoteproc/qcom,sc7280-mss-pil.yaml | 6 +
.../bindings/remoteproc/qcom,sc7280-wpss-pil.yaml | 6 +
.../bindings/remoteproc/qcom,sdm845-adsp-pil.yaml | 6 +
.../bindings/remoteproc/qcom,wcnss-pil.yaml | 6 +
.../bindings/remoteproc/ti,k3-dsp-rproc.yaml | 8 -
.../bindings/remoteproc/ti,k3-r5f-rproc.yaml | 8 -
.../bindings/remoteproc/xlnx,zynqmp-r5fss.yaml | 9 +-
.../devicetree/bindings/soc/ti/ti,omap-dmm.yaml | 53 +
.../bindings/sound/davinci-mcasp-audio.yaml | 4 +-
.../devicetree/bindings/sound/samsung,tm2.yaml | 8 +-
.../devicetree/bindings/sound/simple-card.yaml | 6 +-
.../devicetree/bindings/spi/st,stm32-spi.yaml | 10 +-
.../devicetree/bindings/spi/st,stm32mp25-ospi.yaml | 5 +-
.../devicetree/bindings/sram/sram-consumer.yaml | 26 +
Documentation/devicetree/bindings/sram/sram.yaml | 1 +
.../devicetree/bindings/submitting-patches.rst | 7 +-
.../devicetree/bindings/trivial-devices.yaml | 2 +
.../bindings/usb/chipidea,usb2-common.yaml | 2 +
.../devicetree/bindings/usb/ci-hdrc-usb2.yaml | 7 +-
.../devicetree/bindings/usb/richtek,rt1711h.yaml | 3 +-
.../devicetree/bindings/usb/ti,j721e-usb.yaml | 8 +-
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
.../devicetree/bindings/writing-bindings.rst | 12 +-
.../devicetree/bindings/writing-schema.rst | 2 +-
MAINTAINERS | 8 +-
Makefile | 6 +
drivers/cdx/cdx_msi.c | 10 +-
drivers/iommu/of_iommu.c | 6 +-
drivers/irqchip/irq-gic-its-msi-parent.c | 10 +-
drivers/of/base.c | 270 ++++-
drivers/of/cpu.c | 2 +-
drivers/of/dynamic.c | 20 +-
drivers/of/fdt.c | 4 +-
drivers/of/irq.c | 32 +-
drivers/of/of_reserved_mem.c | 79 +-
drivers/of/overlay.c | 4 +-
drivers/of/property.c | 27 +-
drivers/of/unittest.c | 32 +
drivers/pci/controller/dwc/pci-imx6.c | 55 +-
drivers/pci/controller/pcie-apple.c | 6 +-
drivers/xen/grant-dma-ops.c | 5 +-
include/linux/of.h | 32 +-
scripts/dtc/dt-check-style | 1192 ++++++++++++++++++++
scripts/dtc/dt-style-selftest/bad/dts-spaces.dts | 12 +
.../bad/yaml-child-addr-order.yaml | 41 +
.../bad/yaml-child-name-order.yaml | 37 +
.../dtc/dt-style-selftest/bad/yaml-cont-align.yaml | 30 +
.../bad/yaml-digit-node-order.yaml | 37 +
.../dtc/dt-style-selftest/bad/yaml-hex-case.yaml | 29 +
.../dt-style-selftest/bad/yaml-indent-strict.yaml | 29 +
.../bad/yaml-label-in-string.yaml | 30 +
.../dt-style-selftest/bad/yaml-line-length.yaml | 29 +
.../dt-style-selftest/bad/yaml-mixed-indent.yaml | 29 +
.../dt-style-selftest/bad/yaml-multi-close.yaml | 35 +
.../dtc/dt-style-selftest/bad/yaml-node-close.yaml | 31 +
.../dtc/dt-style-selftest/bad/yaml-prop-order.yaml | 29 +
.../dt-style-selftest/bad/yaml-prop-pairing.yaml | 33 +
.../dt-style-selftest/bad/yaml-required-blank.yaml | 33 +
scripts/dtc/dt-style-selftest/bad/yaml-tab.yaml | 29 +
.../bad/yaml-trailing-comment.yaml | 26 +
.../dt-style-selftest/bad/yaml-trailing-ws.yaml | 29 +
.../bad/yaml-unclosed-comment.yaml | 30 +
.../bad/yaml-unit-addr-prefix.yaml | 29 +
.../dtc/dt-style-selftest/bad/yaml-unit-addr.yaml | 29 +
.../dt-style-selftest/bad/yaml-unused-label.yaml | 29 +
.../bad/yaml-value-ws-multiline.yaml | 27 +
.../dtc/dt-style-selftest/bad/yaml-value-ws.yaml | 29 +
.../dt-style-selftest/expected/dts-spaces.dts.txt | 2 +
.../expected/yaml-child-addr-order.yaml.txt | 2 +
.../expected/yaml-child-name-order.yaml.txt | 2 +
.../expected/yaml-cont-align.yaml.txt | 2 +
.../expected/yaml-digit-node-order.yaml.txt | 2 +
.../expected/yaml-hex-case.yaml.txt | 2 +
.../expected/yaml-indent-strict.yaml.txt | 2 +
.../expected/yaml-label-in-string.yaml.txt | 2 +
.../expected/yaml-line-length.yaml.txt | 2 +
.../expected/yaml-mixed-indent.yaml.txt | 3 +
.../expected/yaml-multi-close.yaml.txt | 3 +
.../expected/yaml-node-close.yaml.txt | 2 +
.../expected/yaml-prop-order.yaml.txt | 2 +
.../expected/yaml-prop-pairing.yaml.txt | 3 +
.../expected/yaml-required-blank.yaml.txt | 3 +
.../dt-style-selftest/expected/yaml-tab.yaml.txt | 2 +
.../expected/yaml-trailing-comment.yaml.txt | 2 +
.../expected/yaml-trailing-ws.yaml.txt | 2 +
.../expected/yaml-unclosed-comment.yaml.txt | 2 +
.../expected/yaml-unit-addr-prefix.yaml.txt | 2 +
.../expected/yaml-unit-addr.yaml.txt | 2 +
.../expected/yaml-unused-label.yaml.txt | 2 +
.../expected/yaml-value-ws-multiline.yaml.txt | 2 +
.../expected/yaml-value-ws.yaml.txt | 2 +
.../dtc/dt-style-selftest/good/dts-cont-align.dts | 26 +
scripts/dtc/dt-style-selftest/good/dts-tab.dts | 29 +
.../dtc/dt-style-selftest/good/yaml-4space.yaml | 41 +
.../good/yaml-tricky-parsing.yaml | 57 +
scripts/dtc/dt-style-selftest/run.sh | 71 ++
scripts/jobserver-exec | 4 +-
166 files changed, 3608 insertions(+), 448 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
delete mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt
create mode 100644 Documentation/devicetree/bindings/arm/st,nomadik.yaml
delete mode 100644 Documentation/devicetree/bindings/arm/ste-nomadik.txt
create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx53-tve.yaml
create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,sofef01-m.yaml
create mode 100644 Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml
create mode 100644 Documentation/devicetree/bindings/extcon/samsung,s2mu005-muic.yaml
create mode 100644 Documentation/devicetree/bindings/hwmon/apple,smc-hwmon.yaml
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,irq-crossbar.yaml
create mode 100644 Documentation/devicetree/bindings/pwm/qcom,ipq6018-pwm.yaml
create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,omap-dmm.yaml
create mode 100644 Documentation/devicetree/bindings/sram/sram-consumer.yaml
create mode 100755 scripts/dtc/dt-check-style
create mode 100644 scripts/dtc/dt-style-selftest/bad/dts-spaces.dts
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-child-addr-order.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-child-name-order.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-cont-align.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-digit-node-order.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-hex-case.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-indent-strict.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-label-in-string.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-line-length.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-mixed-indent.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-multi-close.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-node-close.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-prop-order.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-prop-pairing.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-required-blank.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-tab.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-trailing-comment.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-trailing-ws.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-unclosed-comment.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-unit-addr-prefix.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-unit-addr.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-unused-label.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-value-ws-multiline.yaml
create mode 100644 scripts/dtc/dt-style-selftest/bad/yaml-value-ws.yaml
create mode 100644 scripts/dtc/dt-style-selftest/expected/dts-spaces.dts.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-child-addr-order.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-child-name-order.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-cont-align.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-digit-node-order.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-hex-case.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-indent-strict.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-label-in-string.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-line-length.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-mixed-indent.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-multi-close.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-node-close.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-prop-order.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-prop-pairing.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-required-blank.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-tab.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-trailing-comment.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-trailing-ws.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-unclosed-comment.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-unit-addr-prefix.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-unit-addr.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-unused-label.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-value-ws-multiline.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/expected/yaml-value-ws.yaml.txt
create mode 100644 scripts/dtc/dt-style-selftest/good/dts-cont-align.dts
create mode 100644 scripts/dtc/dt-style-selftest/good/dts-tab.dts
create mode 100644 scripts/dtc/dt-style-selftest/good/yaml-4space.yaml
create mode 100644 scripts/dtc/dt-style-selftest/good/yaml-tricky-parsing.yaml
create mode 100755 scripts/dtc/dt-style-selftest/run.sh
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm: xen: Convert to DT schema
From: Rob Herring (Arm) @ 2026-06-16 22:30 UTC (permalink / raw)
To: Tejas; +Cc: conor+dt, sstabellini, krzk+dt, devicetree
In-Reply-To: <20260615130928.10198-1-tejasmutalikdesai@gmail.com>
On Mon, 15 Jun 2026 18:39:28 +0530, Tejas wrote:
> Convert the Xen ARM device tree binding documentation from the legacy
> plain-text format (Documentation/devicetree/bindings/arm/xen.txt) to
> the YAML schema format, as required by the modern DT binding process.
> The old xen.txt is removed as the YAML schema is now the authoritative
> source.
>
> The YAML schema:
> - Uses the preferred dual license (GPL-2.0-only OR BSD-2-Clause)
> - Validates compatible string format as "xen,xen-<major>.<minor>"
> followed by the generic "xen,xen" string
> - Documents reg as accepting 1..N regions (region 0 mandatory for
> grant table mapping; regions 1..N optional extended regions)
> - Documents the uefi subnode with correct types:
> * xen,uefi-system-table: uint64 (guest PA of UEFI System Table)
> * xen,uefi-mmap-start: uint64 (guest PA of UEFI memory map)
> * xen,uefi-mmap-size: uint32 (size of UEFI memory map)
> * xen,uefi-mmap-desc-size: uint32 (size of each mmap entry)
> * xen,uefi-mmap-desc-ver: uint32 (mmap descriptor format version)
> - Marks all five xen,uefi-* properties as required within the uefi
> subnode; the source table lists all of them as unconditionally
> populated by Xen when UEFI is supported
> - 64-bit properties use /bits/ 64 <value> in the example, consistent
> with other bindings carrying uint64 properties (e.g. opp-v2.yaml,
> arm/mali-bifrost.yaml)
>
> The uefi subnode was originally introduced through a multi-version review
> series (v2..v7); the mistakes caught during those reviews (typos,
> duplicated UEFI spec content, insufficient description of Xen-specific
> hypercall semantics) are avoided with deliberate caution here.
>
> Note: the example emits a dtc warning (unit_address_vs_reg) for the
> /hypervisor node. Both the normative text in xen.txt ("Xen ARM virtual
> platforms shall have a top-level 'hypervisor' node") and the example
> in xen.txt mandate this exact node name — the $nodename: const:
> hypervisor in the schema is a direct encoding of that pre-existing
> requirement. A unit address is therefore impossible despite the presence
> of reg. This warning is pre-existing and not introduced by this
> conversion.
>
> Signed-off-by: Tejas Mutalikdesai <tejasmutalikdesai@gmail.com>
> ---
> Changes since v1:
> - Switch to dual license (GPL-2.0-only OR BSD-2-Clause) as required by
> submitting-patches.rst §3
> - Add required: for all five xen,uefi-* properties within the uefi subnode;
> the source table lists them as unconditionally populated by Xen
> - Fix grammar: "an HYPERVISOR_memory_op" -> "a HYPERVISOR_memory_op"
> - Fix subject: s/YAML schema/DT schema/ per submitting-patches.rst
>
> Documentation/devicetree/bindings/arm/xen.txt | 62 ---------
> .../devicetree/bindings/arm/xen.yaml | 120 ++++++++++++++++++
> 2 files changed, 120 insertions(+), 62 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/xen.txt
> create mode 100644 Documentation/devicetree/bindings/arm/xen.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/arm/xen.example.dts:13.16-26.7: Warning (unit_address_vs_reg): /hypervisor: node has a reg or ranges property, but no unit name
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/xen.example.dtb: /: 'compatible' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/xen.example.dtb: /: 'model' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
doc reference errors (make refcheckdocs):
Warning: arch/arm/xen/enlighten.c references a file that doesn't exist: Documentation/devicetree/bindings/arm/xen.txt
arch/arm/xen/enlighten.c: Documentation/devicetree/bindings/arm/xen.txt
See https://patchwork.kernel.org/project/devicetree/patch/20260615130928.10198-1-tejasmutalikdesai@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v6 2/2] i2c: ls2x: Add clocks property parsing and adjust bus speed
From: Andi Shyti @ 2026-06-16 22:55 UTC (permalink / raw)
To: Hongliang Wang
Cc: Binbin Zhou, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Wolfram Sang, linux-i2c, devicetree, loongarch, Huacai Chen,
stable
In-Reply-To: <20260608024533.32419-3-wanghongliang@loongson.cn>
Hi Hongliang,
On Mon, Jun 08, 2026 at 10:45:33AM +0800, Hongliang Wang wrote:
> The i2c-ls2x driver supports dts and acpi parameter passing.
>
> In dts, uses clock framework, by parsing clocks property to
> get i2c bus reference clock, and define the div of reference
> clock by device data.
>
> In acpi, by passing clocks property to describe i2c bus reference
> clock and clock-div property to describe the div of reference clock.
>
> Based on i2c bus reference clock(clock_a), i2c bus speed(clock_s)
> and div, calculate the prcescale of i2c divider register. The
> calculation formula is
>
> prcescale = (clock_a*10)/(div*clock_s)-1
>
> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
> Cc: stable@vger.kernel.org
what are you fixing exactly? It's not clear from the commit log.
Do we need to add the Fixes tag?
> Signed-off-by: Hongliang Wang <wanghongliang@loongson.cn>
...
> @@ -96,6 +104,8 @@ static irqreturn_t ls2x_i2c_isr(int this_irq, void *dev_id)
> static void ls2x_i2c_adjust_bus_speed(struct ls2x_i2c_priv *priv)
> {
> u16 val;
> + u32 pclk, div;
> + struct clk *clk;
> struct i2c_timings *t = &priv->i2c_t;
> struct device *dev = priv->adapter.dev.parent;
> u32 acpi_speed = i2c_acpi_find_bus_speed(dev);
> @@ -107,12 +117,30 @@ static void ls2x_i2c_adjust_bus_speed(struct ls2x_i2c_priv *priv)
> else
> t->bus_freq_hz = LS2X_I2C_FREQ_STD;
>
> + if (dev_of_node(dev)) {
> + clk = devm_clk_get_optional_enabled(dev, NULL);
Here you got a valid comment from the sashiko-bot, did you check
it?
There are some other comments that is worth checking.
Thanks,
Andi
> + if (!IS_ERR_OR_NULL(clk))
> + pclk = clk_get_rate(clk);
> + else
> + pclk = LS2X_I2C_PCLK_FREQ;
...
^ permalink raw reply
* Re: [PATCH] dt-bindings: i2c: convert axxia i2c to dt-schema
From: Andi Shyti @ 2026-06-16 23:35 UTC (permalink / raw)
To: Chaitanya Sabnis
Cc: wsa, anders.berg, robh, krzk+dt, conor+dt, linux-i2c, devicetree,
linux-kernel
In-Reply-To: <20260505100854.5258-1-chaitanya.msabnis@gmail.com>
Hi Chaitanya,
On Tue, May 05, 2026 at 03:38:54PM +0530, Chaitanya Sabnis wrote:
> Convert the LSI Axxia I2C Controller bindings from legacy text
> format to modern dt-schema (YAML).
>
> During the conversion, the obsolete `device_type = "i2c"` property
> was dropped from the example, as it is deprecated and not utilized
> by the driver. The `clock-names` property is enforced as required
> matching the driver probe behavior. The example node address was
> also updated to a standard 32-bit address.
>
> Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
Sorry for the delay, merged to i2c/i2c-for-7.2.
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: i2c: microchip,corei2c: permit resets
From: Andi Shyti @ 2026-06-16 23:45 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-i2c, Conor Dooley, Krzysztof Kozlowski, Daire McNamara,
Rob Herring, Krzysztof Kozlowski, linux-riscv, devicetree,
linux-kernel
In-Reply-To: <20260506-bronchial-kitten-e3697fb66ba7@spud>
Hi Conor,
On Wed, May 06, 2026 at 04:00:46PM +0100, Conor Dooley wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
>
> Both CoreI2C and the hardened versions of it on mpfs and pic64gx have a
> reset pin. For the former, usually this is wired to a common fabric
> reset not managed by software and for the latter two the platform
> firmware takes them out of reset on first-party boards (or those using
> modified versions of the vendor firmware), but not all boards may take
> this approach. Permit providing a reset in devicetree for Linux, or
> other devicetree-consuming software, to use.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
merged to i2c/i2c-host.
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: qcom: Add PMIH0108 haptics device node
From: Fenglin Wu @ 2026-06-17 1:30 UTC (permalink / raw)
To: Konrad Dybcio, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <6b3155ea-b583-4f82-8313-7a057fd78066@oss.qualcomm.com>
On 6/16/2026 6:27 PM, Konrad Dybcio wrote:
> On 6/16/26 12:08 PM, Fenglin Wu wrote:
>> Add haptics device node in the PMIH0108 PMIC base dtsi files, and enable
>> it on several boards according to the LRA (Linear Resonant Actuator)
>> component mounted on each of them.
>>
>> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
>> ---
>> arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 7 +++++++
>> arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 7 +++++++
>> arch/arm64/boot/dts/qcom/pmih0108-kaanapali.dtsi | 9 +++++++++
>> arch/arm64/boot/dts/qcom/pmih0108.dtsi | 9 +++++++++
>> arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 7 +++++++
>> arch/arm64/boot/dts/qcom/sm8750-qrd.dts | 7 +++++++
> One commit per board, please
>
>> 6 files changed, 46 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
>> index 07247dc98b70..7e3f59fc008e 100644
>> --- a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
>> +++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
>> @@ -952,6 +952,13 @@ wifi@0 {
>> };
>> };
>>
>> +&pmih0108_e1_haptics {
>> + status = "okay";
> 'status' should go last
>
>> +
>> + qcom,lra-period-us = <6667>;
>> + qcom,vmax-mv = <3600>;
> Do these properties depend on the physical characteristics on what's
> connected to the other end of the haptics driver?
Correct. They are basically the parameters of the LRA that's used on the
board. You can find details of them in the binding document.
>
> Konrad
^ permalink raw reply
* [PATCH v3 0/5] iio: adc: Add support for LTC2378 and similar ADCs
From: Marcelo Schmitt @ 2026-06-17 2:02 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel
Cc: jic23, nuno.sa, Michael.Hennerich, dlechner, andy, robh, krzk+dt,
conor+dt, pop.ioan-daniel, marcelo.schmitt1
This patch series adds support for LTC2378 and similar low noise, low power,
high speed, successive approximation register (SAR) ADCs. These ADCs are similar
among each other, varying mainly on the amount of precision bits, maximum sample
rate, and input configuration (either fully differential or pseudo-differential).
The first patch adds device tree documentation for LTC2378.
The second patch enables single-shot sample read with a GPIO connected
to the LTC2378 CNV pin.
The third patch extends IIO DMAengine buffer interface to make
sampling_frequency and sampling_frequency_available buffer attributes.
The fourth patch enables high-speed data captures with SPI offloading.
The setup is similar to AD4030, with a specialized PWM generator being used both
for SPI offload triggering and conversion start signaling.
The last support patch enables running buffered data captures without SPI offloading.
Even though these parts are somewhat similar to AD4000, the wiring configuration
for LTC parts is different as well as the available HDL for high speed sample
rate mode. Because of that, I propose creating a new device driver for
supporting LTC2378-like devices.
Specifications can be found at:
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/233818fa.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/236416fa.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/236418f.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/236716fa.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/236718f.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/236816f.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/236818f.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/236918fa.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237016fa.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237616fa.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237618fa.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237620fb.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237716fa.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237718fa.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237720fb.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237816fa.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237818fa.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237820fb.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237918fb.pdf
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/238016fb.pdf
Some structures and variables are introduced earlier to reduce diff in latter patches.
The initial version of the LTC2378 driver was developed by Ioan-Daniel. Though,
despite of the many changes I made to the code, I've kept him as module author
to provide credit for his work.
Previous submissions:
v2: https://lore.kernel.org/linux-iio/cover.1779976379.git.marcelo.schmitt@analog.com/
v1: https://lore.kernel.org/linux-iio/cover.1779117444.git.marcelo.schmitt1@gmail.com/
Change log v2 -> v3:
[DT]
- Re-added device tree fallback compatibles for LTC2378 chips, now with options
to provide a single compatible string or a pair of single compatible string
plus a fallback string to a slower sample rate spec in case a driver for the
specific part is not found.
[IIO]
- Restricted LTC2378 dependency list to require GPIO
- Use datasheet terminology to indicate polarity/output code.
- Added missing block scope to IIO_DEV_ACQUIRE_DIRECT_MODE.
- Added missing static inline modifier to function stubs declared in header file.
- Fixed the evaluation loop conditions for CNV PWM and SPI Engine trigger PWM,
avoiding potential infinite loop if and CPU stall.
- Added comment to about initial PWM disable.
- Adjusted SPI offload setup initialization to not print error on a valid condition.
- Fully initialize IIO channel scan_type.
- Reworked to make offload support not imply all dependencies to be built in.
- Made sampling_frequency a buffer attribute.
- Made offload support not require DMA and other features to be built in.
- Now using same scan_type configuration for all use cases.
With best regards,
Marcelo
Marcelo Schmitt (5):
dt-bindings: iio: adc: Add ltc2378
iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs
iio: buffer: Extend DMAengine buffer interfaces to take extra sysfs
attributes
iio: adc: ltc2378: Enable high-speed data capture
iio: adc: ltc2378: Enable triggered buffer data capture
.../bindings/iio/adc/adi,ltc2378.yaml | 160 ++++++++
MAINTAINERS | 8 +
drivers/iio/adc/Kconfig | 30 ++
drivers/iio/adc/Makefile | 7 +
drivers/iio/adc/ad4000.c | 3 +-
drivers/iio/adc/ad4030.c | 3 +-
drivers/iio/adc/ad4691.c | 3 +-
drivers/iio/adc/ad4695.c | 2 +-
drivers/iio/adc/ad7380.c | 2 +-
drivers/iio/adc/ad7606_spi.c | 2 +-
drivers/iio/adc/ad7768-1.c | 3 +-
drivers/iio/adc/ad7944.c | 2 +-
drivers/iio/adc/ad_sigma_delta.c | 2 +-
drivers/iio/adc/ltc2378-lib-core.c | 50 +++
drivers/iio/adc/ltc2378-offload-buffer.c | 305 ++++++++++++++
drivers/iio/adc/ltc2378-triggered-buffer.c | 49 +++
drivers/iio/adc/ltc2378.c | 384 ++++++++++++++++++
drivers/iio/adc/ltc2378.h | 120 ++++++
.../buffer/industrialio-buffer-dmaengine.c | 19 +-
drivers/iio/dac/ad5791.c | 2 +-
drivers/iio/dac/ad8460.c | 2 +-
drivers/iio/dac/adi-axi-dac.c | 2 +-
include/linux/iio/buffer-dmaengine.h | 16 +-
23 files changed, 1151 insertions(+), 25 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml
create mode 100644 drivers/iio/adc/ltc2378-lib-core.c
create mode 100644 drivers/iio/adc/ltc2378-offload-buffer.c
create mode 100644 drivers/iio/adc/ltc2378-triggered-buffer.c
create mode 100644 drivers/iio/adc/ltc2378.c
create mode 100644 drivers/iio/adc/ltc2378.h
base-commit: a50909aa46dec46de3c73235fc15a7d6f763d996
--
2.53.0
^ permalink raw reply
* [PATCH v3 1/5] dt-bindings: iio: adc: Add ltc2378
From: Marcelo Schmitt @ 2026-06-17 2:03 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel
Cc: jic23, nuno.sa, Michael.Hennerich, dlechner, andy, robh, krzk+dt,
conor+dt, pop.ioan-daniel, marcelo.schmitt1
In-Reply-To: <cover.1781661028.git.marcelo.schmitt@analog.com>
Document how to describe LTC2378-20 and similar ADCs in device tree.
Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
---
Change log v2 -> v3:
- Re-added device tree fallback compatibles for LTC2378 chips, now with options
to provide a single compatible string or a pair of single compatible string
plus a fallback string to a slower sample rate spec in case a driver for the
specific part is not found.
.../bindings/iio/adc/adi,ltc2378.yaml | 160 ++++++++++++++++++
MAINTAINERS | 7 +
2 files changed, 167 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml
new file mode 100644
index 000000000000..7d30a2cade8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml
@@ -0,0 +1,160 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ltc2378.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices LTC2378 and similar Analog to Digital Converters
+
+maintainers:
+ - Marcelo Schmitt <marcelo.schmitt@analog.com>
+
+description: |
+ Analog Devices LTC2378 series of ADCs.
+ Specifications can be found at:
+ https://www.analog.com/media/en/technical-documentation/data-sheets/233818fa.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/236416fa.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/236418f.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/236716fa.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/236718f.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/236816f.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/236818f.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/236918fa.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/237016fa.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/237616fa.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/237618fa.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/237620fb.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/237716fa.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/237718fa.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/237720fb.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/237816fa.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/237818fa.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/237820fb.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/237918fb.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/238016fb.pdf
+
+$ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ # Single compatible string match.
+ - enum:
+ - adi,ltc2338-18
+ - adi,ltc2364-16
+ - adi,ltc2364-18
+ - adi,ltc2367-16
+ - adi,ltc2367-18
+ - adi,ltc2368-16
+ - adi,ltc2368-18
+ - adi,ltc2369-18
+ - adi,ltc2370-16
+ - adi,ltc2376-16
+ - adi,ltc2376-18
+ - adi,ltc2376-20
+ - adi,ltc2377-16
+ - adi,ltc2377-18
+ - adi,ltc2377-20
+ - adi,ltc2378-16
+ - adi,ltc2378-18
+ - adi,ltc2378-20
+ - adi,ltc2379-18
+ - adi,ltc2380-16
+
+ # Low sample rate fallback for 16-bit unipolar sensors.
+ - items:
+ - enum:
+ - adi,ltc2370-16 # 2 MSPS
+ - adi,ltc2368-16 # 1 MSPS
+ - adi,ltc2367-16 # 500 kSPS
+ - const: adi,ltc2364-16 # fallback (250 kSPS)
+
+ # Low sample rate fallback for 18-bit unipolar sensors.
+ - items:
+ - enum:
+ - adi,ltc2369-18 # 1.6 MSPS
+ - adi,ltc2368-18 # 1 MSPS
+ - adi,ltc2367-18 # 500 kSPS
+ - const: adi,ltc2364-18 # fallback (250 kSPS)
+
+ # Low sample rate fallback for 16-bit bipolar sensors.
+ - items:
+ - enum:
+ - adi,ltc2380-16 # 2 MSPS
+ - adi,ltc2378-16 # 1 MSPS
+ - adi,ltc2377-16 # 500 kSPS
+ - const: adi,ltc2376-16 # fallback (250 kSPS)
+
+ # Low sample rate fallback for 18-bit bipolar sensors.
+ - items:
+ - enum:
+ - adi,ltc2379-18 # 1.6 MSPS
+ - adi,ltc2338-18 # 1 MSPS
+ - adi,ltc2378-18 # 1 MSPS
+ - adi,ltc2377-18 # 500 kSPS
+ - const: adi,ltc2376-18 # fallback (250 kSPS)
+
+ # Low sample rate fallback for 20-bit bipolar sensors.
+ - items:
+ - enum:
+ - adi,ltc2378-20 # 1 MSPS
+ - adi,ltc2377-20 # 500 kSPS
+ - const: adi,ltc2376-20 # fallback (250 kSPS)
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 100000000
+
+ vdd-supply:
+ description: A 2.5V supply that powers the chip (VDD).
+
+ ovdd-supply:
+ description:
+ A 1.71V to 5.25V supply that sets the logic level for digital interface.
+
+ ref-supply:
+ description:
+ A 2.5V to 5.1V supply for the reference input (REF).
+
+ cnv-gpios:
+ description:
+ When provided, this property indicates the GPIO that is connected to the
+ CNV pin.
+ maxItems: 1
+
+ interrupts:
+ description:
+ Interrupt for signaling the completion of conversion results. The active
+ low signal provided on the BUSY pin asserts when ADC conversions finish.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - ovdd-supply
+ - ref-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ adc@0 {
+ compatible = "adi,ltc2378-20", "adi,ltc2376-20";
+ reg = <0>;
+ spi-max-frequency = <71000000>;
+ vdd-supply = <&supply_2_5V>;
+ ovdd-supply = <&supply_3_3V>;
+ ref-supply = <&supply_5V>;
+ cnv-gpios = <&gpio0 88 GPIO_ACTIVE_HIGH>;
+ interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index b051eccafa60..205acb4b0789 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15220,6 +15220,13 @@ S: Maintained
F: Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml
F: drivers/iio/dac/ltc1660.c
+LTC2378 IIO ADC DRIVER
+M: Marcelo Schmitt <marcelo.schmitt@analog.com>
+L: linux-iio@vger.kernel.org
+S: Supported
+W: https://ez.analog.com/linux-software-drivers
+F: Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml
+
LTC2664 IIO DAC DRIVER
M: Michael Hennerich <michael.hennerich@analog.com>
M: Kim Seer Paller <kimseer.paller@analog.com>
--
2.53.0
^ permalink raw reply related
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