* Re: [PATCH V2 1/3] dt-bindings: dma: xilinx: Add optional resets property for ZDMA
From: Krzysztof Kozlowski @ 2026-06-22 11:02 UTC (permalink / raw)
To: Golla Nagendra
Cc: vkoul, Frank.Li, michal.simek, robh, krzk+dt, conor+dt,
jay.buddhabhatti, harini.katakam, m.tretter, radhey.shyam.pandey,
abin.joseph, kees, sakari.ailus, git, dmaengine, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260618071056.2024286-2-nagendra.golla@amd.com>
On Thu, Jun 18, 2026 at 12:40:54PM +0530, Golla Nagendra wrote:
> From: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
>
> Newer SoCs such as Versal Gen2 and Versal‑Net expose a reset line
> for ZDMA. Older SoCs do not have this provision. Add an optional
> resets property to describe this reset.
It should be then restricted further per each variant/device in
allOf:if:then: (see example-schema for syntax - ": false").
>
> Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
> Co-developed-by: Golla Nagendra <nagendra.golla@amd.com>
> Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: display: panel: add Ilitek ILI7807S panel controller
From: Krzysztof Kozlowski @ 2026-06-22 11:04 UTC (permalink / raw)
To: Arpit Saini
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, dri-devel,
devicetree, linux-kernel, ayushi.makhija, rajeevny
In-Reply-To: <20260618-ili7807s-v2-1-b3f0c109b102@oss.qualcomm.com>
On Thu, Jun 18, 2026 at 03:54:02PM +0530, Arpit Saini wrote:
> ILI7807S is a DSI display controller used to drive MIPI-DSI panels.
> The DLC DLC0697 1080x1920 LCD panel is based on this controller.
>
> The panel requires a reset GPIO, I/O voltage supply (vddi), positive
> LCD bias supply (avdd) and negative LCD bias supply (avee). The panel
> operates in video burst mode with four data lanes using RGB888 pixel
> format.
>
> Signed-off-by: Arpit Saini <arpit.saini@oss.qualcomm.com>
> ---
> .../bindings/display/panel/ilitek,ili7807s.yaml | 71 ++++++++++++++++++++++
> 1 file changed, 71 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: power: supply: Add TI BQ25630 charger
From: Krzysztof Kozlowski @ 2026-06-22 11:06 UTC (permalink / raw)
To: Waqar Hameed
Cc: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
kernel, linux-pm, devicetree, linux-kernel
In-Reply-To: <96b7d1a0aa0c00929f0fef2847db116b54079a30.1781789320.git.waqarh@axis.com>
On Thu, Jun 18, 2026 at 03:37:59PM +0200, Waqar Hameed wrote:
> +allOf:
> + - $ref: power-supply.yaml#
> +
> +properties:
> + compatible:
> + const: ti,bq25630
> +
> + reg:
> + const: 0x6b
> + description:
> + Device I2C address.
Drop description, obvious.
> +
> + interrupts:
> + maxItems: 1
> + description: |
Do not need '|' unless you need to preserve formatting.
> + Device sends active low 256 µs pulse. Type should therefore be
> + IRQ_TYPE_EDGE_FALLING.
> +
> + monitored-battery: true
Drop this one
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - monitored-battery
> +
> +additionalProperties: false
And here use 'unevaluatedProperties: false' instead.
With these fixed:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Niklas Söderlund @ 2026-06-22 11:08 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Sebastian Reichel, Javier Martinez Canillas, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Wesley Cheng, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel, linux-samsung-soc, linux-clk, dri-devel,
freedreno, linux-i2c, linux-pm, linux-leds, linux-media,
linux-mmc, linux-phy, linux-gpio, linux-renesas-soc, linux-serial,
linux-sound, linux-usb
In-Reply-To: <20260622101606.485961-4-krzysztof.kozlowski@oss.qualcomm.com>
Hi Krzysztof,
Thanks for your work.
On 2026-06-22 12:16:08 +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
For the two Renesas bindings,
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
>
> ---
>
> Intention for this patch is to go via Rob's tree.
> ---
> .../devicetree/bindings/arm/qcom-soc.yaml | 4 ++--
> .../devicetree/bindings/arm/qcom.yaml | 4 ++--
> .../bindings/arm/samsung/samsung-soc.yaml | 4 ++--
> .../display/msm/dsi-controller-main.yaml | 20 +++++++++----------
> .../display/samsung/samsung,fimd.yaml | 4 ++--
> .../bindings/i2c/samsung,s3c2410-i2c.yaml | 2 +-
> .../interconnect/qcom,msm8998-bwmon.yaml | 2 +-
> .../interconnect/samsung,exynos-bus.yaml | 14 ++++++-------
> .../bindings/leds/qcom,pm8058-led.yaml | 4 ++--
> .../bindings/leds/skyworks,aat1290.yaml | 6 +++---
> .../bindings/media/cec/cec-gpio.yaml | 2 +-
> .../bindings/mmc/samsung,exynos-dw-mshc.yaml | 2 +-
> .../devicetree/bindings/mux/mux-consumer.yaml | 4 ++--
> .../bindings/phy/samsung,mipi-video-phy.yaml | 4 ++--
> .../bindings/phy/samsung,usb2-phy.yaml | 2 +-
> .../bindings/phy/samsung,usb3-drd-phy.yaml | 2 +-
> .../bindings/pinctrl/samsung,pinctrl.yaml | 2 +-
> .../bindings/power/renesas,rcar-sysc.yaml | 2 +-
> .../bindings/power/reset/restart-handler.yaml | 8 ++++----
> .../bindings/regulator/maxim,max77802.yaml | 4 ++--
> .../bindings/regulator/richtek,rtq2208.yaml | 2 +-
> .../bindings/serial/qcom,msm-uartdm.yaml | 2 +-
> .../devicetree/bindings/slimbus/slimbus.yaml | 4 ++--
> .../bindings/soc/qcom/qcom,apr-services.yaml | 2 +-
> .../bindings/soc/qcom/qcom,rpmh-rsc.yaml | 8 ++++----
> .../bindings/soc/qcom/qcom,wcnss.yaml | 2 +-
> .../bindings/soc/renesas/renesas-soc.yaml | 4 ++--
> .../bindings/sound/qcom,q6asm-dais.yaml | 2 +-
> .../thermal/samsung,exynos-thermal.yaml | 4 ++--
> .../devicetree/bindings/usb/qcom,dwc3.yaml | 12 +++++------
> .../bindings/usb/qcom,snps-dwc3.yaml | 12 +++++------
> 31 files changed, 75 insertions(+), 75 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/qcom-soc.yaml b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
> index 27261039d56f..37fdd5a080b7 100644
> --- a/Documentation/devicetree/bindings/arm/qcom-soc.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
> @@ -11,10 +11,10 @@ maintainers:
>
> description: |
> Guidelines for new compatibles for SoC blocks/components.
> - When adding new compatibles in new bindings, use the format::
> + When adding new compatibles in new bindings, use the format:
> qcom,SoC-IP
>
> - For example::
> + For example:
> qcom,sdm845-llcc-bwmon
>
> When adding new compatibles to existing bindings, use the format in the
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index 50cc18a6ec5e..667607ae2c32 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -1215,7 +1215,7 @@ properties:
> items:
> items:
> - description: |
> - MSM chipset ID - an exact match value consisting of two bitfields::
> + MSM chipset ID - an exact match value consisting of two bitfields:
> - bits 0-15 - The unique MSM chipset ID
> - bits 16-31 - Reserved; should be 0
> - description: |
> @@ -1241,7 +1241,7 @@ properties:
> - items:
> - items:
> - description: |
> - Board ID consisting of three bitfields::
> + Board ID consisting of three bitfields:
> - bits 31-24 - Unused
> - bits 23-16 - Platform Version Major
> - bits 15-8 - Platform Version Minor
> diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
> index 653f85997643..ab000befe76d 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
> +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
> @@ -11,10 +11,10 @@ maintainers:
>
> description: |
> Guidelines for new compatibles for SoC blocks/components.
> - When adding new compatibles in new bindings, use the format::
> + When adding new compatibles in new bindings, use the format:
> samsung,SoC-IP
>
> - For example::
> + For example:
> samsung,exynos5433-cmu-isp
>
> select:
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
> index dbc0613e427e..395425a70db8 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
> @@ -73,16 +73,16 @@ properties:
>
> clocks:
> description: |
> - Several clocks are used, depending on the variant. Typical ones are::
> - - bus:: Display AHB clock.
> - - byte:: Display byte clock.
> - - byte_intf:: Display byte interface clock.
> - - core:: Display core clock.
> - - core_mss:: Core MultiMedia SubSystem clock.
> - - iface:: Display AXI clock.
> - - mdp_core:: MDP Core clock.
> - - mnoc:: MNOC clock
> - - pixel:: Display pixel clock.
> + Several clocks are used, depending on the variant. Typical ones are:
> + - bus: Display AHB clock.
> + - byte: Display byte clock.
> + - byte_intf: Display byte interface clock.
> + - core: Display core clock.
> + - core_mss: Core MultiMedia SubSystem clock.
> + - iface: Display AXI clock.
> + - mdp_core: MDP Core clock.
> + - mnoc: MNOC clock
> + - pixel: Display pixel clock.
> minItems: 3
> maxItems: 12
>
> diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
> index ff685031bb2c..729705f419bb 100644
> --- a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
> +++ b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
> @@ -41,7 +41,7 @@ properties:
> additionalProperties: false
> description: |
> Timing configuration for lcd i80 interface support.
> - The parameters are defined as::
> + The parameters are defined as:
> VCLK(internal) __|??????|_____|??????|_____|??????|_____|??????|_____|??
> : : : : :
> Address Output --:<XXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XX
> @@ -132,7 +132,7 @@ patternProperties:
> "^port@[0-4]+$":
> $ref: /schemas/graph.yaml#/properties/port
> description: |
> - Contains ports with port with index::
> + Contains ports with port with index:
> 0 - for CAMIF0 input,
> 1 - for CAMIF1 input,
> 2 - for CAMIF2 input,
> diff --git a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
> index a2ddc6803617..07600b49f2f9 100644
> --- a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
> @@ -35,7 +35,7 @@ properties:
>
> gpios:
> description: |
> - The order of the GPIOs should be the following:: <SDA, SCL>. The GPIO
> + The order of the GPIOs should be the following: <SDA, SCL>. The GPIO
> specifier depends on the gpio controller. Required in all cases except
> for "samsung,s3c2440-hdmiphy-i2c" whose input/output lines are
> permanently wired to the respective client.
> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
> index ff64225e8281..e002e70580f9 100644
> --- a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
> +++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
> @@ -13,7 +13,7 @@ description: |
> Bandwidth Monitor measures current throughput on buses between various NoC
> fabrics and provides information when it crosses configured thresholds.
>
> - Certain SoCs might have more than one Bandwidth Monitors, for example on SDM845::
> + Certain SoCs might have more than one Bandwidth Monitors, for example on SDM845:
> - Measuring the bandwidth between CPUs and Last Level Cache Controller -
> called just BWMON,
> - Measuring the bandwidth between Last Level Cache Controller and memory
> diff --git a/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
> index 5e26e48c7217..0203959c8995 100644
> --- a/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
> +++ b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
> @@ -23,7 +23,7 @@ description: |
> The each AXI bus has the owned source clock but, has not the only owned power
> line. The power line might be shared among one more sub-blocks. So, we can
> divide into two type of device as the role of each sub-block. There are two
> - type of bus devices as following::
> + type of bus devices as following:
> - parent bus device
> - passive bus device
>
> @@ -44,8 +44,8 @@ description: |
> able to support the bus frequency for all Exynos SoCs.
>
> Detailed correlation between sub-blocks and power line according
> - to Exynos SoC::
> - - In case of Exynos3250, there are two power line as following::
> + to Exynos SoC:
> + - In case of Exynos3250, there are two power line as following:
> VDD_MIF |--- DMC (Dynamic Memory Controller)
>
> VDD_INT |--- LEFTBUS (parent device)
> @@ -89,7 +89,7 @@ description: |
> |L5 |200000 |200000 |400000 |300000 | ||1000000 |
> ----------------------------------------------------------
>
> - - In case of Exynos4210, there is one power line as following::
> + - In case of Exynos4210, there is one power line as following:
> VDD_INT |--- DMC (parent device, Dynamic Memory Controller)
> |--- LEFTBUS
> |--- PERIL
> @@ -106,7 +106,7 @@ description: |
> |--- LCD0
> |--- LCD1
>
> - - In case of Exynos4x12, there are two power line as following::
> + - In case of Exynos4x12, there are two power line as following:
> VDD_MIF |--- DMC (Dynamic Memory Controller)
>
> VDD_INT |--- LEFTBUS (parent device)
> @@ -124,7 +124,7 @@ description: |
> |--- LCD0
> |--- ISP
>
> - - In case of Exynos5422, there are two power line as following::
> + - In case of Exynos5422, there are two power line as following:
> VDD_MIF |--- DREX 0 (parent device, DRAM EXpress controller)
> |--- DREX 1
>
> @@ -143,7 +143,7 @@ description: |
> |--- FSYS
> |--- FSYS2
>
> - - In case of Exynos5433, there is VDD_INT power line as following::
> + - In case of Exynos5433, there is VDD_INT power line as following:
> VDD_INT |--- G2D (parent device)
> |--- MSCL
> |--- GSCL
> diff --git a/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml b/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
> index b409b2a8b5c5..5165bfddcd54 100644
> --- a/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
> +++ b/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
> @@ -10,10 +10,10 @@ maintainers:
> - Krzysztof Kozlowski <krzk@kernel.org>
>
> description: |
> - The Qualcomm PM8058 contains an LED block for up to six LEDs:: three normal
> + The Qualcomm PM8058 contains an LED block for up to six LEDs: three normal
> LEDs, two "flash" LEDs and one "keypad backlight" LED. The names are quoted
> because sometimes these LED drivers are used for wildly different things than
> - flash or keypad backlight:: their names are more of a suggestion than a
> + flash or keypad backlight: their names are more of a suggestion than a
> hard-wired usecase.
>
> Hardware-wise the different LEDs support slightly different output currents.
> diff --git a/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml b/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
> index a6aaa92dbccd..65576dfdca11 100644
> --- a/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
> +++ b/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
> @@ -11,7 +11,7 @@ maintainers:
> - Krzysztof Kozlowski <krzk@kernel.org>
>
> description: |
> - The device is controlled through two pins:: FL_EN and EN_SET. The pins when,
> + The device is controlled through two pins: FL_EN and EN_SET. The pins when,
> asserted high, enable flash strobe and movie mode (max 1/2 of flash current)
> respectively. In order to add a capability of selecting the strobe signal
> source (e.g. CPU or camera sensor) there is an additional switch required,
> @@ -39,11 +39,11 @@ properties:
> flash-max-microamp:
> description: |
> Maximum flash LED supply current can be calculated using following
> - formula:: I = 1A * 162 kOhm / Rset.
> + formula: I = 1A * 162 kOhm / Rset.
>
> flash-max-timeout-us:
> description: |
> - Maximum flash timeout can be calculated using following formula::
> + Maximum flash timeout can be calculated using following formula:
> T = 8.82 * 10^9 * Ct.
>
> required:
> diff --git a/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml b/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
> index 582c6c9cae48..21118e4bae0f 100644
> --- a/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
> +++ b/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
> @@ -14,7 +14,7 @@ description: |
> hooked up to a pull-up GPIO line and - optionally - the HPD line is hooked up
> to another GPIO line.
>
> - Please note:: the maximum voltage for the CEC line is 3.63V, for the HPD and
> + Please note: the maximum voltage for the CEC line is 3.63V, for the HPD and
> 5V lines it is 5.3V. So you may need some sort of level conversion
> circuitry when connecting them to a GPIO line.
>
> diff --git a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
> index 27c4060f2f91..223fcc9f651f 100644
> --- a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
> +++ b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
> @@ -85,7 +85,7 @@ properties:
> description: |
> The value of CIU TX and RX clock phase shift value for HS400 mode
> operation.
> - Valid values for SDR and DDR CIU clock timing::
> + Valid values for SDR and DDR CIU clock timing:
> - valid value for tx phase shift and rx phase shift is 0 to 7.
> - when CIU clock divider value is set to 3, all possible 8 phase shift
> values can be used.
> diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> index 9e2d78a78e40..769243a2bf04 100644
> --- a/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> +++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> @@ -13,8 +13,8 @@ description: |
> Mux controller consumers should specify a list of mux controllers that they
> want to use with a property containing a 'mux-ctrl-list':
>
> - mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list]
> - single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier]
> + mux-ctrl-list := <single-mux-ctrl> [mux-ctrl-list]
> + single-mux-ctrl := <mux-ctrl-phandle> [mux-ctrl-specifier]
> mux-ctrl-phandle : phandle to mux controller node
> mux-ctrl-specifier : array of #mux-control-cells specifying the
> given mux controller (controller specific)
> diff --git a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
> index 16967ef8e9ec..87b6a35b2626 100644
> --- a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
> @@ -13,14 +13,14 @@ maintainers:
>
> description: |
> For samsung,s5pv210-mipi-video-phy compatible PHYs the second cell in the
> - PHY specifier identifies the PHY and its meaning is as follows::
> + PHY specifier identifies the PHY and its meaning is as follows:
> 0 - MIPI CSIS 0,
> 1 - MIPI DSIM 0,
> 2 - MIPI CSIS 1,
> 3 - MIPI DSIM 1.
>
> samsung,exynos5420-mipi-video-phy and samsung,exynos5433-mipi-video-phy
> - support additional fifth PHY::
> + support additional fifth PHY:
> 4 - MIPI CSIS 2.
>
> properties:
> diff --git a/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
> index d9f22a801cbf..7db7605a82e2 100644
> --- a/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
> @@ -14,7 +14,7 @@ maintainers:
> description: |
> The first phandle argument in the PHY specifier identifies the PHY, its
> meaning is compatible dependent. For the currently supported SoCs (Exynos4210
> - and Exynos4212) it is as follows::
> + and Exynos4212) it is as follows:
> 0 - USB device ("device"),
> 1 - USB host ("host"),
> 2 - HSIC0 ("hsic0"),
> diff --git a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
> index 4562e0468f4f..a1b3d9e6a094 100644
> --- a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
> @@ -14,7 +14,7 @@ maintainers:
> description: |
> For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
> compatible PHYs, the second cell in the PHY specifier identifies the
> - PHY id, which is interpreted as follows::
> + PHY id, which is interpreted as follows:
> 0 - UTMI+ type phy,
> 1 - PIPE3 type phy.
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> index 7b006009ca0e..5e35686eeed3 100644
> --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> @@ -18,7 +18,7 @@ description: |
> All the pin controller nodes should be represented in the aliases node using
> the following format 'pinctrl{n}' where n is a unique number for the alias.
>
> - The controller supports three types of interrupts::
> + The controller supports three types of interrupts:
> - External GPIO interrupts (see interrupts property in pin controller node);
>
> - External wake-up interrupts - multiplexed (capable of waking up the system
> diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
> index 347571e2545a..b67aa170b2c1 100644
> --- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
> +++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
> @@ -13,7 +13,7 @@ maintainers:
> description: |
> The R-Car (RZ/G) System Controller provides power management for the CPU
> cores and various coprocessors.
> - The power domain IDs for consumers are defined in header files::
> + The power domain IDs for consumers are defined in header files:
> include/dt-bindings/power/r8*-sysc.h
>
> properties:
> diff --git a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
> index 965a834a3dbe..00c00ec5ec81 100644
> --- a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
> +++ b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
> @@ -18,12 +18,12 @@ properties:
> priority:
> $ref: /schemas/types.yaml#/definitions/uint32
> description: |
> - A priority ranging from 0 to 255 according to the following guidelines::
> - 0:: Restart handler of last resort, with limited restart capabilities.
> - 128:: Typical, default restart handler; use if no other restart handler
> + A priority ranging from 0 to 255 according to the following guidelines:
> + 0: Restart handler of last resort, with limited restart capabilities.
> + 128: Typical, default restart handler; use if no other restart handler
> is expected to be available, and/or if restart functionality is
> sufficient to restart the entire system.
> - 255:: Highest priority restart handler, will preempt all other restart handlers.
> + 255: Highest priority restart handler, will preempt all other restart handlers.
> minimum: 0
> maximum: 255
>
> diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
> index b704f05ea454..b886495c1396 100644
> --- a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
> +++ b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
> @@ -22,13 +22,13 @@ description: |
>
> Certain regulators support "regulator-initial-mode" and "regulator-mode".
> The valid modes list is defined in the dt-bindings/regulator/maxim,max77802.h
> - and their meaning is::
> + and their meaning is:
> 1 - Normal regulator voltage output mode.
> 3 - Low Power which reduces the quiescent current down to only 1uA
>
> The standard "regulator-mode" property can only be used for regulators that
> support changing their mode to Low Power Mode during suspend. These
> - regulators are:: bucks 2-4 and LDOs 1-35. Also, it only takes effect if the
> + regulators are: bucks 2-4 and LDOs 1-35. Also, it only takes effect if the
> regulator has been enabled for the given suspend state using
> "regulator-on-in-suspend" and has not been disabled for that state using
> "regulator-off-in-suspend".
> diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
> index 022c1f197364..b0aa38edf8c2 100644
> --- a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
> +++ b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
> @@ -21,7 +21,7 @@ description: |
> conduction mode (FCCM).
>
> The definition of modes is in the datasheet which is available in below link
> - and their meaning is::
> + and their meaning is:
> 0 - Auto mode for power saving, which reducing the switching frequency at light load condition
> to maintain high frequency.
> 1 - FCCM to meet the strict voltage regulation accuracy, which keeping constant switching frequency.
> diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
> index 788ef5c1c446..bc967ead2350 100644
> --- a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
> +++ b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
> @@ -17,7 +17,7 @@ description: |
> software perspective it's mostly compatible with the MSM serial UART except
> that it supports reading and writing multiple characters at a time.
>
> - Note:: Aliases may be defined to ensure the correct ordering of the UARTs.
> + Note: Aliases may be defined to ensure the correct ordering of the UARTs.
> The alias serialN will result in the UART being assigned port N. If any
> serialN alias exists, then an alias must exist for each enabled UART. The
> serialN aliases should be in a .dts file instead of in a .dtsi file.
> diff --git a/Documentation/devicetree/bindings/slimbus/slimbus.yaml b/Documentation/devicetree/bindings/slimbus/slimbus.yaml
> index 5a941610ce4e..3910327c8ded 100644
> --- a/Documentation/devicetree/bindings/slimbus/slimbus.yaml
> +++ b/Documentation/devicetree/bindings/slimbus/slimbus.yaml
> @@ -29,7 +29,7 @@ patternProperties:
> description: |
> Every SLIMbus controller node can contain zero or more child nodes
> representing slave devices on the bus. Every SLIMbus slave device is
> - uniquely determined by the enumeration address containing 4 fields::
> + uniquely determined by the enumeration address containing 4 fields:
> Manufacturer ID, Product code, Device index, and Instance value for the
> device.
>
> @@ -48,7 +48,7 @@ patternProperties:
> reg:
> maxItems: 1
> description: |
> - Pair of (device index, instande ID), where::
> + Pair of (device index, instande ID), where:
> - Device index, which uniquely identifies multiple devices within a
> single component.
> - Instance ID, can be used for the cases where multiple devices of
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
> index bdf482db32aa..b663be3ea5a1 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
> @@ -40,7 +40,7 @@ properties:
> $ref: /schemas/types.yaml#/definitions/string-array
> description: |
> Protection domain service name and path for APR service (if supported).
> - Possible values are::
> + Possible values are:
> "avs/audio", "msm/adsp/audio_pd".
> "kernel/elf_loader", "msm/modem/wlan_pd".
> "tms/servreg", "msm/adsp/audio_pd".
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
> index 26d9bc773ec5..1889139a3f7a 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
> @@ -23,7 +23,7 @@ description: |
> with a few variations that are captured by the properties here.
>
> A TCS may be triggered from Linux or triggered by the F/W after all the CPUs
> - have powered off to facilitate idle power saving. TCS could be classified as::
> + have powered off to facilitate idle power saving. TCS could be classified as:
> ACTIVE - Triggered by Linux
> SLEEP - Triggered by F/W
> WAKE - Triggered by F/W
> @@ -76,7 +76,7 @@ properties:
> items:
> items:
> - description: |
> - TCS type::
> + TCS type:
> - ACTIVE_TCS
> - SLEEP_TCS
> - WAKE_TCS
> @@ -152,7 +152,7 @@ examples:
> - |
> // For a TCS whose RSC base address is 0x179C0000 and is at a DRV id of
> // 2, the register offsets for DRV2 start at 0D00, the register
> - // calculations are like this::
> + // calculations are like this:
> // DRV0: 0x179C0000
> // DRV2: 0x179C0000 + 0x10000 = 0x179D0000
> // DRV2: 0x179C0000 + 0x10000 * 2 = 0x179E0000
> @@ -182,7 +182,7 @@ examples:
> - |
> // For a TCS whose RSC base address is 0xAF20000 and is at DRV id of 0, the
> // register offsets for DRV0 start at 01C00, the register calculations are
> - // like this::
> + // like this:
> // DRV0: 0xAF20000
> // TCS-OFFSET: 0x1C00
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
> index 4fcae6bedfff..72a7f8cb09ba 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
> @@ -28,7 +28,7 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle
> description: |
> Reference to a node specifying the wcnss "ccu" and "dxe" register blocks.
> - The node must be compatible with one of the following::
> + The node must be compatible with one of the following:
> - qcom,riva"
> - qcom,pronto"
>
> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
> index 5ddd31f30f26..57c9d3c57021 100644
> --- a/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
> @@ -12,10 +12,10 @@ maintainers:
>
> description: |
> Guidelines for new compatibles for SoC blocks/components.
> - When adding new compatibles in new bindings, use the format::
> + When adding new compatibles in new bindings, use the format:
> renesas,SoC-IP
>
> - For example::
> + For example:
> renesas,r8a77965-csi2
>
> When adding new compatibles to existing bindings, use the format in the
> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
> index 47a105a97ecf..bc8c8ba24f9c 100644
> --- a/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
> +++ b/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
> @@ -45,7 +45,7 @@ patternProperties:
> $ref: /schemas/types.yaml#/definitions/uint32
> enum: [0, 1, 2]
> description: |
> - The direction of the dai stream::
> + The direction of the dai stream:
> - Q6ASM_DAI_TX_RX (0) for both tx and rx
> - Q6ASM_DAI_TX (1) for only tx (Capture/Encode)
> - Q6ASM_DAI_RX (2) for only rx (Playback/Decode)
> diff --git a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
> index 29a08b0729ee..3f333db72a71 100644
> --- a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
> +++ b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
> @@ -40,7 +40,7 @@ properties:
> description: |
> The Exynos TMU supports generating interrupts when reaching given
> temperature thresholds. Number of supported thermal trip points depends
> - on the SoC (only first trip points defined in DT will be configured)::
> + on the SoC (only first trip points defined in DT will be configured):
> - most of SoC: 4
> - samsung,exynos5433-tmu: 8
> - samsung,exynos7-tmu: 8
> @@ -52,7 +52,7 @@ properties:
> - description: |
> Shared TMU registers.
>
> - Note:: On Exynos5420, the TRIMINFO register is misplaced for TMU
> + Note: On Exynos5420, the TRIMINFO register is misplaced for TMU
> channels 2, 3 and 4 Use "samsung,exynos5420-tmu-ext-triminfo" in
> cases, there is a misplaced register, also provide clock to access
> that base.
> diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
> index a7f58114c02e..90daee616880 100644
> --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
> +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
> @@ -92,14 +92,14 @@ properties:
>
> clocks:
> description: |
> - Several clocks are used, depending on the variant. Typical ones are::
> - - cfg_noc:: System Config NOC clock.
> - - core:: Master/Core clock, has to be >= 125 MHz for SS operation and >=
> + Several clocks are used, depending on the variant. Typical ones are:
> + - cfg_noc: System Config NOC clock.
> + - core: Master/Core clock, has to be >= 125 MHz for SS operation and >=
> 60MHz for HS operation.
> - - iface:: System bus AXI clock.
> - - sleep:: Sleep clock, used for wakeup when USB3 core goes into low
> + - iface: System bus AXI clock.
> + - sleep: Sleep clock, used for wakeup when USB3 core goes into low
> power mode (U3).
> - - mock_utmi:: Mock utmi clock needed for ITP/SOF generation in host
> + - mock_utmi: Mock utmi clock needed for ITP/SOF generation in host
> mode. Its frequency should be 19.2MHz.
> minItems: 1
> maxItems: 9
> diff --git a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
> index 8201656b41ed..d99af9f413d0 100644
> --- a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
> +++ b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
> @@ -87,14 +87,14 @@ properties:
>
> clocks:
> description: |
> - Several clocks are used, depending on the variant. Typical ones are::
> - - cfg_noc:: System Config NOC clock.
> - - core:: Master/Core clock, has to be >= 125 MHz for SS operation and >=
> + Several clocks are used, depending on the variant. Typical ones are:
> + - cfg_noc: System Config NOC clock.
> + - core: Master/Core clock, has to be >= 125 MHz for SS operation and >=
> 60MHz for HS operation.
> - - iface:: System bus AXI clock.
> - - sleep:: Sleep clock, used for wakeup when USB3 core goes into low
> + - iface: System bus AXI clock.
> + - sleep: Sleep clock, used for wakeup when USB3 core goes into low
> power mode (U3).
> - - mock_utmi:: Mock utmi clock needed for ITP/SOF generation in host
> + - mock_utmi: Mock utmi clock needed for ITP/SOF generation in host
> mode. Its frequency should be 19.2MHz.
> minItems: 1
> maxItems: 9
> --
> 2.53.0
>
--
Kind Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH v5 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: linux-kernel-dev @ 2026-06-22 11:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Conor Dooley, Guillaume La Roque,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
In-Reply-To: <2e2a93c7-6bf9-49f2-95ed-f44cf767e9fd@kernel.org>
On 6/22/26 12:02 PM, Krzysztof Kozlowski wrote:
> On 24/04/2026 17:45, Ronald Claveau via B4 Relay wrote:
>> + - |
>> + temperature-sensor@20000 {
>> + compatible = "amlogic,t7-thermal";
>> + reg = <0x0 0x20000 0x0 0x50>;
>> + interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
>
>
> This wasn't ever even built! Really, it fails immediately. I will send
> fixes, but quite disappointing that contributor does not test its own code.-
>
My bad, I thought that `CHECK_DTBS=y` was enough to test
`dt_binding_check` as well. I add it again to my build tests.
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH v3 2/3] arm64: dts: qcom: shikra: Add Iris video codec node
From: Bryan O'Donoghue @ 2026-06-22 11:20 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel,
Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <20260618-shikra_vpu-v3-2-1a32e26a35a1@oss.qualcomm.com>
On 18/06/2026 11:39, Vikash Garodia wrote:
> + memory-region = <&video_mem>;
I'll reiterate, again...
Since we know there is a problem with non-pixel allocations < 600 MB,
submission _must_ address that.
Its irrelevant that something upstream already does the wrong thing.
Please fix this.
---
bod
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible
From: Bryan O'Donoghue @ 2026-06-22 11:23 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel
In-Reply-To: <20260618-shikra_vpu-v3-1-1a32e26a35a1@oss.qualcomm.com>
On 18/06/2026 11:39, Vikash Garodia wrote:
> Document the iris video accelerator used on shikra platforms by adding
> the qcom,shikra-iris compatible.
>
> Although QCM2290 and shikra share the same video hardware and overall
> integration, their SMMU programming differs. QCM2290 exposes separate
> stream IDs for the video hardware and the Xtensa path, requiring two
> explicit IOMMU entries, whereas shikra uses a masked SMR to collapse
> equivalent stream IDs into a single mapping. Due to QCM2290’s SID layout
> and Xtensa isolation requirements, such SMR masking is not applicable on
> QCM2290 platforms.
> Since shikra uses the same video hardware as QCM2290 and shares the same
> programming model and capabilities, it is added as a fallback compatible
> to qcom,qcm2290-venus, with conditional handling to allow either one or
> two IOMMU entries.
>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,qcm2290-venus.yaml | 26 ++++++++++++++++------
> 1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
> index 5977e7d0a71b4fb5681f1c2094439c251366f01f..b27899ebf164229ceff1ca5cda50ee30d875e953 100644
> --- a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
> @@ -13,14 +13,13 @@ description:
> The Venus AR50_LITE IP is a video encode and decode accelerator present
> on Qualcomm platforms.
>
> -allOf:
> - - $ref: qcom,venus-common.yaml#
> -
> properties:
> compatible:
> oneOf:
> - items:
> - - const: qcom,sm6115-venus
> + - enum:
> + - qcom,shikra-venus
> + - qcom,sm6115-venus
> - const: qcom,qcm2290-venus
> - const: qcom,qcm2290-venus
>
> @@ -45,9 +44,6 @@ properties:
> - const: vcodec0_core
> - const: vcodec0_bus
>
> - iommus:
> - maxItems: 2
> -
> interconnects:
> maxItems: 2
>
> @@ -65,6 +61,22 @@ required:
> - power-domain-names
> - iommus
>
> +allOf:
> + - $ref: qcom,venus-common.yaml#
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: qcom,shikra-venus
> + then:
> + properties:
> + iommus:
> + maxItems: 1
> + else:
> + properties:
> + iommus:
> + maxItems: 2
> +
> unevaluatedProperties: false
>
> examples:
>
> --
> 2.34.1
>
NAK.
Fix the 600MB limit in the submission. Its already been flagged more
than once.
---
bod
^ permalink raw reply
* Re: [PATCH v2 0/2] ARM: dts: renesas: r9a06g032-rzn1d400-eb: Enable SPI and FRAM
From: Herve Codina @ 2026-06-22 11:28 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-renesas-soc, Conor Dooley, devicetree, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring
In-Reply-To: <20260615125355.116027-1-wsa+renesas@sang-engineering.com>
Hi Wolfram,
On Mon, 15 Jun 2026 14:53:52 +0200
Wolfram Sang <wsa+renesas@sang-engineering.com> wrote:
> Here are the patches to enable the SPI-FRAM with FIFO (no DMA yet, needs
> more work) on the RZ/N1D Extension board.
>
> Changes since v1 in the individual patches.
>
> Wolfram Sang (2):
> ARM: dts: renesas: r9a06g032: Describe SPI controllers
> ARM: dts: renesas: r9a06g032-rzn1d400-eb: Enable SPI-FRAM
>
> .../dts/renesas/r9a06g032-rzn1d400-eb.dts | 25 ++++++
> arch/arm/boot/dts/renesas/r9a06g032.dtsi | 84 +++++++++++++++++++
> 2 files changed, 109 insertions(+)
>
The 'make CHECK_DTBS=1 renesas/r9a06g032-rzn1d400-eb.dtb' command reports
the following:
spi@50005000 (renesas,r9a06g032-spi): Unevaluated properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/spi/snps,dw-apb-ssi.yaml
IMHO, 'power-domains' property has to be added in the snps,dw-apb-ssi.yaml binding.
Other than that, your modification works on my custom RZN1 board.
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH v2 1/2] ARM: dts: renesas: r9a06g032: Describe SPI controllers
From: Herve Codina @ 2026-06-22 11:30 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-renesas-soc, Geert Uytterhoeven, Magnus Damm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <20260615125355.116027-2-wsa+renesas@sang-engineering.com>
Hi Wolfram,
On Mon, 15 Jun 2026 14:53:53 +0200
Wolfram Sang <wsa+renesas@sang-engineering.com> wrote:
> Add nodes for the 6 SPI controllers of the Renesas RZ/N1D SoC. The first
> 4 can only be controllers, the latter 2 can only be targets. DMA nodes
> are not added yet because DMA needs some extra code in the drivers and
> cannot be tested yet. Basic FIFO mode works reliably, though.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>
> Changes since v1:
> * dropped spi-max-freq because it is a board property (Thanks, Geert!)
> * use 'spi-slave' and 'addr-cells' = 0 and dropped 'num-cs' for targets
> (Thanks, Geert!)
> * moved 'status' to last position in the node
>
> arch/arm/boot/dts/renesas/r9a06g032.dtsi | 84 ++++++++++++++++++++++++
> 1 file changed, 84 insertions(+)
>
Tested ok on my custom RZ/N1 board.
Tested-by: Herve Codina <herve.codina@bootlin.com>
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH v6 5/8] clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support
From: Konrad Dybcio @ 2026-06-22 11:35 UTC (permalink / raw)
To: Qiang Yu, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Taniya Das, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <20260621-tcsr_qref_0622-v6-5-c939c22ded0c@oss.qualcomm.com>
On 6/22/26 7:11 AM, Qiang Yu wrote:
> Mahua is based on Glymur but uses a different QREF topology, requiring
> distinct regulator lists and clock descriptors for its PCIe clock
> references.
>
> Add mahua-specific regulator arrays and clk descriptor table, and use
> match_data to select the correct descriptor table per compatible string at
> probe time.
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
[...]
> +static const struct qcom_clk_ref_desc tcsr_cc_mahua_clk_descs[] = {
> + [TCSR_EDP_CLKREF_EN] = {
> + .name = "tcsr_edp_clkref_en",
> + .offset = 0x60,
EDP goes through CXO1->TX->RPT0->RX0
> + },
> + [TCSR_PCIE_2_CLKREF_EN] = {
> + .name = "tcsr_pcie_2_clkref_en",
> + .offset = 0x4c,
> + .regulator_names = mahua_tcsr_tx1_rpt01_rx1_regulators,
> + .num_regulators = ARRAY_SIZE(mahua_tcsr_tx1_rpt01_rx1_regulators),
this is apparently for PCIE4 (the name you used unfortunately actually
matches the register in TCSR..)
(ok)
> + },
> + [TCSR_PCIE_3_CLKREF_EN] = {
> + .name = "tcsr_pcie_3_clkref_en",
> + .offset = 0x54,
> + .regulator_names = mahua_tcsr_tx1_rpt012_rx2_regulators,
> + .num_regulators = ARRAY_SIZE(mahua_tcsr_tx1_rpt012_rx2_regulators),
This is PCIe3 (actually)
CXO1->TX->RPT0->RPT1->RPT2->RX2 (ok)
> + },
> + [TCSR_PCIE_4_CLKREF_EN] = {
> + .name = "tcsr_pcie_4_clkref_en",
> + .offset = 0x58,
> + .regulator_names = mahua_tcsr_tx1_rpt01_rx1_regulators,
> + .num_regulators = ARRAY_SIZE(mahua_tcsr_tx1_rpt01_rx1_regulators),
This is PCIe6
CXO1->TX->RPT0->RPT1->RX1 (ok)
> + },
> + [TCSR_USB2_1_CLKREF_EN] = {
> + .name = "tcsr_usb2_1_clkref_en",
> + .offset = 0x6c,
> + },
(usb_hs phy)
CXO1->TX->RPT3->RPT4->RPT5->RX3
> + [TCSR_USB2_2_CLKREF_EN] = {
> + .name = "tcsr_usb2_2_clkref_en",
> + .offset = 0x70,
> + },
(mp0 hsphy)
CXO1->TX->RPT3->RPT4->RPT5->RX3
> + [TCSR_USB2_3_CLKREF_EN] = {
> + .name = "tcsr_usb2_3_clkref_en",
> + .offset = 0x74,
> + },
(mp1 hsphy)
CXO1->TX->RPT3->RPT4->RPT5->RX3
> + [TCSR_USB2_4_CLKREF_EN] = {
> + .name = "tcsr_usb2_4_clkref_en",
> + .offset = 0x88,
> + },
same as eDP
> + [TCSR_USB3_0_CLKREF_EN] = {
> + .name = "tcsr_usb3_0_clkref_en",
> + .offset = 0x64,
> + },
(mp0 uniphy)
same as TCSR_USB2_3_CLKREF_EN
> + [TCSR_USB3_1_CLKREF_EN] = {
> + .name = "tcsr_usb3_1_clkref_en",
> + .offset = 0x68,
> + },
(mp1 uniphy)
same as TCSR_USB2_3_CLKREF_EN
> + [TCSR_USB4_1_CLKREF_EN] = {
> + .name = "tcsr_usb4_1_clkref_en",
> + .offset = 0x44,
> + },
ok
(although there is a comment suggesting this may be NC..)
> + [TCSR_USB4_2_CLKREF_EN] = {
> + .name = "tcsr_usb4_2_clkref_en",
> + .offset = 0x5c,
> + },
CXO1->TX->RPT0->RPT1->RX1
You're also missing PCIe_1_CLKREF_EN (+0x48) (for PCIe5)
which goes through CXO1_>TX->RPT0->RPT1->RPT2->RX2
[...]
> static int tcsr_cc_glymur_probe(struct platform_device *pdev)
> {
> + const struct tcsrcc_glymur_data *data = device_get_match_data(&pdev->dev);
Please null-check this
Konrad
^ permalink raw reply
* Re: [PATCH v6 8/8] arm64: dts: qcom: mahua: Switch pcie5_phy ref clock to RPMH_CXO_CLK
From: Konrad Dybcio @ 2026-06-22 11:37 UTC (permalink / raw)
To: Qiang Yu, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Taniya Das, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <20260621-tcsr_qref_0622-v6-8-c939c22ded0c@oss.qualcomm.com>
On 6/22/26 7:11 AM, Qiang Yu wrote:
> PCIe5 PHY on Mahua gets refclk from CXO0 pad directly, so no QREF
> clkref_en voting is required. Override the clock list to use RPMH_CXO_CLK
> directly instead.
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
This must be squashed with patch 7, otherwise PCIe won't probe on
Mahua
Konrad
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8008 PMIC
From: Konrad Dybcio @ 2026-06-22 11:40 UTC (permalink / raw)
To: Xin Xu, andersson, konradybcio; +Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <tencent_598E543ABA6624DF90EE8492CB23BA904505@qq.com>
On 6/19/26 6:07 PM, Xin Xu wrote:
> Add the pm8008 PMIC node on i2c15 with seven LDOs,
> using GPIO84 as interrupt and GPIO76 as reset.
>
> Signed-off-by: Xin Xu <xxsemail@qq.com>
> ---
> .../dts/qcom/sm8250-xiaomi-elish-common.dtsi | 94 +++++++++++++++++++
> 1 file changed, 94 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
> index 51b57c697a75..2687a2a8dda4 100644
> --- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
> @@ -599,6 +599,82 @@ fuel-gauge@55 {
> };
> };
>
> +&i2c15 {
> + clock-frequency = <400000>;
> + status = "okay";
nit: please add an \n before status
> +
> + pm8008: pmic@8 {
> + compatible = "qcom,pm8008";
> + reg = <0x8>;
> +
> + interrupt-parent = <&tlmm>;
> + interrupts = <84 IRQ_TYPE_EDGE_RISING>;
interrupts-extended = <&tlmm 84 IRQ_TYPE_EDGE_RISING>;
> + reset-gpios = <&tlmm 76 GPIO_ACTIVE_LOW>;
> +
> + vdd-l1-l2-supply = <&vreg_s8c_1p35>;
> + vdd-l3-l4-supply = <&vreg_bob>;
> + vdd-l5-supply = <&vreg_bob>;
> + vdd-l6-supply = <&vreg_bob>;
> + vdd-l7-supply = <&vreg_bob>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pm8008_default>;
property-n
property-names
in this order, please
[...]
> + regulators {
> + vreg_l1p: ldo1 {
> + regulator-name = "vreg_l1p";
> + regulator-min-microvolt = <1152000>;
> + regulator-max-microvolt = <1152000>;
Make sure you verified all of the voltage ranges vs downstream,
as incorrect values may lead to hw damage
[...]
> + pm8008_default: pm8008-default-state {
> + int-pins {
> + pins = "gpio84";
> + function = "gpio";
> + bias-disable;
> + drive-strength = <2>;
> + input-enable;
> + };
> +
> + reset-pins {
> + pins = "gpio76";
> + function = "gpio";
> + bias-pull-up;
> + drive-strength = <2>;
> + output-high;
Drop output-high, the driver will take care of setting the output state
Konrad
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Rodrigo Alencar @ 2026-06-22 11:51 UTC (permalink / raw)
To: Nuno Sá, Rodrigo Alencar
Cc: Jonathan Cameron, Conor Dooley, Janani Sunil, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <ajkMBh-R_7pYaoAn@nsa>
On 22/06/26 11:29, Nuno Sá wrote:
> On Mon, Jun 22, 2026 at 10:24:05AM +0100, Rodrigo Alencar wrote:
> > On 21/06/26 15:33, Jonathan Cameron wrote:
> > > On Fri, 19 Jun 2026 16:54:11 +0100
> > > Nuno Sá <noname.nuno@gmail.com> wrote:
> > >
> > > > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > > > >
> > > > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > > > integrated precision reference.
> > > > > > > > > > > > ...
> > > > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > > > >
> > > > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > > > >
> > > > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +patternProperties:
> > > > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > > > + type: object
> > > > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + properties:
> > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > > > + minimum: 0
> > > > > > > > > > > > > + maximum: 15
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > > > + description: |
> > > > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > > > + oneOf:
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: 0
> > > > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + required:
> > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +required:
> > > > > > > > > > > > > + - compatible
> > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +dependencies:
> > > > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +allOf:
> > > > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +examples:
> > > > > > > > > > > > > + - |
> > > > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + spi {
> > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + dac@0 {
> > > > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + channel@0 {
> > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + channel@1 {
> > > > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + channel@2 {
> > > > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > + };
> > > > > > > > > > > > ...
> > > > > > > > > > > >
> > > > > > > > > > > > spi {
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > multi-dac@0 {
> > > > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > > > >
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > dac@0 {
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > >
> > > > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > >
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > channel@2 {
> > > > > > > > > > > > reg = <2>;
> > > > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > > }
> > > > > > > > > > > >
> > > > > > > > > > > > dac@1 {
> > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > >
> > > > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > >
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > > }
> > > > > > > > > > > > };
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > then you might need something like:
> > > > > > > > > > > >
> > > > > > > > > > > > patternProperties:
> > > > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > > > >
> > > > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > > > >
> > > > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > > > >
> > > > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > > > Hi Rodrigo,
> > > > > > > > > > >
> > > > > > > > > > > Thank you for looking at this.
> > > > > > > > > > >
> > > > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > > > speculatively without a validating use case.
> > > > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > > > >
> > > > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > > > >
> > > > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > > > longer term how to support it cleanly in SPI.
> > > > > > > >
> > > > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > > > see if I can find what I am thinking of...
> > > > > > >
> > > > > > >
> > > > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > > > slightly different properties.
> > > > > > >
> > > > > > > microchip,device-addr:
> > > > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > enum: [0, 1, 2, 3]
> > > > > > > default: 0
> > > > > > >
> > > > > > > and
> > > > > > >
> > > > > > >
> > > > > > > microchip,hw-device-address:
> > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > minimum: 0
> > > > > > > maximum: 3
> > > > > > > description:
> > > > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > > > The device address is part of the device markings to avoid
> > > > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > > > addresses are available when multiple devices are present on the same
> > > > > > > SPI bus with only one Chip Select line for all devices.
> > > > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > > > which is first one on the wire).
> > > > > > >
> > > > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > > > here?
> > > > > > >
> > > > > >
> > > > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > > > about solving this at the spi level.
> > > > > >
> > > > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > > > together in the same bus.
> > > > >
> > > > > I'm definitely missing something, because that property for the
> > > > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > > > are completely different devices with different drivers. They have
> > > > > individual device nodes and their own supplies etc etc. These aren't
> > > > > per-channel properties on an adc or dac, they're per child device on a
> > > > > spi bus.
> > > >
> > > > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > > > devices on the same CS right? Because for this chip we would need
> > > > something like:
> > > >
> > > > spi {
> > > > dac@0 {
> > > > reg = <0>;
> > > > adi,pin-id = <0>;
> > > > };
> > > >
> > > > dac@1 {
> > > > reg = <0>; // which seems already problematic?
> > > > adi,pin-id <1>;
> > > > };
> > > >
> > > > ...
> > > >
> > > > //up to 4
> > > > };
> > > Yeah. It's not clear to me how that works for the microchip devices
> > > (I suspect it doesn't!)
> > >
> > > Just thinking as I type, but could we do something a bit nasty with
> > > a gpio mux that doesn't actually switch but represents the GPIO being
> > > shared? Given this is all tied to the spi bus that should all happen
> > > under serializing locks.
> > >
> > > Agreed though that this would be nicer as an SPI thing that let
> > > us specify that a single CS is share by multiple devices and their
> > > is some other signal acting to select which one we are talking to.
> > >
> >
> > If the device-addressing on the same chip-select is to be handled
> > by the spi framework, wouldn't we lose device-specific features?
> >
> > I understand that this multi-device feature is there mostly to extend the
> > channel count from 16 to 32, 48 or 64. I suppose the command:
> >
> > "MULTI DEVICE SW LDAC MODE"
> >
> > exists so that software can update channel values accross multiple devices.
>
> Right! You do have a point! I agree the main driver for a feature like
> this is likely to extend the channel count and effectively "aggregate"
> devices.
>
> But I would say that even with the spi solution the MULTI DEVICE stuff
> should be doable (as we still need a sort of adi,pin-id property).
I don't think we can have something like an IIO buffer shared by multiple
devices. Synchronizing separate devices would be doable with proper hardware
support for this (probably involving an FGPA).
> But yes, I do feel that the whole feature is for aggregation so seeing
> one device with 32 channels is the expectation here? Rather than seeing
> two devices with 16 channels.
Yes, I think aggregation is the whole point there... so that the IIO driver
is multi-device-aware.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Janani Sunil @ 2026-06-22 11:54 UTC (permalink / raw)
To: Nuno Sá, Jonathan Cameron
Cc: Conor Dooley, Rodrigo Alencar, Janani Sunil, Lars-Peter Clausen,
Michael Hennerich, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Philipp Zabel,
Jonathan Corbet, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-doc, Mark Brown
In-Reply-To: <ajkILRPq_g24g4dH@nsa>
On 6/22/26 12:17, Nuno Sá wrote:
> On Mon, Jun 22, 2026 at 10:27:22AM +0100, Jonathan Cameron wrote:
>> On Mon, 22 Jun 2026 10:07:01 +0100
>> Nuno Sá <noname.nuno@gmail.com> wrote:
>>
>>> On Sun, Jun 21, 2026 at 07:35:42PM +0100, Conor Dooley wrote:
>>>> On Sun, Jun 21, 2026 at 03:33:40PM +0100, Jonathan Cameron wrote:
>>>>> On Fri, 19 Jun 2026 16:54:11 +0100
>>>>> Nuno Sá <noname.nuno@gmail.com> wrote:
>>>>>
>>>>>> On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
>>>>>>> On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
>>>>>>>> On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
>>>>>>>>> On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
>>>>>>>>>> On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
>>>>>>>>>>> On 6/14/26 21:44, Jonathan Cameron wrote:
>>>>>>>>>>>> On Tue, 9 Jun 2026 16:47:23 +0200
>>>>>>>>>>>> Janani Sunil <jan.sun97@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 5/26/26 15:11, Rodrigo Alencar wrote:
>>>>>>>>>>>>>> On 26/05/19 05:42PM, Janani Sunil wrote:
>>>>>>>>>>>>>>> Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
>>>>>>>>>>>>>>> buffered voltage output digital-to-analog converter (DAC) with an
>>>>>>>>>>>>>>> integrated precision reference.
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>> Probably others may comment on that, but...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This parent node may support device addressing for multi-device support through
>>>>>>>>>>>>>> those ID pins. I suppose that each device may have its own power supplies or
>>>>>>>>>>>>>> other resources like the toggle pins or reset and enable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That way I suppose that an example would look like...
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +patternProperties:
>>>>>>>>>>>>>>> + "^channel@([0-9]|1[0-5])$":
>>>>>>>>>>>>>>> + type: object
>>>>>>>>>>>>>>> + description: Child nodes for individual channel configuration
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + properties:
>>>>>>>>>>>>>>> + reg:
>>>>>>>>>>>>>>> + description: Channel number.
>>>>>>>>>>>>>>> + minimum: 0
>>>>>>>>>>>>>>> + maximum: 15
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + adi,output-range-microvolt:
>>>>>>>>>>>>>>> + description: |
>>>>>>>>>>>>>>> + Output voltage range for this channel as [min, max] in microvolts.
>>>>>>>>>>>>>>> + If not specified, defaults to 0V to 5V range.
>>>>>>>>>>>>>>> + oneOf:
>>>>>>>>>>>>>>> + - items:
>>>>>>>>>>>>>>> + - const: 0
>>>>>>>>>>>>>>> + - enum: [5000000, 10000000, 20000000, 40000000]
>>>>>>>>>>>>>>> + - items:
>>>>>>>>>>>>>>> + - const: -5000000
>>>>>>>>>>>>>>> + - const: 5000000
>>>>>>>>>>>>>>> + - items:
>>>>>>>>>>>>>>> + - const: -10000000
>>>>>>>>>>>>>>> + - const: 10000000
>>>>>>>>>>>>>>> + - items:
>>>>>>>>>>>>>>> + - const: -15000000
>>>>>>>>>>>>>>> + - const: 15000000
>>>>>>>>>>>>>>> + - items:
>>>>>>>>>>>>>>> + - const: -20000000
>>>>>>>>>>>>>>> + - const: 20000000
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + required:
>>>>>>>>>>>>>>> + - reg
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + additionalProperties: false
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +required:
>>>>>>>>>>>>>>> + - compatible
>>>>>>>>>>>>>>> + - reg
>>>>>>>>>>>>>>> + - vdd-supply
>>>>>>>>>>>>>>> + - avdd-supply
>>>>>>>>>>>>>>> + - hvdd-supply
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +dependencies:
>>>>>>>>>>>>>>> + spi-cpha: [ spi-cpol ]
>>>>>>>>>>>>>>> + spi-cpol: [ spi-cpha ]
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +allOf:
>>>>>>>>>>>>>>> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +unevaluatedProperties: false
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +examples:
>>>>>>>>>>>>>>> + - |
>>>>>>>>>>>>>>> + #include <dt-bindings/gpio/gpio.h>
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + spi {
>>>>>>>>>>>>>>> + #address-cells = <1>;
>>>>>>>>>>>>>>> + #size-cells = <0>;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + dac@0 {
>>>>>>>>>>>>>>> + compatible = "adi,ad5529r-16";
>>>>>>>>>>>>>>> + reg = <0>;
>>>>>>>>>>>>>>> + spi-max-frequency = <25000000>;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + vdd-supply = <&vdd_regulator>;
>>>>>>>>>>>>>>> + avdd-supply = <&avdd_regulator>;
>>>>>>>>>>>>>>> + hvdd-supply = <&hvdd_regulator>;
>>>>>>>>>>>>>>> + hvss-supply = <&hvss_regulator>;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + #address-cells = <1>;
>>>>>>>>>>>>>>> + #size-cells = <0>;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + channel@0 {
>>>>>>>>>>>>>>> + reg = <0>;
>>>>>>>>>>>>>>> + adi,output-range-microvolt = <0 5000000>;
>>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + channel@1 {
>>>>>>>>>>>>>>> + reg = <1>;
>>>>>>>>>>>>>>> + adi,output-range-microvolt = <(-10000000) 10000000>;
>>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + channel@2 {
>>>>>>>>>>>>>>> + reg = <2>;
>>>>>>>>>>>>>>> + adi,output-range-microvolt = <0 40000000>;
>>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> spi {
>>>>>>>>>>>>>> #address-cells = <1>;
>>>>>>>>>>>>>> #size-cells = <0>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> multi-dac@0 {
>>>>>>>>>>>>>> compatible = "adi,ad5529r-16";
>>>>>>>>>>>>>> reg = <0>;
>>>>>>>>>>>>>> spi-max-frequency = <25000000>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> #address-cells = <1>;
>>>>>>>>>>>>>> #size-cells = <0>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> dac@0 {
>>>>>>>>>>>>>> reg = <0>;
>>>>>>>>>>>>>> vdd-supply = <&vdd_regulator>;
>>>>>>>>>>>>>> avdd-supply = <&avdd_regulator>;
>>>>>>>>>>>>>> hvdd-supply = <&hvdd_regulator>;
>>>>>>>>>>>>>> hvss-supply = <&hvss_regulator>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> #address-cells = <1>;
>>>>>>>>>>>>>> #size-cells = <0>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> channel@0 {
>>>>>>>>>>>>>> reg = <0>;
>>>>>>>>>>>>>> adi,output-range-microvolt = <0 5000000>;
>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> channel@1 {
>>>>>>>>>>>>>> reg = <1>;
>>>>>>>>>>>>>> adi,output-range-microvolt = <(-10000000) 10000000>;
>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> channel@2 {
>>>>>>>>>>>>>> reg = <2>;
>>>>>>>>>>>>>> adi,output-range-microvolt = <0 40000000>;
>>>>>>>>>>>>>> };
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> dac@1 {
>>>>>>>>>>>>>> reg = <1>;
>>>>>>>>>>>>>> vdd-supply = <&vdd_regulator>;
>>>>>>>>>>>>>> avdd-supply = <&avdd_regulator>;
>>>>>>>>>>>>>> hvdd-supply = <&hvdd_regulator>;
>>>>>>>>>>>>>> hvss-supply = <&hvss_regulator>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> #address-cells = <1>;
>>>>>>>>>>>>>> #size-cells = <0>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> channel@0 {
>>>>>>>>>>>>>> reg = <0>;
>>>>>>>>>>>>>> adi,output-range-microvolt = <0 5000000>;
>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> channel@1 {
>>>>>>>>>>>>>> reg = <1>;
>>>>>>>>>>>>>> adi,output-range-microvolt = <(-10000000) 10000000>;
>>>>>>>>>>>>>> };
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> };
>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> then you might need something like:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> patternProperties:
>>>>>>>>>>>>>> "^dac@[0-3]$":
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> and put most of the things under this node pattern.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So the main driver that you're putting together might need to handle up to four instances.
>>>>>>>>>>>>>> Even if your current driver cannot handle this, the dt-bindings might need cover that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Need to double check if each dac node needs a separate compatible, so you would maybe populate
>>>>>>>>>>>>>> a platform data to be shared with the child nodes, which would be a separate driver.
>>>>>>>>>>>>>> (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
>>>>>>>>>>>>> Hi Rodrigo,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you for looking at this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
>>>>>>>>>>>>> hardware/use case we have only needs one device node and the driver is written around that model as well.
>>>>>>>>>>>>> While the device addressing pins could allow multi-device topology, we do not have an actual platform using
>>>>>>>>>>>>> that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
>>>>>>>>>>>>> speculatively without a validating use case.
>>>>>>>>>>>> Interesting feature - kind of similar to address control on a typical i2c bus device, or
>>>>>>>>>>>> looking at it another way a kind of distributed SPI mux.
>>>>>>>>>>>>
>>>>>>>>>>>> Challenge of a binding is we need to anticipate the future. So I think we do need something
>>>>>>>>>>>> like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
>>>>>>>>>>>> That would leave the path open to supporting the addressing at a later date.
>>>>>>>>>>>> An alternative might be to look at it like a chained device setup. In those we pretend there
>>>>>>>>>>>> is just one device with a lot of channels etc. The snag is that here things are more loosely
>>>>>>>>>>>> coupled whereas for those devices it tends to be you have to read / write the same register
>>>>>>>>>>>> in all devices in the chain as one big SPI message.
>>>>>>>>>>>>
>>>>>>>>>>>> +CC Mark Brown as he may know of some precedence for this feature. For his reference..
>>>>>>>>>>>> - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
>>>>>>>>>>>> value that matches that or they are ignored. Thus a single bus + 1 chip select can
>>>>>>>>>>>> be used to talk to 4 devices. Question is what that looks like in device tree + I guess
>>>>>>>>>>>> longer term how to support it cleanly in SPI.
>>>>>>>>>> I'd swear I have seen this before, from some Microchip devices. Let me
>>>>>>>>>> see if I can find what I am thinking of...
>>>>>>>>>
>>>>>>>>> microchip,mcp3911 and microchip,mcp3564 both seem to do this with
>>>>>>>>> slightly different properties.
>>>>>>>>>
>>>>>>>>> microchip,device-addr:
>>>>>>>>> description: Device address when multiple MCP3911 chips are present on the same SPI bus.
>>>>>>>>> $ref: /schemas/types.yaml#/definitions/uint32
>>>>>>>>> enum: [0, 1, 2, 3]
>>>>>>>>> default: 0
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> microchip,hw-device-address:
>>>>>>>>> $ref: /schemas/types.yaml#/definitions/uint32
>>>>>>>>> minimum: 0
>>>>>>>>> maximum: 3
>>>>>>>>> description:
>>>>>>>>> The address is set on a per-device basis by fuses in the factory,
>>>>>>>>> configured on request. If not requested, the fuses are set for 0x1.
>>>>>>>>> The device address is part of the device markings to avoid
>>>>>>>>> potential confusion. This address is coded on two bits, so four possible
>>>>>>>>> addresses are available when multiple devices are present on the same
>>>>>>>>> SPI bus with only one Chip Select line for all devices.
>>>>>>>>> Each device communication starts by a CS falling edge, followed by the
>>>>>>>>> clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
>>>>>>>>> which is first one on the wire).
>>>>>>>>>
>>>>>>>>> This sounds exactly like the sort of feature that you're dealing with
>>>>>>>>> here?
>>>>>>>>>
>>>>>>>> The core idea yes but for this chip, things are a bit more annoying (but
>>>>>>>> Janani can correct me if I'm wrong). Here, each device can, in theory,
>>>>>>>> have it's own supplies, pins and at the very least, channels with maybe
>>>>>>>> different scales. That is why Janani is proposing dac nodes. Given I
>>>>>>>> honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
>>>>>>>> about solving this at the spi level.
>>>>>>>>
>>>>>>>> Ah and to make it more annoying, we can also mix 12 and 16 bits variants
>>>>>>>> together in the same bus.
>>>>>>> I'm definitely missing something, because that property for the
>>>>>>> microchip devices is not impacted what else is on the bus. AFAICT, you
>>>>>>> could have an mcp3911 and an mcp3564 on the same bus even though both
>>>>>>> are completely different devices with different drivers. They have
>>>>>>> individual device nodes and their own supplies etc etc. These aren't
>>>>>>> per-channel properties on an adc or dac, they're per child device on a
>>>>>>> spi bus.
>>>>>> Maybe I'm the one missing something :). IIRC, spi would not allow two
>>>>>> devices on the same CS right? Because for this chip we would need
>>>>>> something like:
>>>>>>
>>>>>> spi {
>>>>>> dac@0 {
>>>>>> reg = <0>;
>>>>>> adi,pin-id = <0>;
>>>>>> };
>>>>>>
>>>>>> dac@1 {
>>>>>> reg = <0>; // which seems already problematic?
>>>>>> adi,pin-id <1>;
>>>>>> };
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> //up to 4
>>>>>> };
>>>>> Yeah. It's not clear to me how that works for the microchip devices
>>>>> (I suspect it doesn't!)
>>>>>
>>>>> Just thinking as I type, but could we do something a bit nasty with
>>>>> a gpio mux that doesn't actually switch but represents the GPIO being
>>>>> shared? Given this is all tied to the spi bus that should all happen
>>>>> under serializing locks.
>>>>>
>>>>> Agreed though that this would be nicer as an SPI thing that let
>>>>> us specify that a single CS is share by multiple devices and their
>>>>> is some other signal acting to select which one we are talking to.
>>>> Whether it works or not, I think it is the more correct approach. Messing
>>>> with gpio muxes seems completely wrong, given the chip select may not be
>>>> a gpio at all.
>>>>
>>>> Why do you think the microchip devices won't work? Does the spi core
>>>> reject multiple devices with the same chip select being registered or
>>>> something like that?
>>> Not sure how things work atm. But I'm fairly sure it used to be like
>>> that. SPI would reject devices on the same controller and CS. Now that
>>> we support more than one CS per controller, not sure how things work.
>> We always supported more than one per CS per controller. I guess you mean
>> per device.
> Obviously :)
>>> Janani, maybe you can give it a try?
>> I think we'd need to get it to work with shared gpio proxy which maybe
>> will just get set up under the hood. This used to be opt in, but seems
>> that changed fairly recently so maybe some of us are working with out
>> of date knowledge! I haven't played with it yet, so might not be
>> that simple.
>>
> What I meant for Janani was basically testing two devices on the same CS
> as in my pseudo DT. For the GPIO, you mean having a way to select
> between devices on the same CS?
>
> For these devices the pin id numbers get's setted up as part of the spi message
> so my assumption is that all of them will receive the message but only one acks it.
>
> - Nuno Sá
Hi Everyone,
I tested the case where there are two devices on the same CS. The SPI core does reject it at spi_dev_check_cs():
https://github.com/torvalds/linux/blob/master/drivers/spi/spi.c#L631
-Janani Sunil
>
>> Jonathan
>>
>>> - Nuno Sá
>>>
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: brige: lt9611c: add port-select property for LT9611C
From: Mohit Dsor @ 2026-06-22 12:01 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, dri-devel, devicetree, linux-kernel, boss,
qc-display-maintainer
In-Reply-To: <20260611-burrowing-fervent-serpent-584cac@quoll>
On Thu, Jun 11, 2026 at 12:40:38PM +0200, Krzysztof Kozlowski wrote:
> On Thu, Jun 11, 2026 at 02:44:56AM +0530, Mohit Dsor wrote:
> > Add a new optional `lontium,port-select` property to describe the DSI
> > input port configuration for the LT9611C variant, which supports
> > single-port (A or B) and dual-port (A+B) operation.
> >
> > This property allows explicitly selecting the active DSI input port(s):
> > 0 = port A (default)
> > 1 = port B
> > 2 = ports A and B (dual-port)
> >
> > Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
> > ---
> > .../devicetree/bindings/display/bridge/lontium,lt9611.yaml | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> > index e0821a63d9d7..77220f893bf8 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> > @@ -41,6 +41,17 @@ properties:
> > vcc-supply:
> > description: Regulator for 3.3V IO power.
> >
> > + lontium,port-select:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + enum: [0, 1, 2]
> > + default: 0
> > + description: |
> > + Selects which DSI input port(s) the bridge uses. Only relevant for
> > + the lontium,lt9611c compatible.
> > + 0 = PORT_SELECT_A - single DSI port A (default)
> > + 1 = PORT_SELECT_B - single DSI port B
> > + 2 = PORT_SELECT_AB - dual DSI ports A and B
>
> Why graph is not enough? Seems exactly duplicating the graph ports.
>
> Best regards,
> Krzysztof
>
Hi Krzysztof,
Thanks for the review.
The graph describes the physical connectivity between endpoints, however it does not fully capture the internal mode of operation of the LT9611C. This variant supports multiple functional configurations (single-port A, single-port B, or dual-port A+B), which affect how the hardware internally combines or selects DSI inputs.
In particular:
- The graph can describe connections to both ports, but it does not indicate whether the device should operate in single-port or dual-port aggregation mode.
- For single-port use, both ports may be described in DT for board consistency, while the driver still needs to know which port is actively selected.
- Dual-port mode requires explicit configuration even when both endpoints are present in the graph.
So, this property is not duplicating connectivity, but rather describing the *operational mode* of the device, which cannot be reliably inferred from the graph alone.
Thanks,
Mohit
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: brige: lt9611c: add port-select property for LT9611C
From: Laurent Pinchart @ 2026-06-22 12:08 UTC (permalink / raw)
To: Mohit Dsor
Cc: Krzysztof Kozlowski, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, dri-devel, devicetree, linux-kernel, boss,
qc-display-maintainer
In-Reply-To: <ajkkINI1PzxArMzL@hu-mdsor-hyd.qualcomm.com>
On Mon, Jun 22, 2026 at 05:31:36PM +0530, Mohit Dsor wrote:
> On Thu, Jun 11, 2026 at 12:40:38PM +0200, Krzysztof Kozlowski wrote:
> > On Thu, Jun 11, 2026 at 02:44:56AM +0530, Mohit Dsor wrote:
> > > Add a new optional `lontium,port-select` property to describe the DSI
> > > input port configuration for the LT9611C variant, which supports
> > > single-port (A or B) and dual-port (A+B) operation.
> > >
> > > This property allows explicitly selecting the active DSI input port(s):
> > > 0 = port A (default)
> > > 1 = port B
> > > 2 = ports A and B (dual-port)
> > >
> > > Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
> > > ---
> > > .../devicetree/bindings/display/bridge/lontium,lt9611.yaml | 13 +++++++++++++
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> > > index e0821a63d9d7..77220f893bf8 100644
> > > --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> > > +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> > > @@ -41,6 +41,17 @@ properties:
> > > vcc-supply:
> > > description: Regulator for 3.3V IO power.
> > >
> > > + lontium,port-select:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + enum: [0, 1, 2]
> > > + default: 0
> > > + description: |
> > > + Selects which DSI input port(s) the bridge uses. Only relevant for
> > > + the lontium,lt9611c compatible.
> > > + 0 = PORT_SELECT_A - single DSI port A (default)
> > > + 1 = PORT_SELECT_B - single DSI port B
> > > + 2 = PORT_SELECT_AB - dual DSI ports A and B
> >
> > Why graph is not enough? Seems exactly duplicating the graph ports.
> >
> > Best regards,
> > Krzysztof
> >
> Hi Krzysztof,
>
> Thanks for the review.
>
> The graph describes the physical connectivity between endpoints,
> however it does not fully capture the internal mode of operation of
> the LT9611C. This variant supports multiple functional configurations
> (single-port A, single-port B, or dual-port A+B), which affect how the
> hardware internally combines or selects DSI inputs.
>
> In particular:
> - The graph can describe connections to both ports, but it does not
> indicate whether the device should operate in single-port or dual-port
> aggregation mode.
> - For single-port use, both ports may be described in DT for board
> consistency, while the driver still needs to know which port is
> actively selected.
> - Dual-port mode requires explicit configuration even when both
> endpoints are present in the graph.
If both modes of operation are possible on a given board, then it sounds
like the mode should be selected at runtime, not hardcoded in the device
tree.
> So, this property is not duplicating connectivity, but rather
> describing the *operational mode* of the device, which cannot be
> reliably inferred from the graph alone.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 3/4] drm-bridge: lontium lt9611c: fixes and improvements
From: Mohit Dsor @ 2026-06-22 12:08 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, dri-devel,
devicetree, linux-kernel, boss, qc-display-maintainer
In-Reply-To: <DJ6YOZ4G73A3.37QF618MHAR4F@bootlin.com>
On Fri, Jun 12, 2026 at 11:26:34AM +0200, Luca Ceresoli wrote:
> On Wed Jun 10, 2026 at 11:14 PM CEST, Mohit Dsor wrote:
> > Remove two redundant lt9611c_reset() calls:
> >
> > 1. In lt9611c_bridge_atomic_pre_enable(): a reset is already performed
> > during probe and resume; calling it again on every display enable
> > adds ~440ms of unnecessary latency.
> >
> > 2. At the end of lt9611c_probe(): a reset was already performed earlier
> > in probe before lt9611c_lock(). The second reset is redundant.
> >
> > Also, the DRM HDMI bridge framework requires hdmi_write_hdmi_infoframe and
> > hdmi_clear_hdmi_infoframe callbacks for HDMI vendor-specific infoframe
> > (VSI) support, used for features such as HDR metadata signalling.
> >
> > This patch add stub implementations that return success. Wire them into the bridge
> > function table.
> >
> > Also, Store the chip variant enum value in the of_match_table .data field and
> > retrieve it via of_device_get_match_data() when probing from a DT node.
> > Fall back to i2c_device_id.driver_data for non-DT (e.g. ACPI) probe
> > paths.
> >
> > This is the standard kernel pattern for passing per-compatible data
> > through the OF match table, and avoids relying solely on the I2C device
> > ID table for chip type detection when DT is available.
> >
> > Populate bridge.vendor and bridge.product so the DRM HDMI framework can
> > report the correct manufacturer and product name in the HDMI connector
> > properties (visible via xrandr --prop and related sysfs entries).
> >
> > Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
>
> These are several unrelated changes and should be separate commits.
>
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Hi Luca,
Thanks for the review.
I see your point about separation, but in this case I intended this as a single cohesive update to the driver rather than unrelated changes.
The redundant lt9611c_reset() removals are cleanup to avoid unnecessary latency during enable/probe.
The HDMI VSI infoframe callbacks are required to align with the DRM HDMI bridge framework expectations.
The OF match data change ensures correct chip variant detection when probing via DT.
The bridge vendor/product population improves user-visible HDMI connector reporting.
All of these are small, tightly scoped updates that improve correctness, framework compliance, and observability of the same driver without introducing independent functional changes.
Given that, I felt keeping them together makes the update easier to review in context. However, I can split them if you strongly prefer that.
Regards,
Mohit
^ permalink raw reply
* Re: [PATCH v6 3/8] clk: qcom: Add generic clkref_en support
From: Konrad Dybcio @ 2026-06-22 12:13 UTC (permalink / raw)
To: Qiang Yu, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Taniya Das, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <20260621-tcsr_qref_0622-v6-3-c939c22ded0c@oss.qualcomm.com>
On 6/22/26 7:11 AM, Qiang Yu wrote:
> Before XO refclk is distributed to PCIe/USB/eDP PHYs, it passes through
> a QREF block. QREF is powered by dedicated LDO rails, and the clkref_en
> register controls whether refclk is gated through to the PHY side.
>
> These clkref controls are different from typical GCC branch clocks:
> - only a single enable bit is present, without branch-style config bits
> - regulators must be voted before enable and unvoted after disable
>
> Model this as a dedicated clk_ref clock type with custom clk_ops instead
> of reusing struct clk_branch semantics.
>
> Also provide a common registration/probe API so the same clkref model
> can be reused regardless of where clkref_en registers are placed, e.g.
> TCSR on glymur and TLMM on SM8750.
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
[...]
> + for (clk_idx = 0; clk_idx < num_clk_refs; clk_idx++) {
> + clk_ref = &clk_refs[clk_idx];
> + desc = &descs[clk_idx];
> +
> + if (!desc->name)
> + continue;
Carrying over from the previous discussion:
> // this allows "holes" in dt-bindings for $reasons
> if (!desc)
> continue;
>
> // this makes sure the programmer did not omit something important
> // while not taking the entire system down
> if (WARN_ON(!desc->name)
> continue;
>
The NULL name check is intentional - the descriptor array is indexed by
clock ID, and mahua has fewer clocks than glymur, leaving holes at
certain indices. So this is expected at runtime. WARN_ON would be noise
log here.
->
Your worry is captured by nullchecking `desc` (i.e. descs[clk_idx])
because in the mahua case we've got (ephemeral indices)
tcsr_cc_mahua_clk_descs[] = {
[0] = { foo },
// [1] is unassigned - OK
[2] = { bar },
};
while (!desc->name) checks for:
tcsr_cc_mahua_clk_descs[] = {
[0] = { .name = "foo", .offset = 0x10 },
// name is NULL by virtue of partial struct initialization
[1] = { .offset = 0x20 },
};
however I overlooked that we actually just have a normal array of
structs.. if we turn it into a struct pointer array with assigmnents
like:
[TCSR_EDP_CLKREF_EN] = &(const struct qcom_clk_ref_desc) {
.name = "foo",
...
};
we can achieve that
Konrad
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Conor Dooley @ 2026-06-22 12:14 UTC (permalink / raw)
To: Janani Sunil
Cc: Nuno Sá, Jonathan Cameron, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <caa54d52-72db-4c58-ae3f-1d1343bd7845@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]
On Mon, Jun 22, 2026 at 01:54:25PM +0200, Janani Sunil wrote:
> > > > > Why do you think the microchip devices won't work? Does the spi core
> > > > > reject multiple devices with the same chip select being registered or
> > > > > something like that?
> > > > Not sure how things work atm. But I'm fairly sure it used to be like
> > > > that. SPI would reject devices on the same controller and CS. Now that
> > > > we support more than one CS per controller, not sure how things work.
> > > We always supported more than one per CS per controller. I guess you mean
> > > per device.
> > Obviously :)
> > > > Janani, maybe you can give it a try?
> > > I think we'd need to get it to work with shared gpio proxy which maybe
> > > will just get set up under the hood. This used to be opt in, but seems
> > > that changed fairly recently so maybe some of us are working with out
> > > of date knowledge! I haven't played with it yet, so might not be
> > > that simple.
> > >
> > What I meant for Janani was basically testing two devices on the same CS
> > as in my pseudo DT. For the GPIO, you mean having a way to select
> > between devices on the same CS?
> >
> > For these devices the pin id numbers get's setted up as part of the spi message
> > so my assumption is that all of them will receive the message but only one acks it.
> >
> > - Nuno Sá
>
> Hi Everyone,
>
> I tested the case where there are two devices on the same CS. The SPI core does reject it at spi_dev_check_cs():
> https://github.com/torvalds/linux/blob/master/drivers/spi/spi.c#L631
Can you try again, but delete that check and allow the code to continue?
Worth knowing if the problem is policy (which makes sense for 99.99% of
devices that cannot share a chip select) or actually not supported by
the spi core code.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v6 6/8] arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSR
From: Konrad Dybcio @ 2026-06-22 12:16 UTC (permalink / raw)
To: Qiang Yu, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Taniya Das, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <20260621-tcsr_qref_0622-v6-6-c939c22ded0c@oss.qualcomm.com>
On 6/22/26 7:11 AM, Qiang Yu wrote:
> The TCSR clkref_en clocks gate the QREF block which provides reference
> clocks to the PCIe PHYs. Wire up the LDO supplies required by the QREF
> and refgen blocks on the CRD board.
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/glymur-crd.dts | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dts b/arch/arm64/boot/dts/qcom/glymur-crd.dts
> index c98dfb3941fa..92b929ee3448 100644
> --- a/arch/arm64/boot/dts/qcom/glymur-crd.dts
> +++ b/arch/arm64/boot/dts/qcom/glymur-crd.dts
> @@ -278,6 +278,26 @@ &smb2370_k_e2_eusb2_repeater {
> vdd3-supply = <&vreg_l7b_e0_2p79>;
> };
>
> +&tcsr {
> + vdda-qrefrpt0-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrpt1-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrpt2-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrpt3-0p9-supply = <&vreg_l2h_e0_0p72>;
l2c_e0
> + vdda-qrefrpt4-0p9-supply = <&vreg_l2h_e0_0p72>;
l2c_e0
> + vdda-qrefrx0-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrx1-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrx2-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrx4-0p9-supply = <&vreg_l2h_e0_0p72>;
l2c_e0
> + vdda-qrefrx5-0p9-supply = <&vreg_l3f_e0_0p72>;
> + vdda-qreftx0-0p9-supply = <&vreg_l3f_e0_0p72>;
> + vdda-qreftx0-1p2-supply = <&vreg_l4h_e0_1p2>;
l4c_e0
> + vdda-qreftx1-0p9-supply = <&vreg_l1f_e1_0p82>;
> + vdda-refgen3-0p9-supply = <&vreg_l2f_e0_0p82>;
> + vdda-refgen3-1p2-supply = <&vreg_l4h_e0_1p2>;
l4c_e0
Konrad
^ permalink raw reply
* Re: [PATCH v6 7/8] arm64: dts: qcom: mahua: Add QREF regulator supplies to TCSR
From: Konrad Dybcio @ 2026-06-22 12:18 UTC (permalink / raw)
To: Qiang Yu, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Taniya Das, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <20260621-tcsr_qref_0622-v6-7-c939c22ded0c@oss.qualcomm.com>
On 6/22/26 7:11 AM, Qiang Yu wrote:
> Mahua has a different PCIe QREF topology from glymur. Override the TCSR
> compatible to qcom,mahua-tcsr in mahua.dtsi, and wire up the required
> LDO supplies for the PCIe clkref paths on the CRD board.
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/mahua-crd.dts | 15 +++++++++++++++
> arch/arm64/boot/dts/qcom/mahua.dtsi | 4 ++++
> 2 files changed, 19 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/mahua-crd.dts b/arch/arm64/boot/dts/qcom/mahua-crd.dts
> index 9c8244e892dd..8b42f5174b31 100644
> --- a/arch/arm64/boot/dts/qcom/mahua-crd.dts
> +++ b/arch/arm64/boot/dts/qcom/mahua-crd.dts
> @@ -19,3 +19,18 @@ / {
> model = "Qualcomm Technologies, Inc. Mahua CRD";
> compatible = "qcom,mahua-crd", "qcom,mahua";
> };
> +
> +&tcsr {
> + vdda-qrefrpt0-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrpt1-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrpt2-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrpt3-0p9-supply = <&vreg_l1f_e1_0p82>;
> + vdda-qrefrpt4-0p9-supply = <&vreg_l2h_e0_0p72>;
> + vdda-qrefrpt5-0p9-supply = <&vreg_l2h_e0_0p72>;
> + vdda-qrefrx1-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrx2-0p9-supply = <&vreg_l2f_e1_0p83>;
> + vdda-qrefrx3-0p9-supply = <&vreg_l2h_e0_0p72>;
> + vdda-qreftx1-0p9-supply = <&vreg_l1f_e1_0p82>;
> + vdda-refgen3-0p9-supply = <&vreg_l1f_e1_0p82>;
> + vdda-refgen3-1p2-supply = <&vreg_l4f_e1_1p08>;
The supplies are correct, but QREF uses refgen4 on Mahua
There's also rx0 with a 0p9 supply on l2f_e1
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: iio: magnetometer: add Melexis MLX90393
From: Krzysztof Kozlowski @ 2026-06-22 12:19 UTC (permalink / raw)
To: Nikhil Gautam
Cc: linux-iio, jic23, dlechner, nuno.sa, andy, robh, krzk+dt,
conor+dt, devicetree, linux-kernel
In-Reply-To: <20260618160141.11409-2-nikhilgtr@gmail.com>
On Thu, Jun 18, 2026 at 09:31:40PM +0530, Nikhil Gautam wrote:
> +description:
> + Melexis MLX90393 3-axis magnetometer and temperature sensor.
> +
> +properties:
> + compatible:
> + const: melexis,mlx90393
> +
> + reg:
> + maxItems: 1
> +
> + vdd-supply: true
> + vddio-supply: true
> +
> + interrupts:
> + maxItems: 1
> +
> + trigger-gpios:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
Supplies should be required.
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + magnetometer@c {
> + compatible = "melexis,mlx90393";
> + reg = <0x0c>;
> +
> + interrupt-parent = <&gpio>;
> + interrupts = <17 IRQ_TYPE_EDGE_RISING>;
> +
> + trigger-gpios = <&gpio 18 GPIO_ACTIVE_HIGH>;
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a92290fffa16..e9ddcd12feb5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -24926,6 +24926,12 @@ S: Maintained
> F: Documentation/devicetree/bindings/iio/magnetometer/ti,tmag5273.yaml
> F: drivers/iio/magnetometer/tmag5273.c
>
> +MELEXIS MLX90393 MAGNETOMETER DRIVER
> +M: Nikhil Gautam <nikhilgtr@gmail.com>
> +L: linux-iio@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/iio/magnetometer/melexis,mlx90393.yaml
> +
> TI TRF7970A NFC DRIVER
This feels like completely random order.
> M: Mark Greer <mgreer@animalcreek.com>
> L: linux-wireless@vger.kernel.org
> --
> 2.39.5
>
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Nuno Sá @ 2026-06-22 12:20 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: Jonathan Cameron, Conor Dooley, Janani Sunil, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <pifhwgj3cp2vc7ia4m6penh52iekzjljrp75y5b7j57vvtooad@32wfqruiqqjl>
On Mon, Jun 22, 2026 at 12:51:20PM +0100, Rodrigo Alencar wrote:
> On 22/06/26 11:29, Nuno Sá wrote:
> > On Mon, Jun 22, 2026 at 10:24:05AM +0100, Rodrigo Alencar wrote:
> > > On 21/06/26 15:33, Jonathan Cameron wrote:
> > > > On Fri, 19 Jun 2026 16:54:11 +0100
> > > > Nuno Sá <noname.nuno@gmail.com> wrote:
> > > >
> > > > > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > > > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > > > > >
> > > > > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > > > > integrated precision reference.
> > > > > > > > > > > > > ...
> > > > > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > > > > >
> > > > > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > > > > >
> > > > > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +patternProperties:
> > > > > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > > > > + type: object
> > > > > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + properties:
> > > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > > > > + minimum: 0
> > > > > > > > > > > > > > + maximum: 15
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > > > > + description: |
> > > > > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > > > > + oneOf:
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: 0
> > > > > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + required:
> > > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +required:
> > > > > > > > > > > > > > + - compatible
> > > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +dependencies:
> > > > > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +allOf:
> > > > > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +examples:
> > > > > > > > > > > > > > + - |
> > > > > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + spi {
> > > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + dac@0 {
> > > > > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@0 {
> > > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@1 {
> > > > > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@2 {
> > > > > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > ...
> > > > > > > > > > > > >
> > > > > > > > > > > > > spi {
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > multi-dac@0 {
> > > > > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > dac@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@2 {
> > > > > > > > > > > > > reg = <2>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > dac@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > > }
> > > > > > > > > > > > > };
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > then you might need something like:
> > > > > > > > > > > > >
> > > > > > > > > > > > > patternProperties:
> > > > > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > > > > >
> > > > > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > > > > Hi Rodrigo,
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you for looking at this.
> > > > > > > > > > > >
> > > > > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > > > > speculatively without a validating use case.
> > > > > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > > > > >
> > > > > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > > > > >
> > > > > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > > > > longer term how to support it cleanly in SPI.
> > > > > > > > >
> > > > > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > > > > see if I can find what I am thinking of...
> > > > > > > >
> > > > > > > >
> > > > > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > > > > slightly different properties.
> > > > > > > >
> > > > > > > > microchip,device-addr:
> > > > > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > > enum: [0, 1, 2, 3]
> > > > > > > > default: 0
> > > > > > > >
> > > > > > > > and
> > > > > > > >
> > > > > > > >
> > > > > > > > microchip,hw-device-address:
> > > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > > minimum: 0
> > > > > > > > maximum: 3
> > > > > > > > description:
> > > > > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > > > > The device address is part of the device markings to avoid
> > > > > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > > > > addresses are available when multiple devices are present on the same
> > > > > > > > SPI bus with only one Chip Select line for all devices.
> > > > > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > > > > which is first one on the wire).
> > > > > > > >
> > > > > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > > > > here?
> > > > > > > >
> > > > > > >
> > > > > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > > > > about solving this at the spi level.
> > > > > > >
> > > > > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > > > > together in the same bus.
> > > > > >
> > > > > > I'm definitely missing something, because that property for the
> > > > > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > > > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > > > > are completely different devices with different drivers. They have
> > > > > > individual device nodes and their own supplies etc etc. These aren't
> > > > > > per-channel properties on an adc or dac, they're per child device on a
> > > > > > spi bus.
> > > > >
> > > > > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > > > > devices on the same CS right? Because for this chip we would need
> > > > > something like:
> > > > >
> > > > > spi {
> > > > > dac@0 {
> > > > > reg = <0>;
> > > > > adi,pin-id = <0>;
> > > > > };
> > > > >
> > > > > dac@1 {
> > > > > reg = <0>; // which seems already problematic?
> > > > > adi,pin-id <1>;
> > > > > };
> > > > >
> > > > > ...
> > > > >
> > > > > //up to 4
> > > > > };
> > > > Yeah. It's not clear to me how that works for the microchip devices
> > > > (I suspect it doesn't!)
> > > >
> > > > Just thinking as I type, but could we do something a bit nasty with
> > > > a gpio mux that doesn't actually switch but represents the GPIO being
> > > > shared? Given this is all tied to the spi bus that should all happen
> > > > under serializing locks.
> > > >
> > > > Agreed though that this would be nicer as an SPI thing that let
> > > > us specify that a single CS is share by multiple devices and their
> > > > is some other signal acting to select which one we are talking to.
> > > >
> > >
> > > If the device-addressing on the same chip-select is to be handled
> > > by the spi framework, wouldn't we lose device-specific features?
> > >
> > > I understand that this multi-device feature is there mostly to extend the
> > > channel count from 16 to 32, 48 or 64. I suppose the command:
> > >
> > > "MULTI DEVICE SW LDAC MODE"
> > >
> > > exists so that software can update channel values accross multiple devices.
> >
> > Right! You do have a point! I agree the main driver for a feature like
> > this is likely to extend the channel count and effectively "aggregate"
> > devices.
> >
> > But I would say that even with the spi solution the MULTI DEVICE stuff
> > should be doable (as we still need a sort of adi,pin-id property).
>
> I don't think we can have something like an IIO buffer shared by multiple
> devices. Synchronizing separate devices would be doable with proper hardware
> support for this (probably involving an FGPA).
True!
>
> > But yes, I do feel that the whole feature is for aggregation so seeing
> > one device with 32 channels is the expectation here? Rather than seeing
> > two devices with 16 channels.
>
> Yes, I think aggregation is the whole point there... so that the IIO driver
> is multi-device-aware.
Which makes me feel that different pins per device might be possible
from an HW point of view but does not make much sense. For example, for
the buffer example I would expect LDAC to be shared between all the
devices.
- Nuno Sá
^ permalink raw reply
* [PATCH 1/2] dt-bindings: hwmon: chipcap2: Add label property
From: Flaviu Nistor @ 2026-06-22 12:21 UTC (permalink / raw)
To: Guenter Roeck, Javier Carrasco, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan
Cc: Flaviu Nistor, linux-hwmon, linux-kernel, devicetree, linux-doc
Add support for an optional label property similar to other hwmon devices.
This allows, in case of boards with multiple CHIPCAP2 sensors, to assign
distinct names to each instance.
Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
---
.../devicetree/bindings/hwmon/amphenol,chipcap2.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
index 17351fdbefce..f00b5a4b14dd 100644
--- a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
+++ b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
@@ -33,6 +33,10 @@ properties:
reg:
maxItems: 1
+ label:
+ description:
+ A descriptive name for this channel, like "ambient" or "psu".
+
interrupts:
items:
- description: measurement ready indicator
@@ -72,6 +76,7 @@ examples:
<5 IRQ_TYPE_EDGE_RISING>,
<6 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "ready", "low", "high";
+ label = "somelabel";
vdd-supply = <®_vdd>;
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH 2/2] hwmon: (chipcap2) Add support for label
From: Flaviu Nistor @ 2026-06-22 12:22 UTC (permalink / raw)
To: Guenter Roeck, Javier Carrasco, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan
Cc: Flaviu Nistor, linux-hwmon, linux-kernel, devicetree, linux-doc
In-Reply-To: <20260622122200.14245-1-flaviu.nistor@gmail.com>
Add support for label sysfs attribute similar to other hwmon devices.
This is particularly useful for systems with multiple sensors on the
same board, where identifying individual sensors is much easier since
labels can be defined via device tree.
Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
---
Documentation/hwmon/chipcap2.rst | 2 ++
drivers/hwmon/chipcap2.c | 25 +++++++++++++++++++++++--
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Documentation/hwmon/chipcap2.rst b/Documentation/hwmon/chipcap2.rst
index dc165becc64c..c38d87b91b69 100644
--- a/Documentation/hwmon/chipcap2.rst
+++ b/Documentation/hwmon/chipcap2.rst
@@ -70,4 +70,6 @@ humidity1_min_hyst: RW humidity low hystersis
humidity1_max_hyst: RW humidity high hystersis
humidity1_min_alarm: RO humidity low alarm indicator
humidity1_max_alarm: RO humidity high alarm indicator
+humidity1_label: RO descriptive name for the sensor
+temp1_label: RO descriptive name for the sensor
=============================== ======= ========================================
diff --git a/drivers/hwmon/chipcap2.c b/drivers/hwmon/chipcap2.c
index 4aecf463180f..086571d556b7 100644
--- a/drivers/hwmon/chipcap2.c
+++ b/drivers/hwmon/chipcap2.c
@@ -22,6 +22,8 @@
#include <linux/irq.h>
#include <linux/module.h>
#include <linux/regulator/consumer.h>
+#include <linux/mod_devicetable.h>
+#include <linux/property.h>
#define CC2_START_CM 0xA0
#define CC2_START_NOM 0x80
@@ -83,6 +85,7 @@ struct cc2_data {
struct i2c_client *client;
struct regulator *regulator;
const char *name;
+ const char *label;
int irq_ready;
int irq_low;
int irq_high;
@@ -449,6 +452,8 @@ static umode_t cc2_is_visible(const void *data, enum hwmon_sensor_types type,
switch (attr) {
case hwmon_humidity_input:
return 0444;
+ case hwmon_humidity_label:
+ return cc2->label ? 0444 : 0;
case hwmon_humidity_min_alarm:
return cc2->rh_alarm.low_alarm_visible ? 0444 : 0;
case hwmon_humidity_max_alarm:
@@ -466,6 +471,8 @@ static umode_t cc2_is_visible(const void *data, enum hwmon_sensor_types type,
switch (attr) {
case hwmon_temp_input:
return 0444;
+ case hwmon_temp_label:
+ return cc2->label ? 0444 : 0;
default:
return 0;
}
@@ -552,6 +559,16 @@ static int cc2_humidity_max_alarm_status(struct cc2_data *data, long *val)
return 0;
}
+static int cc2_read_string(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, const char **str)
+{
+ struct cc2_data *data = dev_get_drvdata(dev);
+
+ *str = data->label;
+
+ return 0;
+}
+
static int cc2_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
int channel, long *val)
{
@@ -670,8 +687,9 @@ static int cc2_request_alarm_irqs(struct cc2_data *data, struct device *dev)
}
static const struct hwmon_channel_info *cc2_info[] = {
- HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT),
- HWMON_CHANNEL_INFO(humidity, HWMON_H_INPUT | HWMON_H_MIN | HWMON_H_MAX |
+ HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT | HWMON_T_LABEL),
+ HWMON_CHANNEL_INFO(humidity, HWMON_H_INPUT | HWMON_H_LABEL |
+ HWMON_H_MIN | HWMON_H_MAX |
HWMON_H_MIN_HYST | HWMON_H_MAX_HYST |
HWMON_H_MIN_ALARM | HWMON_H_MAX_ALARM),
NULL
@@ -680,6 +698,7 @@ static const struct hwmon_channel_info *cc2_info[] = {
static const struct hwmon_ops cc2_hwmon_ops = {
.is_visible = cc2_is_visible,
.read = cc2_read,
+ .read_string = cc2_read_string,
.write = cc2_write,
};
@@ -710,6 +729,8 @@ static int cc2_probe(struct i2c_client *client)
return dev_err_probe(dev, PTR_ERR(data->regulator),
"Failed to get regulator\n");
+ device_property_read_string(dev, "label", &data->label);
+
ret = cc2_request_ready_irq(data, dev);
if (ret)
return dev_err_probe(dev, ret, "Failed to request ready irq\n");
--
2.34.1
^ 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