* 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
* Re: [PATCH v2 2/2] arm64: dts: qcom: milos: Add IMEM node
From: Krzysztof Kozlowski @ 2026-04-08 8:36 UTC (permalink / raw)
To: Luca Weiss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, ~postmarketos/upstreaming, phone-devel,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <DHNMDZ7M0BVS.36Z923XKNXPEC@fairphone.com>
On 08/04/2026 10:11, Luca Weiss wrote:
>>> };
>>>
>>> + sram@14680000 {
>>> + compatible = "qcom,milos-imem", "mmio-sram";
>>> + reg = <0x0 0x14680000 0x0 0x2c000>;
>>> + ranges = <0 0 0x14680000 0x2c000>;
>>
>> Use hex here as well.
>
> Will do: ranges = <0x0 0x0 0x14680000 0x2c000>;
>
> Do you also have a comment around the name of the subnodes? Do you think
> they're okay as-is, or should they be changed?
I think they follow what the binding expects, so not much to discuss here :)
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v4 net-next 09/14] net: dsa: add NETC switch tag support
From: Wei Fang @ 2026-04-08 8:35 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Claudiu Manoil, Vladimir Oltean, 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: <20260403011736.1795610-1-kuba@kernel.org>
> > diff --git a/net/dsa/tag_netc.c b/net/dsa/tag_netc.c
> > new file mode 100644
> > index 000000000000..addd41f7f1b6
> > --- /dev/null
> > +++ b/net/dsa/tag_netc.c
> [ ... ]
> > +static void *netc_fill_common_tp_tag(struct sk_buff *skb,
> > + struct net_device *ndev,
> > + u8 subtype, int tag_len)
> > +{
> > + struct dsa_port *dp = dsa_user_to_port(ndev);
> > + u16 queue = skb_get_queue_mapping(skb);
> > + u8 ipv = netdev_txq_to_tc(ndev, queue);
>
> What happens here if the interface doesn't have traffic classes configured?
netdev_txq_to_tc() will return 0 if not TC configured, I mean ndev->num_tc is
0.
>
> By default, netdev_txq_to_tc() returns -1. Because ipv is an unsigned 8-bit
> integer, this casts to 255.
Okay, this is a potential bug when we add TC_SETUP_QDISC_MQPRIO
support. I will fix it.
>
> When this is later passed to FIELD_PREP(NETC_TAG_IPV, ipv) in
> netc_fill_common_tag(), the macro blindly masks the variable, silently
> forcing the IPV field to 7 (the maximum priority) for all default,
> unconfigured traffic. Valid TC values greater than 7 would also be silently
> truncated.
>
> Does this code bypass the intended QoS mechanisms?
No, configure IPV to send packets according to the expected TC.
>
> > + void *tag;
> > +
> > + skb_push(skb, tag_len);
> > + dsa_alloc_etype_header(skb, tag_len);
> > +
> > + tag = dsa_etype_header_pos_tx(skb);
> > + memset(tag + NETC_TAG_CMN_LEN, 0, tag_len - NETC_TAG_CMN_LEN);
> > + netc_fill_common_tag(tag, NETC_TAG_TO_PORT, subtype,
> > + dp->ds->index, dp->index, ipv);
>
> Will this break communication for standard single-switch setups?
>
> The driver passes dp->ds->index as the hardware switch ID here, which
> defaults to 0 for the first switch in a DSA tree. However, on the receive
> path, frames stamped with switch ID 0 are rejected.
>
> If the physical switch hardware uses an ID greater than 0, frames will fail
> the lookup in dsa_conduit_find_user() on receive because the software index
> is 0.
We added the 'dsa,member' property to the netc switch DT-binding doc, specifying
that the 'member' (switch index) value cannot be 0. Furthermore, the netc switch
driver also checks the switch index to ensure it is not 0. Therefore, the software index
and hardware index are equal.
>
> > +
> > + return tag;
> > +}
> [ ... ]
> > +static struct sk_buff *netc_rcv(struct sk_buff *skb,
> > + struct net_device *ndev)
> > +{
> > + struct netc_tag_cmn *tag_cmn;
> > + int tag_len, sw_id, port;
> [ ... ]
> > + if (tag_cmn->qos & NETC_TAG_QV)
> > + skb->priority = FIELD_GET(NETC_TAG_IPV, tag_cmn->qos);
> > +
> > + sw_id = NETC_TAG_SWITCH & tag_cmn->switch_port;
>
> This isn't a bug, but is there a reason to use a raw bitwise AND for sw_id
> instead of using FIELD_GET(NETC_TAG_SWITCH, ...) to match how the port
> field is extracted just below this?
I think either is fine, the final result is the same. I just wrote it this way for
convenience during implementation.
^ permalink raw reply
* RE: [PATCH V11 04/12] PCI: imx6: Add support for parsing the reset property in new Root Port binding
From: Sherry Sun @ 2026-04-08 8:34 UTC (permalink / raw)
To: Manivannan Sadhasivam
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: <7ewnbwdo5qtasbxj4uel6a6uthczq2l6udbvoqqkwm776lvseb@v54ri2gknwxn>
> On Tue, Apr 07, 2026 at 06:41:46PM +0800, Sherry Sun wrote:
> > The current DT binding for pci-imx6 specifies the 'reset-gpios'
> > property in the host bridge node. However, the PERST# signal logically
> > belongs to individual Root Ports rather than the host bridge itself.
> > This becomes important when supporting PCIe KeyE connector and PCI
> > power control framework for pci-imx6 driver, which requires properties
> > to be specified in Root Port nodes.
> >
> > Add support for parsing 'reset-gpios' from Root Port child nodes using
> > the common helper pci_host_common_parse_ports(), and update the reset
> > GPIO handling to use the parsed port list from bridge->ports. To
> > maintain DT backwards compatibility, fallback to the legacy method of
> > parsing the host bridge node if the reset property is not present in
> > the Root Port node.
> >
> > Since now the reset GPIO is obtained with GPIOD_ASIS flag, it may be
> > in input mode, using gpiod_direction_output() instead of
> > gpiod_set_value_cansleep() to ensure the reset GPIO is properly
> > configured as output before setting its value.
> >
> > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > ---
> > drivers/pci/controller/dwc/pci-imx6.c | 75
> > +++++++++++++++++++++------
> > 1 file changed, 60 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index d99da7e42590..dd8f9c0fcec4 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -34,6 +34,7 @@
> > #include <linux/pm_runtime.h>
> >
> > #include "../../pci.h"
> > +#include "../pci-host-common.h"
> > #include "pcie-designware.h"
> >
> > #define IMX8MQ_GPR_PCIE_REF_USE_PAD BIT(9)
> > @@ -152,7 +153,6 @@ struct imx_lut_data {
> >
> > struct imx_pcie {
> > struct dw_pcie *pci;
> > - struct gpio_desc *reset_gpiod;
> > struct clk_bulk_data *clks;
> > int num_clks;
> > bool supports_clkreq;
> > @@ -1224,6 +1224,32 @@ static void imx_pcie_disable_device(struct
> pci_host_bridge *bridge,
> > imx_pcie_remove_lut(imx_pcie, pci_dev_id(pdev)); }
> >
> > +static int imx_pcie_parse_legacy_binding(struct imx_pcie *pcie) {
> > + struct device *dev = pcie->pci->dev;
> > + struct pci_host_bridge *bridge = pcie->pci->pp.bridge;
> > + struct pci_host_port *port;
> > + struct gpio_desc *reset;
> > +
> > + reset = devm_gpiod_get_optional(dev, "reset", GPIOD_ASIS);
> > + if (IS_ERR(reset))
> > + return PTR_ERR(reset);
> > +
> > + if (!reset)
> > + return 0;
> > +
> > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > + if (!port)
> > + return -ENOMEM;
> > +
> > + port->reset = reset;
> > + INIT_LIST_HEAD(&port->list);
> > + list_add_tail(&port->list, &bridge->ports);
> > +
> > + return devm_add_action_or_reset(dev,
> pci_host_common_delete_ports,
> > + &bridge->ports);
> > +}
> > +
> > static void imx_pcie_vpcie_aux_disable(void *data) {
> > struct regulator *vpcie_aux = data;
> > @@ -1233,13 +1259,22 @@ static void imx_pcie_vpcie_aux_disable(void
> > *data)
> >
> > static void imx_pcie_assert_perst(struct imx_pcie *imx_pcie, bool
> > assert) {
> > - if (assert) {
> > - gpiod_set_value_cansleep(imx_pcie->reset_gpiod, 1);
> > - } else {
> > - if (imx_pcie->reset_gpiod) {
> > - msleep(PCIE_T_PVPERL_MS);
> > - gpiod_set_value_cansleep(imx_pcie->reset_gpiod, 0);
> > - msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > + struct dw_pcie *pci = imx_pcie->pci;
> > + struct pci_host_bridge *bridge = pci->pp.bridge;
> > + struct pci_host_port *port;
> > +
> > + if (!bridge)
> > + return;
> > +
> > + list_for_each_entry(port, &bridge->ports, list) {
> > + if (assert) {
> > + gpiod_direction_output(port->reset, 1);
> > + } else {
> > + if (port->reset) {
> > + msleep(PCIE_T_PVPERL_MS);
> > + gpiod_direction_output(port->reset, 0);
> > + msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > + }
>
> Sashiko flagged this loop:
>
> ```
> Does this loop multiply the initialization delays?
> If a controller has multiple Root Ports, the msleep calls will run sequentially
> for each port, linearly increasing the delay. Could we optimize this by
> asserting all reset GPIOs, waiting the pre-delay once, de-asserting all GPIOs,
> and waiting the post-delay once for the entire bus?
> ```
>
> Maybe you should do:
>
> if (!list_empty(&bridge->ports) && !assert)
> msleep(PCIE_T_PVPERL_MS);
>
> list_for_each_entry(port, &bridge->ports, list) {
> ...
> gpiod_direction_output(port->reset, 0);
> ...
> }
>
> if (!list_empty(&bridge->ports) && !assert)
> msleep(PCIE_RESET_CONFIG_WAIT_MS);
>
Hi Mani, I think the code below looks clearer, is that ok for you?
if (assert) {
list_for_each_entry(port, &bridge->ports, list)
gpiod_direction_output(port->reset, 1);
} else {
if (list_empty(&bridge->ports))
return;
msleep(PCIE_T_PVPERL_MS);
list_for_each_entry(port, &bridge->ports, list)
gpiod_direction_output(port->reset, 0);
msleep(PCIE_RESET_CONFIG_WAIT_MS);
}
> And then this:
>
> ```
> Also, since this function is called from imx_pcie_resume_noirq, which
> executes with hardware interrupts disabled, does the use of msleep here
> trigger a 'sleeping while atomic' bug?
> ```
>
> This is a valid concern. You should use mdelay(). But I'd recommend switching
> to IRQ enabled callback, resume() instead. There is no complelling reason to
> use resume_noirq() in this driver and adding delays in noirq() callbacks is not
> recommended as it may increase the overall system resume time.
>
> I will submit a separate series to convert dw_pcie_resume_noirq() and its
> callers to IRQ enabled callbacks since this dw_pcie_resume_noirq() could
> potentially cause delay up to 1sec.
Yes, this is not a new bug introduced by this patch. I agree we should covert the
convert dw_pcie_resume_noirq() and the caller to IRQ enabled callbacks to fix
this in a separate patch series.
For now, should I leave it as is, or switch to mdelay in this patch?
>
> > }
> > }
> > }
> > @@ -1249,8 +1284,25 @@ static int imx_pcie_host_init(struct dw_pcie_rp
> *pp)
> > struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > struct device *dev = pci->dev;
> > struct imx_pcie *imx_pcie = to_imx_pcie(pci);
> > + struct pci_host_bridge *bridge = pp->bridge;
> > int ret;
> >
> > + if (bridge && list_empty(&bridge->ports)) {
> > + /* Parse Root Port nodes if present */
> > + ret = pci_host_common_parse_ports(dev, bridge);
> > + if (ret) {
> > + if (ret != -ENOENT) {
> > + dev_err(dev, "Failed to parse Root Port
> nodes: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + /* Fallback to legacy binding for DT backwards
> compatibility */
> > + ret = imx_pcie_parse_legacy_binding(imx_pcie);
>
> This is also flagged by Sashiko:
>
> ```
> Could this error handling corrupt the port state and trigger an invalid legacy
> fallback?
>
> If a device tree defines multiple Root Ports and one lacks the optional reset
> GPIO, pci_host_common_parse_ports returns -ENOENT. This causes the code
> to fall back to imx_pcie_parse_legacy_binding.
>
> Since the already-parsed child ports remain in bridge->ports without rollback,
> the legacy host bridge GPIO will be appended alongside them.
> Valid child nodes are skipped, and both child and legacy GPIOs will be toggled
> simultaneously.
> ```
>
> You should try to cleanup Root Port resources if
> pci_host_common_parse_ports() fails with -ENOENT.
Sure, I will call pci_host_common_delete_ports() to clean up any partially parsed
Root Port resources before falling back to legacy binding.
Best Regards
Sherry
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Frank Li @ 2026-04-08 8:28 UTC (permalink / raw)
To: Liu Ying
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <f5cd5da8-566d-4dff-b712-3d48927f97eb@nxp.com>
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
> >
> > 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.
can the same board be use for imx91 or other evk 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
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: spi: renesas,rzv2h-rspi: Document RZ/G3L SoC
From: Geert Uytterhoeven @ 2026-04-08 8:28 UTC (permalink / raw)
To: Biju
Cc: Fabrizio Castro, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Biju Das, linux-spi, linux-renesas-soc,
devicetree, linux-kernel, Prabhakar Mahadev Lad
In-Reply-To: <20260407145753.101840-2-biju.das.jz@bp.renesas.com>
On Tue, 7 Apr 2026 at 16:57, Biju <biju.das.au@gmail.com> wrote:
> 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.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> v2->v3:
> * Added ordered DMA names for the dma-names property.
> * Dropped the tag
> v1->v2:
> * Collected tag
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 17/19] drm/panel: add driver for Waveshare 8.8" DSI TOUCH-A panel
From: Linus Walleij @ 2026-04-08 8:27 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Bartosz Golaszewski, dri-devel, devicetree, linux-kernel,
linux-gpio
In-Reply-To: <20260401-waveshare-dsi-touch-v1-17-5e9119b5a014@oss.qualcomm.com>
On Wed, Apr 1, 2026 at 9:27 AM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
> Add driver for the panel found on Waveshare 8.8" DSI TOUCH-A kit. It
> uses ota7290b IC as a controller.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 15/19] drm/panel: ilitek-ili9881c: support Waveshare 7.0" DSI panel
From: Linus Walleij @ 2026-04-08 8:26 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Bartosz Golaszewski, dri-devel, devicetree, linux-kernel,
linux-gpio
In-Reply-To: <20260401-waveshare-dsi-touch-v1-15-5e9119b5a014@oss.qualcomm.com>
Hi Dmitry,
thanks for your patch!
On Wed, Apr 1, 2026 at 9:27 AM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
> Enable support for Waveshare 7.0" DSI TOUCH-A panel. It requires
> additional voltage regulator, iovcc.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
(...)
> + ILI9881C_COMMAND_INSTR(0x01, 0x00),
> + ILI9881C_COMMAND_INSTR(0x02, 0x00),
Same comment about using a jam table here.
Yours,
Linus Walleij
^ 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