* [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
* Re: [PATCH 16/19] drm/panel: add devm_drm_panel_add() helper
From: Linus Walleij @ 2026-04-08 8:25 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-16-5e9119b5a014@oss.qualcomm.com>
On Wed, Apr 1, 2026 at 9:27 AM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
> Add devm_drm_panel_add(), devres-managed version of drm_panel_add().
> It's not uncommon for the panel drivers to use devres functions for most
> of the resources. Provide corresponding replacement for drm_panel_add().
>
> 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 14/19] drm/panel: jadard-jd9365da-h3: support Waveshare DSI panels
From: Linus Walleij @ 2026-04-08 8:24 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-14-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:
> Add configuration for Waveshare DSI panels using JD9365 controller.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Some more words with details on all the panels added perhaps?
> - desc = of_device_get_match_data(dev);
> + jd9365da_switch_page(&dsi_ctx, 0x01);
> + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0x00, 0x00);
> + mipi_dsi_dcs_write_seq_multi(&dsi_ctx, 0x01, 0x41);
Predictably I'm not very happy with all the unexplained magic and nonestisting
defines used here. Do you have some info/defines?
But there is also one more thing, this looks like a big "jam table"
with just register+value tuples, so construct something like:
struct jadard_jam_tbl_entry {
u8 reg;
u8 val;
};
static const struct jadard_jam_tbl_entry jd_3_4_c_init_jam[] = {
{0x00, 0x00}, {0x01, 0x41}, ...};
(Ideas taken from drivers/net/dsa/realtek/rtl8366rb.c, take a look
for code and all, you get the picture.)
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] dt-bindings: i2c: nxp,pca9564: convert to DT schema
From: Akhila YS @ 2026-04-08 8:23 UTC (permalink / raw)
To: Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Rosin
Cc: linux-i2c, devicetree, linux-kernel, Akhila YS
Convert NXP PCA PCA9564/PCA9665 I2C controller to YAML format.
Signed-off-by: Akhila YS <akhilayalmati@gmail.com>
---
.../devicetree/bindings/i2c/i2c-pca-platform.txt | 27 ----------
.../devicetree/bindings/i2c/nxp,pca9564.yaml | 60 ++++++++++++++++++++++
2 files changed, 60 insertions(+), 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pca-platform.txt b/Documentation/devicetree/bindings/i2c/i2c-pca-platform.txt
deleted file mode 100644
index 73a693d66ef7..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-pca-platform.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* NXP PCA PCA9564/PCA9665 I2C controller
-
-The PCA9564/PCA9665 serves as an interface between most standard
-parallel-bus microcontrollers/microprocessors and the serial I2C-bus
-and allows the parallel bus system to communicate bi-directionally
-with the I2C-bus.
-
-Required properties :
-
- - reg : Offset and length of the register set for the device
- - compatible : one of "nxp,pca9564" or "nxp,pca9665"
-
-Optional properties
- - interrupts : the interrupt number
- - reset-gpios : gpio specifier for gpio connected to RESET_N pin. As the line
- is active low, it should be marked GPIO_ACTIVE_LOW.
- - clock-frequency : I2C bus frequency.
-
-Example:
- i2c0: i2c@80000 {
- compatible = "nxp,pca9564";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x80000 0x4>;
- reset-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
- clock-frequency = <100000>;
- };
diff --git a/Documentation/devicetree/bindings/i2c/nxp,pca9564.yaml b/Documentation/devicetree/bindings/i2c/nxp,pca9564.yaml
new file mode 100644
index 000000000000..5d5653255b91
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/nxp,pca9564.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/nxp,pca9564.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PCA9564 / PCA9665 I2C Controller
+
+maintainers:
+ - Peter Rosin <peda@axentia.se>
+
+description:
+ The PCA9564/PCA9665 serves as an interface between standard
+ parallel-bus microcontrollers/microprocessors and the serial I2C bus.
+ It enables bidirectional communication between the parallel bus
+ system and the I2C bus.
+
+properties:
+ compatible:
+ enum:
+ - nxp,pca9564
+ - nxp,pca9665
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ clock-frequency:
+ default: 100000
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c@80000 {
+ compatible = "nxp,pca9564";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x80000 0x4>;
+ reset-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
+ clock-frequency = <100000>;
+ };
+...
---
base-commit: d4906ae14a5f136ceb671bb14cedbf13fa560da6
change-id: 20260407-i2c-nxp-29f251ad86b0
Best regards,
--
Akhila YS <akhilayalmati@gmail.com>
^ permalink raw reply related
* Re: (subset) [PATCH v3 0/3] Add the missing mpll3 clock and clock controller nodes
From: Jerome Brunet @ 2026-04-08 8:20 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Martin Blumenstingl, Stephen Boyd,
Michael Turquette, robh+dt, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jian Hu
Cc: devicetree, linux-clk, linux-amlogic, linux-kernel,
linux-arm-kernel, Ronald Claveau, Ferass El Hafidi
In-Reply-To: <20260326092645.1053261-1-jian.hu@amlogic.com>
Applied to clk-meson (clk-meson-next), thanks!
[1/3] dt-bindings: clock: amlogic: Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
https://github.com/BayLibre/clk-meson/commit/6d6be1cca2c9
[2/3] dt-bindings: clock: amlogic: t7: Add missing mpll3 parent clock
https://github.com/BayLibre/clk-meson/commit/87edca62c4f5
Best regards,
--
Jerome
^ permalink raw reply
* Re: [PATCH 13/19] drm/panel: jadard-jd9365da-h3: set prepare_prev_first
From: Linus Walleij @ 2026-04-08 8:15 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-13-5e9119b5a014@oss.qualcomm.com>
On Wed, Apr 1, 2026 at 9:27 AM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
> Sending DSI commands from the prepare() callback requires DSI link to be
> up at that point. For DSI hosts is guaranteed only if the panel driver
> sets the .prepare_prev_first flag. Set it to let these panels work with
> the DSI hosts which don't power on the link in their .mode_set callback.
>
> 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 12/19] drm/panel: jadard-jd9365da-h3: support variable DSI configuration
From: Linus Walleij @ 2026-04-08 8:15 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-12-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:
> Several panels support attachment either using 4 DSI lanes or just 2. In
> some cases, this requires a different panel mode to fulfill clock
> requirements. Extend the driver to handle such cases by letting the
> panel description to omit lanes specification and parsing number of
> lanes from the DT.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
(...)
> + if (dsi_ctx->dsi->lanes == 2)
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0x80, 0x01);
> + else
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0x80, 0x03);
If lanes 2 we do unexplicable magic A else we do unexplicable magic B?
Do we know more about what is actually going on here?
Can you check the datasheet?
The patch is nice anyway and no big deal so, so +/- that fixup:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: milos: Add IMEM node
From: Luca Weiss @ 2026-04-08 8:11 UTC (permalink / raw)
To: Krzysztof Kozlowski, 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: <20260408-adamant-hairy-galago-61deed@quoll>
Hi Krzysztof,
On Wed Apr 8, 2026 at 9:34 AM CEST, Krzysztof Kozlowski wrote:
> On Tue, Apr 07, 2026 at 05:11:11PM +0200, Luca Weiss wrote:
>> Add a node for the IMEM found on Milos, which contains pil-reloc-info
>> and the modem tables for IPA, among others.
>>
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>> ---
>> Not happy about the names of the subnodes. pil-reloc-sram is not allowed
>> it seems. Glymur calls it "pil-sram@94c", not sure this is wanted?
>>
>> Please advice.
>> ---
>> arch/arm64/boot/dts/qcom/milos.dtsi | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
>> index 4a64a98a434b..0c69d5810f5e 100644
>> --- a/arch/arm64/boot/dts/qcom/milos.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/milos.dtsi
>> @@ -2289,6 +2289,26 @@ scl-pins {
>> };
>> };
>>
>> + 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?
Regards
Luca
^ permalink raw reply
* Re: [PATCH 11/19] drm/panel: jadard-jd9365da-h3: use drm_connector_helper_get_modes_fixed
From: Linus Walleij @ 2026-04-08 8:10 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-11-5e9119b5a014@oss.qualcomm.com>
On Wed, Apr 1, 2026 at 9:27 AM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
> Use existing helper instead of manually coding it.
>
> 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 12/16] irqchip/eip201-aic: Add support for Safexcel EIP-201 AIC
From: Geert Uytterhoeven @ 2026-04-08 8:05 UTC (permalink / raw)
To: Miquel Raynal (Schneider Electric)
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thomas Gleixner, Olivia Mackall, Herbert Xu,
Jayesh Choudhary, David S. Miller, Christian Marangi,
Antoine Tenart, Magnus Damm, Thomas Petazzoni, Pascal EBERHARD,
Wolfram Sang, linux-clk, devicetree, linux-kernel, linux-crypto,
linux-renesas-soc
In-Reply-To: <20260327-schneider-v7-0-rc1-crypto-v1-12-5e6ff7853994@bootlin.com>
Hi Miquel,
On Fri, 27 Mar 2026 at 21:11, Miquel Raynal (Schneider Electric)
<miquel.raynal@bootlin.com> wrote:
> Describe the EIP-201 Advanced Interrupt Controller from Inside Secure,
> typically found in a bigger block named EIP-150. This controller is
> rather simple and is driven using the generic irqchip model. Its
> own interrupt domain is limited to just a few interrupts connected to
> other inner blocks, such as a Random Number Generator and a Public Key
> Accelerator.
>
> The one I used receives only rising edge interrupts and uses its own
> logic to track them. It is theoretically possible to wire devices with
> level interrupts, but not in the context of the EIP-150.
>
> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
Thanks for your patch!
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -826,4 +826,12 @@ config SUNPLUS_SP7021_INTC
> chained controller, routing all interrupt source in P-Chip to
> the primary controller on C-Chip.
>
> +config SAFEXCEL_EIP201_AIC
> + tristate "Safexcel EIP201 AIC"
Is there any platform dependency that could be added here?
> + select IRQ_DOMAIN
> + help
> + Support for the Advanced Interrupt Controller (AIC) typically
> + inside Safexcel EIP150 IPs, gathering Public Key Accelerator
> + and True Random Number Generator interrupts.
> +
> endmenu
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 10/19] drm/panel: himax-hx8394: support Waveshare DSI panels
From: Linus Walleij @ 2026-04-08 8:10 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-10-5e9119b5a014@oss.qualcomm.com>
On Wed, Apr 1, 2026 at 9:27 AM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
> Enable support for Waveshare 5.0" and 5.5" DSI TOUCH-A panels.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
This looks excellent, good documentation and references to (incomplete...)
datasheet. Maybe this datasheet has the defs I was complaining about
in the other patch?
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 09/19] drm/panel: himax-hx8394: simplify hx8394_enable()
From: Linus Walleij @ 2026-04-08 8:08 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-9-5e9119b5a014@oss.qualcomm.com>
On Wed, Apr 1, 2026 at 9:27 AM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
> Simplify hx8394_enable() function by using hx8394_disable() instead of
> open-coding it and mipi_dsi_msleep() instead of manual checks.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Excellent, thanks!
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 08/19] drm/panel: himax-hx8394: set prepare_prev_first
From: Linus Walleij @ 2026-04-08 8:08 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-8-5e9119b5a014@oss.qualcomm.com>
On Wed, Apr 1, 2026 at 9:27 AM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
> Sending DSI commands from the prepare() callback requires DSI link to be
> up at that point. For DSI hosts is guaranteed only if the panel driver
> sets the .prepare_prev_first flag. Set it to let these panels work with
> the DSI hosts which don't power on the link in their .mode_set callback.
>
> 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] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Liu Ying @ 2026-04-08 8:08 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: <adYKtjPvIgoK2oou@lizhi-Precision-Tower-5810>
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?
>
> 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 v4 1/2] media: dt-bindings: rockchip,rk3568-mipi-csi2: add rk3588 compatible
From: Sakari Ailus @ 2026-04-08 8:05 UTC (permalink / raw)
To: michael.riesch
Cc: Mauro Carvalho Chehab, Laurent Pinchart, Frank Li, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Collabora Kernel Team, linux-media, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260305-rk3588-csi2rx-v4-1-81c6bcfefa63@collabora.com>
Hi Michael,
On Fri, Mar 27, 2026 at 12:10:00AM +0100, Michael Riesch via B4 Relay wrote:
> From: Michael Riesch <michael.riesch@collabora.com>
>
> The RK3588 MIPI CSI-2 receivers are compatible to the ones found in
> the RK3568.
> Introduce a list of compatible variants and add the RK3588 variant to
> it.
Please use your editor to wrap the commit messages in the future as needed.
It became:
The RK3588 MIPI CSI-2 receivers are compatible to the ones found in the
RK3568. Introduce a list of compatible variants and add the RK3588 variant
to it.
--
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v6 01/27] Revert "treewide: Fix probing of devices in DT overlays"
From: Geert Uytterhoeven @ 2026-04-08 8:03 UTC (permalink / raw)
To: Herve Codina
Cc: Andrew Lunn, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kalle Niemi, Matti Vaittinen, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Michael Turquette,
Stephen Boyd, Andi Shyti, Wolfram Sang, Peter Rosin,
Arnd Bergmann, Saravana Kannan, Bjorn Helgaas, Charles Keepax,
Richard Fitzgerald, David Rhodes, Linus Walleij, Ulf Hansson,
Mark Brown, Len Brown, Andy Shevchenko, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Davidlohr Bueso, Jonathan Cameron,
Dave Jiang, Alison Schofield, Vishal Verma, Ira Weiny,
Dan Williams, Shawn Guo, Wolfram Sang, linux-kernel, driver-core,
imx, linux-arm-kernel, linux-clk, linux-i2c, devicetree,
linux-pci, linux-sound, patches, linux-gpio, linux-pm, linux-spi,
linux-acpi, linux-cxl, Allan Nielsen, Horatiu Vultur,
Steen Hegelund, Luca Ceresoli, Thomas Petazzoni, Saravana Kannan
In-Reply-To: <20260325143555.451852-2-herve.codina@bootlin.com>
On Wed, 25 Mar 2026 at 15:36, Herve Codina <herve.codina@bootlin.com> wrote:
> From: Saravana Kannan <saravanak@google.com>
>
> This reverts commit 1a50d9403fb90cbe4dea0ec9fd0351d2ecbd8924.
>
> While the commit fixed fw_devlink overlay handling for one case, it
> broke it for another case. So revert it and redo the fix in a separate
> patch.
>
> Fixes: 1a50d9403fb9 ("treewide: Fix probing of devices in DT overlays")
> Reported-by: Herve Codina <herve.codina@bootlin.com>
> Closes: https://lore.kernel.org/lkml/CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com/
> Closes: https://lore.kernel.org/all/20240221095137.616d2aaa@bootlin.com/
> Closes: https://lore.kernel.org/lkml/20240312151835.29ef62a0@bootlin.com/
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> Link: https://lore.kernel.org/lkml/20240411235623.1260061-2-saravanak@google.com/
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> Acked-by: Mark Brown <broonie@kernel.org>
> --- a/drivers/bus/imx-weim.c
> +++ b/drivers/bus/imx-weim.c
> @@ -327,12 +327,6 @@ static int of_weim_notify(struct notifier_block *nb, unsigned long action,
> "Failed to setup timing for '%pOF'\n", rd->dn);
>
> if (!of_node_check_flag(rd->dn, OF_POPULATED)) {
> - /*
> - * Clear the flag before adding the device so that
> - * fw_devlink doesn't skip adding consumers to this
> - * device.
> - */
> - rd->dn->fwnode.flags &= ~FWNODE_FLAG_NOT_DEVICE;
> if (!of_platform_device_create(rd->dn, NULL, &pdev->dev)) {
> dev_err(&pdev->dev,
> "Failed to create child device '%pOF'\n",
Note that all these removals no longer apply cleanly due to commit
f72e77c33e4b5657 ("device property: Make modifications of fwnode
"flags" thread safe") in driver-core-next, which is gonna complicate
backporting to stable.
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
* [PATCH 1/3] dt-bindings: nvmem: Add a binding for the RPi Firmware OTP register
From: Gregor Herburger @ 2026-04-08 8:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Gregor Herburger
In-Reply-To: <20260408-rpi-otp-driver-v1-0-e02d1dbe6008@linutronix.de>
The firmware running on the Raspberry Pi VideoCore can be used to access
OTP registers. There are two OTP regions (private and customer). Add a
binding for these.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
.../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index 983ea80eaec9..975c8927d75b 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -137,6 +137,20 @@ required:
- compatible
- mboxes
+patternProperties:
+ "^otp-(customer|private)$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ enum:
+ - raspberrypi,firmware-otp-customer
+ - raspberrypi,firmware-otp-private
+
+ required:
+ - compatible
+
additionalProperties: false
examples:
@@ -156,6 +170,10 @@ examples:
#gpio-cells = <2>;
};
+ otp: otp-private {
+ compatible = "raspberrypi,firmware-otp-private";
+ };
+
reset: reset {
compatible = "raspberrypi,firmware-reset";
#reset-cells = <1>;
--
2.47.3
^ permalink raw reply related
* [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver
From: Gregor Herburger @ 2026-04-08 8:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Gregor Herburger
In-Reply-To: <20260408-rpi-otp-driver-v1-0-e02d1dbe6008@linutronix.de>
Raspberry Pis have OTP registers which can be accessed through the
videocore firmware. Add a nvmem driver to support these OTP registers.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
drivers/nvmem/Kconfig | 12 +++
drivers/nvmem/Makefile | 1 +
drivers/nvmem/raspberrypi-otp.c | 159 +++++++++++++++++++++++++++++
include/soc/bcm2835/raspberrypi-firmware.h | 2 +
4 files changed, 174 insertions(+)
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 74ddbd0f79b0..892d05fe67be 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -483,4 +483,16 @@ config NVMEM_QORIQ_EFUSE
This driver can also be built as a module. If so, the module
will be called nvmem_qoriq_efuse.
+config NVMEM_RASPBERRYPI_OTP
+ tristate "Raspberry Pi OTP support"
+ # Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
+ # happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.
+ depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE)
+ help
+ This driver provides access to the Raspberry Pi OTP memory via the
+ nvmem subsystem. The driver supports the customer otp as well as the
+ device specific private key OTP.
+
+ This driver can also be built as a module. If so, the module
+ will be called raspberrypi-otp.
endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 7252b8ec88d4..8ca2095e068f 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -95,3 +95,4 @@ obj-$(CONFIG_NVMEM_ZYNQMP) += nvmem_zynqmp_nvmem.o
nvmem_zynqmp_nvmem-y := zynqmp_nvmem.o
obj-$(CONFIG_NVMEM_QORIQ_EFUSE) += nvmem-qoriq-efuse.o
nvmem-qoriq-efuse-y := qoriq-efuse.o
+obj-$(CONFIG_NVMEM_RASPBERRYPI_OTP) += raspberrypi-otp.o
diff --git a/drivers/nvmem/raspberrypi-otp.c b/drivers/nvmem/raspberrypi-otp.c
new file mode 100644
index 000000000000..13ee3784b137
--- /dev/null
+++ b/drivers/nvmem/raspberrypi-otp.c
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <soc/bcm2835/raspberrypi-firmware.h>
+
+struct rpi_otp_priv {
+ struct rpi_firmware *fw;
+ struct device *dev;
+ u32 read_tag;
+ u32 write_tag;
+};
+
+struct rpi_otp_driver_data {
+ const char *name;
+ u32 read_tag;
+ u32 write_tag;
+};
+
+struct rpi_otp_header {
+ u32 start;
+ u32 count;
+ u32 data[];
+};
+
+static int rpi_otp_read(void *context, unsigned int offset, void *buf, size_t bytes)
+{
+ struct rpi_otp_priv *priv = context;
+ struct rpi_otp_header *fwbuf;
+ int ret;
+
+ fwbuf = kmalloc(sizeof(struct rpi_otp_header) + bytes, GFP_KERNEL);
+ if (!fwbuf)
+ return -ENOMEM;
+
+ fwbuf->start = offset / 4;
+ fwbuf->count = bytes / 4;
+
+ ret = rpi_firmware_property(priv->fw, priv->read_tag, fwbuf,
+ sizeof(struct rpi_otp_header) + bytes);
+ if (ret)
+ goto out;
+
+ memcpy(buf, fwbuf->data, bytes);
+
+out:
+ kfree(fwbuf);
+ return ret;
+}
+
+static int rpi_otp_write(void *context, unsigned int offset, void *val, size_t bytes)
+{
+ struct rpi_otp_priv *priv = context;
+ struct rpi_otp_header *fwbuf;
+ int ret;
+
+ fwbuf = kmalloc(sizeof(struct rpi_otp_header) + bytes, GFP_KERNEL);
+ if (!fwbuf)
+ return -ENOMEM;
+
+ fwbuf->start = offset / 4;
+ fwbuf->count = bytes / 4;
+ memcpy(fwbuf->data, val, bytes);
+
+ ret = rpi_firmware_property(priv->fw, priv->write_tag, fwbuf,
+ sizeof(struct rpi_otp_header) + bytes);
+
+ kfree(fwbuf);
+ return ret;
+}
+
+static const struct rpi_otp_driver_data rpi_otp_customer = {
+ .name = "rpi-otp-customer",
+ .read_tag = RPI_FIRMWARE_GET_CUSTOMER_OTP,
+ .write_tag = RPI_FIRMWARE_SET_CUSTOMER_OTP,
+};
+
+static const struct rpi_otp_driver_data rpi_otp_private = {
+ .name = "rpi-otp-private",
+ .read_tag = RPI_FIRMWARE_GET_PRIVATE_OTP,
+ .write_tag = RPI_FIRMWARE_SET_PRIVATE_OTP,
+};
+
+static int rpi_otp_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct nvmem_device *nvmem;
+ struct rpi_otp_priv *priv;
+ struct device_node *np;
+ const struct rpi_otp_driver_data *data;
+ struct nvmem_config config = {
+ .read_only = false,
+ .word_size = 4,
+ .stride = 4,
+ .reg_read = rpi_otp_read,
+ .reg_write = rpi_otp_write,
+ .size = 32,
+ };
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ data = device_get_match_data(dev);
+ if (!data)
+ return -ENODEV;
+
+ np = of_get_parent(dev->of_node);
+ if (!np) {
+ dev_err(dev, "Missing firmware node\n");
+ return -ENOENT;
+ }
+
+ priv->fw = devm_rpi_firmware_get(&pdev->dev, np);
+ of_node_put(np);
+ if (!priv->fw)
+ return -EPROBE_DEFER;
+
+ priv->dev = dev;
+ priv->read_tag = data->read_tag;
+ priv->write_tag = data->write_tag;
+ config.dev = dev;
+ config.priv = priv;
+ config.name = data->name;
+
+ nvmem = devm_nvmem_register(dev, &config);
+ if (IS_ERR(nvmem))
+ return dev_err_probe(dev, PTR_ERR(nvmem), "error registering nvmem config\n");
+
+ return 0;
+}
+
+static const struct of_device_id rpi_otp_of_match[] = {
+ {
+ .compatible = "raspberrypi,firmware-otp-customer",
+ .data = &rpi_otp_customer
+ },
+ {
+ .compatible = "raspberrypi,firmware-otp-private",
+ .data = &rpi_otp_private,
+ },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, rpi_otp_of_match);
+
+static struct platform_driver raspberry_otp_driver = {
+ .probe = rpi_otp_probe,
+ .driver = {
+ .name = "rpi-otp",
+ .of_match_table = rpi_otp_of_match,
+ },
+};
+module_platform_driver(raspberry_otp_driver);
+
+MODULE_AUTHOR("Gregor Herburger <gregor.herburger@linutronix.de>");
+MODULE_DESCRIPTION("Raspberry OTP driver");
+MODULE_LICENSE("GPL");
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index e1f87fbfe554..6e94ccf34f47 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -92,6 +92,8 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_SET_POE_HAT_VAL = 0x00030050,
RPI_FIRMWARE_NOTIFY_XHCI_RESET = 0x00030058,
RPI_FIRMWARE_NOTIFY_DISPLAY_DONE = 0x00030066,
+ RPI_FIRMWARE_GET_PRIVATE_OTP = 0x00030081,
+ RPI_FIRMWARE_SET_PRIVATE_OTP = 0x00038081,
/* Dispmanx TAGS */
RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE = 0x00040001,
--
2.47.3
^ 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