* Re: [PATCH v3 3/4] soc: rockchip: rk3588: add SYS_GRF SOC_CON6 register offset
From: Nicolas Frattaroli @ 2026-04-07 8:10 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Daniele Briguglio
Cc: linux-clk, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Daniele Briguglio
In-Reply-To: <20260320-rk3588-mclk-gate-grf-v3-3-980338eacd2c@superkali.me>
On Friday, 20 March 2026 11:34:15 Central European Summer Time Daniele Briguglio wrote:
> Add the RK3588_SYSGRF_SOC_CON6 register offset to the RK3588 GRF
> header. This register contains the I2S MCLK output to IO gate bits,
> needed by the clock driver.
>
> Signed-off-by: Daniele Briguglio <hello@superkali.me>
> ---
> include/soc/rockchip/rk3588_grf.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/soc/rockchip/rk3588_grf.h b/include/soc/rockchip/rk3588_grf.h
> index 02a7b2432d99..db0092fc66ad 100644
> --- a/include/soc/rockchip/rk3588_grf.h
> +++ b/include/soc/rockchip/rk3588_grf.h
> @@ -19,4 +19,6 @@
> /* Whether the LPDDR5 is in 2:1 (= 0) or 4:1 (= 1) CKR a.k.a. DQS mode */
> #define RK3588_PMUGRF_OS_REG6_LP5_CKR BIT(0)
>
> +#define RK3588_SYSGRF_SOC_CON6 0x0318
> +
> #endif /* __SOC_RK3588_GRF_H */
>
>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Verified the definition by comparing it to hardware documentation,
it checks out.
^ permalink raw reply
* Re: [PATCH v4 6/6] clk: fsl-sai: Add MCLK generation support
From: Michael Walle @ 2026-04-07 8:02 UTC (permalink / raw)
To: Marek Vasut, linux-clk
Cc: Michael Walle, Brian Masney, Conor Dooley, Krzysztof Kozlowski,
Michael Turquette, Rob Herring, Stephen Boyd, devicetree,
linux-kernel
In-Reply-To: <20260406215150.176599-6-marex@nabladev.com>
[-- Attachment #1: Type: text/plain, Size: 2833 bytes --]
On Mon Apr 6, 2026 at 11:49 PM CEST, Marek Vasut wrote:
> The driver currently supports generating BCLK. There are systems which
> require generation of MCLK instead. Register new MCLK clock and handle
> clock-cells = <1> to differentiate between BCLK and MCLK. In case of a
> legacy system with clock-cells = <0>, the driver behaves as before, i.e.
> always returns BCLK.
>
> Note that it is not possible re-use the current SAI audio driver to
> generate MCLK and correctly enable and disable the MCLK.
>
> If SAI (audio driver) is used to control the MCLK enablement, then MCLK
> clock is not always enabled, and it is not necessarily enabled when the
> codec may need the clock to be enabled. There is also no way for the
> codec node to specify phandle to clock provider in DT, because the SAI
> (audio driver) is not clock provider.
>
> If SAI (clock driver) is used to control the MCLK enablement, then MCLK
> clock is enabled when the codec needs the clock enabled, because the
> codec is the clock consumer and the SAI (clock driver) is the clock
> provider, and the codec driver can request the clock to be enabled when
> needed. There is also the usual phandle to clock provider in DT, because
> the SAI (clock driver) is clock provider.
>
> Acked-by: Michael Walle <mwalle@kernel.org>
> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
> Cc: Brian Masney <bmasney@redhat.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Michael Walle <michael@walle.cc>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> V2: No change
> V3: - Rebase on current next, update mail address
> - Update commit message according to clarify the difference between
> SAI audio and SAI clock driver
> - Pick ancient AB from Michael, although this may be outdated
> https://patchwork.kernel.org/project/alsa-devel/patch/20241226162234.40141-4-marex@denx.de/
I'm fine with this, but I want to point out, that this is still a
hack as the correct way would be to make the original SAI (audio
driver) a clock provider. Keep in mind that both driver variants are
mutually exclusive. So if a SoC has 6 SAIs for example, you can only
use 5, because the one will have to be MCLK the clock provider
driver.
In the original LS1028A case (which doesn't have a MCLK), you
actually have to use the hardware peripheral block to generate the
BCLK, thus you'll loose one SAI anyway. In this case - at least from
what I understands - this is just a software construct, because the
original SAI driver is missing a clock provider (phandle).
-michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: milos: Add Iris VPU v2.0
From: Krzysztof Kozlowski @ 2026-04-07 8:05 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Luca Weiss, linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260406-milos-iris-v1-3-17ed0167ba6f@pm.me>
On Mon, Apr 06, 2026 at 10:19:50AM +0000, Alexander Koskovich wrote:
> Add devicetree nodes for the Iris codec (VPU 2.0) found on the Milos
> platform.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> arch/arm64/boot/dts/qcom/milos.dtsi | 85 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 85 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
> index e1a51d43943f..07aa398c9695 100644
> --- a/arch/arm64/boot/dts/qcom/milos.dtsi
> +++ b/arch/arm64/boot/dts/qcom/milos.dtsi
> @@ -7,6 +7,7 @@
> #include <dt-bindings/clock/qcom,milos-dispcc.h>
> #include <dt-bindings/clock/qcom,milos-gcc.h>
> #include <dt-bindings/clock/qcom,milos-gpucc.h>
> +#include <dt-bindings/clock/qcom,milos-videocc.h>
> #include <dt-bindings/clock/qcom,rpmh.h>
> #include <dt-bindings/clock/qcom,sm8650-tcsr.h>
> #include <dt-bindings/dma/qcom-gpi.h>
> @@ -1517,6 +1518,90 @@ usb_1_dwc3_hs: endpoint {
> };
> };
>
> + iris: video-codec@aa00000 {
> + compatible = "qcom,milos-iris";
> + reg = <0 0x0aa00000 0 0xf0000>;
Hex, please.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: media: qcom,milos-iris: Add Milos video codec
From: Krzysztof Kozlowski @ 2026-04-07 8:04 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Luca Weiss, linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260406-milos-iris-v1-1-17ed0167ba6f@pm.me>
On Mon, Apr 06, 2026 at 10:19:34AM +0000, Alexander Koskovich wrote:
> Add binding for Qualcomm Milos Iris video codec.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> .../devicetree/bindings/media/qcom,milos-iris.yaml | 166 +++++++++++++++++++++
> 1 file changed, 166 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: bridge: lt9211: Require data-lanes on DSI input ports
From: Krzysztof Kozlowski @ 2026-04-07 8:00 UTC (permalink / raw)
To: Marek Vasut
Cc: devicetree, Andrzej Hajda, Conor Dooley, David Airlie,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Rob Herring, Robert Foss, Simona Vetter,
Thomas Zimmermann, dri-devel, linux-kernel
In-Reply-To: <20260404034123.340818-1-marex@nabladev.com>
On Sat, Apr 04, 2026 at 05:40:18AM +0200, Marek Vasut wrote:
> The Lontium LT9211 is capable of 1..4 DSI lanes per input DSI port,
> describe the lane count for each input port in the schema.
Ah, and subject does not really match what you did in the patch. It will
match when you fix the patch, though...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: bridge: lt9211: Require data-lanes on DSI input ports
From: Krzysztof Kozlowski @ 2026-04-07 8:00 UTC (permalink / raw)
To: Marek Vasut
Cc: devicetree, Andrzej Hajda, Conor Dooley, David Airlie,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Rob Herring, Robert Foss, Simona Vetter,
Thomas Zimmermann, dri-devel, linux-kernel
In-Reply-To: <20260404034123.340818-1-marex@nabladev.com>
On Sat, Apr 04, 2026 at 05:40:18AM +0200, Marek Vasut wrote:
> The Lontium LT9211 is capable of 1..4 DSI lanes per input DSI port,
> describe the lane count for each input port in the schema.
>
> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
> Cc: Andrzej Hajda <andrzej.hajda@intel.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
> Cc: Jonas Karlman <jonas@kwiboo.se>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Neil Armstrong <neil.armstrong@linaro.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Robert Foss <rfoss@kernel.org>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: devicetree@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> ---
> NOTE: For example Linux kernel driver does already use that information
> and fails to probe if it is missing. There are currently no intree
The first sentence must be part of the commit msg. That is important
reason why you are doing this... but I don't see how you achieve any of
this. Look:
> users for this binding, so no new warnings will be generated once
> this is applied, but a new user is about to be added.
What warnings? How?
> ---
> .../display/bridge/lontium,lt9211.yaml | 37 ++++++++++++++++++-
> 1 file changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
> index 9a6e9b25d14a9..5264fb2b68b78 100644
> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
> @@ -36,18 +36,50 @@ properties:
>
> properties:
> port@0:
> - $ref: /schemas/graph.yaml#/properties/port
> + $ref: /schemas/graph.yaml#/$defs/port-base
OK, that's correct.
> + unevaluatedProperties: false
> description:
> Primary MIPI DSI port-1 for MIPI input or
> LVDS port-1 for LVDS input or DPI input.
>
> + properties:
> + endpoint:
> + $ref: /schemas/media/video-interfaces.yaml#
> + unevaluatedProperties: false
That's correct.
> +
> + properties:
> + data-lanes:
> + description: array of physical DSI data lane indexes.
> + minItems: 1
> + items:
> + - const: 1
> + - const: 2
> + - const: 3
> + - const: 4
That's almost redundant in this context - it was already there - and the
point is that it solves noting in the problem you had. Binding still
does not validate the ABI and does not match it, still.
Since commit foo bar, driver needs data-lanes, so what you need to do is
allow them and to require them. You can also specify their constraints
if device can be configured multiple ways, up to 4 lanes.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: PCI: Add UltraRISC DP1000 PCIe controller
From: Krzysztof Kozlowski @ 2026-04-07 7:50 UTC (permalink / raw)
To: Jia Wang
Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Jingoo Han,
Xincheng Zhang, Krzysztof Kozlowski, Conor Dooley, linux-riscv,
linux-kernel, linux-pci, devicetree
In-Reply-To: <20260407-ultrarisc-pcie-v2-3-2aa2a19a7fb3@ultrarisc.com>
On Tue, Apr 07, 2026 at 10:40:54AM +0800, Jia Wang wrote:
> Add UltraRISC DP1000 SoC PCIe controller devicetree bindings.
>
> Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
> ---
> .../bindings/pci/ultrarisc,dp1000-pcie.yaml | 103 +++++++++++++++++++++
> 1 file changed, 103 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/ultrarisc,dp1000-pcie.yaml b/Documentation/devicetree/bindings/pci/ultrarisc,dp1000-pcie.yaml
> new file mode 100644
> index 000000000000..d0517130e127
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/ultrarisc,dp1000-pcie.yaml
> @@ -0,0 +1,103 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/ultrarisc,dp1000-pcie.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: UltraRISC DP1000 PCIe Host Controller
> +
> +description: |
Do not need '|' unless you need to preserve formatting.
> + UltraRISC DP1000 SoC PCIe host controller is based on the DesignWare PCIe IP.
> + This binding describes the UltraRISC specific extensions to the base
> + DesignWare PCIe binding.
Drop sentence. Do not describe in description what the binding
describes. It's circular / repetitive. Just describe that.
> +
> +maintainers:
> + - Xincheng Zhang <zhangxincheng@ultrarisc.com>
> + - Jia Wang <wangjia@ultrarisc.com>
> +
> +allOf:
> + - $ref: /schemas/pci/snps,dw-pcie.yaml#
> +
> +properties:
> + compatible:
> + const: ultrarisc,dp1000-pcie
> +
> + reg:
> + items:
> + - description: Data Bus Interface (DBI) registers.
> + - description: PCIe configuration space region.
> +
> + reg-names:
> + items:
> + - const: dbi
> + - const: config
> +
> + num-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [4, 16]
> + description: Number of lanes to use.
> +
> + max-link-speed:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + const: 4
If const then deducible from the compatible. Drop the property.
> + description: Maximum PCIe link speed supported.
> +
> + interrupts:
> + description: List of interrupt specifiers used by the controller
Drop description. Obvious.
> + items:
> + - description: MSI interrupt
> + - description: Legacy INTA interrupt
> + - description: Legacy INTB interrupt
> + - description: Legacy INTC interrupt
> + - description: Legacy INTD interrupt
> +
> + interrupt-names:
> + items:
> + - const: msi
> + - const: inta
> + - const: intb
> + - const: intc
> + - const: intd
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> + - interrupt-names
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + pcie_x16: pcie@21000000 {
Drop unused label
> + compatible = "ultrarisc,dp1000-pcie";
reg, names and ranges go here. Please follow DTS coding style.
> + #address-cells = <3>;
> + #size-cells = <2>;
> + #interrupt-cells = <1>;
> + reg = <0x0 0x21000000 0x0 0x01000000>,
> + <0x0 0x4fff0000 0x0 0x00010000>;
> + reg-names = "dbi", "config";
> + device_type = "pci";
> + dma-coherent;
> + bus-range = <0x0 0xff>;
> + num-lanes = <16>;
> + ranges = <0x81000000 0x0 0x4fbf0000 0x0 0x4fbf0000 0x0 0x00400000>,
> + <0x82000000 0x0 0x40000000 0x0 0x40000000 0x0 0x0fbf0000>,
> + <0xc3000000 0x40 0x00000000 0x40 0x00000000 0xd 0x00000000>;
> +
> + max-link-speed = <4>;
Drop, compatible defines this.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/4] MAINTAINERS: Add entry for the UltraRISC DP1000 PCIe controller driver and its DT binding
From: Krzysztof Kozlowski @ 2026-04-07 7:44 UTC (permalink / raw)
To: Jia Wang
Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Jingoo Han,
Xincheng Zhang, Krzysztof Kozlowski, Conor Dooley, linux-riscv,
linux-kernel, linux-pci, devicetree
In-Reply-To: <20260407-ultrarisc-pcie-v2-2-2aa2a19a7fb3@ultrarisc.com>
On Tue, Apr 07, 2026 at 10:40:53AM +0800, Jia Wang wrote:
> Add a MAINTAINERS entry for the UltraRISC DP1000 PCIe host driver and its
> DT binding.
>
> Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
> ---
> MAINTAINERS | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c3fe46d7c4bc..c8159670a14d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20582,6 +20582,14 @@ S: Maintained
> F: Documentation/devicetree/bindings/pci/starfive,jh7110-pcie.yaml
> F: drivers/pci/controller/plda/pcie-starfive.c
>
> +PCIE DRIVER FOR ULTRARISC DP1000
> +M: Xincheng Zhang <zhangxincheng@ultrarisc.com>
> +M: Jia Wang <wangjia@ultrarisc.com>
> +L: linux-pci@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/pci/ultrarisc,dp1000-pcie.yaml
There is no such file.
This is not supposed to be a separate commit.
> +F: drivers/pci/controller/dwc/pcie-ultrarisc.c
No such file.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: interconnect: document the RPMh Network-On-Chip interconnect in Hawi SoC
From: Krzysztof Kozlowski @ 2026-04-07 7:42 UTC (permalink / raw)
To: Vivek Aknurwar
Cc: Georgi Djakov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-pm, devicetree, linux-kernel, Mike Tipton
In-Reply-To: <20260406-icc-hawi-v2-1-6cfee87a1d25@oss.qualcomm.com>
On Mon, Apr 06, 2026 at 04:04:41PM -0700, Vivek Aknurwar wrote:
> Document the RPMh Network-On-Chip Interconnect of the Hawi platform.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
Same fixes needed I wrote to Hawi upstreaming lead in private. That's
why I gave that feedback (privately) very fast, to avoid repeating the
mistake. So since private feedback was ignored, you have now review on
the lists.
All Qualcomm previous patches are poor:
document the RPMh Network-On-Chip interconnect in Mahua SoC
document the RPMh Network-On-Chip interconnect in Eliza SoC
document the RPMh Network-On-Chip interconnect in Kaanapali SoC
document the RPMh Network-On-Chip interconnect in Glymur SoC
Made by the same people.
Why can't you look how Neil did it for SM8650? Or Luca recently for
Milos? Or if you cannot look at non-qcom commits then Rajendra for X1E?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 01/13] dt-bindings: soc: starfive: Add StarFive JHB100 syscon modules
From: Krzysztof Kozlowski @ 2026-04-07 7:37 UTC (permalink / raw)
To: Changhuang Liang
Cc: Michael Turquette, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Philipp Zabel, Emil Renner Berthing, Chen Wang,
Inochi Amaoto, Alexey Charkov, Thomas Bogendoerfer, Keguang Zhang,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
Leyfoon Tan
In-Reply-To: <ZQ4PR01MB1202F9AC0B854D3341EB2CAFF25A2@ZQ4PR01MB1202.CHNPR01.prod.partner.outlook.cn>
On 07/04/2026 09:34, Changhuang Liang wrote:
> Hi, Krzysztof
>
> Thanks for the review.
>
>> On Thu, Apr 02, 2026 at 10:49:33PM -0700, Changhuang Liang wrote:
>>> Add documentation to describe StarFive JHB100 SoC System Controller
>>> Registers.
>>>
>>> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
>>> ---
>>> .../soc/starfive/starfive,jhb100-syscon.yaml | 140
>> ++++++++++++++++++
>>> MAINTAINERS | 5 +
>>> 2 files changed, 145 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-syscon.
>>> yaml
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-sysco
>>> n.yaml
>>> b/Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-sysco
>>> n.yaml
>>> new file mode 100644
>>> index 000000000000..c0e1f6f68fa2
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-s
>>> +++ yscon.yaml
>>> @@ -0,0 +1,140 @@
>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
>>> +---
>>> +$id:
>>> +http://devicetree.org/schemas/soc/starfive/starfive,jhb100-syscon.yam
>>> +l#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: StarFive JHB100 SoC system controller
>>> +
>>> +maintainers:
>>> + - Kevin Xie <kevin.xie@starfivetech.com>
>>> + - Changhuang Liang <changhuang.liang@starfivetech.com>
>>> +
>>> +description:
>>> + The StarFive JHB100 SoC system controller provides register
>>> +information such
>>> + as offset, mask and shift to configure related modules such as PLL and
>> PCIe.
>>
>> How a MMIO based device can provide a MMIO information? What exactly
>> does it provide? Register where the value is the offset of other register?
>
> For example:
> in per1 syscon:
> offset 0x4 is the register configuration for implementing eMMC extended functions,
> and offsets 0x40–0x4c are used for PLL7 register configuration.
>
> In sys0 syscon:
> offsets 0x0–0x2c are used for register configuration of PLL2 to PLL5,
> and offset 0x38 is used for register configuration to provide the product ID.
That's not what the text said. You wrote the device, in MMIO registers,
provides information: offset, mask and shift.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC v1 01/11] media: uapi: v4l2-isp: Add v4l2 ISP extensible statistics definitions
From: Antoine Bouyer @ 2026-04-07 7:37 UTC (permalink / raw)
To: Jacopo Mondi
Cc: julien.vuillaumier, alexi.birlinger, daniel.baluta, peng.fan,
frank.li, laurent.pinchart, mchehab, robh, krzk+dt, conor+dt,
shawnguo, s.hauer, kernel, festevam, linux-kernel, linux-media,
devicetree, linux-arm-kernel, Jai Luthra, paul elder
In-Reply-To: <ac93m33MhldSpYDj@zed>
Hi Jacopo
On 4/3/26 10:19 AM, Jacopo Mondi wrote:
>
>
> Hello Antoine
>
> in cc Jai and Paul
>
> Jai and Paul are working on upstreaming new ISP formats which would
> benefit from usage of extensible stats.
>
> No pressure of course, just wanted to check how things are progressing
> on your side. Do you have an updated version of this patch which can
> be taken in ? Should we sync and work on an updated version ?
I'm still on it. Things are progressing well, but little bit delayed
because of neoisp rework. I hope to submit patchset (v4l2-isp + neo) by
end of this week.
BR
Antoine
>
> Thanks!
> j
>
> On Fri, Jan 23, 2026 at 09:09:28AM +0100, Antoine Bouyer wrote:
>> Extend the v4l2-isp extensible format introduced for isp parameters buffer
>> to the statistics buffer as well.
>>
>> Like for ISP configuration purpose, that will help supporting various ISP
>> hardware versions reporting different statistics data with less impact on
>> userspace.
>>
>> The `v4l2_isp_stats_buffer` reuses the `v4l2_isp_params_buffer` container
>> definitions, with similar header, versions and flags. V0 and V1 versions
>> are provided to match with params versions. On the other side, ENABLE and
>> DISABLE flags are not really meaningfull for statistics purpose. So VALID
>> and INVALID flags are introduced. Purpose is to force ISP driver to
>> validate a statistics buffer, before it is consumed by userspace.
>>
>> Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
>> ---
>> include/uapi/linux/media/v4l2-isp.h | 85 +++++++++++++++++++++++++++++
>> 1 file changed, 85 insertions(+)
>>
>> diff --git a/include/uapi/linux/media/v4l2-isp.h b/include/uapi/linux/media/v4l2-isp.h
>> index 779168f9058e..ed1279b86694 100644
>> --- a/include/uapi/linux/media/v4l2-isp.h
>> +++ b/include/uapi/linux/media/v4l2-isp.h
>> @@ -99,4 +99,89 @@ struct v4l2_isp_params_buffer {
>> __u8 data[] __counted_by(data_size);
>> };
>>
>> +/**
>> + * enum v4l2_isp_stats_version - V4L2 ISP statistics versioning
>> + *
>> + * @V4L2_ISP_STATS_VERSION_V0: First version of the V4L2 ISP statistics format
>> + * (for compatibility)
>> + * @V4L2_ISP_STATS_VERSION_V1: First version of the V4L2 ISP statistics format
>> + *
>> + * V0 and V1 are identical, and comply with V4l2 ISP parameters versions. So
>> + * both V0 and V1 refers to the first version of the V4L2 ISP statistics
>> + * format.
>> + *
>> + * Future revisions of the V4L2 ISP statistics format should start from the
>> + * value of 2.
>> + */
>> +enum v4l2_isp_stats_version {
>> + V4L2_ISP_STATS_VERSION_V0 = 0,
>> + V4L2_ISP_STATS_VERSION_V1,
>> +};
>> +
>> +#define V4L2_ISP_PARAMS_FL_BLOCK_VALID (1U << 0)
>> +#define V4L2_ISP_PARAMS_FL_BLOCK_INVALID (1U << 1)
>> +
>> +/*
>> + * Reserve the first 8 bits for V4L2_ISP_STATS_FL_* flag.
>> + *
>> + * Driver-specific flags should be defined as:
>> + * #define DRIVER_SPECIFIC_FLAG0 ((1U << V4L2_ISP_STATS_FL_DRIVER_FLAGS(0))
>> + * #define DRIVER_SPECIFIC_FLAG1 ((1U << V4L2_ISP_STATS_FL_DRIVER_FLAGS(1))
>> + */
>> +#define V4L2_ISP_STATS_FL_DRIVER_FLAGS(n) ((n) + 8)
>> +
>> +/**
>> + * struct v4l2_isp_stats_block_header - V4L2 extensible statistics block header
>> + * @type: The statistics block type (driver-specific)
>> + * @flags: A bitmask of block flags (driver-specific)
>> + * @size: Size (in bytes) of the statistics block, including this header
>> + *
>> + * This structure represents the common part of all the ISP statistics blocks.
>> + * Each statistics block shall embed an instance of this structure type as its
>> + * first member, followed by the block-specific statistics data.
>> + *
>> + * The @type field is an ISP driver-specific value that identifies the block
>> + * type. The @size field specifies the size of the parameters block.
>> + *
>> + * The @flags field is a bitmask of per-block flags V4L2_STATS_ISP_FL_* and
>> + * driver-specific flags specified by the driver header.
>> + */
>> +struct v4l2_isp_stats_block_header {
>> + __u16 type;
>> + __u16 flags;
>> + __u32 size;
>> +} __attribute__((aligned(8)));
>> +
>> +/**
>> + * struct v4l2_isp_stats_buffer - V4L2 extensible statistics data
>> + * @version: The statistics buffer version (driver-specific)
>> + * @data_size: The statistics data effective size, excluding this header
>> + * @data: The statistics data
>> + *
>> + * This structure contains the statistics information of the ISP hardware,
>> + * serialized for userspace into a data buffer. Each statistics block is
>> + * represented by a block-specific structure which contains a
>> + * :c:type:`v4l2_isp_stats_block_header` entry as first member. Driver
>> + * populates the @data buffer with statistics information of the ISP blocks it
>> + * intends to share to userspace. As a consequence, the data buffer effective
>> + * size changes according to the number of ISP blocks that driver intends to
>> + * provide and is set by the driver in the @data_size field.
>> + *
>> + * The statistics buffer is versioned by the @version field to allow modifying
>> + * and extending its definition. Driver shall populate the @version field to
>> + * inform the userpsace about the version it intends to use. The userspace will
>> + * parse and handle the @data buffer according to the data layout specific to
>> + * the indicated version.
>> + *
>> + * For each ISP block that driver wants to report, a block-specific structure
>> + * is appended to the @data buffer, one after the other without gaps in
>> + * between. Driver shall populate the @data_size field with the effective
>> + * size, in bytes, of the @data buffer.
>> + */
>> +struct v4l2_isp_stats_buffer {
>> + __u32 version;
>> + __u32 data_size;
>> + __u8 data[] __counted_by(data_size);
>> +};
>> +
>> #endif /* _UAPI_V4L2_ISP_H_ */
>> --
>> 2.52.0
>>
^ permalink raw reply
* Re: [PATCH v1 01/13] dt-bindings: soc: starfive: Add StarFive JHB100 syscon modules
From: Changhuang Liang @ 2026-04-07 7:34 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Michael Turquette, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Philipp Zabel, Emil Renner Berthing, Chen Wang,
Inochi Amaoto, Alexey Charkov, Thomas Bogendoerfer, Keguang Zhang,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
Leyfoon Tan
In-Reply-To: <20260405-nocturnal-mighty-pegasus-eff399@quoll>
Hi, Krzysztof
Thanks for the review.
> On Thu, Apr 02, 2026 at 10:49:33PM -0700, Changhuang Liang wrote:
> > Add documentation to describe StarFive JHB100 SoC System Controller
> > Registers.
> >
> > Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> > ---
> > .../soc/starfive/starfive,jhb100-syscon.yaml | 140
> ++++++++++++++++++
> > MAINTAINERS | 5 +
> > 2 files changed, 145 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-syscon.
> > yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-sysco
> > n.yaml
> > b/Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-sysco
> > n.yaml
> > new file mode 100644
> > index 000000000000..c0e1f6f68fa2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/soc/starfive/starfive,jhb100-s
> > +++ yscon.yaml
> > @@ -0,0 +1,140 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +http://devicetree.org/schemas/soc/starfive/starfive,jhb100-syscon.yam
> > +l#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: StarFive JHB100 SoC system controller
> > +
> > +maintainers:
> > + - Kevin Xie <kevin.xie@starfivetech.com>
> > + - Changhuang Liang <changhuang.liang@starfivetech.com>
> > +
> > +description:
> > + The StarFive JHB100 SoC system controller provides register
> > +information such
> > + as offset, mask and shift to configure related modules such as PLL and
> PCIe.
>
> How a MMIO based device can provide a MMIO information? What exactly
> does it provide? Register where the value is the offset of other register?
For example:
in per1 syscon:
offset 0x4 is the register configuration for implementing eMMC extended functions,
and offsets 0x40–0x4c are used for PLL7 register configuration.
In sys0 syscon:
offsets 0x0–0x2c are used for register configuration of PLL2 to PLL5,
and offset 0x38 is used for register configuration to provide the product ID.
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - items:
> > + - enum:
> > + - starfive,jhb100-pcierp-syscon
> > + - starfive,jhb100-per0-syscon
> > + - starfive,jhb100-per1-syscon
> > + - starfive,jhb100-sys0-syscon
> > + - const: syscon
> > + - const: simple-mfd
> > + - items:
> > + - enum:
> > + - starfive,jhb100-b2h-syscon
> > + - starfive,jhb100-gpu-syscon
> > + - starfive,jhb100-h2b-syscon
> > + - starfive,jhb100-host-syscon
> > + - starfive,jhb100-husb-syscon
> > + - starfive,jhb100-husbcmn-syscon
> > + - starfive,jhb100-husbd-syscon
> > + - starfive,jhb100-npu-syscon
> > + - starfive,jhb100-pcieep-ecsr-syscon
> > + - starfive,jhb100-pcierp-ecsr-syscon
> > + - starfive,jhb100-per2-syscon
> > + - starfive,jhb100-per3-syscon
>
> Hm? per2 as starfive,jhb100-per2crg is a separate device, so how can it be
> also a syscon?
The JHB100 SoC is divided into many domains, including the per2 domain.
Each domain has its own CRG and syscon.
Best Regards,
Changhuang
^ permalink raw reply
* Re: [PATCH v5 8/9] driver core: Replace dev->of_node_reused with dev_of_node_reused()
From: Manivannan Sadhasivam @ 2026-04-07 7:27 UTC (permalink / raw)
To: Douglas Anderson
Cc: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern, Alexey Kardashevskiy, Johan Hovold, Eric Dumazet,
Leon Romanovsky, Christoph Hellwig, Robin Murphy, maz,
Alexander Lobakin, Saravana Kannan, Mark Brown, alexander.stein,
andrew, andrew, andriy.shevchenko, astewart, bhelgaas, brgl,
davem, devicetree, driver-core, hkallweit1, jirislaby, joel, kees,
kuba, lgirdwood, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pci, linux-serial, linux-usb, linux, netdev, pabeni, robh
In-Reply-To: <20260406162231.v5.8.I806b8636cd3724f6cd1f5e199318ab8694472d90@changeid>
On Mon, Apr 06, 2026 at 04:23:01PM -0700, Douglas Anderson wrote:
> In C, bitfields are not necessarily safe to modify from multiple
> threads without locking. Switch "of_node_reused" over to the "flags"
> field so modifications are safe.
>
> Cc: Johan Hovold <johan@kernel.org>
> Acked-by: Mark Brown <broonie@kernel.org>
> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
> Reviewed-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org> # PCI_PWRCTRL
- Mani
> ---
> Not fixing any known bugs; problem is theoretical and found by code
> inspection. Change is done somewhat manually and only lightly tested
> (mostly compile-time tested).
>
> (no changes since v4)
>
> Changes in v4:
> - Use accessor functions for flags
>
> Changes in v3:
> - New
>
> drivers/base/core.c | 2 +-
> drivers/base/pinctrl.c | 2 +-
> drivers/base/platform.c | 2 +-
> drivers/net/pcs/pcs-xpcs-plat.c | 2 +-
> drivers/of/device.c | 6 +++---
> drivers/pci/of.c | 2 +-
> drivers/pci/pwrctrl/core.c | 2 +-
> drivers/regulator/bq257xx-regulator.c | 2 +-
> drivers/regulator/rk808-regulator.c | 2 +-
> drivers/tty/serial/serial_base_bus.c | 2 +-
> drivers/usb/gadget/udc/aspeed-vhub/dev.c | 2 +-
> include/linux/device.h | 7 ++++---
> 12 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 8a83d7c93361..30825bf83234 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -5283,7 +5283,7 @@ void device_set_of_node_from_dev(struct device *dev, const struct device *dev2)
> {
> of_node_put(dev->of_node);
> dev->of_node = of_node_get(dev2->of_node);
> - dev->of_node_reused = true;
> + dev_set_of_node_reused(dev);
> }
> EXPORT_SYMBOL_GPL(device_set_of_node_from_dev);
>
> diff --git a/drivers/base/pinctrl.c b/drivers/base/pinctrl.c
> index 6e250272c843..0bbc83231234 100644
> --- a/drivers/base/pinctrl.c
> +++ b/drivers/base/pinctrl.c
> @@ -24,7 +24,7 @@ int pinctrl_bind_pins(struct device *dev)
> {
> int ret;
>
> - if (dev->of_node_reused)
> + if (dev_of_node_reused(dev))
> return 0;
>
> dev->pins = devm_kzalloc(dev, sizeof(*(dev->pins)), GFP_KERNEL);
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index d44591d52e36..199e6fb25770 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -856,7 +856,7 @@ struct platform_device *platform_device_register_full(
> pdev->dev.parent = pdevinfo->parent;
> pdev->dev.fwnode = pdevinfo->fwnode;
> pdev->dev.of_node = of_node_get(to_of_node(pdev->dev.fwnode));
> - pdev->dev.of_node_reused = pdevinfo->of_node_reused;
> + dev_assign_of_node_reused(&pdev->dev, pdevinfo->of_node_reused);
>
> if (pdevinfo->dma_mask) {
> pdev->platform_dma_mask = pdevinfo->dma_mask;
> diff --git a/drivers/net/pcs/pcs-xpcs-plat.c b/drivers/net/pcs/pcs-xpcs-plat.c
> index b8c48f9effbf..f4b1b8246ce9 100644
> --- a/drivers/net/pcs/pcs-xpcs-plat.c
> +++ b/drivers/net/pcs/pcs-xpcs-plat.c
> @@ -349,7 +349,7 @@ static int xpcs_plat_init_dev(struct dw_xpcs_plat *pxpcs)
> * up later. Make sure DD-core is aware of the OF-node being re-used.
> */
> device_set_node(&mdiodev->dev, fwnode_handle_get(dev_fwnode(dev)));
> - mdiodev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&mdiodev->dev);
>
> /* Pass the data further so the DW XPCS driver core could use it */
> mdiodev->dev.platform_data = (void *)device_get_match_data(dev);
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index f7e75e527667..be4e1584e0af 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -26,7 +26,7 @@
> const struct of_device_id *of_match_device(const struct of_device_id *matches,
> const struct device *dev)
> {
> - if (!matches || !dev->of_node || dev->of_node_reused)
> + if (!matches || !dev->of_node || dev_of_node_reused(dev))
> return NULL;
> return of_match_node(matches, dev->of_node);
> }
> @@ -192,7 +192,7 @@ ssize_t of_device_modalias(struct device *dev, char *str, ssize_t len)
> {
> ssize_t sl;
>
> - if (!dev || !dev->of_node || dev->of_node_reused)
> + if (!dev || !dev->of_node || dev_of_node_reused(dev))
> return -ENODEV;
>
> sl = of_modalias(dev->of_node, str, len - 2);
> @@ -254,7 +254,7 @@ int of_device_uevent_modalias(const struct device *dev, struct kobj_uevent_env *
> {
> int sl;
>
> - if ((!dev) || (!dev->of_node) || dev->of_node_reused)
> + if ((!dev) || (!dev->of_node) || dev_of_node_reused(dev))
> return -ENODEV;
>
> /* Devicetree modalias is tricky, we add it in 2 steps */
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index 9f8eb5df279e..1f9b669abdb0 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -38,7 +38,7 @@ int pci_set_of_node(struct pci_dev *dev)
> struct device *pdev __free(put_device) =
> bus_find_device_by_of_node(&platform_bus_type, node);
> if (pdev)
> - dev->bus->dev.of_node_reused = true;
> + dev_set_of_node_reused(&dev->bus->dev);
>
> device_set_node(&dev->dev, of_fwnode_handle(no_free_ptr(node)));
> return 0;
> diff --git a/drivers/pci/pwrctrl/core.c b/drivers/pci/pwrctrl/core.c
> index 7754baed67f2..72963a92362a 100644
> --- a/drivers/pci/pwrctrl/core.c
> +++ b/drivers/pci/pwrctrl/core.c
> @@ -39,7 +39,7 @@ static int pci_pwrctrl_notify(struct notifier_block *nb, unsigned long action,
> * If we got here then the PCI device is the second after the
> * power control platform device. Mark its OF node as reused.
> */
> - dev->of_node_reused = true;
> + dev_set_of_node_reused(dev);
> break;
> }
>
> diff --git a/drivers/regulator/bq257xx-regulator.c b/drivers/regulator/bq257xx-regulator.c
> index dab8f1ab4450..40e0f1a7ae81 100644
> --- a/drivers/regulator/bq257xx-regulator.c
> +++ b/drivers/regulator/bq257xx-regulator.c
> @@ -143,7 +143,7 @@ static int bq257xx_regulator_probe(struct platform_device *pdev)
> struct regulator_config cfg = {};
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> pdata = devm_kzalloc(&pdev->dev, sizeof(struct bq257xx_reg_data), GFP_KERNEL);
> if (!pdata)
> diff --git a/drivers/regulator/rk808-regulator.c b/drivers/regulator/rk808-regulator.c
> index e66408f23bb6..8297d31cde9f 100644
> --- a/drivers/regulator/rk808-regulator.c
> +++ b/drivers/regulator/rk808-regulator.c
> @@ -2115,7 +2115,7 @@ static int rk808_regulator_probe(struct platform_device *pdev)
> int ret, i, nregulators;
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> regmap = dev_get_regmap(pdev->dev.parent, NULL);
> if (!regmap)
> diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c
> index a12935f6b992..5f23284a8778 100644
> --- a/drivers/tty/serial/serial_base_bus.c
> +++ b/drivers/tty/serial/serial_base_bus.c
> @@ -74,7 +74,7 @@ static int serial_base_device_init(struct uart_port *port,
> dev->parent = parent_dev;
> dev->bus = &serial_base_bus_type;
> dev->release = release;
> - dev->of_node_reused = true;
> + dev_set_of_node_reused(dev);
>
> device_set_node(dev, fwnode_handle_get(dev_fwnode(parent_dev)));
>
> diff --git a/drivers/usb/gadget/udc/aspeed-vhub/dev.c b/drivers/usb/gadget/udc/aspeed-vhub/dev.c
> index 2ecd049dacc2..8b9449d16324 100644
> --- a/drivers/usb/gadget/udc/aspeed-vhub/dev.c
> +++ b/drivers/usb/gadget/udc/aspeed-vhub/dev.c
> @@ -593,7 +593,7 @@ int ast_vhub_init_dev(struct ast_vhub *vhub, unsigned int idx)
> d->gadget.max_speed = USB_SPEED_HIGH;
> d->gadget.speed = USB_SPEED_UNKNOWN;
> d->gadget.dev.of_node = vhub->pdev->dev.of_node;
> - d->gadget.dev.of_node_reused = true;
> + dev_set_of_node_reused(&d->gadget.dev);
>
> rc = usb_add_gadget_udc(d->port_dev, &d->gadget);
> if (rc != 0)
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 5b0fb6ad4c72..a79865a212e9 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -483,6 +483,8 @@ struct device_physical_location {
> * driver/bus sync_state() callback.
> * @DEV_FLAG_DMA_COHERENT: This particular device is dma coherent, even if the
> * architecture supports non-coherent devices.
> + * @DEV_FLAG_OF_NODE_REUSED: Set if the device-tree node is shared with an
> + * ancestor device.
> */
> enum struct_device_flags {
> DEV_FLAG_READY_TO_PROBE = 0,
> @@ -492,6 +494,7 @@ enum struct_device_flags {
> DEV_FLAG_DMA_OPS_BYPASS = 4,
> DEV_FLAG_STATE_SYNCED = 5,
> DEV_FLAG_DMA_COHERENT = 6,
> + DEV_FLAG_OF_NODE_REUSED = 7,
>
> DEV_FLAG_COUNT
> };
> @@ -573,8 +576,6 @@ enum struct_device_flags {
> *
> * @offline_disabled: If set, the device is permanently online.
> * @offline: Set after successful invocation of bus type's .offline().
> - * @of_node_reused: Set if the device-tree node is shared with an ancestor
> - * device.
> * @flags: DEV_FLAG_XXX flags. Use atomic bitfield operations to modify.
> *
> * At the lowest level, every device in a Linux system is represented by an
> @@ -681,7 +682,6 @@ struct device {
>
> bool offline_disabled:1;
> bool offline:1;
> - bool of_node_reused:1;
>
> DECLARE_BITMAP(flags, DEV_FLAG_COUNT);
> };
> @@ -715,6 +715,7 @@ __create_dev_flag_accessors(dma_skip_sync, DEV_FLAG_DMA_SKIP_SYNC);
> __create_dev_flag_accessors(dma_ops_bypass, DEV_FLAG_DMA_OPS_BYPASS);
> __create_dev_flag_accessors(state_synced, DEV_FLAG_STATE_SYNCED);
> __create_dev_flag_accessors(dma_coherent, DEV_FLAG_DMA_COHERENT);
> +__create_dev_flag_accessors(of_node_reused, DEV_FLAG_OF_NODE_REUSED);
>
> #undef __create_dev_flag_accessors
>
> --
> 2.53.0.1213.gd9a14994de-goog
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 3/3] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Linus Walleij @ 2026-04-07 7:27 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: brgl, robh, krzk+dt, conor+dt, afaerber, tychang, linux-gpio,
devicetree, linux-kernel, linux-arm-kernel, linux-realtek-soc,
cy.huang, stanley_chang, james.tai
In-Reply-To: <20260331113835.3510341-4-eleanor.lin@realtek.com>
On Tue, Mar 31, 2026 at 1:38 PM Yu-Chun Lin <eleanor.lin@realtek.com> wrote:
> From: Tzuyi Chang <tychang@realtek.com>
>
> Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs.
>
> Unlike the existing Realtek GPIO driver (drivers/gpio/gpio-rtd.c),
> which manages pins via shared bank registers, the RTD1625 introduces
> a per-pin register architecture. Each GPIO line now has its own
> dedicated 32-bit control register to manage configuration independently,
> including direction, output value, input value, interrupt enable, and
> debounce. Therefore, this distinct hardware design requires a separate
> driver.
>
> Signed-off-by: Tzuyi Chang <tychang@realtek.com>
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
With Bartosz comment addressed:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v1 11/13] dt-bindings: hwinfo: Add starfive,jhb100-socinfo
From: Krzysztof Kozlowski @ 2026-04-07 7:06 UTC (permalink / raw)
To: Changhuang Liang
Cc: Michael Turquette, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Philipp Zabel, Emil Renner Berthing, Chen Wang,
Inochi Amaoto, Alexey Charkov, Thomas Bogendoerfer, Keguang Zhang,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
Leyfoon Tan
In-Reply-To: <ZQ4PR01MB12021DE82F5D893BBA15A659F25A2@ZQ4PR01MB1202.CHNPR01.prod.partner.outlook.cn>
On 07/04/2026 08:49, Changhuang Liang wrote:
> Hi, Krzysztof
>
> Thanks for the review.
>
>> On Thu, Apr 02, 2026 at 10:49:43PM -0700, Changhuang Liang wrote:
>>> Add starfive,jhb100-socinfo for StarFive JHB100 SoC.
>>>
>>> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
>>> ---
>>> .../hwinfo/starfive,jhb100-socinfo.yaml | 36
>> +++++++++++++++++++
>>> 1 file changed, 36 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/hwinfo/starfive,jhb100-socinfo.yaml
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/hwinfo/starfive,jhb100-socinfo.yam
>>> l
>>> b/Documentation/devicetree/bindings/hwinfo/starfive,jhb100-socinfo.yam
>>> l
>>> new file mode 100644
>>> index 000000000000..cc6b7d5a4c91
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/hwinfo/starfive,jhb100-socinfo
>>> +++ .yaml
>>> @@ -0,0 +1,36 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
>>> +---
>>> +$id:
>>> +http://devicetree.org/schemas/hwinfo/starfive,jhb100-socinfo.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: StarFive JHB100 SoC platform chipid module
>>> +
>>> +maintainers:
>>> + - Changhuang Liang <changhuang.liang@starfivetech.com>
>>> +
>>> +description:
>>> + StarFive JHB100 SoC platform chipid module is represented by
>>> +JHB100_PRODUCT_ID
>>> + register which contains information about revision. This register
>>> +is located
>>> + under the syscon.
>>> +
>>> +properties:
>>> + compatible:
>>> + items:
>>> + - const: starfive,jhb100-socinfo
>>
>> No, not a separate device.
>>
>>> +
>>> + reg:
>>> + maxItems: 1
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> +
>>> +additionalProperties: false
>>> +
>>> +examples:
>>> + - |
>>> + chipid@38 {
>>> + compatible = "starfive,jhb100-socinfo";
>>> + reg = <0x38 0x4>;
>>
>> One register is not a device. NAK.
>
> I noticed that other platforms have similar practices:
> https://elixir.bootlin.com/linux/v7.0-rc7/source/arch/arm/boot/dts/aspeed/aspeed-g4.dtsi#L205
Sure, how is that DTS and platform?
Why did you chosen exactly this one, known of poor quality and multiple
warnings, but did not choose something which is reviewed in detail and
passes all expectations?
> or could you provide me with alternative suggestions? Thank you very much.
Fold into the parent. See also writing bindings or DTS101 talk.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm: qcom: Document Xiaomi Poco F1 Tianma variant
From: Krzysztof Kozlowski @ 2026-04-07 7:04 UTC (permalink / raw)
To: David Heidelberg
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Marijn Suijten, Casey Connolly, Joel Selvaraj,
Jens Reidel, Arnaud Ferraris, Marco Mattiolo, Petr Hodina,
linux-arm-msm, devicetree, linux-kernel, phone-devel
In-Reply-To: <20260405-beryllium-compat-string-v2-1-91149be07835@ixit.cz>
On Sun, Apr 05, 2026 at 12:54:55PM +0200, David Heidelberg wrote:
> Document the panel-specific compatible string for the Tianma variant
> of the Xiaomi Poco F1:
>
> - "xiaomi,beryllium-tianma"
>
> and require the generic fallback compatible:
>
> - "xiaomi,beryllium"
>
> Update the binding to clarify that all panel variants must list the
> variant-specific compatible first, followed by the generic device
> compatible, in accordance with DT matching rules.
>
> The previous binding documentation did not describe the Tianma variant
> and did not clearly specify the required fallback compatible, which
> resulted in inconsistent DTS implementations.
>
> No functional differences are currently exposed between Tianma and EBBG
> variants at the binding level; both rely on the same generic device
> compatibility for software support.
>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 4/4] arm64: dts: qcom: sdm670: add lpi pinctrl
From: Linus Walleij @ 2026-04-07 7:03 UTC (permalink / raw)
To: Richard Acayan
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm, linux-gpio,
devicetree
In-Reply-To: <20260331200658.1306-5-mailingradian@gmail.com>
On Tue, Mar 31, 2026 at 10:06 PM Richard Acayan <mailingradian@gmail.com> wrote:
> The Snapdragon 670 has a separate TLMM for audio pins. Add the device
> node for it.
>
> Also add reserved GPIOs for the Pixel 3a, which blocks access to the
> sensor GPIOs.
>
> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Acked-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 0/4] SDM670 LPASS LPI pin controller support
From: Linus Walleij @ 2026-04-07 7:02 UTC (permalink / raw)
To: Richard Acayan
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm, linux-gpio,
devicetree
In-Reply-To: <20260331200658.1306-1-mailingradian@gmail.com>
On Tue, Mar 31, 2026 at 10:06 PM Richard Acayan <mailingradian@gmail.com> wrote:
> Richard Acayan (4):
> dt-bindings: qcom: lpass-lpi-common: add reserved GPIOs property
> dt-bindings: pinctrl: qcom: Add SDM670 LPASS LPI pinctrl
> pinctrl: qcom: add sdm670 lpi tlmm
These three patches applied to the pinctrl tree for v7.1
> arm64: dts: qcom: sdm670: add lpi pinctrl
Please funnel this patch through the SoC tree!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v1 02/13] dt-bindings: clock: Add system-0 domain PLL clock
From: Krzysztof Kozlowski @ 2026-04-07 7:02 UTC (permalink / raw)
To: Changhuang Liang
Cc: Michael Turquette, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Philipp Zabel, Emil Renner Berthing, Chen Wang,
Inochi Amaoto, Alexey Charkov, Thomas Bogendoerfer, Keguang Zhang,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
Leyfoon Tan
In-Reply-To: <ZQ4PR01MB120275BC5277C4FF18A738E6F25A2@ZQ4PR01MB1202.CHNPR01.prod.partner.outlook.cn>
On 07/04/2026 08:56, Changhuang Liang wrote:
> Hi, Krzysztof
>
> Thanks for the review.
>
>> On Thu, Apr 02, 2026 at 10:49:34PM -0700, Changhuang Liang wrote:
>>> Add system-0 domain PLL clock for StarFive JHB100 SoC.
>>>
>>> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
>>> ---
>>> .../bindings/clock/starfive,jhb100-pll.yaml | 44 +++++++++++++++++++
>>> .../dt-bindings/clock/starfive,jhb100-crg.h | 6 +++
>>
>> You did not test your code. Apply patch #1 and test it. Do you see build-level
>> errors?
>
> I'm very sorry about this. I will reorganize my patch to avoid the related errors.
>
Anyway this one should be folded into the parent. You have one generic,
system-wide clock as input, so as well this can be the resource of the
parent. And no address spaces.
Other examples have one-register address spaces, so these are not really
separate devices.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v9 3/3] riscv: dts: spacemit: Enable USB3.0/PCIe on OrangePi RV2
From: Chukun Pan @ 2026-04-07 7:00 UTC (permalink / raw)
To: gaohan
Cc: alex, amadeus, aou, conor+dt, devicetree, dlan, krzk+dt, legoll,
linux-kernel, linux-riscv, palmer, pjw, rabenda.cn, robh,
spacemit
In-Reply-To: <dba1428ac649dbc6d3fe4c58f0c6d24bb7432b9f.1775417019.git.gaohan@iscas.ac.cn>
Hi,
> + pcie_vcc3v3: regulator-pcie-vcc3v3 {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio K1_GPIO(116) GPIO_ACTIVE_HIGH>;
> + regulator-name = "pcie_vcc3v3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
Please add: `vin-supply = <&vcc_5v0>;`
> + vcc5v0_usb30: regulator-vcc5v0-usb30 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_usb30";
> + enable-active-high;
> + gpios = <&gpio K1_GPIO(123) GPIO_ACTIVE_HIGH>;
Could you place `regulator-name` under `gpios`?
vcc5v0_usb30: regulator-vcc5v0-usb30 {
compatible = "regulator-fixed";
enable-active-high;
gpios = <&gpio K1_GPIO(123) GPIO_ACTIVE_HIGH>;
regulator-name = "vcc5v0_usb30";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
vin-supply = <&vcc_5v0>;
};
> +&pcie1 {
> + vpcie3v3-supply = <&pcie_vcc3v3>;
Redundant vpcie3v3-supply.
> + status = "okay";
> };
Thanks,
Chukun
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: hwmon/pmbus: Add Infineon XDP720
From: Krzysztof Kozlowski @ 2026-04-07 7:00 UTC (permalink / raw)
To: ASHISH YADAV
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Ashish Yadav
In-Reply-To: <20260406101647.109667-2-Ashish.Yadav@infineon.com>
On Mon, Apr 06, 2026 at 03:46:46PM +0530, ASHISH YADAV wrote:
> From: Ashish Yadav <ashish.yadav@infineon.com>
>
> Add documentation for the device tree binding of the XDP720 eFuse.
> This patch introduces a YAML schema describing the required and optional
Redundant parts was supposed to go to /dev/null.
You already said this in the first sentence.
Also, there is no such thing as YAML schema.
> properties for the XDP720 eFuse device node. It includes details on the
> compatible string, register mapping,supply and rimon-micro-ohms(RIMON).
So nothing here is useful - nothing explains the hardware, so drop all
this and keep only first sentence. Or say something useful about
hardware.
>
> Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com>
> ---
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: leds: Document LTC3208 Multidisplay LED Driver
From: Krzysztof Kozlowski @ 2026-04-07 6:58 UTC (permalink / raw)
To: Jan Carlo Roleda
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-kernel, linux-leds, devicetree
In-Reply-To: <20260406-upstream-ltc3208-v3-2-7f0b1d20ee7a@analog.com>
On Mon, Apr 06, 2026 at 03:17:06PM +0800, Jan Carlo Roleda wrote:
> Add Documentation for LTC3208 Multidisplay LED Driver.
>
> Signed-off-by: Jan Carlo Roleda <jancarlo.roleda@analog.com>
> ---
Still incorrect order.
...
> +
> + led-controller@1b {
> + compatible = "adi,ltc3208";
> + reg = <0x1b>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + adi,disable-camhl-pin;
> + adi,cfg-enrgbs-pin;
> + adi,disable-rgb-aux4-dropout;
> +
> + led@0 {
> + reg = <0>;
I still expect this to be complete, so at least function and color.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 02/13] dt-bindings: clock: Add system-0 domain PLL clock
From: Changhuang Liang @ 2026-04-07 6:56 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Michael Turquette, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Philipp Zabel, Emil Renner Berthing, Chen Wang,
Inochi Amaoto, Alexey Charkov, Thomas Bogendoerfer, Keguang Zhang,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
Leyfoon Tan
In-Reply-To: <20260405-godlike-pistachio-mackerel-7ab494@quoll>
Hi, Krzysztof
Thanks for the review.
> On Thu, Apr 02, 2026 at 10:49:34PM -0700, Changhuang Liang wrote:
> > Add system-0 domain PLL clock for StarFive JHB100 SoC.
> >
> > Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> > ---
> > .../bindings/clock/starfive,jhb100-pll.yaml | 44 +++++++++++++++++++
> > .../dt-bindings/clock/starfive,jhb100-crg.h | 6 +++
>
> You did not test your code. Apply patch #1 and test it. Do you see build-level
> errors?
I'm very sorry about this. I will reorganize my patch to avoid the related errors.
Best Regards,
Changhuang
^ permalink raw reply
* Re: [PATCH V10 03/13] PCI: dwc: Parse Root Port nodes in dw_pcie_host_init()
From: Manivannan Sadhasivam @ 2026-04-07 6:52 UTC (permalink / raw)
To: Sherry Sun
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <VI0PR04MB121147E4D3F9FDC95391C1153925AA@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Tue, Apr 07, 2026 at 03:21:30AM +0000, Sherry Sun wrote:
> > On Thu, Apr 02, 2026 at 05:50:57PM +0800, Sherry Sun wrote:
> > > Add support for parsing Root Port child nodes in dw_pcie_host_init()
> > > using pci_host_common_parse_ports(). This allows DWC-based drivers to
> > > specify Root Port properties (like reset GPIOs) in individual Root
> > > Port nodes rather than in the host bridge node.
> > >
> > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > ---
> > > drivers/pci/controller/dwc/pcie-designware-host.c | 8 ++++++++
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > index da152c31bb2e..f6fca984fb34 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > @@ -20,6 +20,7 @@
> > > #include <linux/platform_device.h>
> > >
> > > #include "../../pci.h"
> > > +#include "../pci-host-common.h"
> > > #include "pcie-designware.h"
> > >
> > > static struct pci_ops dw_pcie_ops;
> > > @@ -581,6 +582,13 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
> > >
> > > pp->bridge = bridge;
> > >
> > > + /* Parse Root Port nodes if present */
> > > + ret = pci_host_common_parse_ports(dev, bridge);
> > > + if (ret && ret != -ENOENT) {
> > > + dev_err(dev, "Failed to parse Root Port nodes: %d\n", ret);
> > > + return ret;
> >
> > Won't this change break drivers that parse Root Ports on their own? Either
> > you need to modify them also in this change or call this API from imx6 driver
> > and let other drivers switch to it in a phased manner.
> >
> > I perfer the latter.
>
> Hi Mani, sorry I didn't fully get your point here, there are no changes to this part
> V10, for drivers that parse Root Ports on their own, here pci_host_common_parse_ports()
> will return -ENOENT, so nothing break as we discussed this in V8
> https://lore.kernel.org/all/dcl3bdljrdzgeaybrg3dc5uaxkebkjns7pajix6mxxftao5g4m@vm3ywyyp4ujh/.
>
So if this API gets called first, it will acquire PERST# from the Root Port node
and if the controller drivers try to do the same in their own parsing code,
PERST# request will return -EBUSY and the probe will fail.
On the other hand, if the controller drivers parse PERST# first, this API will
return -EBUSY and will result in probe failure.
Only way to fix this issue would be to call this API from imx6 driver for now
and start migrating other drivers later.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v1 11/13] dt-bindings: hwinfo: Add starfive,jhb100-socinfo
From: Changhuang Liang @ 2026-04-07 6:49 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Michael Turquette, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Philipp Zabel, Emil Renner Berthing, Chen Wang,
Inochi Amaoto, Alexey Charkov, Thomas Bogendoerfer, Keguang Zhang,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
Leyfoon Tan
In-Reply-To: <20260405-strong-watchful-marmot-fdfad6@quoll>
Hi, Krzysztof
Thanks for the review.
> On Thu, Apr 02, 2026 at 10:49:43PM -0700, Changhuang Liang wrote:
> > Add starfive,jhb100-socinfo for StarFive JHB100 SoC.
> >
> > Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> > ---
> > .../hwinfo/starfive,jhb100-socinfo.yaml | 36
> +++++++++++++++++++
> > 1 file changed, 36 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/hwinfo/starfive,jhb100-socinfo.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/hwinfo/starfive,jhb100-socinfo.yam
> > l
> > b/Documentation/devicetree/bindings/hwinfo/starfive,jhb100-socinfo.yam
> > l
> > new file mode 100644
> > index 000000000000..cc6b7d5a4c91
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/hwinfo/starfive,jhb100-socinfo
> > +++ .yaml
> > @@ -0,0 +1,36 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +http://devicetree.org/schemas/hwinfo/starfive,jhb100-socinfo.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: StarFive JHB100 SoC platform chipid module
> > +
> > +maintainers:
> > + - Changhuang Liang <changhuang.liang@starfivetech.com>
> > +
> > +description:
> > + StarFive JHB100 SoC platform chipid module is represented by
> > +JHB100_PRODUCT_ID
> > + register which contains information about revision. This register
> > +is located
> > + under the syscon.
> > +
> > +properties:
> > + compatible:
> > + items:
> > + - const: starfive,jhb100-socinfo
>
> No, not a separate device.
>
> > +
> > + reg:
> > + maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + chipid@38 {
> > + compatible = "starfive,jhb100-socinfo";
> > + reg = <0x38 0x4>;
>
> One register is not a device. NAK.
I noticed that other platforms have similar practices:
https://elixir.bootlin.com/linux/v7.0-rc7/source/arch/arm/boot/dts/aspeed/aspeed-g4.dtsi#L205
or could you provide me with alternative suggestions? Thank you very much.
Best Regards,
Changhuang
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox