* Re: [PATCH v3] Add remoteproc PAS loader for SoCCP on Glymur DT
From: Ananthu C V @ 2026-04-10 7:28 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Sibi Sankar
In-Reply-To: <238b23bf-a180-4dfc-a896-955b1559bee7@oss.qualcomm.com>
On Tue, Apr 07, 2026 at 01:41:33PM +0200, Konrad Dybcio wrote:
> On 4/3/26 1:39 PM, Ananthu C V wrote:
> > From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> >
> > Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> > Co-developed-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> > Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> > ---
>
> [...]
>
> > + remoteproc_soccp: remoteproc-soccp@d00000 {
>
> remoteproc-soccp@ ->remoteproc@
ack
> > + compatible = "qcom,glymur-soccp-pas", "qcom,kaanapali-soccp-pas";
> > + reg = <0x0 0x00d00000 0x0 0x200000>;
> > +
> > + interrupts-extended = <&intc GIC_SPI 167 IRQ_TYPE_EDGE_RISING>,
> > + <&soccp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
> > + <&soccp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
> > + <&soccp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
> > + <&soccp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
> > + <&soccp_smp2p_in 9 IRQ_TYPE_EDGE_RISING>;
> > + interrupt-names = "wdog",
> > + "fatal",
> > + "ready",
> > + "handover",
> > + "stop-ack",
> > + "pong";
> > +
> > + clocks = <&rpmhcc RPMH_CXO_CLK>;
> > + clock-names = "xo";
> > +
> > + power-domains = <&rpmhpd RPMHPD_CX>,
> > + <&rpmhpd RPMHPD_MX>;
> > + power-domain-names = "cx",
> > + "mx";
> > +
> > + memory-region = <&soccp_mem>,
> > + <&soccpdtb_mem>;
> > +
> > + qcom,smem-states = <&soccp_smp2p_out 0>,
> > + <&soccp_smp2p_out 8>;
> > + qcom,smem-state-names = "stop",
> > + "ping";
> > +
> > + status = "disabled";
>
> Let's drop this line, no one should desire to run a system without SoCCP
ack, that makes sense.
> > +
> > + glink-edge {
> > + interrupts-extended = <&ipcc IPCC_MPROC_SOCCP
> > + IPCC_MPROC_SIGNAL_GLINK_QMP
> > + IRQ_TYPE_EDGE_RISING>;
> > + mboxes = <&ipcc IPCC_MPROC_SOCCP
> > + IPCC_MPROC_SIGNAL_GLINK_QMP>;
> > + qcom,remote-pid = <19>;
> > + label = "soccp";
> > +
> > + };
>
> Stray \n above
noted, will fix.
> Konrad
Thanks for the review Konrad, will reflect the changes in the next revision.
Best,
Ananthu
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: interconnect: qcom: document the RPMh NoC for Hawi SoC
From: Krzysztof Kozlowski @ 2026-04-10 7:26 UTC (permalink / raw)
To: Vivek Aknurwar
Cc: Georgi Djakov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-pm, devicetree, linux-kernel, Mike Tipton
In-Reply-To: <20260409-icc-hawi-v3-1-851cac12a81d@oss.qualcomm.com>
On Thu, Apr 09, 2026 at 02:01:37PM -0700, Vivek Aknurwar wrote:
> Document the RPMh Network-On-Chip interconnect for the Qualcomm Hawi SoC.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
> .../bindings/interconnect/qcom,hawi-rpmh.yaml | 131 ++++++++++++++++
> include/dt-bindings/interconnect/qcom,hawi-rpmh.h | 164 +++++++++++++++++++++
> 2 files changed, 295 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3] Add remoteproc PAS loader for SoCCP on Glymur DT
From: Ananthu C V @ 2026-04-10 7:25 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Sibi Sankar
In-Reply-To: <ghd4psugqtmgotr5j3754756dvdmlnxtvuefyjrirfwe26lvrb@47f3qinh53sk>
On Fri, Apr 03, 2026 at 11:25:50PM +0300, Dmitry Baryshkov wrote:
> On Fri, Apr 03, 2026 at 04:39:05AM -0700, Ananthu C V wrote:
> > From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> >
> > Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> > Co-developed-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> > Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> > ---
> > arch/arm64/boot/dts/qcom/glymur-crd.dtsi | 7 +++++
> > arch/arm64/boot/dts/qcom/glymur.dtsi | 47 ++++++++++++++++++++++++++++++++
> > 2 files changed, 54 insertions(+)
>
> Missing commit message.
It appears trying out some b4 shenanigans messed this up, I'll fix it.
> Also, as this is adding SocCP, can we get pmic glink device?
pmic-glink for glymur is already present, in glymur-crd.dts.
> --
> With best wishes
> Dmitry
Thank you for the review Dmitry, much appreciated.
Best,
Ananthu
^ permalink raw reply
* RE: [PATCH v6 03/10] clk: realtek: Introduce a common probe()
From: Yu-Chun Lin [林祐君] @ 2026-04-10 7:22 UTC (permalink / raw)
To: Brian Masney
Cc: mturquette@baylibre.com, sboyd@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, p.zabel@pengutronix.de,
Edgar Lee [李承諭], afaerber@suse.com,
Jyan Chou [周芷安], devicetree@vger.kernel.org,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <ac_NB8y414PtbtqM@redhat.com>
Hi Brian,
> Hi Cheng-Yu,
>
> On Thu, Apr 02, 2026 at 03:39:50PM +0800, Cheng-Yu Lee wrote:
> > Add rtk_clk_probe() to set up the shared regmap, register clock
> > hardware, and add the clock provider.
> >
> > Additionally, if the "#reset-cells" property is present in the device
> > tree, it creates and registers an auxiliary device using the provided
> aux_name.
> > This allows the dedicated reset driver to bind to this device,
> > enabling both clock and reset drivers to share the same regmap.
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v6:
> > - Replace direct reset controller initialization with auxiliary device creation.
> > - Add aux_name parameter to rtk_clk_probe() to register the reset auxiliary
> device.
> > - Simplify rtk_clk_desc because reset data is handled entirely by the auxiliary
> reset driver.
> > - In Kconfig, change "depends on RESET_CONTROLLER" to "select
> RESET_CONTROLLER"
> > - Remove unused includes headers and added <linux/auxiliary_bus.h>.
> > ---
> > MAINTAINERS | 1 +
> > drivers/clk/Kconfig | 1 +
> > drivers/clk/Makefile | 1 +
> > drivers/clk/realtek/Kconfig | 28 +++++++++++++++
> > drivers/clk/realtek/Makefile | 4 +++ drivers/clk/realtek/common.c |
> > 67 ++++++++++++++++++++++++++++++++++++
> > drivers/clk/realtek/common.h | 37 ++++++++++++++++++++
> > 7 files changed, 139 insertions(+)
> > create mode 100644 drivers/clk/realtek/Kconfig create mode 100644
> > drivers/clk/realtek/Makefile create mode 100644
> > drivers/clk/realtek/common.c create mode 100644
> > drivers/clk/realtek/common.h
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS index
> > 8f355896583b..8318156a02b5 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -22240,6 +22240,7 @@ L: devicetree@vger.kernel.org
> > L: linux-clk@vger.kernel.org
> > S: Supported
> > F: Documentation/devicetree/bindings/clock/realtek*
> > +F: drivers/clk/realtek/*
> > F: drivers/reset/realtek/*
> > F: include/dt-bindings/clock/realtek*
> > F: include/dt-bindings/reset/realtek*
> > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index
> > 3d803b4cf5c1..d60f6415b0a3 100644
> > --- a/drivers/clk/Kconfig
> > +++ b/drivers/clk/Kconfig
> > @@ -519,6 +519,7 @@ source "drivers/clk/nuvoton/Kconfig"
> > source "drivers/clk/pistachio/Kconfig"
> > source "drivers/clk/qcom/Kconfig"
> > source "drivers/clk/ralink/Kconfig"
> > +source "drivers/clk/realtek/Kconfig"
> > source "drivers/clk/renesas/Kconfig"
> > source "drivers/clk/rockchip/Kconfig"
> > source "drivers/clk/samsung/Kconfig"
> > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index
> > f7bce3951a30..69b84d1e7bcc 100644
> > --- a/drivers/clk/Makefile
> > +++ b/drivers/clk/Makefile
> > @@ -140,6 +140,7 @@ obj-$(CONFIG_COMMON_CLK_PISTACHIO)
> += pistachio/
> > obj-$(CONFIG_COMMON_CLK_PXA) += pxa/
> > obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/
> > obj-y += ralink/
> > +obj-$(CONFIG_COMMON_CLK_REALTEK) += realtek/
> > obj-y += renesas/
> > obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
> > obj-$(CONFIG_COMMON_CLK_SAMSUNG) += samsung/
> > diff --git a/drivers/clk/realtek/Kconfig b/drivers/clk/realtek/Kconfig
> > new file mode 100644 index 000000000000..bc47d3f1c452
> > --- /dev/null
> > +++ b/drivers/clk/realtek/Kconfig
> > @@ -0,0 +1,28 @@
> > +# SPDX-License-Identifier: GPL-2.0-only config COMMON_CLK_REALTEK
> > + bool "Clock driver for Realtek SoCs"
> > + depends on ARCH_REALTEK || COMPILE_TEST
> > + default ARCH_REALTEK
> > + help
> > + Enable the common clock framework infrastructure for Realtek
> > + system-on-chip platforms.
> > +
> > + This provides the base support required by individual Realtek
> > + clock controller drivers to expose clocks to peripheral devices.
> > +
> > + If you have a Realtek-based platform, say Y.
> > +
> > +if COMMON_CLK_REALTEK
> > +
> > +config RTK_CLK_COMMON
> > + tristate "Realtek Clock Common"
> > + select RESET_CONTROLLER
> > + select RESET_RTK_COMMON
>
> select AUXILIARY_BUS ?
>
Ack.
> > + help
> > + Common helper code shared by Realtek clock controller drivers.
> > +
> > + This provides utility functions and data structures used by
> > + multiple Realtek clock implementations, and include integration
> > + with reset controllers where required.
> > +
> > +endif
> > diff --git a/drivers/clk/realtek/Makefile
> > b/drivers/clk/realtek/Makefile new file mode 100644 index
> > 000000000000..377ec776ee47
> > --- /dev/null
> > +++ b/drivers/clk/realtek/Makefile
> > @@ -0,0 +1,4 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +obj-$(CONFIG_RTK_CLK_COMMON) += clk-rtk.o
> > +
> > +clk-rtk-y += common.o
> > diff --git a/drivers/clk/realtek/common.c
> > b/drivers/clk/realtek/common.c new file mode 100644 index
> > 000000000000..c5aea15a3714
> > --- /dev/null
> > +++ b/drivers/clk/realtek/common.c
> > @@ -0,0 +1,67 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2019 Realtek Semiconductor Corporation
>
> If you are making changes here, should the copyrights be updated to include
> 2026?
>
Agreed. Will include 2026.
> > + * Author: Cheng-Yu Lee <cylee12@realtek.com> */
> > +
> > +#include <linux/auxiliary_bus.h>
> > +#include <linux/device.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/module.h>
> > +#include <linux/platform_device.h>
> > +#include "common.h"
> > +
> > +static int rtk_reset_controller_register(struct device *dev, const
> > +char *aux_name) {
> > + struct auxiliary_device *adev;
> > +
> > + if (!of_property_present(dev->of_node, "#reset-cells"))
> > + return 0;
> > +
> > + adev = devm_auxiliary_device_create(dev, aux_name, NULL);
> > +
> > + if (IS_ERR(adev))
> > + return PTR_ERR(adev);
> > + return 0;
>
> Add newline before return.
>
Ack.
> > +}
> > +
> > +int rtk_clk_probe(struct platform_device *pdev, const struct rtk_clk_desc
> *desc,
> > + const char *aux_name)
> > +{
> > + int i, ret;
> > + struct regmap *regmap;
> > + struct device *dev = &pdev->dev;
>
> Put variables in reverse Christmas tree order.
>
Ack.
> > +
> > + regmap = device_node_to_regmap(pdev->dev.of_node);
> > + if (IS_ERR(regmap))
> > + return dev_err_probe(dev, PTR_ERR(regmap), "failed to
> > + get regmap\n");
> > +
> > + for (i = 0; i < desc->num_clks; i++)
> > + desc->clks[i]->regmap = regmap;
> > +
> > + for (i = 0; i < desc->clk_data->num; i++) {
> > + struct clk_hw *hw = desc->clk_data->hws[i];
> > +
> > + if (!hw)
> > + continue;
> > +
> > + ret = devm_clk_hw_register(dev, hw);
> > +
> > + if (ret) {
>
> Remove newline before if.
>
Ack.
> > + dev_warn(dev, "failed to register hw of clk%d:
> %d\n", i,
> > + ret);
> > + desc->clk_data->hws[i] = NULL;
>
> This chunk doesn't take into account probe deferrals.
Will return error here.
Best Regards,
Yu-Chun
>
> Brian
^ permalink raw reply
* Re: [PATCH v4 1/3] dt-bindings: thermal: Add SpacemiT K1 thermal sensor
From: Krzysztof Kozlowski @ 2026-04-10 7:22 UTC (permalink / raw)
To: Shuwei Wu
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yixun Lan,
Philipp Zabel, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, linux-pm, devicetree, linux-riscv, spacemit,
linux-kernel, Krzysztof Kozlowski, Vincent Legoll, Gong Shuai
In-Reply-To: <20260410-k1-thermal-v1-1-12c87dd063c3@mailbox.org>
On Fri, Apr 10, 2026 at 11:31:36AM +0800, Shuwei Wu wrote:
> Document the SpacemiT K1 Thermal Sensor, which supports
> monitoring temperatures for five zones: soc, package, gpu, cluster0,
> and cluster1.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
> Tested-by: Vincent Legoll <legoll@online.fr> # OrangePi-RV2
> Tested-by: Gong Shuai <gsh517025@gmail.com>
No, not possible. Otherwise explain me how your device tested a YAML
file.
Drop all of such tags.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 13/13] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Krzysztof Kozlowski @ 2026-04-10 7:18 UTC (permalink / raw)
To: Guenter Roeck, Akhil R, Alexandre Belloni, Frank Li, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rafael J . Wysocki,
Robert Moore, Len Brown, Philipp Zabel, Eric Biggers,
Sakari Ailus, Wolfram Sang, Miquel Raynal, linux-i3c, devicetree,
linux-kernel, linux-acpi, acpica-devel, linux-hwmon
In-Reply-To: <0a943b31-ca52-4ed7-b455-87fbb98fbc23@roeck-us.net>
On 10/04/2026 08:57, Guenter Roeck wrote:
> On 4/9/26 23:39, Krzysztof Kozlowski wrote:
>> On 09/04/2026 12:57, Akhil R wrote:
>>> Add I3C subsystem support, DesignWare I3C master controller, and
>>> SPD5118 hwmon sensor as modules to the defconfig and therefore
>>> enable the support for SPD5118 sensor on SOCAMM found in NVIDIA
>>> Vera platforms.
>>
>> git grep for "Vera" gave me zero results. Are you sure this is an
>> upstream platform? Please point the DTS using this.
>>
>
> I think this is an ACPI based system, or at least that is what Google search
> tells me.
Thanks. Following Google Vera is either a "CPU" or entire architecture
(at least that's how they call it), so it does not have SPD5118 sensor.
"Nvidia vera socamm" gives me something about "rubin". It's not me who
should be guessing all this.
"nvidia vera socamm SPD5118" gives me even less, so justification is flaky.
To remind, this commit msg should convince why generic kernel for
developers affecting all possible platforms - not end users, because
they always use distro kernels - should enable these configs. And it
should bring me clear rule what I can or cannot remove from defconfig,
if in 2 years I come and start pruning it from symbols.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 02/12] ASoC: dt-bindings: Add RZ/G3E (R9A09G047) sound binding
From: Krzysztof Kozlowski @ 2026-04-10 7:10 UTC (permalink / raw)
To: John Madieu
Cc: Kuninori Morimoto, Mark Brown, Liam Girdwood, Geert Uytterhoeven,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela,
Takashi Iwai, Magnus Damm, Philipp Zabel, Claudiu Beznea,
Biju Das, john.madieu, linux-sound, linux-renesas-soc, devicetree,
linux-kernel
In-Reply-To: <20260409090302.2243305-3-john.madieu.xa@bp.renesas.com>
On Thu, Apr 09, 2026 at 11:02:51AM +0200, John Madieu wrote:
> The RZ/G3E shares the same audio IP as the R-Car variants but differs
> in several aspects: it supports up to 5 DMA controllers per audio
> channel, requires additional clocks (47 total including per-SSI ADG
> clocks, SCU domain clocks and SSIF supply) and additional reset lines
> (14 total including SCU, ADG and Audio DMAC peri-peri resets).
>
> Add a dedicated devicetree binding for the RZ/G3E sound controller.
> The binding references the common renesas,rsnd-common.yaml schema for
> shared property and subnode definitions.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
>
> Changes:
>
> v4: No changes
> v3: No changes
> v2:
> - Introduce RZ/G3E sound binding as a standalone schema
>
> .../sound/renesas,r9a09g047-sound.yaml | 371 ++++++++++++++++++
> 1 file changed, 371 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml b/Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml
> new file mode 100644
> index 000000000000..1dfe9bab3382
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml
> @@ -0,0 +1,371 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/renesas,r9a09g047-sound.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas RZ/G3E Sound Controller
> +
> +maintainers:
> + - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> + - John Madieu <john.madieu.xa@bp.renesas.com>
> +
> +description:
> + The RZ/G3E (R9A09G047) integrates an R-Car compatible sound controller
> + with extended DMA channel support (up to 5 DMACs per direction), additional
> + clock domains, and additional reset lines compared to the R-Car Gen2/Gen3
> + variants.
> +
> +allOf:
> + - $ref: renesas,rsnd-common.yaml#
> +
> +properties:
> + compatible:
> + const: renesas,r9a09g047-sound
> +
> + reg:
> + maxItems: 5
> +
> + reg-names:
> + items:
> + - const: scu
> + - const: adg
> + - const: ssiu
> + - const: ssi
> + - const: audmapp
> +
> + clocks:
> + maxItems: 47
> +
> + clock-names:
> + items:
> + - const: ssi-all
> + - const: ssi.9
> + - const: ssi.8
> + - const: ssi.7
> + - const: ssi.6
> + - const: ssi.5
> + - const: ssi.4
> + - const: ssi.3
> + - const: ssi.2
> + - const: ssi.1
> + - const: ssi.0
> + - const: src.9
> + - const: src.8
> + - const: src.7
> + - const: src.6
> + - const: src.5
> + - const: src.4
> + - const: src.3
> + - const: src.2
> + - const: src.1
> + - const: src.0
> + - const: mix.1
> + - const: mix.0
> + - const: ctu.1
> + - const: ctu.0
> + - const: dvc.0
> + - const: dvc.1
> + - const: clk_a
> + - const: clk_b
> + - const: clk_c
> + - const: clk_i
> + - const: ssif_supply
> + - const: scu
> + - const: scu_x2
> + - const: scu_supply
> + - const: adg.ssi.9
> + - const: adg.ssi.8
> + - const: adg.ssi.7
> + - const: adg.ssi.6
> + - const: adg.ssi.5
> + - const: adg.ssi.4
> + - const: adg.ssi.3
> + - const: adg.ssi.2
> + - const: adg.ssi.1
> + - const: adg.ssi.0
> + - const: audmapp
> + - const: adg
> +
Missing clock-cells.
Mising dai-cells.
Why your binding is so flexible? You have a fixed (as in afixed) ABI, no?
> + resets:
> + maxItems: 14
> +
> + reset-names:
> + items:
> + - const: ssi-all
> + - const: ssi.9
> + - const: ssi.8
> + - const: ssi.7
> + - const: ssi.6
> + - const: ssi.5
> + - const: ssi.4
> + - const: ssi.3
> + - const: ssi.2
> + - const: ssi.1
> + - const: ssi.0
> + - const: scu
> + - const: adg
> + - const: audmapp
> +
> + rcar_sound,dvc:
All new properties must follow standard rules. I understand it will
create duplication, but really that's a mistake of 2014 of adding fake
vendor prefix rcar_sound.
So nodes do not have prefixes.
> + description: DVC subnode.
Pretty redundant comment. Can a node called "dvc" be anything else than
a "DVC subnode"?
> + type: object
> + patternProperties:
> + "^dvc-[0-1]$":
> + type: object
> + additionalProperties: false
> + properties:
> + dmas:
> + maxItems: 5
> + dma-names:
> + maxItems: 5
> + allOf:
> + - items:
> + enum:
> + - tx
> + required:
> + - dmas
> + - dma-names
> + additionalProperties: false
> +
> + rcar_sound,src:
> + description: SRC subnode.
> + type: object
> + patternProperties:
> + "^src-[0-9]$":
> + type: object
> + additionalProperties: false
> + properties:
> + interrupts:
> + maxItems: 1
> + dmas:
> + maxItems: 10
> + dma-names:
> + maxItems: 10
> + allOf:
> + - items:
> + enum:
> + - tx
> + - rx
> + additionalProperties: false
> +
> + rcar_sound,ssiu:
> + description: SSIU subnode.
> + type: object
> + patternProperties:
> + "^ssiu-[0-9]+$":
> + type: object
> + additionalProperties: false
> + properties:
> + dmas:
> + maxItems: 10
> + dma-names:
> + maxItems: 10
> + allOf:
> + - items:
> + enum:
> + - tx
> + - rx
> + required:
> + - dmas
> + - dma-names
> + additionalProperties: false
...
your example is also incomplete. Your common binding said you have many
other nodes.
Are you sure you created a common binding, not some collection of
unrelated stuff?
> + rcar_sound,dai {
> + dai0 {
> + playback = <&ssi3>, <&src1>, <&dvc1>;
> + capture = <&ssi4>, <&src0>, <&dvc0>;
> + };
> + };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + rsnd_port0: port@0 {
> + reg = <0>;
> + rsnd_endpoint0: endpoint {
> + remote-endpoint = <&codec_endpoint>;
> + dai-format = "i2s";
> + bitclock-master = <&rsnd_endpoint0>;
> + frame-master = <&rsnd_endpoint0>;
> + playback = <&ssi3>, <&src1>, <&dvc1>;
> + capture = <&ssi4>, <&src0>, <&dvc0>;
> + };
> + };
> + };
> + };
> +
> + codec {
Drop, not part of the binding.
> + port {
> + codec_endpoint: endpoint {
> + remote-endpoint = <&rsnd_endpoint0>;
> + };
> + };
> + };
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v4 01/12] ASoC: dt-bindings: renesas,rsnd: Split into generic and SoC-specific parts
From: Krzysztof Kozlowski @ 2026-04-10 7:05 UTC (permalink / raw)
To: John Madieu
Cc: Kuninori Morimoto, Mark Brown, Liam Girdwood, Geert Uytterhoeven,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela,
Takashi Iwai, Magnus Damm, Philipp Zabel, Claudiu Beznea,
Biju Das, john.madieu, linux-sound, linux-renesas-soc, devicetree,
linux-kernel
In-Reply-To: <20260409090302.2243305-2-john.madieu.xa@bp.renesas.com>
On Thu, Apr 09, 2026 at 11:02:50AM +0200, John Madieu wrote:
> The current renesas,rsnd.yaml binding file handles all supported SoCs
> in a single schema, resulting in deeply nested if/else/then constructs
> that become increasingly difficult to maintain. Each new SoC addition
> amplifies this complexity, making reviews harder and diffs noisier than
> they need to be.
>
> Refactor the binding by extracting the common properties shared across
> all SoCs into a dedicated renesas,rsnd-common.yaml schema, and keeping
> only SoC-specific constraints (required nodes, port counts, clock names,
> etc.) in per-SoC or per-family files that $ref the common part.
>
> This prepares the ground for upcoming SoCs such as the RZ/G3E, which
> introduces a different set of audio resources compared to existing
> R-Car Gen variants. With the split in place, adding RZ/G3E support
> becomes a self-contained change that neither bloats a monolithic schema
> nor buries new constraints inside ever-deeper conditional blocks.
>
> No functional change in validation behaviour for existing device trees.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
>
> Changes:
>
> v4: No changes
> v3: No changes
> v2:
> - Split of rsnd.yaml into common and R-Car-specific schemas
>
> .../bindings/sound/renesas,rsnd-common.yaml | 196 +++++++++++
> .../bindings/sound/renesas,rsnd.yaml | 319 +++++-------------
> 2 files changed, 274 insertions(+), 241 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/sound/renesas,rsnd-common.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd-common.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd-common.yaml
> new file mode 100644
> index 000000000000..ec6bf644d1a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd-common.yaml
> @@ -0,0 +1,196 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/renesas,rsnd-common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas R-Car/RZ Sound Common Properties
> +
> +maintainers:
> + - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> +
> +description:
> + Common property and subnode definitions shared by Renesas R-Car and RZ
> + sound controller bindings.
> +
> +select: false
Drop
> +
> +properties:
> + compatible: true
Drop
> +
> + reg: true
> +
> + reg-names: true
Drop both. They are pointless if they do not provide any reasonable
information like constraints.
> +
> + "#sound-dai-cells":
> + description:
> + Must be 0 for a single-DAI system and 1 for a multi-DAI system.
> + enum: [0, 1]
Drop, dai-common brings it.
> +
> + "#clock-cells":
> + description:
> + Must be 0 when the system has audio_clkout and 1 when it has
> + audio_clkout0/1/2/3.
> + enum: [0, 1]
Is every device a clock? Anyway, having it here is almost pointless if
every binding has to add it anyway.
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + clock-frequency:
> + description: Audio clock output frequency for audio_clkout0/1/2/3.
> +
> + clkout-lr-asynchronous:
> + description: audio_clkoutn is asynchronous with lr-clock.
> + $ref: /schemas/types.yaml#/definitions/flag
> +
> + power-domains: true
> +
> + resets: true
> +
> + reset-names: true
> +
> + clocks: true
> +
> + clock-names: true
All pointless.
Please use existing code as guideline. Which recently added common
bindings have such syntax?
> +
> + port:
> + $ref: audio-graph-port.yaml#/definitions/port-base
> + unevaluatedProperties: false
> + patternProperties:
> + "^endpoint(@[0-9a-f]+)?$":
> + $ref: audio-graph-port.yaml#/definitions/endpoint-base
> + properties:
> + playback:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + capture:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + unevaluatedProperties: false
> +
> + rcar_sound,dvc:
> + description: DVC subnode.
> + type: object
> + patternProperties:
> + "^dvc-[0-1]$":
> + type: object
> + additionalProperties: false
> + properties:
> + dmas: true
> + dma-names: true
> + required:
> + - dmas
> + - dma-names
> + additionalProperties: false
> +
> + rcar_sound,mix:
> + description: MIX subnode.
> + type: object
> + patternProperties:
> + "^mix-[0-1]$":
> + type: object
> + additionalProperties: false
> + additionalProperties: false
> +
> + rcar_sound,ctu:
> + description: CTU subnode.
> + type: object
> + patternProperties:
> + "^ctu-[0-7]$":
> + type: object
> + additionalProperties: false
> + additionalProperties: false
> +
> + rcar_sound,src:
> + description: SRC subnode.
> + type: object
> + patternProperties:
> + "^src-[0-9]$":
> + type: object
> + additionalProperties: false
> + properties:
> + interrupts:
> + maxItems: 1
> + dmas: true
> + dma-names: true
> + additionalProperties: false
> +
> + rcar_sound,ssiu:
> + description: SSIU subnode.
> + type: object
> + patternProperties:
> + "^ssiu-[0-9]+$":
> + type: object
> + additionalProperties: false
> + properties:
> + dmas: true
> + dma-names: true
> + required:
> + - dmas
> + - dma-names
> + additionalProperties: false
> +
> + rcar_sound,ssi:
> + description: SSI subnode.
> + type: object
> + patternProperties:
> + "^ssi-[0-9]$":
> + type: object
> + additionalProperties: false
> + properties:
> + interrupts:
> + maxItems: 1
> + dmas: true
> + dma-names: true
> + shared-pin:
> + description: Shared clock pin.
> + $ref: /schemas/types.yaml#/definitions/flag
> + pio-transfer:
> + description: PIO transfer mode.
> + $ref: /schemas/types.yaml#/definitions/flag
> + no-busif:
> + description: BUSIF is not used for the mem-to-SSI via DMA case.
> + $ref: /schemas/types.yaml#/definitions/flag
> + required:
> + - interrupts
> + additionalProperties: false
> +
> +patternProperties:
> + 'rcar_sound,dai(@[0-9a-f]+)?$':
> + description: DAI subnode.
> + type: object
> + patternProperties:
> + "^dai([0-9]+)?$":
> + type: object
> + additionalProperties: false
> + properties:
> + playback:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + capture:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + anyOf:
> + - required:
> + - playback
> + - required:
> + - capture
> + additionalProperties: false
> +
> + 'ports(@[0-9a-f]+)?$':
> + $ref: audio-graph-port.yaml#/definitions/port-base
> + unevaluatedProperties: false
> + patternProperties:
> + '^port(@[0-9a-f]+)?$':
> + $ref: "#/properties/port"
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> +
> +allOf:
> + - $ref: dai-common.yaml#
> +
> +additionalProperties: true
> diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
> index e8a2acb92646..0d989922a5b4 100644
> --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
> +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
> @@ -9,8 +9,11 @@ title: Renesas R-Car Sound Driver
> maintainers:
> - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> -properties:
> +description:
> + Binding for Renesas R-Car Gen1/Gen2/Gen3/Gen4 and RZ/G1/G2 sound
Drop "Binding for" and describe the hardware instead.
> + controllers using the standard RSND layout.
>
> +properties:
> compatible:
> oneOf:
> # for Gen1 SoC
> @@ -67,34 +70,6 @@ properties:
> minItems: 1
> maxItems: 5
>
> - "#sound-dai-cells":
> - description: |
> - it must be 0 if your system is using single DAI
> - it must be 1 if your system is using multi DAIs
> - This is used on simple-audio-card
> - enum: [0, 1]
> -
> - "#clock-cells":
> - description: |
> - it must be 0 if your system has audio_clkout
> - it must be 1 if your system has audio_clkout0/1/2/3
> - enum: [0, 1]
> -
> - "#address-cells":
> - const: 1
> -
> - "#size-cells":
> - const: 0
> -
> - clock-frequency:
> - description: for audio_clkout0/1/2/3
> -
> - clkout-lr-asynchronous:
> - description: audio_clkoutn is asynchronizes with lr-clock.
> - $ref: /schemas/types.yaml#/definitions/flag
> -
> - power-domains: true
> -
> resets:
> minItems: 1
> maxItems: 11
> @@ -109,181 +84,45 @@ properties:
> maxItems: 31
>
> clock-names:
> - description: List of necessary clock names.
> - # details are defined below
> -
> - # ports is below
> - port:
> - $ref: audio-graph-port.yaml#/definitions/port-base
> - unevaluatedProperties: false
> - patternProperties:
> - "^endpoint(@[0-9a-f]+)?":
> - $ref: audio-graph-port.yaml#/definitions/endpoint-base
> - properties:
> - playback:
> - $ref: /schemas/types.yaml#/definitions/phandle-array
> - capture:
> - $ref: /schemas/types.yaml#/definitions/phandle-array
> - unevaluatedProperties: false
> -
> - rcar_sound,dvc:
> - description: DVC subnode.
> - type: object
> - patternProperties:
> - "^dvc-[0-1]$":
> - type: object
> - additionalProperties: false
> -
> - properties:
> - dmas:
> - maxItems: 1
> - dma-names:
> - const: tx
> - required:
> - - dmas
> - - dma-names
> - additionalProperties: false
> -
> - rcar_sound,mix:
> - description: MIX subnode.
> - type: object
> - patternProperties:
> - "^mix-[0-1]$":
> - type: object
> - additionalProperties: false
> - additionalProperties: false
> -
> - rcar_sound,ctu:
> - description: CTU subnode.
> - type: object
> - patternProperties:
> - "^ctu-[0-7]$":
> - type: object
> - additionalProperties: false
> - additionalProperties: false
> -
> - rcar_sound,src:
> - description: SRC subnode.
> - type: object
> - patternProperties:
> - "^src-[0-9]$":
> - type: object
> - additionalProperties: false
> -
> - properties:
> - interrupts:
> - maxItems: 1
> - dmas:
> - maxItems: 2
> - dma-names:
> - allOf:
> - - items:
> - enum:
> - - tx
> - - rx
> - additionalProperties: false
> -
> - rcar_sound,ssiu:
> - description: SSIU subnode.
> - type: object
> - patternProperties:
> - "^ssiu-[0-9]+$":
> - type: object
> - additionalProperties: false
> -
> - properties:
> - dmas:
> - maxItems: 2
> - dma-names:
> - allOf:
> - - items:
> - enum:
> - - tx
> - - rx
> - required:
> - - dmas
> - - dma-names
> - additionalProperties: false
> -
> - rcar_sound,ssi:
> - description: SSI subnode.
> - type: object
> - patternProperties:
> - "^ssi-[0-9]$":
> - type: object
> - additionalProperties: false
> -
> - properties:
> - interrupts:
> - maxItems: 1
> - dmas:
> - minItems: 2
> - maxItems: 4
> - dma-names:
> - allOf:
> - - items:
> - enum:
> - - tx
> - - rx
> - - txu # if no ssiu node
> - - rxu # if no ssiu node
> -
> - shared-pin:
> - description: shared clock pin
> - $ref: /schemas/types.yaml#/definitions/flag
> - pio-transfer:
> - description: PIO transfer mode
> - $ref: /schemas/types.yaml#/definitions/flag
> - no-busif:
> - description: BUSIF is not used when [mem -> SSI] via DMA case
> - $ref: /schemas/types.yaml#/definitions/flag
> - required:
> - - interrupts
> - additionalProperties: false
> + description: List of clock names.
> + minItems: 1
> + maxItems: 31
> +
> + "#sound-dai-cells": true
> +
> + "#clock-cells": true
> +
> + "#address-cells": true
> +
> + "#size-cells": true
> +
> + clock-frequency: true
> +
> + clkout-lr-asynchronous: true
> +
> + power-domains: true
> +
> + port: true
> +
> + rcar_sound,dvc: true
> +
> + rcar_sound,mix: true
> +
> + rcar_sound,ctu: true
> +
> + rcar_sound,src: true
> +
> + rcar_sound,ssiu: true
> +
> + rcar_sound,ssi: true
What are all these? Why are you adding such blanket properties? This is
not the syntax binding should follow, there are almost no other bindings
using such style. Except pin control maybe and this is not a pinctrl.
You miss here proper constraints for all your properties like clock-cells, sound-dai-cells and so on.
>
> patternProperties:
> - # For DAI base
> - 'rcar_sound,dai(@[0-9a-f]+)?$':
> - description: DAI subnode.
> - type: object
> - patternProperties:
> - "^dai([0-9]+)?$":
> - type: object
> - additionalProperties: false
> -
> - properties:
> - playback:
> - $ref: /schemas/types.yaml#/definitions/phandle-array
> - capture:
> - $ref: /schemas/types.yaml#/definitions/phandle-array
> - anyOf:
> - - required:
> - - playback
> - - required:
> - - capture
> - additionalProperties: false
> -
> - 'ports(@[0-9a-f]+)?$':
> - $ref: audio-graph-port.yaml#/definitions/port-base
> - unevaluatedProperties: false
> - patternProperties:
> - '^port(@[0-9a-f]+)?$':
> - $ref: "#/properties/port"
> -
> -required:
> - - compatible
> - - reg
> - - reg-names
> - - clocks
> - - clock-names
> + 'rcar_sound,dai(@[0-9a-f]+)?$': true
> + 'ports(@[0-9a-f]+)?$': true
Also no. This is pure redundant code. No effect, no benefits.
>
> allOf:
> - - $ref: dai-common.yaml#
> + - $ref: renesas,rsnd-common.yaml#
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 13/13] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Akhil R @ 2026-04-10 7:04 UTC (permalink / raw)
To: krzk
Cc: Frank.Li, acpica-devel, akhilrajeev, alexandre.belloni, conor+dt,
devicetree, ebiggers, krzk+dt, lenb, linux-acpi, linux-hwmon,
linux-i3c, linux-kernel, linux, miquel.raynal, p.zabel, rafael,
robert.moore, robh, sakari.ailus, wsa+renesas
In-Reply-To: <6fd4bb71-90c5-4fe2-a520-97167fba049f@kernel.org>
On Fri, 10 Apr 2026 08:39:19 +0200, Krzysztof Kozlowski wrote:
> On 09/04/2026 12:57, Akhil R wrote:
>> Add I3C subsystem support, DesignWare I3C master controller, and
>> SPD5118 hwmon sensor as modules to the defconfig and therefore
>> enable the support for SPD5118 sensor on SOCAMM found in NVIDIA
>> Vera platforms.
>
> git grep for "Vera" gave me zero results. Are you sure this is an
> upstream platform? Please point the DTS using this.
Vera is an ACPI based platform. Yes, it is an upstream platform.
SoC changes go under the name Tegra410.
Regards,
Akhil
^ permalink raw reply
* [PATCH v4 2/2] hwmon:(pmbus/xdp720) Add support for efuse xdp720
From: ASHISH YADAV @ 2026-04-10 7:01 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel, Ashish Yadav
In-Reply-To: <20260410070154.3313-1-Ashish.Yadav@infineon.com>
From: Ashish Yadav <ashish.yadav@infineon.com>
Add the pmbus driver for Infineon XDP720 Digital eFuse Controller.
Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com>
---
XDP720 Digital eFuse Controller provides accurate system telemetry
(V, I, P, T) and reports analog current at the IMON pin for post-processing.
The Current and Power measurement depends on the RIMON and GIMON values.
Please look into data sheet sections 5.4.2 and 5.4.4 for more details:
https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp720-001-datasheet-en.pdf
The GIMON (microA/A) depends on the 10th bit of TELEMETRY_AVG PMBUS Register.
The value of RIMON (kohm) can be provided by the user through device tree using
infineon,rimon-micro-ohms property.
---
drivers/hwmon/pmbus/Kconfig | 9 +++
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/xdp720.c | 128 +++++++++++++++++++++++++++++++++++
3 files changed, 138 insertions(+)
create mode 100644 drivers/hwmon/pmbus/xdp720.c
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index fc1273abe357..c419e3ecce90 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -702,6 +702,15 @@ config SENSORS_XDP710
This driver can also be built as a module. If so, the module will
be called xdp710.
+config SENSORS_XDP720
+ tristate "Infineon XDP720 family"
+ help
+ If you say yes here you get hardware monitoring support for Infineon
+ XDP720.
+
+ This driver can also be built as a module. If so, the module will
+ be called xdp720.
+
config SENSORS_XDPE152
tristate "Infineon XDPE152 family"
help
diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
index d6c86924f887..1cac7ccae79f 100644
--- a/drivers/hwmon/pmbus/Makefile
+++ b/drivers/hwmon/pmbus/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_SENSORS_TPS546D24) += tps546d24.o
obj-$(CONFIG_SENSORS_UCD9000) += ucd9000.o
obj-$(CONFIG_SENSORS_UCD9200) += ucd9200.o
obj-$(CONFIG_SENSORS_XDP710) += xdp710.o
+obj-$(CONFIG_SENSORS_XDP720) += xdp720.o
obj-$(CONFIG_SENSORS_XDPE122) += xdpe12284.o
obj-$(CONFIG_SENSORS_XDPE152) += xdpe152c4.o
obj-$(CONFIG_SENSORS_ZL6100) += zl6100.o
diff --git a/drivers/hwmon/pmbus/xdp720.c b/drivers/hwmon/pmbus/xdp720.c
new file mode 100644
index 000000000000..8729a771f216
--- /dev/null
+++ b/drivers/hwmon/pmbus/xdp720.c
@@ -0,0 +1,128 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Hardware monitoring driver for Infineon XDP720 Digital eFuse Controller
+ *
+ * Copyright (c) 2026 Infineon Technologies. All rights reserved.
+ */
+
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/of_device.h>
+#include <linux/bitops.h>
+#include <linux/math64.h>
+#include "pmbus.h"
+
+/*
+ * The IMON resistor required to generate the system overcurrent protection.
+ * Arbitrary default Rimon value: 2k Ohm
+ */
+#define XDP720_DEFAULT_RIMON 2000000000 /* 2k ohm */
+#define XDP720_TELEMETRY_AVG 0xE9
+
+static struct pmbus_driver_info xdp720_info = {
+ .pages = 1,
+ .format[PSC_VOLTAGE_IN] = direct,
+ .format[PSC_VOLTAGE_OUT] = direct,
+ .format[PSC_CURRENT_OUT] = direct,
+ .format[PSC_POWER] = direct,
+ .format[PSC_TEMPERATURE] = direct,
+
+ .m[PSC_VOLTAGE_IN] = 4653,
+ .b[PSC_VOLTAGE_IN] = 0,
+ .R[PSC_VOLTAGE_IN] = -2,
+ .m[PSC_VOLTAGE_OUT] = 4653,
+ .b[PSC_VOLTAGE_OUT] = 0,
+ .R[PSC_VOLTAGE_OUT] = -2,
+ /*
+ * Current and Power measurement depends on the RIMON (kOhm) and
+ * GIMON(microA/A) values.
+ */
+ .m[PSC_CURRENT_OUT] = 24668,
+ .b[PSC_CURRENT_OUT] = 0,
+ .R[PSC_CURRENT_OUT] = -4,
+ .m[PSC_POWER] = 4486,
+ .b[PSC_POWER] = 0,
+ .R[PSC_POWER] = -1,
+ .m[PSC_TEMPERATURE] = 54,
+ .b[PSC_TEMPERATURE] = 22521,
+ .R[PSC_TEMPERATURE] = -1,
+
+ .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_VOUT | PMBUS_HAVE_PIN |
+ PMBUS_HAVE_TEMP | PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_INPUT |
+ PMBUS_HAVE_STATUS_TEMP,
+};
+
+static int xdp720_probe(struct i2c_client *client)
+{
+ struct pmbus_driver_info *info;
+ int ret;
+ u32 rimon;
+ int gimon;
+
+ info = devm_kmemdup(&client->dev, &xdp720_info, sizeof(*info),
+ GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ ret = devm_regulator_get_enable(&client->dev, "vdd-vin");
+ if (ret)
+ return dev_err_probe(&client->dev, ret,
+ "failed to enable vdd-vin supply\n");
+
+ ret = i2c_smbus_read_word_data(client, XDP720_TELEMETRY_AVG);
+ if (ret < 0) {
+ dev_err(&client->dev, "Can't get TELEMETRY_AVG\n");
+ return ret;
+ }
+
+ ret >>= 10; /* 10th bit of TELEMETRY_AVG REG for GIMON Value */
+ ret &= GENMASK(0, 0);
+ if (ret == 1)
+ gimon = 18200; /* output gain 18.2 microA/A */
+ else
+ gimon = 9100; /* output gain 9.1 microA/A */
+
+ if (of_property_read_u32(client->dev.of_node,
+ "infineon,rimon-micro-ohms", &rimon))
+ rimon = XDP720_DEFAULT_RIMON; /* Default if not set via DT */
+ if (rimon == 0)
+ return -EINVAL;
+
+ /* Adapt the current and power scale for each instance */
+ info->m[PSC_CURRENT_OUT] = DIV64_U64_ROUND_CLOSEST((u64)
+ info->m[PSC_CURRENT_OUT] * rimon * gimon, 1000000000000ULL);
+ info->m[PSC_POWER] = DIV64_U64_ROUND_CLOSEST((u64)
+ info->m[PSC_POWER] * rimon * gimon, 1000000000000000ULL);
+
+ return pmbus_do_probe(client, info);
+}
+
+static const struct of_device_id xdp720_of_match[] = {
+ { .compatible = "infineon,xdp720" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, xdp720_of_match);
+
+static const struct i2c_device_id xdp720_id[] = {
+ { "xdp720" },
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, xdp720_id);
+
+static struct i2c_driver xdp720_driver = {
+ .driver = {
+ .name = "xdp720",
+ .of_match_table = xdp720_of_match,
+ },
+ .probe = xdp720_probe,
+ .id_table = xdp720_id,
+};
+
+module_i2c_driver(xdp720_driver);
+
+MODULE_AUTHOR("Ashish Yadav <ashish.yadav@infineon.com>");
+MODULE_DESCRIPTION("PMBus driver for Infineon XDP720 Digital eFuse Controller");
+MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("PMBUS");
--
2.39.5
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: hwmon/pmbus: Add Infineon XDP720
From: ASHISH YADAV @ 2026-04-10 7:01 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel, Ashish Yadav
In-Reply-To: <20260410070154.3313-1-Ashish.Yadav@infineon.com>
From: Ashish Yadav <ashish.yadav@infineon.com>
Add documentation for the device tree binding of the XDP720 eFuse.
Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com>
---
.../bindings/hwmon/pmbus/infineon,xdp720.yaml | 59 +++++++++++++++++++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
new file mode 100644
index 000000000000..72bc3a5e7139
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/hwmon/pmbus/infineon,xdp720.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Infineon XDP720 Digital eFuse Controller
+
+maintainers:
+ - Ashish Yadav <ashish.yadav@infineon.com>
+
+description: |
+ The XDP720 is an eFuse with integrated current sensor and digital
+ controller. It provides accurate system telemetry (V, I, P, T) and
+ reports analog current at the IMON pin for post-processing.
+
+ Datasheet:
+ https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp720-001-datasheet-en.pdf
+
+properties:
+ compatible:
+ enum:
+ - infineon,xdp720
+
+ reg:
+ maxItems: 1
+
+ infineon,rimon-micro-ohms:
+ description:
+ The value of the RIMON resistor, in micro ohms, required to enable
+ the system overcurrent protection.
+
+ vdd-vin-supply:
+ description:
+ Supply for the VDD_VIN pin (pin 9), the IC controller power supply.
+ Typically connected to the input bus (VIN) through a 100 ohm / 100 nF
+ RC filter.
+
+required:
+ - compatible
+ - reg
+ - vdd-vin-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hwmon@11 {
+ compatible = "infineon,xdp720";
+ reg = <0x11>;
+ vdd-vin-supply = <&vdd_vin>;
+ infineon,rimon-micro-ohms = <1098000000>; /* 1.098k ohm */
+ };
+ };
--
2.39.5
^ permalink raw reply related
* [PATCH v4 0/2] Add support for Infineon Digital eFuse XDP720
From: ASHISH YADAV @ 2026-04-10 7:01 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel, Ashish Yadav
From: Ashish Yadav <ashish.yadav@infineon.com>
Hi,
These patches add support for Infineon Digital eFuse XDP720.
XDP720 provides accurate system telemetry (V, I, P, T) and
reports analog current at the IMON pin for post-processing.
The Current and Power measurement depends on the RIMON and GIMON values.
Please look into data sheet sections 5.4.2 and 5.4.4 for more details:
https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp720-001-datasheet-en.pdf
With Best Regards,
Ashish Yadav
---
Changes in v4:
- Link to v3:
https://lore.kernel.org/all/20260406101647.109667-1-Ashish.Yadav@infineon.com/
- Fix commit msg for devicetree binding patch.
https://lore.kernel.org/all/20260407-monumental-mastiff-of-sunshine-fb27ab@quoll/
Changes in v3:
- Link to v2:
https://lore.kernel.org/all/20260401104550.115715-1-Ashish.Yadav@infineon.com/
- Fix commit msg, added missing supply info in devicetree binding document.
https://lore.kernel.org/all/20260402-enlightened-analytic-leopard-ddc512@quoll/
- Fix .m[PSC_POWER] value issue.The divisor value is 10^15 rather than 10^12.
- Added devm_regulator_get_enable().
https://lore.kernel.org/all/258dd77a-a8d9-4540-a32a-91a3f13c6ed5@roeck-us.net/
Changes in v2:
- Link to v1:
https://lore.kernel.org/all/20260330102345.37065-1-Ashish.Yadav@infineon.com/
- Fix make dt_binding_check issue:
https://patchwork.kernel.org/project/devicetree/patch/20260330102345.37065-2-Ashish.Yadav@infineon.com/
- Address reviews comments for infineon,xdp720.yaml, Kconfig, Makefile and xpe720.c:
https://sashiko.dev/#/patchset/20260330102345.37065-1-Ashish.Yadav%40infineon.com
It includes fixing of extra space, non-ASCII characters and use spaces
instead of tabs.
The xpe720.c driver file update with DIV64_U64_ROUND_CLOSEST() and
MODULE_DEVICE_TABLE() as suggested in review comments.
Ashish Yadav (2):
dt-bindings: hwmon/pmbus: Add Infineon XDP720
hwmon:(pmbus/xdp720) Add support for efuse xdp720
.../bindings/hwmon/pmbus/infineon,xdp720.yaml | 59 ++++++++
drivers/hwmon/pmbus/Kconfig | 9 ++
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/xdp720.c | 128 ++++++++++++++++++
4 files changed, 197 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
create mode 100644 drivers/hwmon/pmbus/xdp720.c
--
2.39.5
^ permalink raw reply
* Re: [PATCH v2 13/13] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Guenter Roeck @ 2026-04-10 6:57 UTC (permalink / raw)
To: Krzysztof Kozlowski, Akhil R, Alexandre Belloni, Frank Li,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafael J . Wysocki, Robert Moore, Len Brown, Philipp Zabel,
Eric Biggers, Sakari Ailus, Wolfram Sang, Miquel Raynal,
linux-i3c, devicetree, linux-kernel, linux-acpi, acpica-devel,
linux-hwmon
In-Reply-To: <6fd4bb71-90c5-4fe2-a520-97167fba049f@kernel.org>
On 4/9/26 23:39, Krzysztof Kozlowski wrote:
> On 09/04/2026 12:57, Akhil R wrote:
>> Add I3C subsystem support, DesignWare I3C master controller, and
>> SPD5118 hwmon sensor as modules to the defconfig and therefore
>> enable the support for SPD5118 sensor on SOCAMM found in NVIDIA
>> Vera platforms.
>
> git grep for "Vera" gave me zero results. Are you sure this is an
> upstream platform? Please point the DTS using this.
>
I think this is an ACPI based system, or at least that is what Google search
tells me.
Guenter
^ permalink raw reply
* RE: [PATCH v6 02/10] reset: Add Realtek basic reset support
From: Yu-Chun Lin [林祐君] @ 2026-04-10 6:49 UTC (permalink / raw)
To: Philipp Zabel, mturquette@baylibre.com, sboyd@kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Edgar Lee [李承諭], afaerber@suse.com,
Jyan Chou [周芷安]
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <5dd7ddb50b71de737aae6ad4d11bd28fa52443a9.camel@pengutronix.de>
> On Do, 2026-04-02 at 15:39 +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Define the reset operations backed by a regmap-based register
> > interface and prepare the reset controller to be registered through
> > the reset framework.
> >
> > Since the reset controllers on Realtek SoCs often share the same
> > register space with the clock controllers, this common framework is
> > designed to extract the regmap and device tree node from the parent
> > device (e.g., an auxiliary device parent).
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v6:
> > - Remove the global header include/linux/reset/realtek.h and use a
> > local common.h instead.
> > - Extract regmap and of_node directly from the parent device.
> > - Remove struct rtk_reset_initdata. Now, pass struct rtk_reset_data
> > directly when calling rtk_reset_controller_add().
> > ---
> > MAINTAINERS | 1 +
> > drivers/reset/Kconfig | 1 +
> > drivers/reset/Makefile | 1 +
> > drivers/reset/realtek/Kconfig | 3 ++
> > drivers/reset/realtek/Makefile | 2 + drivers/reset/realtek/common.c
> > | 85 ++++++++++++++++++++++++++++++++++
> > drivers/reset/realtek/common.h | 29 ++++++++++++
> > 7 files changed, 122 insertions(+)
> > create mode 100644 drivers/reset/realtek/Kconfig create mode 100644
> > drivers/reset/realtek/Makefile create mode 100644
> > drivers/reset/realtek/common.c create mode 100644
> > drivers/reset/realtek/common.h
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS index
> > 07e73bf621b0..8f355896583b 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -22240,6 +22240,7 @@ L: devicetree@vger.kernel.org
> > L: linux-clk@vger.kernel.org
> > S: Supported
> > F: Documentation/devicetree/bindings/clock/realtek*
> > +F: drivers/reset/realtek/*
> > F: include/dt-bindings/clock/realtek*
> > F: include/dt-bindings/reset/realtek*
> >
> > diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index
> > 7ce151f6a7e4..03be1931f264 100644
> > --- a/drivers/reset/Kconfig
> > +++ b/drivers/reset/Kconfig
> > @@ -398,6 +398,7 @@ config RESET_ZYNQMP
> >
> > source "drivers/reset/amlogic/Kconfig"
> > source "drivers/reset/hisilicon/Kconfig"
> > +source "drivers/reset/realtek/Kconfig"
> > source "drivers/reset/spacemit/Kconfig"
> > source "drivers/reset/starfive/Kconfig"
> > source "drivers/reset/sti/Kconfig"
> > diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile index
> > fc0cc99f8514..4407d1630070 100644
> > --- a/drivers/reset/Makefile
> > +++ b/drivers/reset/Makefile
> > @@ -2,6 +2,7 @@
> > obj-y += core.o
> > obj-y += amlogic/
> > obj-y += hisilicon/
> > +obj-y += realtek/
> > obj-y += spacemit/
> > obj-y += starfive/
> > obj-y += sti/
> > diff --git a/drivers/reset/realtek/Kconfig
> > b/drivers/reset/realtek/Kconfig new file mode 100644 index
> > 000000000000..99a14d355803
> > --- /dev/null
> > +++ b/drivers/reset/realtek/Kconfig
> > @@ -0,0 +1,3 @@
> > +# SPDX-License-Identifier: GPL-2.0-only config RESET_RTK_COMMON
> > + bool
>
> Please make this build-testable with COMPILE_TEST.
>
I will change Kconfig to
config RESET_RTK_COMMON
tristate "Realtek common reset driver" if COMPILE_TEST
help
Common helper code shared by Realtek reset controller drivers.
config COMMON_RESET_RTD1625
tristate "RTD1625 Reset Controller"
depends on ARCH_REALTEK || COMPILE_TEST
select RESET_RTK_COMMON
select AUXILIARY_BUS
help
This enables the reset controller driver for Realtek RTD1625 SoC.
> > diff --git a/drivers/reset/realtek/Makefile
> > b/drivers/reset/realtek/Makefile new file mode 100644 index
> > 000000000000..b59a3f7f2453
> > --- /dev/null
> > +++ b/drivers/reset/realtek/Makefile
> > @@ -0,0 +1,2 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +obj-$(CONFIG_RESET_RTK_COMMON) += common.o
> > diff --git a/drivers/reset/realtek/common.c
> > b/drivers/reset/realtek/common.c new file mode 100644 index
> > 000000000000..ea7ff27117e7
> > --- /dev/null
> > +++ b/drivers/reset/realtek/common.c
> > @@ -0,0 +1,85 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2019 Realtek Semiconductor Corporation */
> > +
> > +#include <linux/device.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/regmap.h>
> > +#include "common.h"
> > +
> > +static inline struct rtk_reset_data *to_rtk_reset_controller(struct
> > +reset_controller_dev *r) {
> > + return container_of(r, struct rtk_reset_data, rcdev); }
> > +
> > +static inline struct rtk_reset_desc *rtk_reset_get_desc(struct rtk_reset_data
> *data,
> > + unsigned
> long
> > +idx) {
> > + return &data->descs[idx];
> > +}
> > +
> > +static int rtk_reset_assert(struct reset_controller_dev *rcdev,
> > + unsigned long idx) {
> > + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> > + struct rtk_reset_desc *desc = rtk_reset_get_desc(data, idx);
> > + u32 mask = desc->write_en ? (0x3 << desc->bit) : BIT(desc->bit);
> > + u32 val = desc->write_en ? (0x2 << desc->bit) : 0;
> > +
> > + return regmap_update_bits(data->regmap, desc->ofs, mask, val); }
> > +
> > +static int rtk_reset_deassert(struct reset_controller_dev *rcdev,
> > + unsigned long idx) {
> > + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> > + struct rtk_reset_desc *desc = rtk_reset_get_desc(data, idx);
> > + u32 mask = desc->write_en ? (0x3 << desc->bit) : BIT(desc->bit);
> > + u32 val = mask;
> > +
> > + return regmap_update_bits(data->regmap, desc->ofs, mask, val); }
> > +
> > +static int rtk_reset_status(struct reset_controller_dev *rcdev,
> > + unsigned long idx) {
> > + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> > + struct rtk_reset_desc *desc = rtk_reset_get_desc(data, idx);
> > + u32 val;
> > + int ret;
> > +
> > + ret = regmap_read(data->regmap, desc->ofs, &val);
> > + if (ret)
> > + return ret;
> > +
> > + return !((val >> desc->bit) & 1); }
> > +
> > +static const struct reset_control_ops rtk_reset_ops = {
> > + .assert = rtk_reset_assert,
> > + .deassert = rtk_reset_deassert,
> > + .status = rtk_reset_status,
> > +};
> > +
> > +/* The caller must initialize data->rcdev.nr_resets and data->descs
> > +before
> > + * calling rtk_reset_controller_add().
> > + */
> > +int rtk_reset_controller_add(struct device *dev,
> > + struct rtk_reset_data *data) {
> > + struct device *parent = dev->parent;
> > +
> > + data->regmap = dev_get_regmap(parent, NULL);
> > + if (!data->regmap)
> > + return -ENODEV;
> > +
> > + data->rcdev.owner = THIS_MODULE;
>
> The rtk_reset_desc arrays used by this code live in the calling module, so it
> would be better to let the caller initialize .owner as well.
>
> It doesn't make a difference in practice, since CONFIG_RESET_RTK_COMMON
> isn't tristate (right now).
>
I will move 'data->rcdev.owner = THIS_MODULE' to the caller.
Best Regards,
Yu-Chun
>
> regards
> Philipp
^ permalink raw reply
* [PATCH v7 2/2] iio: dac: ad5706r: Add support for AD5706R DAC
From: Alexis Czezar Torreno @ 2026-04-10 6:48 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-iio, devicetree, linux-kernel, Alexis Czezar Torreno,
Andy Shevchenko
In-Reply-To: <20260410-dev_ad5706r-v7-0-af93a4caa186@analog.com>
Add support for the Analog Devices AD5706R, a 4-channel 16-bit
current output digital-to-analog converter with SPI interface.
Features:
- 4 independent DAC channels
- Hardware and software LDAC trigger
- Configurable output range
- PWM-based LDAC control
- Dither and toggle modes
- Dynamically configurable SPI speed
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
---
Changes in v7:
- Moved/added size validation before data access in write()/read()
Changes in v6:
- Added size validation in regmap_write()
- Used &st->tx_buf[0] consistently _be32/be16 calls
- Added missing indent in AD5706R_CHAN
Changes in v5:
- Kconfig: Added select REGMAP_SPI dependency
- Headers: Removed device.h, errno.h, string.h; added dev_printk.h
- Use IIO_DMA_MINALIGN instead of ARCH_DMA_MINALIGN
- Replaced memcpy/memset with put_unaligned_be* for consistency
- Added struct device *dev shorthand in probe()
- Added newline to error message
- Other minor style edits
Changes in v4:
- Added missing includes
- Converted to use regmap with custom SPI bus implementation
- Removed driver-specific mutex/guards in favor of regmap locking
- Minor style cleanups
Changes in v3:
- Removed redundant includes, added respective includes of APIs used
- Simplified bit manipulation in SPI read/write
- Fixed inconsistent trailing commas in device ID tables
- Removed zero initialization in spi_device_id
Changes in v2:
- Removed PWM, GPIO, clock generator, debugfs, regmap, IIO_BUFFER
- Removed all custom ext_info sysfs attributes
- Simplified to basic raw read/write and read-only scale
- SPI read/write can handle multibyte registers
---
---
MAINTAINERS | 1 +
drivers/iio/dac/Kconfig | 11 ++
drivers/iio/dac/Makefile | 1 +
drivers/iio/dac/ad5706r.c | 253 ++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 266 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 17a3d2d45fccb9cd3c93fd35666fb85d17d53cde..3d7bd98b4d1b55836e40687a9a3ac9f4935a8acb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1502,6 +1502,7 @@ L: linux-iio@vger.kernel.org
S: Supported
W: https://ez.analog.com/linux-software-drivers
F: Documentation/devicetree/bindings/iio/dac/adi,ad5706r.yaml
+F: drivers/iio/dac/ad5706r.c
ANALOG DEVICES INC AD7091R DRIVER
M: Marcelo Schmitt <marcelo.schmitt@analog.com>
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index db9f5c711b3df90641f017652fbbef594cc1627d..a5a328818233e3d019cddaee369dd5b7b1529031 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -178,6 +178,17 @@ config AD5624R_SPI
Say yes here to build support for Analog Devices AD5624R, AD5644R and
AD5664R converters (DAC). This driver uses the common SPI interface.
+config AD5706R
+ tristate "Analog Devices AD5706R DAC driver"
+ depends on SPI
+ select REGMAP_SPI
+ help
+ Say yes here to build support for Analog Devices AD5706R 4-channel,
+ 16-bit current output DAC.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad5706r.
+
config AD9739A
tristate "Analog Devices AD9739A RF DAC spi driver"
depends on SPI
diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
index 2a80bbf4e80ad557da79ed916027cedff286984b..0034317984985035f7987a744899924bfd4612e3 100644
--- a/drivers/iio/dac/Makefile
+++ b/drivers/iio/dac/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_AD5449) += ad5449.o
obj-$(CONFIG_AD5592R_BASE) += ad5592r-base.o
obj-$(CONFIG_AD5592R) += ad5592r.o
obj-$(CONFIG_AD5593R) += ad5593r.o
+obj-$(CONFIG_AD5706R) += ad5706r.o
obj-$(CONFIG_AD5755) += ad5755.o
obj-$(CONFIG_AD5758) += ad5758.o
obj-$(CONFIG_AD5761) += ad5761.o
diff --git a/drivers/iio/dac/ad5706r.c b/drivers/iio/dac/ad5706r.c
new file mode 100644
index 0000000000000000000000000000000000000000..026f871ce121cd63331b2a34da8879491b2d0f3c
--- /dev/null
+++ b/drivers/iio/dac/ad5706r.c
@@ -0,0 +1,253 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * AD5706R 16-bit Current Output Digital to Analog Converter
+ *
+ * Copyright 2026 Analog Devices Inc.
+ */
+
+#include <linux/array_size.h>
+#include <linux/bits.h>
+#include <linux/dev_printk.h>
+#include <linux/err.h>
+#include <linux/iio/iio.h>
+#include <linux/minmax.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/spi/spi.h>
+#include <linux/types.h>
+#include <linux/unaligned.h>
+
+/* SPI frame layout */
+#define AD5706R_RD_MASK BIT(15)
+#define AD5706R_ADDR_MASK GENMASK(11, 0)
+
+/* Registers */
+#define AD5706R_REG_DAC_INPUT_A_CH(x) (0x60 + ((x) * 2))
+#define AD5706R_REG_DAC_DATA_READBACK_CH(x) (0x68 + ((x) * 2))
+
+#define AD5706R_DAC_RESOLUTION 16
+#define AD5706R_DAC_MAX_CODE BIT(16)
+#define AD5706R_MULTIBYTE_REG_START 0x14
+#define AD5706R_MULTIBYTE_REG_END 0x71
+#define AD5706R_MAX_REG 0x77
+#define AD5706R_SINGLE_BYTE_LEN 1
+#define AD5706R_DOUBLE_BYTE_LEN 2
+
+struct ad5706r_state {
+ struct spi_device *spi;
+ struct regmap *regmap;
+
+ u8 tx_buf[4] __aligned(IIO_DMA_MINALIGN);
+ u8 rx_buf[4];
+};
+
+static int ad5706r_reg_len(unsigned int reg)
+{
+ if (reg >= AD5706R_MULTIBYTE_REG_START && reg <= AD5706R_MULTIBYTE_REG_END)
+ return AD5706R_DOUBLE_BYTE_LEN;
+
+ return AD5706R_SINGLE_BYTE_LEN;
+}
+
+static int ad5706r_regmap_write(void *context, const void *data, size_t count)
+{
+ struct ad5706r_state *st = context;
+ unsigned int num_bytes, val;
+ u16 reg;
+
+ if (count != 4)
+ return -EINVAL;
+
+ reg = get_unaligned_be16(data);
+ num_bytes = ad5706r_reg_len(reg);
+
+ struct spi_transfer xfer = {
+ .tx_buf = st->tx_buf,
+ .len = num_bytes + 2,
+ };
+
+ val = get_unaligned_be32(data);
+ put_unaligned_be32(val, &st->tx_buf[0]);
+
+ /* For single byte, copy the data to the correct position */
+ if (num_bytes == AD5706R_SINGLE_BYTE_LEN)
+ st->tx_buf[2] = st->tx_buf[3];
+
+ return spi_sync_transfer(st->spi, &xfer, 1);
+}
+
+static int ad5706r_regmap_read(void *context, const void *reg_buf,
+ size_t reg_size, void *val_buf, size_t val_size)
+{
+ struct ad5706r_state *st = context;
+ unsigned int num_bytes;
+ u16 reg, cmd, val;
+ int ret;
+
+ if (reg_size != 2 || val_size != 2)
+ return -EINVAL;
+
+ reg = get_unaligned_be16(reg_buf);
+ num_bytes = ad5706r_reg_len(reg);
+
+ /* Full duplex, device responds immediately after command */
+ struct spi_transfer xfer = {
+ .tx_buf = st->tx_buf,
+ .rx_buf = st->rx_buf,
+ .len = 2 + num_bytes,
+ };
+
+ cmd = AD5706R_RD_MASK | (reg & AD5706R_ADDR_MASK);
+ put_unaligned_be16(cmd, &st->tx_buf[0]);
+ put_unaligned_be16(0, &st->tx_buf[2]);
+
+ ret = spi_sync_transfer(st->spi, &xfer, 1);
+ if (ret)
+ return ret;
+
+ /* Extract value from response (skip 2-byte command echo) */
+ if (num_bytes == AD5706R_SINGLE_BYTE_LEN)
+ val = st->rx_buf[2];
+ else if (num_bytes == AD5706R_DOUBLE_BYTE_LEN)
+ val = get_unaligned_be16(&st->rx_buf[2]);
+ else
+ return -EINVAL;
+
+ put_unaligned_be16(val, val_buf);
+
+ return 0;
+}
+
+static int ad5706r_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct ad5706r_state *st = iio_priv(indio_dev);
+ unsigned int reg, reg_val;
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ reg = AD5706R_REG_DAC_DATA_READBACK_CH(chan->channel);
+ ret = regmap_read(st->regmap, reg, ®_val);
+ if (ret)
+ return ret;
+
+ *val = reg_val;
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ *val = 50;
+ *val2 = AD5706R_DAC_RESOLUTION;
+ return IIO_VAL_FRACTIONAL_LOG2;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int ad5706r_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int val, int val2, long mask)
+{
+ struct ad5706r_state *st = iio_priv(indio_dev);
+ unsigned int reg;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ if (!in_range(val, 0, AD5706R_DAC_MAX_CODE))
+ return -EINVAL;
+
+ reg = AD5706R_REG_DAC_INPUT_A_CH(chan->channel);
+ return regmap_write(st->regmap, reg, val);
+ default:
+ return -EINVAL;
+ }
+}
+
+static const struct regmap_bus ad5706r_regmap_bus = {
+ .write = ad5706r_regmap_write,
+ .read = ad5706r_regmap_read,
+ .reg_format_endian_default = REGMAP_ENDIAN_BIG,
+ .val_format_endian_default = REGMAP_ENDIAN_BIG,
+};
+
+static const struct regmap_config ad5706r_regmap_config = {
+ .reg_bits = 16,
+ .val_bits = 16,
+ .max_register = AD5706R_MAX_REG,
+};
+
+static const struct iio_info ad5706r_info = {
+ .read_raw = ad5706r_read_raw,
+ .write_raw = ad5706r_write_raw,
+};
+
+#define AD5706R_CHAN(_channel) { \
+ .type = IIO_CURRENT, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_SCALE), \
+ .output = 1, \
+ .indexed = 1, \
+ .channel = _channel, \
+}
+
+static const struct iio_chan_spec ad5706r_channels[] = {
+ AD5706R_CHAN(0),
+ AD5706R_CHAN(1),
+ AD5706R_CHAN(2),
+ AD5706R_CHAN(3),
+};
+
+static int ad5706r_probe(struct spi_device *spi)
+{
+ struct device *dev = &spi->dev;
+ struct iio_dev *indio_dev;
+ struct ad5706r_state *st;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*st));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ st = iio_priv(indio_dev);
+ st->spi = spi;
+
+ st->regmap = devm_regmap_init(dev, &ad5706r_regmap_bus,
+ st, &ad5706r_regmap_config);
+ if (IS_ERR(st->regmap))
+ return dev_err_probe(dev, PTR_ERR(st->regmap),
+ "Failed to init regmap\n");
+
+ indio_dev->name = "ad5706r";
+ indio_dev->info = &ad5706r_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->channels = ad5706r_channels;
+ indio_dev->num_channels = ARRAY_SIZE(ad5706r_channels);
+
+ return devm_iio_device_register(dev, indio_dev);
+}
+
+static const struct of_device_id ad5706r_of_match[] = {
+ { .compatible = "adi,ad5706r" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ad5706r_of_match);
+
+static const struct spi_device_id ad5706r_id[] = {
+ { "ad5706r" },
+ { }
+};
+MODULE_DEVICE_TABLE(spi, ad5706r_id);
+
+static struct spi_driver ad5706r_driver = {
+ .driver = {
+ .name = "ad5706r",
+ .of_match_table = ad5706r_of_match,
+ },
+ .probe = ad5706r_probe,
+ .id_table = ad5706r_id,
+};
+module_spi_driver(ad5706r_driver);
+
+MODULE_AUTHOR("Alexis Czezar Torreno <alexisczezar.torreno@analog.com>");
+MODULE_DESCRIPTION("AD5706R 16-bit Current Output DAC driver");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH v7 1/2] dt-bindings: iio: dac: Add ADI AD5706R
From: Alexis Czezar Torreno @ 2026-04-10 6:48 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-iio, devicetree, linux-kernel, Alexis Czezar Torreno,
Krzysztof Kozlowski
In-Reply-To: <20260410-dev_ad5706r-v7-0-af93a4caa186@analog.com>
Add device tree binding documentation for the Analog Devices
AD5706R 4-channel 16-bit current output digital-to-analog converter.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
---
Changes in v5:
- Changed out-en-gpios to enable-gpios.
Changes in v4:
- Reverted pwm and gpio entries
- Added missing power supply properties
- Clocks not added back as they were driver specific
Changes in v3:
- Added allOf and ref to spi-peripheral-props.yaml
- Changed additionalProperties to unevaluatedProperties
- Added avdd-supply property and added it to required
Changes in v1:
- Removed clocks, clock-names, pwms, pwm-names, gpio properties
- Simplified example to use plain SPI bus
---
---
.../devicetree/bindings/iio/dac/adi,ad5706r.yaml | 105 +++++++++++++++++++++
MAINTAINERS | 7 ++
2 files changed, 112 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5706r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5706r.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..19cc744a9f0fc35907de8b8bdd9f088676620b54
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5706r.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/adi,ad5706r.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD5706R 4-Channel Current Output DAC
+
+maintainers:
+ - Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
+
+description: |
+ The AD5706R is a 4-channel, 16-bit resolution, current output
+ digital-to-analog converter (DAC) with programmable output current
+ ranges (50mA, 150mA, 200mA, 300mA), an integrated 2.5V voltage
+ reference, and load DAC, A/B toggle, and dither functions.
+
+ Datasheet:
+ https://www.analog.com/en/products/ad5706r.html
+
+properties:
+ compatible:
+ enum:
+ - adi,ad5706r
+
+ reg:
+ maxItems: 1
+
+ avdd-supply:
+ description: Analog power supply (2.9V to 3.6V).
+
+ iovdd-supply:
+ description: Logic power supply (1.14V to 1.89V).
+
+ pvdd0-supply:
+ description: Power supply for IDAC0 channel (1.65V to AVDD).
+
+ pvdd1-supply:
+ description: Power supply for IDAC1 channel (1.65V to AVDD).
+
+ pvdd2-supply:
+ description: Power supply for IDAC2 channel (1.65V to AVDD).
+
+ pvdd3-supply:
+ description: Power supply for IDAC3 channel (1.65V to AVDD).
+
+ vref-supply:
+ description:
+ Optional external 2.5V voltage reference. If not provided, the
+ internal 2.5V reference is used.
+
+ pwms:
+ maxItems: 1
+ description:
+ Optional PWM connected to the LDAC/TGP/DCK pin for hardware
+ triggered DAC updates, toggle, or dither clock generation.
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ GPIO connected to the active low RESET pin. If not provided,
+ software reset is used.
+
+ enable-gpios:
+ maxItems: 1
+ description:
+ GPIO connected to the active low OUT_EN pin. Controls whether
+ the current outputs are enabled or in high-Z/ground state.
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - iovdd-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@0 {
+ compatible = "adi,ad5706r";
+ reg = <0>;
+ avdd-supply = <&avdd>;
+ iovdd-supply = <&iovdd>;
+ pvdd0-supply = <&pvdd>;
+ pvdd1-supply = <&pvdd>;
+ pvdd2-supply = <&pvdd>;
+ pvdd3-supply = <&pvdd>;
+ vref-supply = <&vref>;
+ spi-max-frequency = <50000000>;
+ pwms = <&pwm0 0 1000000 0>;
+ reset-gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
+ };
+ };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 1251965d70bdfa990c66966cd77f7ab52ae3385f..17a3d2d45fccb9cd3c93fd35666fb85d17d53cde 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1496,6 +1496,13 @@ W: https://ez.analog.com/linux-software-drivers
F: Documentation/devicetree/bindings/iio/adc/adi,ad4851.yaml
F: drivers/iio/adc/ad4851.c
+ANALOG DEVICES INC AD5706R DRIVER
+M: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
+L: linux-iio@vger.kernel.org
+S: Supported
+W: https://ez.analog.com/linux-software-drivers
+F: Documentation/devicetree/bindings/iio/dac/adi,ad5706r.yaml
+
ANALOG DEVICES INC AD7091R DRIVER
M: Marcelo Schmitt <marcelo.schmitt@analog.com>
L: linux-iio@vger.kernel.org
--
2.34.1
^ permalink raw reply related
* [PATCH v7 0/2] Add support for AD5706R DAC
From: Alexis Czezar Torreno @ 2026-04-10 6:48 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-iio, devicetree, linux-kernel, Alexis Czezar Torreno,
Krzysztof Kozlowski, Andy Shevchenko
This series adds support for the Analog Devices AD5706R, a 4-channel
16-bit current output digital-to-analog converter with SPI interface.
The AD5706R features:
- 4 independent current output DAC channels
- Configurable output ranges (50mA, 150mA, 200mA, 300mA)
- Hardware and software LDAC trigger with configurable edge selection
- Toggle and dither modes per channel
- Internal or external voltage reference selection
- PWM-controlled LDAC
- Dynamic change SPI speed
The driver exposes standard IIO raw/scale/offset channel attributes for
DAC output control, sampling frequency for PWM-based LDAC timing, and
extended attributes for device configuration including output range
selection, trigger mode, and multiplexer output.
This driver is developed and tested on the Cora Z7S platform using
the AXI SPI Engine and AXI CLKGEN IP cores. The 'clocks' property
enables dynamic SPI clock rate management via the CLKGEN.
Datasheet: https://www.analog.com/en/products/ad5706r.html
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
---
Changes in v7:
- driver:
- Moved/added size validation before data access in write()/read()
- Link to v6: https://lore.kernel.org/r/20260410-dev_ad5706r-v6-0-f3fda5921fe4@analog.com
Changes in v6:
- driver:
- Added size validation in regmap_write()
- Used &st->tx_buf[0] consistently in _be32/be16 calls
- Added missing indent in AD5706R_CHAN
- Link to v5: https://lore.kernel.org/r/20260407-dev_ad5706r-v5-0-a4c7737b6ae9@analog.com
Changes in v5:
- dt-bindings:
- Changed out-en-gpios to enable-gpios
- driver:
- Kconfig: Added select REGMAP_SPI
- Headers: Removed device.h, errno.h, string.h; added dev_printk.h
- Use IIO_DMA_MINALIGN instead of ARCH_DMA_MINALIGN
- Replaced memcpy/memset with put_unaligned_be* for consistency
- Added struct device *dev shorthand in probe()
- other minor style edits
- Link to v4: https://lore.kernel.org/r/20260401-dev_ad5706r-v4-0-a785184a8d53@analog.com
Changes in v4:
- dt-bindings:
- Reverted pwm and gpio entries.
- Added missing power supply properties
- Clocks not added back as they were driver specific, not device
properties
- driver:
- Added missing includes
- Converted to use regmap with custom SPI bus implementation.
spi_write_then_read not applied as suggested, prevents future
need to change SPI speed
- removed driver speciifc mutex/guards in favor of regmap internal
locking
- Minor style cleanups
- Link to v3: https://lore.kernel.org/r/20260318-dev_ad5706r-v3-0-5d078f41e988@analog.com
Changes in v3:
- Added MAINTAINERS entry, files added on each patch
- dt-bindings:
- Added allOf and ref to spi-peripheral-props.yaml
- Changed additionalProperties to unevaluatedProperties
- Added avdd-supply property and added it to required
- driver:
- Removed redundant includes, added respective includes of APIs used
- Simplified bit manipulation in SPI read/write, used feedback from v2
- Fixed inconsistent trailing commas in device ID tables
- Removed zero initialization in spi_device_id
- Link to v2: https://lore.kernel.org/r/20260311-dev_ad5706r-v2-0-f367063dbd1b@analog.com
Changes in v2:
- Stripped driver down to basic DAC functionality (read/write raw,
read-only scale) as suggested.
- Removed PWM (LDAC), GPIO (reset/shutdown), clock generator,
SPI engine frequency switching, debugfs streaming, and all
custom ext_info sysfs attributes
- Removed regmap, IIO_BUFFER, and iio/sysfs.h dependencies
- Simplified SPI read/write to use standard spi_sync_transfer
without clock mode logic
- Scale reports default 50mA range as read-only using
IIO_VAL_FRACTIONAL_LOG2; writable range selection deferred
to future follow-up series
- Simplified DT binding to only require compatible, reg, and
spi-max-frequency
- Link to v1: https://lore.kernel.org/r/20260220-dev_ad5706r-v1-0-7253bbd74889@analog.com
---
Alexis Czezar Torreno (2):
dt-bindings: iio: dac: Add ADI AD5706R
iio: dac: ad5706r: Add support for AD5706R DAC
.../devicetree/bindings/iio/dac/adi,ad5706r.yaml | 105 +++++++++
MAINTAINERS | 8 +
drivers/iio/dac/Kconfig | 11 +
drivers/iio/dac/Makefile | 1 +
drivers/iio/dac/ad5706r.c | 253 +++++++++++++++++++++
5 files changed, 378 insertions(+)
---
base-commit: 3674f3ca92730d9a07b42b311f1337d83c4d5605
change-id: 20260220-dev_ad5706r-2105e1dd29ab
Best regards,
--
Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Krzysztof Kozlowski @ 2026-04-10 6:42 UTC (permalink / raw)
To: Hongliang Wang
Cc: Binbin Zhou, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, loongarch
In-Reply-To: <0f560e80-3fbb-c24f-51f9-b4425db17867@loongson.cn>
On 10/04/2026 05:04, Hongliang Wang wrote:
> Hi, Krzysztof
>
> On 2026/4/9 下午8:11, Krzysztof Kozlowski wrote:
>> On 09/04/2026 14:03, Hongliang Wang wrote:
>>> I have a question, the input clock of i2c controller can be described by
>>> "clocks",
>>> but there is no existing attribute can describe the divisor of the input
>>> clock,
>>> Can I define a new attribute named "clock-div" to describe it in DT
>>> bindings?
>>> or do you have any standard solutions for the divisor problem? Thank you.
>>>
>> You should determine/calculate the divisor in the driver code, depending
>> on clocks and bus frequencies. You don't need a property for that, usually.
>
> Not only clocks and bus frequencies, but also a third property is required.
>
> The frequency divison calculation formula of i2c is
> Prcescale = clock_a/(clock_div*clock_s)-1
>
> There is three parameters in this formula:
> clock_a represents the input clock, which is described by "clocks",
> clock_s represents the i2c bus frequency, which is described by
> "clock-frequency",
> but there is no existing property to describe clock_div, which has
> different value
> on different platform (for example, it is 5 on 7a1000/7a2000, 4 on
> 2K1000/2K2000,
> 5.5 on 2K3000.), So I need a property to describe clock_div in this formula.
So it is fixed per compatible? Then you do not need.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 13/13] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Krzysztof Kozlowski @ 2026-04-10 6:39 UTC (permalink / raw)
To: Akhil R, Alexandre Belloni, Frank Li, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rafael J . Wysocki,
Robert Moore, Len Brown, Guenter Roeck, Philipp Zabel,
Eric Biggers, Sakari Ailus, Wolfram Sang, Miquel Raynal,
linux-i3c, devicetree, linux-kernel, linux-acpi, acpica-devel,
linux-hwmon
In-Reply-To: <20260409105747.48158-14-akhilrajeev@nvidia.com>
On 09/04/2026 12:57, Akhil R wrote:
> Add I3C subsystem support, DesignWare I3C master controller, and
> SPD5118 hwmon sensor as modules to the defconfig and therefore
> enable the support for SPD5118 sensor on SOCAMM found in NVIDIA
> Vera platforms.
git grep for "Vera" gave me zero results. Are you sure this is an
upstream platform? Please point the DTS using this.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 6/6] arm64: defconfig: make Tegra238 and Tegra264 Pinctrl a loadable module
From: Krzysztof Kozlowski @ 2026-04-10 6:37 UTC (permalink / raw)
To: pshete, linux-gpio, devicetree, linux-tegra, linux-kernel, arnd,
bjorn.andersson, conor+dt, dmitry.baryshkov, ebiggers, geert,
jonathanh, krzk+dt, kuninori.morimoto.gx, linusw, luca.weiss,
michal.simek, prabhakar.mahadev-lad.rj, robh, rosenp, sven,
thierry.reding, webgeek1234
In-Reply-To: <20260409131340.168556-7-pshete@nvidia.com>
On 09/04/2026 15:13, pshete@nvidia.com wrote:
> From: Prathamesh Shete <pshete@nvidia.com>
>
> Building the Pinctrl driver into the kernel image increases its size.
That's obvious.
> These drivers are not required during early boot, build them as a loadable
> module instead to reduce the kernel image size.
So you replace built-in into module?
>
> Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
> ---
> arch/arm64/configs/defconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index dd1ac01ee29b..f525670d3b84 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -711,6 +711,8 @@ CONFIG_PINCTRL_SC8280XP_LPASS_LPI=m
> CONFIG_PINCTRL_SM8550_LPASS_LPI=m
> CONFIG_PINCTRL_SM8650_LPASS_LPI=m
> CONFIG_PINCTRL_SOPHGO_SG2000=y
> +CONFIG_PINCTRL_TEGRA238=m
> +CONFIG_PINCTRL_TEGRA264=m
No, you just added as module. Why do we want them in upstream defconfig?
Standard question, already asked Nvidia more than once.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1] ASoC: codecs: wcd937x: Add conditional regulator control for wcd937x
From: Krzysztof Kozlowski @ 2026-04-10 6:27 UTC (permalink / raw)
To: Karthik S, Srinivas Kandagatla, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela,
Takashi Iwai
Cc: linux-arm-msm, linux-sound, devicetree, linux-kernel
In-Reply-To: <1c203ea9-c674-43b6-a2e5-87054a9e3b83@oss.qualcomm.com>
On 10/04/2026 07:38, Karthik S wrote:
>>>
>>> diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
>>> index f94203798f24..d89fff1f7171 100644
>>> --- a/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
>>> +++ b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
>>> @@ -28,6 +28,12 @@ properties:
>>> vdd-px-supply:
>>> description: A reference to the 1.8V I/O supply
>>>
>>> + qcom,always-on-supply:
>> You described the desired Linux feature or behavior, not the actual
>> hardware. The bindings are about the latter, so instead you need to
>> rephrase the property and its description to match actual hardware
>> capabilities/features/configuration etc.
>
> Current description in dt-binding:
> Indicates that the codec supply regulators are always enabled by the
> system and must not be requested or enabled by the codec driver.
>
> new description in dt-binding:
> implies that the codec supply Vdd is on always on rails off the
> board/hardware and must not be requested or enabled by the codec driver.
Still driver stuff. But another point is that kernel handles well always
on rails, so this property is completely redundant.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Uwe Kleine-König @ 2026-04-10 6:27 UTC (permalink / raw)
To: Andrea della Porta
Cc: linux-pwm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Broadcom internal kernel review list,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov
In-Reply-To: <adfQ6Tvst3Vd1Mxe@apocalypse>
[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]
Hello Andrea,
On Thu, Apr 09, 2026 at 06:16:41PM +0200, Andrea della Porta wrote:
> On 23:45 Sun 05 Apr , Uwe Kleine-König wrote:
> > On Fri, Apr 03, 2026 at 04:31:55PM +0200, Andrea della Porta wrote:
> > > +static void rp1_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
> > > +{
> > > + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> > > + u32 value;
> > > +
> > > + value = readl(rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > + value &= ~PWM_MODE_MASK;
> > > + writel(value, rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > +
> > > + rp1_pwm_apply_config(chip, pwm);
> >
> > What is the purpose of this call?
>
> To update the configuration on the next PWM strobe in order to avoid
> glitches. I'll add a short comment in the code.
.pwm_free() should not touch the hardware configuration. Changing the
pinmuxing (which I guess is the purpose of clearing PWM_MODE_MASK) is
somewhat a grey area. If that saves energy, that's okish. Otherwise
not interfering with the operation of the PWM (e.g. to keep a display on
during kexec or so) is preferred.
> > > +static int rp1_pwm_resume(struct device *dev)
> > > +{
> > > + struct rp1_pwm *rp1 = dev_get_drvdata(dev);
> > > +
> > > + return clk_prepare_enable(rp1->clk);
> >
> > Hmm, if this fails and then the driver is unbound, the clk operations
> > are not balanced.
>
> I'll add some flags to check if the clock is really enabled or not.
To be honest, I guess that is a problem of several drivers, not only in
drivers/pwm. If this complicates the driver, I guess addressing this
isn't very critical.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 09/13] i3c: dw-i3c-master: Add a quirk to skip clock and reset
From: Akhil R @ 2026-04-10 6:07 UTC (permalink / raw)
To: frank.li
Cc: acpica-devel, akhilrajeev, alexandre.belloni, conor+dt,
devicetree, ebiggers, krzk+dt, lenb, linux-acpi, linux-hwmon,
linux-i3c, linux-kernel, linux, miquel.raynal, p.zabel, rafael,
robert.moore, robh, sakari.ailus, wsa+renesas
In-Reply-To: <adhkNYQW73yQ728h@lizhi-Precision-Tower-5810>
On Thu, 9 Apr 2026 22:45:09 -0400, Frank Li wrote:
> On Thu, Apr 09, 2026 at 04:27:39PM +0530, Akhil R wrote:
>> Some ACPI-enumerated devices like Tegra410 do not have clock and reset
>> resources exposed via the clk/reset frameworks. Add a match data for
>
> why not export fix clock at ACPI?
>
>> such devices to skip acquiring clock and reset controls during probe.
>>
>> Move match data parsing before clock/reset acquisition so the quirk is
>> available early enough. When the quirk is set, fall back to reading
>> the clock rate from the "clock-frequency" device property instead.
>
> "clock-frequency" is legacy proptery.
The document ACPI on ARMv8 Servers [1] suggests not to use clock or reset
framework at all. I also could not find any proper way to export the clock
to the kernel from the ACPI table. The same document suggests to use only
_DSD properties, if to pass any data to the kernel.
I can rename the property to 'default-clock-rate' if that sounds good.
Please let me know your suggestion.
[1]: https://www.kernel.org/doc/html/v6.1/arm64/arm-acpi.html#programmable-power-control-resources
Best Regards,
Akhil
^ permalink raw reply
* [PATCH v2] ASoC: dt-bindings: rockchip: convert rk3399-gru-sound to DT Schema
From: Anushka Badhe @ 2026-04-10 5:55 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner
Cc: linux-sound, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Anushka Badhe
Convert the rockchip,rk3399-gru-sound.txt DT binding to DT Schema
format.
Update rockchip,cpu from a single I2S controller phandle to a
phandle-array. Add an optional second entry for the SPDIF controller,
as seen in rk3399-gru.dtsi, required by boards with DisplayPort audio.
Signed-off-by: Anushka Badhe <anushkabadhe@gmail.com>
---
Changes in v2:
- Fix subject and body: "YAML Schema" -> "DT Schema"
- Fix title: "ROCKCHIP" -> "Rockchip"
- List items for rockchip,cpu with I2S and SPDIF descriptions
- List items for rockchip,codec
- Update descriptions for rockchip,cpu, rockchip,codec and
dmic-wakeup-delay-ms
.../sound/rockchip,rk3399-gru-sound.txt | 22 -------
.../sound/rockchip,rk3399-gru-sound.yaml | 60 +++++++++++++++++++
2 files changed, 60 insertions(+), 22 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
create mode 100644 Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml
diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
deleted file mode 100644
index 72d3cf4c2606..000000000000
--- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-ROCKCHIP with MAX98357A/RT5514/DA7219 codecs on GRU boards
-
-Required properties:
-- compatible: "rockchip,rk3399-gru-sound"
-- rockchip,cpu: The phandle of the Rockchip I2S controller that's
- connected to the codecs
-- rockchip,codec: The phandle of the audio codecs
-
-Optional properties:
-- dmic-wakeup-delay-ms : specify delay time (ms) for DMIC ready.
- If this option is specified, which means it's required dmic need
- delay for DMIC to ready so that rt5514 can avoid recording before
- DMIC send valid data
-
-Example:
-
-sound {
- compatible = "rockchip,rk3399-gru-sound";
- rockchip,cpu = <&i2s0>;
- rockchip,codec = <&max98357a &rt5514 &da7219>;
- dmic-wakeup-delay-ms = <20>;
-};
diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml
new file mode 100644
index 000000000000..e9d13695cc77
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/rockchip,rk3399-gru-sound.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip with MAX98357A/RT5514/DA7219 codecs on GRU boards
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ const: rockchip,rk3399-gru-sound
+
+ rockchip,cpu:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ List of phandles to the Rockchip CPU DAI controllers connected to codecs
+ minItems: 1
+ items:
+ - items:
+ - description: Phandle to the Rockchip I2S controllers
+ - items:
+ - description: |
+ Phandle to the Rockchip SPDIF controller. Required when a
+ DisplayPort audio codec is referenced in rockchip,codec
+
+ rockchip,codec:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ The phandles of the audio codecs connected to the Rockchip CPU DAI
+ controllers
+ minItems: 1
+ maxItems: 6
+ items:
+ maxItems: 1
+
+ dmic-wakeup-delay-ms:
+ description: |
+ specify delay time (ms) for DMIC ready.
+ If this option is specified, a delay is required for DMIC to get ready
+ so that rt5514 can avoid recording before DMIC sends valid data
+
+required:
+ - compatible
+ - rockchip,cpu
+ - rockchip,codec
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "rockchip,rk3399-gru-sound";
+ rockchip,cpu = <&i2s0 &spdif>;
+ rockchip,codec = <&max98357a &rt5514 &da7219 &cdn_dp>;
+ dmic-wakeup-delay-ms = <20>;
+ };
+
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 4/8] clk: qcom: videocc: Add video clock controller driver for Eliza
From: Taniya Das @ 2026-04-10 5:46 UTC (permalink / raw)
To: Jie Gan, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Maxime Coquelin, Alexandre Torgue
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Konrad Dybcio
In-Reply-To: <c7706c41-d855-4ed4-92c4-dca43c8f6d2a@oss.qualcomm.com>
On 4/10/2026 10:18 AM, Jie Gan wrote:
>> + depends on ARM64 || COMPILE_TEST
>> + select CLK_GLYMUR_GCC
>
> Hi,
>
> My bot found a [BUG] here, please ignore it if it's a false positive issue.
>
> CLK_ELIZA_VIDEOCC selects CLK_GLYMUR_GCC instead of CLK_ELIZA_GCC
>
> - select CLK_GLYMUR_GCC pulls in gcc-glymur.c instead of gcc-eliza.c
> - On an Eliza system, gcc-glymur.c will never probe (no matching DTS
> node), so GCC_VIDEO_AHB_CLK from the Eliza GCC will never be available
> to videocc
> - The videocc driver's clocks = <&gcc GCC_VIDEO_AHB_CLK> will fail to
> resolve at runtime
> - The correct fix is select CLK_ELIZA_GCC, consistent with all other
> Eliza clock controllers
>
Thanks, Jie for pointing out, will fix this.
GCC of ELIZA is already 'y' and Video driver probes as this
GCC_VIDEO_AHB_CLK is kept enabled/critical.
Please find the 'clk_summary' from device.
bi-tcxo-div2-clk 1 1 0 19200000
0 0 50000 Y deviceless
no_connection_id
video_cc_xo_clk_src 0 0 0 19200000
0 0 50000 ? deviceless
no_connection_id
video_cc_mvs0_shift_clk 0 0 0 19200000
0 0 50000 N deviceless
no_connection_id
video_cc_mvs0c_shift_clk 0 0 0 19200000
0 0 50000 N deviceless
no_connection_id
video_cc_pll0 0 0 0 576000000
0 0 50000 N deviceless
no_connection_id
video_cc_mvs0_clk_src 0 0 0 19200000
0 0 50000 ? deviceless
no_connection_id
video_cc_mvs0c_div2_div_clk_src 0 0 0
9600000 0 0 50000 Y deviceless
no_connection_id
video_cc_mvs0c_clk 0 0 0 9600000
0 0 50000 N deviceless
no_connection_id
video_cc_mvs0_div_clk_src 0 0 0 6400000
0 0 50000 Y deviceless
no_connection_id
video_cc_mvs0_clk 0 0 0 6400000
0 0 50000 N deviceless
no_connection_id
video_cc_ahb_clk_src 0 0 0 19200000
0 0 50000 ? deviceless
no_connection_id
--
Thanks,
Taniya Das
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox