* Re: [PATCH 12/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: add LPASS CPU audio variant
From: Konrad Dybcio @ 2026-04-08 9:06 UTC (permalink / raw)
To: Xilin Wu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Liam Girdwood, Mark Brown, Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, linux-sound
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-12-14aca49dde3d@radxa.com>
On 4/7/26 5:20 PM, Xilin Wu wrote:
> Add a qcs6490-radxa-dragon-q6a-lpass-cpu.dts variant for debugging and
> bring-up of the host-controlled LPASS audio path on the Radxa Dragon
> Q6A.
>
> This variant enables the LPASS blocks and codec macros needed by the
> lpass-cpu driver, wires WCD9380 playback/capture and DisplayPort audio
> to the LPASS CDC DMA and DP interfaces, and disables remoteproc_adsp so
> that the audio hardware is owned directly by Linux.
>
> This DTB is an optional configuration for systems booted with the kernel
> running at EL2, where direct CPU access to the LPASS hardware is
> available. It is useful for users who need low-latency and fully
> controllable audio.
I believe on Chrome platforms it was done this way because at some point
it was determined that they would specifically like not to use the DSP.
I think this is more of a hack than anything else.. but at the end of the
commit message you mention low latency - is the impact actually measurable?
Konrad
^ permalink raw reply
* Re: [PATCH] Update my email address
From: Krzysztof Kozlowski @ 2026-04-08 9:04 UTC (permalink / raw)
To: Sean Anderson
Cc: Andrew Morton, linux-kernel, Rob Herring, devicetree,
Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260407164722.211610-1-sean.anderson@linux.dev>
On Tue, Apr 07, 2026 at 12:47:21PM -0400, Sean Anderson wrote:
> Soon I will no longer be working at SECO. Update the mailmap to redirect
> to my linux.dev address which I still have access to.
>
> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> ---
>
> .mailmap | 1 +
> Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml | 2 +-
> MAINTAINERS | 4 ++--
> 3 files changed, 4 insertions(+), 3 deletions(-)
You CC-ed Andrew, so maybe he will take the patch?
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 08/12] arm64: dts: qcom: kodiak: Mark secondary USB controller as wakeup source
From: Konrad Dybcio @ 2026-04-08 9:04 UTC (permalink / raw)
To: Xilin Wu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Liam Girdwood, Mark Brown, Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, linux-sound,
Stephen Chen
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-8-14aca49dde3d@radxa.com>
On 4/7/26 5:20 PM, Xilin Wu wrote:
> From: Stephen Chen <stephen@radxa.com>
>
> Mark the secondary USB controller (usb_2) as a wakeup source so that it
> can be used to wake the system from suspend.
>
> Signed-off-by: Stephen Chen <stephen@radxa.com>
> Signed-off-by: Xilin Wu <sophon@radxa.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 07/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Correct GPIO_27 label
From: Konrad Dybcio @ 2026-04-08 9:04 UTC (permalink / raw)
To: Xilin Wu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Liam Girdwood, Mark Brown, Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, linux-sound,
Stephen Chen
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-7-14aca49dde3d@radxa.com>
On 4/7/26 5:19 PM, Xilin Wu wrote:
> From: Stephen Chen <stephen@radxa.com>
>
> The label of GPIO_27 is wrong. Fix it.
>
> Fixes: ef254b12ec60 ("arm64: dts: qcom: qcs6490: Introduce Radxa Dragon Q6A")
> Signed-off-by: Stephen Chen <stephen@radxa.com>
> Signed-off-by: Xilin Wu <sophon@radxa.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 05/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Use board-specific CDSP firmware
From: Konrad Dybcio @ 2026-04-08 9:04 UTC (permalink / raw)
To: Xilin Wu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Liam Girdwood, Mark Brown, Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, linux-sound
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-5-14aca49dde3d@radxa.com>
On 4/7/26 5:19 PM, Xilin Wu wrote:
> The official boot firmware for Dragon Q6A has been switched to the
> Qualcomm WP (Windows) boot firmware. Use the matching board-specific
> CDSP firmware instead of the generic one so that the DSP firmware stack
> remains compatible with the new boot firmware.
>
> The corresponding custom DSP firmware has already been added to
> linux-firmware:
>
> https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/882
>
> Signed-off-by: Xilin Wu <sophon@radxa.com>
> ---
It's a little shaky given you say it must be changed to remain compatible..
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v1] dt-bindings: soc: microchip: document irqmux on pic64gx
From: Krzysztof Kozlowski @ 2026-04-08 9:04 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-riscv, Conor Dooley, Daire McNamara, Rob Herring,
Krzysztof Kozlowski, devicetree, linux-kernel
In-Reply-To: <20260407-headache-reward-ae93bacdba0e@spud>
On Tue, Apr 07, 2026 at 04:29:31PM +0100, Conor Dooley wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
>
> Being practically identical to PolarFire SoC, pic64gx has a irqmux
> that's entirely compatible with that on mpfs.
>
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> CC: Conor Dooley <conor.dooley@microchip.com>
> CC: Daire McNamara <daire.mcnamara@microchip.com>
> CC: Rob Herring <robh@kernel.org>
> CC: Krzysztof Kozlowski <krzk+dt@kernel.org>
> CC: linux-riscv@lists.infradead.org
> CC: devicetree@vger.kernel.org
> CC: linux-kernel@vger.kernel.org
> ---
> .../bindings/soc/microchip/microchip,mpfs-irqmux.yaml | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 03/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable USB 3.0 and HDMI ports
From: Konrad Dybcio @ 2026-04-08 9:03 UTC (permalink / raw)
To: Xilin Wu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Liam Girdwood, Mark Brown, Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, linux-sound
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-3-14aca49dde3d@radxa.com>
On 4/7/26 5:19 PM, Xilin Wu wrote:
> This board doesn't feature a regular Type-C port. The usb_1_qmpphy's
I guess the receptacle on board is power-only?
> RX1/TX1 pair is statically connected to the USB-A port, while its RX0/TX0
> pair is connected to the RA620 DP-to-HDMI bridge.
>
> Add and enable the nodes for the features to work.
>
> Signed-off-by: Xilin Wu <sophon@radxa.com>
> ---
> .../boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts | 152 +++++++++++++++++++++
> 1 file changed, 152 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> index c961d3ec625f..8d649b3a1cfa 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> @@ -111,6 +111,71 @@ usb2_3_connector: endpoint {
> };
> };
>
> + usb3_con: connector {
This label is unused
> + compatible = "usb-a-connector";
No vbus-supply?
[...]
> +&mdss_dp {
> + sound-name-prefix = "Display Port0";
Hmmmmm.. other platforms call it "DisplayPort0" (without a space)..
But I suppose this name needs to match UCM..
We'd also normally push this property to the SoC DTSI
Konrad
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: monaco: Add default GIC address cells
From: Krzysztof Kozlowski @ 2026-04-08 9:02 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam,
Ziyue Zhang, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <4de63324-2f66-48ca-be1d-e8f20e8727e0@oss.qualcomm.com>
On 08/04/2026 10:56, Konrad Dybcio wrote:
> On 4/7/26 10:15 PM, Krzysztof Kozlowski wrote:
>> Add missing address-cells 0 to GIC interrupt node to silence W=1
>> warning:
>>
>> monaco.dtsi:2326.4-2329.30: Warning (interrupt_map): /soc@0/pci@1c00000:interrupt-map:
>> Missing property '#address-cells' in node /soc@0/interrupt-controller@17a00000, using 0 as fallback
>>
>> Value '0' is correct because:
>> 1. GIC interrupt controller does not have children,
>> 2. interrupt-map property (in PCI node) consists of five components and
>> the fourth component 'parent unit address', which size is defined by
>> '#address-cells' of the node pointed to by the interrupt-parent
>> component, is not used (=0).
>>
>> Fixes: 46a7c01e7e9d ("arm64: dts: qcom: qcs8300: enable pcie0")
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>
>> ---
>>
>> Fix for v7.0-rcX.
>> ---
>
> An alternative change would be to describe the GIC_ITS
Yes, but that's pretty different goal and requires testing.
My goal is that code people sent is without warnings :/. I wish there
were some tools helping in that, like you run a command and it tells you
if there is a warning or not.
>
> but for this warning fix:
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [net-next v1 v1 5/5] net: stmmac: starfive: Add STMMAC_FLAG_SPH_DISABLE flag
From: Minda Chen @ 2026-04-08 8:44 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260408084416.29753-1-minda.chen@starfivetech.com>
Add default disable split header flag in all the starfive
soc.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
index df7b2fc9989d..f6e5a2c4dc27 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
@@ -143,7 +143,7 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
}
dwmac->dev = &pdev->dev;
- plat_dat->flags |= STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP;
+ plat_dat->flags |= (STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP | STMMAC_FLAG_SPH_DISABLE);
plat_dat->bsp_priv = dwmac;
plat_dat->dma_cfg->dche = true;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 2/3] ARM: dts: aspeed: anacapa: add EVT1 devicetree and point wrapper to it
From: Krzysztof Kozlowski @ 2026-04-08 9:00 UTC (permalink / raw)
To: Colin Huang
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, colin.huang2
In-Reply-To: <CAPBH0A-ER9-_KpknyOKTmS2sBk-xv0c016y9WsLOvZ8CjSiwCw@mail.gmail.com>
On 08/04/2026 10:52, Colin Huang wrote:
> Hi Krzysztof,
> Thanks for reply.
Do not top post.
> Could you let me know what kind test I need to run?
> Following is what I do before send.
> * I build this dts with linux 6.6.x
v6.6? That's like 2.5 years ago.
No, you must work on recent kernel.
> * run "b4 prep --check"
Google - how to validate DTS in Linux kernel
Best regards,
Krzysztof
^ permalink raw reply
* [net-next v1 v1 0/5] Add StarFive JHB100 soc SGMII GMAC support
From: Minda Chen @ 2026-04-08 8:44 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
JHB100 is a Starfive new RISC-V SoC for datacenter BMC (BaseBoard
Managent Controller). Similar with Aspeed 27x0.
The JHB100 minimal system upstream is in progress:
https://patchwork.kernel.org/project/linux-riscv/cover/20260403054945.467700-1-changhuang.liang@starfivetech.com/
JHB100 GMAC still using designware GMAC core like JH7100 and JH7110,
and contains 2 SGMII interfaces, 1 RGMII/RMII interface, 1 RMII
interface. In JH7100/JH7110 dwmac-starfive.c have supported RGMII/RMII
interface. So require to add SGMII support to dwmac-starfive.c for JHB100.
SGMII serdes PHY has been intergrated in JHB100 and do not have driver
setting.
In JHB100 EVB board, SGMII connect with motorcomm YT8531s external PHY
and support RJ45 ethernet port.
The patch base in 7.0-rc5
Minda Chen (5):
dt-bindings: net: starfive,jh7110-dwmac: Remove JH8100
dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 support
dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 sgmii rx clk
net: stmmac: starfive: Add JHB100 SGMII interface
net: stmmac: starfive: Add STMMAC_FLAG_SPH_DISABLE flag
.../devicetree/bindings/net/snps,dwmac.yaml | 1 +
.../bindings/net/starfive,jh7110-dwmac.yaml | 89 +++++++++++++------
.../ethernet/stmicro/stmmac/dwmac-starfive.c | 38 +++++++-
3 files changed, 98 insertions(+), 30 deletions(-)
base-commit: c369299895a591d96745d6492d4888259b004a9e
--
2.17.1
^ permalink raw reply
* Re: [PATCH 02/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable UFS controller
From: Konrad Dybcio @ 2026-04-08 8:59 UTC (permalink / raw)
To: Xilin Wu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Liam Girdwood, Mark Brown, Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, linux-sound
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-2-14aca49dde3d@radxa.com>
On 4/7/26 5:19 PM, Xilin Wu wrote:
> Add and enable UFS related nodes for this board.
>
> Note that UFS Gear-4 Rate-B is unstable due to board and UFS module design
> limitations. UFS on this board is stable when working at Gear-4 Rate-A.
>
> Signed-off-by: Xilin Wu <sophon@radxa.com>
> ---
> .../boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> index bb5a42b038f1..c961d3ec625f 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> @@ -959,6 +959,29 @@ &uart5 {
> status = "okay";
> };
>
> +&ufs_mem_hc {
> + reset-gpios = <&tlmm 175 GPIO_ACTIVE_LOW>;
> + vcc-supply = <&vreg_l7b_2p96>;
> + vcc-max-microamp = <800000>;
> + vccq-supply = <&vreg_l9b_1p2>;
> + vccq-max-microamp = <900000>;
> + vccq2-supply = <&vreg_l9b_1p2>;
> + vccq2-max-microamp = <1300000>;
> +
> + /* Gear-4 Rate-B is unstable due to board */
> + /* and UFS module design limitations */
/* it's a bit weird to add two single-line */
/* comments near one another for a single paragraph */
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* RE: [PATCH v4 net-next 10/14] net: dsa: netc: introduce NXP NETC switch driver for i.MX94
From: Wei Fang @ 2026-04-08 8:59 UTC (permalink / raw)
To: Jakub Kicinski, Vladimir Oltean
Cc: Claudiu Manoil, Clark Wang, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
f.fainelli@gmail.com, Frank Li, chleroy@kernel.org,
horms@kernel.org, linux@armlinux.org.uk, andrew@lunn.ch,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011738.1795644-1-kuba@kernel.org>
> > +static int netc_init_switch_id(struct netc_switch *priv)
> > +{
> > + struct netc_switch_regs *regs = &priv->regs;
> > + struct dsa_switch *ds = priv->ds;
> > +
> > + /* The value of 0 is reserved for the VEPA switch and cannot
> > + * be used.
> > + */
> > + if (ds->index > SWCR_SWID || !ds->index) {
> > + dev_err(priv->dev, "Switch index %d out of range\n",
> > + ds->index);
> > + return -ERANGE;
> > + }
>
> Does this check cause the probe to fail unconditionally for standard
> single-switch topologies?
>
> The DSA core typically assigns ds->index = 0 by default for the first switch.
> Because !ds->index evaluates to true for index 0, this setup function will
> always fail unless the dsa,member property is explicitly overridden in the
> device tree.
As I mentioned in another mail, we added the 'dsa,member' property to the
netc switch DT-binding doc, specifying that the 'member' (switch index) value
cannot be 0. And 'dsa,member' is a required property for netc switch.
>
> Could the driver translate the hardware ID internally, for example by writing
> ds->index + 1 to NETC_SWCR, rather than forcing this hardware-specific
> restriction onto the software DSA index?
The current approach is based on Vladimir's suggestion. I need to confirm with
Vladimir which approach is better.
Hi Vladimir,
What are your thoughts on this suggestion? Is this approach better?
>
> [ ... ]
> > + for_each_available_child_of_node_scoped(ports, child) {
> > + /* If the node does not have phy-handle property, then
> > + * the port does not connect to a PHY, so the port is
> > + * not the EMDIO consumer.
> > + */
> > + phy_node = of_parse_phandle(child, "phy-handle", 0);
> > + if (!phy_node)
> > + continue;
> > +
> > + if (!netc_port_is_emdio_consumer(child)) {
> > + of_node_put(phy_node);
> > + continue;
> > + }
> > +
> > + phydev = of_phy_find_device(phy_node);
> > + of_node_put(phy_node);
> > + if (!phydev) {
> > + err = -EPROBE_DEFER;
> > + goto out;
> > + }
>
> Could this logic cause an infinite probe deferral loop for ports sharing an
> internal MDIO bus?
>
> The netc_port_is_emdio_consumer() function assumes any port node without
> an
> mdio child is an EMDIO consumer waiting for an external controller. However,
> if multiple sibling ports on the same switch share a single internal MDIO bus
> defined under one port, the other ports will lack an mdio child node.
>
> This would cause those ports to be mistakenly treated as external EMDIO
> consumers, calling of_phy_find_device(). Because the internal MDIO bus is not
> registered until later in netc_setup(), the PHY device cannot be found, and
> the driver returns -EPROBE_DEFER.
>
> Since netc_setup() is never reached, the MDIO bus is never registered,
> causing an infinite deferral loop. Could the driver more accurately identify
> whether the PHY belongs to its own switch before deferring?
This case will not be true, from the hardware perspective, the switch ports
do not support share a single internal MDIO bus defined under one port.
The internal MDIO bus of a port can only access its own external PHY. So
a switch port must either use EMDIO to access its PHY or its internal MDIO
bus to access its PHY.
>
> > +
> > + put_device(&phydev->mdio.dev);
> > + }
> > +
> > +out:
> > + of_node_put(ports);
> > +
> > + return err;
> > +}
> > +
> > +static int netc_switch_pci_init(struct pci_dev *pdev)
> > +{
> [ ... ]
> > + regs->base = pci_ioremap_bar(pdev, NETC_REGS_BAR);
> > + if (!regs->base) {
> > + err = -ENXIO;
> > + dev_err(dev, "pci_ioremap_bar() failed\n");
> > + goto release_mem_regions;
> > + }
> [ ... ]
> > +static void netc_switch_pci_destroy(struct pci_dev *pdev)
> > +{
> > + struct netc_switch *priv = pci_get_drvdata(pdev);
> > +
> > + iounmap(priv->regs.base);
> > + pci_release_mem_regions(pdev);
> > + pci_disable_device(pdev);
> > +}
>
> Does unmapping the memory here introduce a use-after-unmap issue when the
> MDIO bus is unregistered?
>
> The driver registers the MDIO bus using devm_of_mdiobus_register(), meaning
> devres cleans it up asynchronously after the remove function returns or when
> probe fails.
>
> However, in netc_switch_pci_destroy(), the driver explicitly unmaps the PCI
> I/O memory via iounmap(). Since netc_switch_pci_destroy() is called
> synchronously inside the remove function and probe error paths, the memory is
> unmapped before the MDIO bus is unregistered by devres.
>
> When devres eventually unregisters the MDIO bus, it detaches PHY devices,
> which often perform MDIO transactions during removal. Because the
> underlying
> memory priv->regs.base is already unmapped, these MDIO read/write callbacks
> could trigger a synchronous external abort or kernel panic.
>
> Would it be better to use pcim_iomap() to tie the memory mapping lifecycle to
> devres, ensuring it outlives the MDIO bus?
Great, I will pcim_iomap().
^ permalink raw reply
* Re: [PATCH RFC v3 3/7] drm/msm/adreno: rename llc_mmio to cx_misc_mmio
From: Konrad Dybcio @ 2026-04-08 8:58 UTC (permalink / raw)
To: Alexander Koskovich, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Akhil P Oommen, Bjorn Andersson
Cc: Luca Weiss, linux-arm-msm, dri-devel, freedreno, devicetree,
linux-kernel
In-Reply-To: <20260407-adreno-810-v3-3-30cb7f196ed4@pm.me>
On 4/8/26 3:45 AM, Alexander Koskovich wrote:
> This region is used for more than just LLCC, it also provides access to
> software fuse values (raytracing, etc).
>
> Rename relevant symbols from _llc to _cx_misc for use in a follow up
> change that decouples this from LLCC.
>
> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
Seems you lost my tag
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: monaco: Add default GIC address cells
From: Konrad Dybcio @ 2026-04-08 8:56 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam,
Ziyue Zhang, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260407201518.24949-2-krzysztof.kozlowski@oss.qualcomm.com>
On 4/7/26 10:15 PM, Krzysztof Kozlowski wrote:
> Add missing address-cells 0 to GIC interrupt node to silence W=1
> warning:
>
> monaco.dtsi:2326.4-2329.30: Warning (interrupt_map): /soc@0/pci@1c00000:interrupt-map:
> Missing property '#address-cells' in node /soc@0/interrupt-controller@17a00000, using 0 as fallback
>
> Value '0' is correct because:
> 1. GIC interrupt controller does not have children,
> 2. interrupt-map property (in PCI node) consists of five components and
> the fourth component 'parent unit address', which size is defined by
> '#address-cells' of the node pointed to by the interrupt-parent
> component, is not used (=0).
>
> Fixes: 46a7c01e7e9d ("arm64: dts: qcom: qcs8300: enable pcie0")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Fix for v7.0-rcX.
> ---
An alternative change would be to describe the GIC_ITS
but for this warning fix:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH v4 1/2] dt-bindings: spi: renesas,rzv2h-rspi: Document RZ/G3L SoC
From: Biju @ 2026-04-08 8:54 UTC (permalink / raw)
To: Fabrizio Castro, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, linux-spi, linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad, Biju Das, Krzysztof Kozlowski
In-Reply-To: <20260408085418.18770-1-biju.das.jz@bp.renesas.com>
From: Biju Das <biju.das.jz@bp.renesas.com>
Document RSPI IP found on the RZ/G3L SoC. The RSPI IP is compatible with
the RZ/V2H RSPI IP, but has 2 clocks compared to 3 on RZ/V2H.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v3->v4:
* Added a blank line before the dmas property.
* Collected tags.
v2->v3:
* Added ordered DMA names for the dma-names property.
* Dropped the tag
v1->v2:
* Collected tag
---
.../bindings/spi/renesas,rzv2h-rspi.yaml | 29 +++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
index 2c9045fd51de..f40f316943ba 100644
--- a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
+++ b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
@@ -13,6 +13,7 @@ properties:
compatible:
oneOf:
- enum:
+ - renesas,r9a08g046-rspi # RZ/G3L
- renesas,r9a09g057-rspi # RZ/V2H(P)
- renesas,r9a09g077-rspi # RZ/T2H
- items:
@@ -90,6 +91,34 @@ required:
allOf:
- $ref: spi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a08g046-rspi
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: tclk
+
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ required:
+ - resets
+ - reset-names
+
- if:
properties:
compatible:
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/2] Add Renesas RZ/G3L RSPI support
From: Biju @ 2026-04-08 8:54 UTC (permalink / raw)
To: Fabrizio Castro, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, linux-spi, linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad, Biju Das
From: Biju Das <biju.das.jz@bp.renesas.com>
This patch series adds binding and driver support for RSPI IP found on the
RZ/G3L SoC. The RSPI is compatible with RZ/V2H RSPI, but has 2 clocks
compared to 3 on RZ/V2H.
v3->v4:
* Added a blank line before the dmas property in bindings.
* Collected tags for binding patch.
v2->v3:
* Added ordered DMA names for the dma-names property.
* Dropped the tag from bindings as there is a change related to dma-names
property.
v1->v2:
* Rebased to next
* Collected tags
Biju Das (2):
dt-bindings: spi: renesas,rzv2h-rspi: Document RZ/G3L SoC
spi: rzv2h-rspi: Add support for RZ/G3L (R9A08G046)
.../bindings/spi/renesas,rzv2h-rspi.yaml | 29 +++++++++++++++++++
drivers/spi/spi-rzv2h-rspi.c | 8 +++++
2 files changed, 37 insertions(+)
--
2.43.0
^ permalink raw reply
* Re: [PATCH 2/3] ARM: dts: aspeed: anacapa: add EVT1 devicetree and point wrapper to it
From: Colin Huang @ 2026-04-08 8:52 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, colin.huang2
In-Reply-To: <20260408-glorious-vehement-robin-b6def3@quoll>
Hi Krzysztof,
Thanks for reply.
Could you let me know what kind test I need to run?
Following is what I do before send.
* I build this dts with linux 6.6.x
* run "b4 prep --check"
BR,
Colin Huang
Krzysztof Kozlowski <krzk@kernel.org> 於 2026年4月8日週三 下午3:52寫道：
>
> On Tue, Apr 07, 2026 at 09:54:33PM +0800, Colin Huang wrote:
> > This change introduces a development-phase devicetree for the
> > Facebook Anacapa BMC EVT1 hardware revision and updates the Anacapa
> > wrapper DTS to reference it.
> >
> > A dedicated EVT1 DTS is added for revision-specific hardware while
> > keeping a single, Anacapa entrypoint used by the build and deployment
> > flow. The top-level aspeed-bmc-facebook-anacapa.dts
> >
> > Signed-off-by: Colin Huang <u8813345@gmail.com>
> > ---
> > .../aspeed/aspeed-bmc-facebook-anacapa-evt1.dts | 1069 ++++++++++++++++++++
> > .../dts/aspeed/aspeed-bmc-facebook-anacapa.dts | 1064 +------------------
> > 2 files changed, 1070 insertions(+), 1063 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa-evt1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa-evt1.dts
> > new file mode 100644
> > index 000000000000..a29b7fa1155b
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa-evt1.dts
> > @@ -0,0 +1,1069 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +
> > +/dts-v1/;
> > +#include "aspeed-g6.dtsi"
> > +#include <dt-bindings/gpio/aspeed-gpio.h>
> > +#include <dt-bindings/i2c/i2c.h>
> > +
> > +/ {
> > + model = "Facebook Anacapa BMC";
> > + compatible = "facebook,anacapa-bmc-evt1",
> > + "facebook,anacapa-bmc",
> > + "aspeed,ast2600";
>
> Test your DTS before you send, not after. Your binding clearly said
> something else.
>
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH] clk: microchip: mpfs-ccc: fix out-of-bounds write
From: Conor Dooley @ 2026-04-08 8:49 UTC (permalink / raw)
To: Aleš Pečnik
Cc: Conor Dooley, Daire McNamara, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, linux-riscv, linux-clk,
linux-kernel, devicetree
In-Reply-To: <20260408-mpfs-clk-oob-write-v1-1-8b3b387f2a6f@skylabs.si>
[-- Attachment #1: Type: text/plain, Size: 3029 bytes --]
On Wed, Apr 08, 2026 at 07:07:34AM +0200, Aleš Pečnik wrote:
> Issue was allocated array size for clk_data.
> When clocks are being registered their index is taken from defines in
> dt-bindings. The last 2 clocks had their index outside of allocated range.
> Two defines (CLK_CCC_DLL0, CLK_CCC_DLL1) were not used and skipped over
> which was not taken into account when allocating the array.
>
> This patch is minimal change to resolve the issue.
>
> Issue was found using KASAN when debugging unrelated xdma driver issue.
> Consequently fixing this issue also resolved xdma driver issue.
>
> Related dmesg output:
> [ 0.290703] BUG: KASAN: slab-out-of-bounds in mpfs_ccc_register_outputs.constprop.0+0xd0/0x1fa
> [ 0.290984] Write of size 8 at addr ffffffe7be6e3ca8 by task swapper/0/1
> [ 0.291253] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.43-linux4microchip+fpga-2023.09 #1
> [ 0.291482] Hardware name: Skylabs HPC (DT)
> [ 0.291611] Call Trace:
> ...
> [ 0.292999] [<ffffffff808508c8>] mpfs_ccc_register_outputs.constprop.0+0xd0/0x1fa
> [ 0.293245] [<ffffffff80850b66>] mpfs_ccc_probe+0x174/0x30e
> [ 0.293437] [<ffffffff808d4af2>] platform_probe+0x74/0xba
> ...
>
> Fixes: d39fb172760e ("clk: microchip: add PolarFire SoC fabric clock support")
> Signed-off-by: Aleš Pečnik <ales.pecnik@skylabs.si>
I think this should be already fixed in linux-next, in commit
2f7ae8ab6aa73 ("clk: microchip: mpfs-ccc: fix out of bounds access
during output registration")
Regardless, thanks for your patch.
> ---
> drivers/clk/microchip/clk-mpfs-ccc.c | 3 +--
> include/dt-bindings/clock/microchip,mpfs-clock.h | 2 ++
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/microchip/clk-mpfs-ccc.c b/drivers/clk/microchip/clk-mpfs-ccc.c
> index 3a3ea2d142f8..71fbb6265ea4 100644
> --- a/drivers/clk/microchip/clk-mpfs-ccc.c
> +++ b/drivers/clk/microchip/clk-mpfs-ccc.c
> @@ -234,8 +234,7 @@ static int mpfs_ccc_probe(struct platform_device *pdev)
> unsigned int num_clks;
> int ret;
>
> - num_clks = ARRAY_SIZE(mpfs_ccc_pll_clks) + ARRAY_SIZE(mpfs_ccc_pll0out_clks) +
> - ARRAY_SIZE(mpfs_ccc_pll1out_clks);
> + num_clks = CLK_CCC_NUM;
>
> clk_data = devm_kzalloc(&pdev->dev, struct_size(clk_data, hw_data.hws, num_clks),
> GFP_KERNEL);
> diff --git a/include/dt-bindings/clock/microchip,mpfs-clock.h b/include/dt-bindings/clock/microchip,mpfs-clock.h
> index b52f19a2b480..8d53f2b81a54 100644
> --- a/include/dt-bindings/clock/microchip,mpfs-clock.h
> +++ b/include/dt-bindings/clock/microchip,mpfs-clock.h
> @@ -73,4 +73,6 @@
> #define CLK_CCC_DLL1_OUT0 14
> #define CLK_CCC_DLL1_OUT1 15
>
> +#define CLK_CCC_NUM 16
> +
> #endif /* _DT_BINDINGS_CLK_MICROCHIP_MPFS_H_ */
>
> ---
> base-commit: bfe62a454542cfad3379f6ef5680b125f41e20f4
> change-id: 20260407-mpfs-clk-oob-write-a0cec9a5c224
>
> Best regards,
> --
> Aleš Pečnik <ales.pecnik@skylabs.si>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 11/12] ASoC: dt-bindings: google,sc7280-herobrine: Add Radxa Dragon Q6A sound card
From: Krzysztof Kozlowski @ 2026-04-08 8:48 UTC (permalink / raw)
To: Xilin Wu
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Liam Girdwood, Mark Brown,
Judy Hsiao, linux-arm-msm, linux-kernel, devicetree,
Konrad Dybcio, linux-sound
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-11-14aca49dde3d@radxa.com>
On Tue, Apr 07, 2026 at 11:20:03PM +0800, Xilin Wu wrote:
> The Radxa Dragon Q6A can boot in EL2, allowing the kernel to access the
> LPASS hardware directly. Add the compatible for it to the bindings.
You are not adding compatible for LPASS, but for the sound card. And
since you mentioned it, what happens when you boot in EL1?
You need to post bindings for both cases.
Best regards,
Krzysztof
^ permalink raw reply
* [net-next v1 v1 3/5] dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 sgmii rx clk
From: Minda Chen @ 2026-04-08 8:44 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260408084416.29753-1-minda.chen@starfivetech.com>
JHB100 SGMII interface tx/rx mac clock is split and require to
set clock rate in 10M/100M/1000M speed. So dts need to add a
new rx clock in code, dts and dt binding doc.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../bindings/net/starfive,jh7110-dwmac.yaml | 42 ++++++++++++++++---
1 file changed, 36 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index edc246a71ce3..847d67a2c1d5 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -39,20 +39,26 @@ properties:
maxItems: 1
clocks:
+ minItems: 5
items:
- description: GMAC main clock
- description: GMAC AHB clock
- description: PTP clock
- description: TX clock
- description: GTX clock
+ - description: SGMII RX clock
clock-names:
- items:
- - const: stmmaceth
- - const: pclk
- - const: ptp_ref
- - const: tx
- - const: gtx
+ minItems: 5
+ maxItems: 6
+ contains:
+ enum:
+ - stmmaceth
+ - pclk
+ - ptp_ref
+ - tx
+ - gtx
+ - rx
starfive,tx-use-rgmii-clk:
description:
@@ -99,6 +105,14 @@ allOf:
minItems: 2
maxItems: 2
+ clocks:
+ minItems: 5
+ maxItems: 5
+
+ clock-names:
+ minItems: 5
+ maxItems: 5
+
resets:
maxItems: 1
@@ -120,6 +134,14 @@ allOf:
minItems: 3
maxItems: 3
+ clocks:
+ minItems: 5
+ maxItems: 5
+
+ clock-names:
+ minItems: 5
+ maxItems: 5
+
resets:
minItems: 2
@@ -139,6 +161,14 @@ allOf:
interrupt-names:
const: macirq
+ clocks:
+ minItems: 5
+ maxItems: 6
+
+ clock-names:
+ minItems: 5
+ maxItems: 6
+
resets:
maxItems: 1
--
2.17.1
^ permalink raw reply related
* [net-next v1 v1 2/5] dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 support
From: Minda Chen @ 2026-04-08 8:44 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260408084416.29753-1-minda.chen@starfivetech.com>
Add StarFive JHB100 dwmac support and compatible.
The JHB100 dwmac shares the same driver code as the JH7110 dwmac,
which contains 2 SGMII interfaces, 1 RGMII/RMII interface and
1 RMII interface.
JHB100 dwmacc has only one reset signal and one main interrupt
line.
Please refer to below:
JHB100: reset-names = "stmmaceth";
Example usage of JHB100 in the device tree:
gmac0: ethernet@11b80000 {
compatible = "starfive,jhb100-dwmac",
"snps,dwmac-5.20";
interrupts = <225>;
interrupt-names = "macirq";
...
};
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../devicetree/bindings/net/snps,dwmac.yaml | 1 +
.../bindings/net/starfive,jh7110-dwmac.yaml | 23 +++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 38bc34dc4f09..85cd3252e8b1 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -115,6 +115,7 @@ properties:
- sophgo,sg2044-dwmac
- starfive,jh7100-dwmac
- starfive,jh7110-dwmac
+ - starfive,jhb100-dwmac
- tesla,fsd-ethqos
- thead,th1520-gmac
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index 0d1962980f57..edc246a71ce3 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -18,6 +18,7 @@ select:
enum:
- starfive,jh7100-dwmac
- starfive,jh7110-dwmac
+ - starfive,jhb100-dwmac
required:
- compatible
@@ -30,6 +31,9 @@ properties:
- items:
- const: starfive,jh7110-dwmac
- const: snps,dwmac-5.20
+ - items:
+ - const: starfive,jhb100-dwmac
+ - const: snps,dwmac-5.20
reg:
maxItems: 1
@@ -122,6 +126,25 @@ allOf:
reset-names:
minItems: 2
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jhb100-dwmac
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: macirq
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: stmmaceth
+
unevaluatedProperties: false
examples:
--
2.17.1
^ permalink raw reply related
* [net-next v1 v1 1/5] dt-bindings: net: starfive,jh7110-dwmac: Remove JH8100
From: Minda Chen @ 2026-04-08 8:44 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260408084416.29753-1-minda.chen@starfivetech.com>
Remove JH8100 dt-bindings because do not support it now.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../bindings/net/starfive,jh7110-dwmac.yaml | 28 ++++---------------
1 file changed, 5 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index 313a15331661..0d1962980f57 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -30,10 +30,6 @@ properties:
- items:
- const: starfive,jh7110-dwmac
- const: snps,dwmac-5.20
- - items:
- - const: starfive,jh8100-dwmac
- - const: starfive,jh7110-dwmac
- - const: snps,dwmac-5.20
reg:
maxItems: 1
@@ -120,25 +116,11 @@ allOf:
minItems: 3
maxItems: 3
- if:
- properties:
- compatible:
- contains:
- const: starfive,jh8100-dwmac
- then:
- properties:
- resets:
- maxItems: 1
-
- reset-names:
- const: stmmaceth
- else:
- properties:
- resets:
- minItems: 2
-
- reset-names:
- minItems: 2
+ resets:
+ minItems: 2
+
+ reset-names:
+ minItems: 2
unevaluatedProperties: false
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Liu Ying @ 2026-04-08 8:40 UTC (permalink / raw)
To: Frank Li
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <adYRuAU5ueEKHK5l@lizhi-Precision-Tower-5810>
On Wed, Apr 08, 2026 at 04:28:40AM -0400, Frank Li wrote:
> On Wed, Apr 08, 2026 at 04:08:24PM +0800, Liu Ying wrote:
>> On Wed, Apr 08, 2026 at 03:58:59AM -0400, Frank Li wrote:
>>> On Wed, Apr 08, 2026 at 02:02:54PM +0800, Liu Ying wrote:
>>>> Hi Frank,
>>>>
>>>> On Tue, Apr 07, 2026 at 05:55:29AM -0400, Frank Li wrote:
>>>>> On Tue, Apr 07, 2026 at 05:15:31PM +0800, Liu Ying wrote:
>>>>>> Support tianma,tm050rdh03 DPI panel on i.MX93 9x9 QSB.
>>>>>>
>>>>>> The panel connects with the QSB board through an adapter board[1]
>>>>>> designed by NXP.
>>>>>>
>>>>>> Link: https://www.nxp.com/design/design-center/development-boards-and-designs/parallel-lcd-display:TM050RDH03-41 [1]
>>>>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>>>>>> ---
>>>>>> arch/arm64/boot/dts/freescale/Makefile | 2 +
>>>>>> .../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi | 110 +++++++++++++++++++++
>>>>>> .../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso | 106 +-------------------
>>>>>
>>>>> Can you add some description about raname in commit message?
>>>>
>>>> I'll add some description about the file copy in commit message.
>>>>
>>>>> Use -C option to create patch.
>>>>
>>>> Will do.
>>>>
>>>>>
>>>>> ...
>>>>>> diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
>>>>>> new file mode 100644
>>>>>> index 000000000000..c233797ec28c
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
>>>>>> @@ -0,0 +1,14 @@
>>>>>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>>>>>> +/*
>>>>>> + * Copyright 2026 NXP
>>>>>> + */
>>>>>> +
>>>>>> +#include <dt-bindings/gpio/gpio.h>
>>>>>> +#include "imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi"
>>>>>> +
>>>>>> +&{/} {
>>>>>> + panel {
>>>>>> + compatible = "tianma,tm050rdh03";
>>>>>> + enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
>>>>>> + };
>>>>>> +};
>>>>>
>>>>> Is it possible to appply this overlay file and kd50g21-40nt-a1 overlay file
>>>>>
>>>>> to imx93-9x9-qsb.dtb, so needn't create dtsi.
>>>>
>>>> I'm sorry, I don't get your question here.
>>>> Anyway, the DT overlays are needed, because the 40-pin EXP/PRI interface on
>>>> the i.MX93 9x9 QSB board can not only connect to a DPI panel adapter board
>>>> but also to an audio hat[2], and maybe more. The newly introduced .dtsi
>>>> file just aims to avoid duplicated code.
>>>
>>> My means apply two overlay files to dtb
>>>
>>> imx93-9x9-qsb-tianma-tm050rdh03-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo imx93-9x9-qsb-tianma-tm050rdh03.dtbo
This ...
>>>
>>> In imx93-9x9-qsb-tianma-tm050rdh03.dtbo, only include
>>> &{/} {
>>> panel {
>>> compatible = "tianma,tm050rdh03";
>>> enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
>>> };
>>> };
>>
>> If an user wants to use imx93-9x9-qsb.dtb and the DT overlay blob
>> imx93-9x9-qsb-tianma-tm050rdh03.dtbo to enable the tianma,tm050rdh03
>> DPI panel, then it won't work unless the user also apply
>> imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo, right?
>>
>>>
>
> Yes, imx93-9x9-qsb-tianma-tm050rdh03.dtb already created, which already
> applied both overlay file.
.... indicates that imx93-9x9-qsb-tianma-tm050rdh03.dtb is generated by
applying both imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo and
imx93-9x9-qsb-tianma-tm050rdh03.dtbo to imx93-9x9-qsb.dtb.
While, imx93-9x9-qsb-tianma-tm050rdh03.dtbo(a DT overlay blob) just contains
the panel node, which means that an user __cannot_ enable the tianma,tm050rdh03
DPI panel by only applying it to imx93-9x9-qsb.dtb, unless the user also
applies imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo. That's why the .dtsi
file is needed.
>
> can the same board be use for imx91 or other evk boards?
Yes, both tianma,tm050rdh03 and ontat,kd50g21-40nt-a1 DPI panels can be
connected to i.MX91/93 11x11 EVK and 9x9 QSB boards.
>
> Frank
>
>>> Frank
>>>>
>>>> [2] https://www.nxp.com/design/design-center/development-boards-and-designs/mx93aud-hat-audio-board:MX93AUD-HAT
>>>>
>>>>>
>>>>> Frank
>>>>>>
>>>>>> ---
>>>>>> base-commit: 816f193dd0d95246f208590924dd962b192def78
>>>>>> change-id: 20260407-tianma-tm050rdh03-imx93-9x9-qsb-6e4bbbde3d08
>>>>>>
>>>>>> Best regards,
>>>>>> --
>>>>>> Liu Ying <victor.liu@nxp.com>
>>>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Liu Ying
>>
>> --
>> Regards,
>> Liu Ying
--
Regards,
Liu Ying
^ permalink raw reply
* [PATCH v2] dt-bindings: i2c: cnxt,cx92755-i2c: Convert to DT schema
From: Shi Hao @ 2026-04-08 8:35 UTC (permalink / raw)
To: robh
Cc: krzk+dt, andi.shyti, conor+dt, linux-i2c, devicetree,
linux-kernel, daniel.baluta, simona.toaca, d-gole, m-chawdhry,
i.shihao.999
Convert the Conexant Digicolor I2C bindings to DT schema.
Signed-off-by: Shi Hao <i.shihao.999@gmail.com>
---
v2:
- Omitted address-cells and size-cells in required section
Note:
This patch is part of the GSoC2026 application process for device tree
bindings conversions https://github.com/LinuxFoundationGSoC/ProjectIde
as/wiki/GSoC-2026-Device-Tree-Bindings
---
.../bindings/i2c/cnxt,cx92755-i2c.yaml | 49 +++++++++++++++++++
.../devicetree/bindings/i2c/i2c-digicolor.txt | 25 ----------
2 files changed, 49 insertions(+), 25 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/cnxt,cx92755-i2c.yaml
delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-digicolor.txt
diff --git a/Documentation/devicetree/bindings/i2c/cnxt,cx92755-i2c.yaml b/Documentation/devicetree/bindings/i2c/cnxt,cx92755-i2c.yaml
new file mode 100644
index 000000000000..c11bbf8aa9c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/cnxt,cx92755-i2c.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/cnxt,cx92755-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Conexant Digicolor I2C controller
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+maintainers:
+ - Baruch Siach <baruch@tkos.co.il>
+
+properties:
+ compatible:
+ const: cnxt,cx92755-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency:
+ default: 100000
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c@f0000120 {
+ compatible = "cnxt,cx92755-i2c";
+ reg = <0xf0000120 0x10>;
+ interrupts = <28>;
+ clocks = <&main_clk>;
+ clock-frequency = <100000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-digicolor.txt b/Documentation/devicetree/bindings/i2c/i2c-digicolor.txt
deleted file mode 100644
index 457a098d4f7e..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-digicolor.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Conexant Digicolor I2C controller
-
-Required properties:
- - compatible: must be "cnxt,cx92755-i2c"
- - reg: physical address and length of the device registers
- - interrupts: a single interrupt specifier
- - clocks: clock for the device
- - #address-cells: should be <1>
- - #size-cells: should be <0>
-
-Optional properties:
-- clock-frequency: the desired I2C bus clock frequency in Hz; in
- absence of this property the default value is used (100 kHz).
-
-Example:
-
- i2c: i2c@f0000120 {
- compatible = "cnxt,cx92755-i2c";
- reg = <0xf0000120 0x10>;
- interrupts = <28>;
- clocks = <&main_clk>;
- clock-frequency = <100000>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox