* Re: [PATCH v5 8/9] driver core: Replace dev->of_node_reused with dev_of_node_reused()
From: Johan Hovold @ 2026-04-07 9:07 UTC (permalink / raw)
To: Douglas Anderson
Cc: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern, Alexey Kardashevskiy, Eric Dumazet, Leon Romanovsky,
Christoph Hellwig, Robin Murphy, maz, Alexander Lobakin,
Saravana Kannan, Mark Brown, alexander.stein, andrew, andrew,
andriy.shevchenko, astewart, bhelgaas, brgl, davem, devicetree,
driver-core, hkallweit1, jirislaby, joel, kees, kuba, lgirdwood,
linux-arm-kernel, linux-aspeed, linux-kernel, linux-pci,
linux-serial, linux-usb, linux, mani, netdev, pabeni, robh
In-Reply-To: <20260406162231.v5.8.I806b8636cd3724f6cd1f5e199318ab8694472d90@changeid>
On Mon, Apr 06, 2026 at 04:23:01PM -0700, Doug Anderson wrote:
> In C, bitfields are not necessarily safe to modify from multiple
> threads without locking. Switch "of_node_reused" over to the "flags"
> field so modifications are safe.
This flag is only set before registering a device with driver core so
there is no issue using the existing bitfield here (with the caveat that
PCI pwrctrl may have gotten that wrong). I haven't checked the other
flags, but I assume most of them work the same way.
But apart from the commit message being misleading, switching to using
atomic ops and accessors for consistency is fine.
> Cc: Johan Hovold <johan@kernel.org>
> Acked-by: Mark Brown <broonie@kernel.org>
> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
> Reviewed-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> Not fixing any known bugs; problem is theoretical and found by code
> inspection. Change is done somewhat manually and only lightly tested
> (mostly compile-time tested).
> diff --git a/drivers/regulator/bq257xx-regulator.c b/drivers/regulator/bq257xx-regulator.c
> index dab8f1ab4450..40e0f1a7ae81 100644
> --- a/drivers/regulator/bq257xx-regulator.c
> +++ b/drivers/regulator/bq257xx-regulator.c
> @@ -143,7 +143,7 @@ static int bq257xx_regulator_probe(struct platform_device *pdev)
> struct regulator_config cfg = {};
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> pdata = devm_kzalloc(&pdev->dev, sizeof(struct bq257xx_reg_data), GFP_KERNEL);
> if (!pdata)
> diff --git a/drivers/regulator/rk808-regulator.c b/drivers/regulator/rk808-regulator.c
> index e66408f23bb6..8297d31cde9f 100644
> --- a/drivers/regulator/rk808-regulator.c
> +++ b/drivers/regulator/rk808-regulator.c
> @@ -2115,7 +2115,7 @@ static int rk808_regulator_probe(struct platform_device *pdev)
> int ret, i, nregulators;
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> regmap = dev_get_regmap(pdev->dev.parent, NULL);
> if (!regmap)
These two uses are broken currently though and should be using
device_set_of_node_from_dev() so that an extra reference is taken to
balance the one dropped by the platform bus code.
I'll send two fixes to Mark, any merge conflict should be trivial to
fixup.
Reviewed-by: Johan Hovold <johan@kernel.org>
Johan
^ permalink raw reply
* Re: [PATCH net-next v2 4/9] net: dsa: lan9645x: add basic dsa driver for LAN9645X
From: Vladimir Oltean @ 2026-04-07 9:12 UTC (permalink / raw)
To: Jens Emil Schulz Ostergaard
Cc: Jakub Kicinski, UNGLinuxDriver, andrew, davem, edumazet, pabeni,
horms, robh, krzk+dt, conor+dt, woojung.huh, linux,
Steen.Hegelund, daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <c1b824a3e597b37df133053f6b216e9196b130d5.camel@microchip.com>
On Wed, Apr 01, 2026 at 01:46:19PM +0200, Jens Emil Schulz Ostergaard wrote:
> On Sun, 2026-03-29 at 12:56 -0700, Jakub Kicinski wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least plausible.
> > ---
> > Subject: net: dsa: lan9645x: add basic dsa driver for LAN9645X
> >
> > This commit adds a basic DSA driver for the Microchip LAN9645X switch. It
> > includes initialization, port module setup for NPI, CPU, and front ports,
> > and phylink integration for MAC side configuration.
> >
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
> > --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
> > [ ... ]
> > > +static void disable_conduit_ipv6(struct lan9645x *lan9645x,
> > > + struct net_device *conduit)
> > > +{
> > > + struct inet6_dev *dev_v6;
> > > +
> > > + if (!conduit)
> > > + return;
> > > +
> > > + /* IPv6 on the conduit will generate frames bypassing our tag driver, so
> > > + * they lack an IFH. This will be garbage in garbage out and we want to
> > > + * avoid this.
> > > + */
> > > + rtnl_lock();
> > > + dev_v6 = __in6_dev_get(conduit);
> > > + if (dev_v6) {
> > > + WRITE_ONCE(dev_v6->cnf.disable_ipv6, 1);
> > > + dev_warn(lan9645x->dev, "Disabled IPv6 on conduit device: %s\n",
> > > + netdev_name(conduit));
> > > + }
> > > + rtnl_lock();
> > > +}
> >
> > Does directly modifying dev_v6->cnf.disable_ipv6 bypass the proper sysctl
> > teardown path (addrconf_disable_ipv6) and leave the IPv6 stack in an
> > inconsistent state on the conduit device by failing to clean up routes,
> > addresses, and MLD memberships?
> >
> > Is it a layering violation for a switch driver to alter the networking
> > configuration of an external upper device, especially since this change
> > isn't reverted during driver unbind?
>
> Yes this will bypass the sysctl teardown path. I can change this to instead
> read disable_ipv6 state and warn the user that their device is misconfigured.
I don't want to have to deal with a DSA driver altering the conduit
configuration outside of the DSA core. NACK to any attempts of trying
this.
Define "garbage in, garbage out" for your case. The packets are sent to
random ports? Normally, switches are configured by their drivers to drop
those packets that don't contain DSA tags. You can also do that, by
setting up the switch to require an injection prefix.
> > [ ... ]
> > > + /* Configure IFH prefix mode for NPI port. */
> > > + lan_rmw(SYS_PORT_MODE_INCL_XTR_HDR_SET(LAN9645X_TAG_PREFIX_LONG) |
> > > + SYS_PORT_MODE_INCL_INJ_HDR_SET(LAN9645X_TAG_PREFIX_NONE),
> > > + SYS_PORT_MODE_INCL_XTR_HDR |
> > > + SYS_PORT_MODE_INCL_INJ_HDR,
> > > + lan9645x,
> > > + SYS_PORT_MODE(p->chip_port));
> >
> > Setting LAN9645X_TAG_PREFIX_NONE means the hardware interprets the first
> > bytes of any frame received from the host as an IFH command structure.
> >
> > Does this allow a local user to transmit crafted frames (for example, via
> > raw sockets or standard protocols) whose MAC address bytes map to malicious
> > IFH commands, thereby bypassing VLAN isolation or flooding the switch?
> >
> > Should the hardware be configured to require a strict prefix, such as
> > LAN9645X_TAG_PREFIX_LONG, for injected frames to prevent this?
>
> A prefix offers no protection against the described scenario. The current
> configuration is correct. If a prefix is configured frames MUST contain the
> prefix. With the conduit exposed in userspace this is not something we can
> guarantee.
The short prefix prevents user space from sending frames by mistake
which will reach the wire (daemons attaching to all interfaces, like for DHCP).
It still allows user space to intentionally inject frames into the
switch (for example from XDP on the conduit).
I recommend you go for the short prefix and drop the conduit alterations.
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > [ ... ]
> > > +static int lan9645x_setup(struct dsa_switch *ds)
> > > +{
> > > + struct lan9645x *lan9645x = ds->priv;
> > > + struct device *dev = lan9645x->dev;
> > > + u32 all_phys_ports;
> > > + int err;
> > > +
> > > + lan9645x->num_phys_ports = ds->num_ports;
> > > + all_phys_ports = GENMASK(lan9645x->num_phys_ports - 1, 0);
> > > +
> > > + err = lan9645x_reset_switch(lan9645x);
> > > + if (err)
> > > + return err;
> > > +
> > > + lan9645x->ports = devm_kcalloc(lan9645x->dev, lan9645x->num_phys_ports,
> > > + sizeof(struct lan9645x_port *),
> > > + GFP_KERNEL);
> >
> > Since the DSA .setup callback can be invoked multiple times during the
> > platform device's lifetime (for example, when the DSA master interface is
> > unbound and bound again), does using devm_kcalloc here cause a memory leak?
> > Should these allocations be moved to .probe or managed with kcalloc and
> > freed in .teardown?
> >
>
> Hmm I do not think this is right? I think dsa_tree_teardown is called from
> dsa_switch_remove which is called by the switch drivers .remove.
>
> So I do not think you can get multiple setup/teardown cycles during the device
> lifetime?
>
> As far as I can tell both felix and ksz use device managed allocations in their
> setup callback.
It's valid feedback in general. In a multi-switch tree, ds->ops->setup()
is called when the tree is complete, and ds->ops->teardown() when the
first switch disappears. If there are 2 switches and you unbind and
rebind the driver from A, then switch B will see a ds->ops->teardown()
call followed by ds->ops->setup().
In your case, since the switch doesn't support cascading, it probably
doesn't matter. But the LLM doesn't have the context to know that.
> > [ ... ]
> > > + /* Set all the entries to obey VLAN. */
> > > + for (int i = 0; i < PGID_ENTRIES; ++i)
> > > + lan_wr(ANA_PGID_CFG_OBEY_VLAN_SET(1),
> > > + lan9645x, ANA_PGID_CFG(i));
> >
> > PGID_ENTRIES is defined as 89, so this loop initializes indices 0 through
> > 88. Since the CPU port is index 9, its source PGID is PGID_SRC + CPU_PORT
> > (80 + 9 = 89).
> >
> > Is index 89 left uninitialized, breaking the OBEY_VLAN rule and allowing
> > CPU-injected frames to leak across VLAN boundaries?
> >
>
> No I this misunderstands OBEY_VLAN. When set the vlan table can control
> whether cpu copy from the pgid table is enabled. It makes no sense for PGID 89.
Explain that in a comment.
> > [ ... ]
> > > + /* Multicast to all front ports */
> > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MC));
> > > +
> > > + /* IP multicast to all front ports */
> > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MCIPV4));
> > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MCIPV6));
> > > +
> > > + /* Unicast to all front ports */
> > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_UC));
> > > +
> > > + /* Broadcast to all ports */
> > > + lan_wr(BIT(CPU_PORT) | all_phys_ports, lan9645x, ANA_PGID(PGID_BC));
> >
> > PGID_BC includes BIT(CPU_PORT) and all_phys_ports (which includes the NPI
> > port). Will this forward broadcast frames to both the CPU extraction queue
> > and the NPI port's normal egress queue, causing duplicate frames for the host?
> >
> > Conversely, the multicast masks and PGID_UC exclude BIT(CPU_PORT). Does
> > this cause them to bypass the CPU extraction queue entirely, thereby
> > lacking the LONG extraction prefix and breaking the host's DSA tagger parsing?
> >
>
> No this is not how it works. Generally when you configure the CPU port to use
> an NPI port, the hardware manages this internally. You do you have to start
> using the npi port number all of a sudden.
The comment is fair though. Why would you set all_phys_ports to
GENMASK(lan9645x->num_phys_ports - 1, 0) when you can compute the mask
of user ports which are enabled? It seems sloppy at best, and also
contradictory (comments say "all front ports", but code includes the NPI
port in this mask).
> > [ ... ]
> > > +int lan9645x_port_setup(struct dsa_switch *ds, int port)
> > > +{
> > > + struct dsa_port *dp = dsa_to_port(ds, port);
> > > + struct lan9645x *lan9645x = ds->priv;
> > > + struct lan9645x_port *p;
> > > +
> > > + p = lan9645x_to_port(lan9645x, port);
> > > +
> > > + if (dp->dn) {
> > > + p->rx_internal_delay =
> > > + of_property_present(dp->dn, "rx-internal-delay-ps");
> > > + p->tx_internal_delay =
> > > + of_property_present(dp->dn, "tx-internal-delay-ps");
> > > + }
> >
> > These are standard integer properties specifying delays in picoseconds. If
> > a user explicitly disables the delay via devicetree using a value of 0,
> > will of_property_present evaluate to true and enable the hardware delay
> > anyway? Should of_property_read_u32 be used instead to check the value?
>
> A value of 0 is not allowed per the bindings. The bindings enforce that if this
> is present the value must be 2000.
Bindings may change. Please use of_property_read_u32().
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: sm8750: Correct DPU VBIF address space size
From: Konrad Dybcio @ 2026-04-07 9:12 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kuogee Hsieh, Neil Armstrong, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260402-dts-qcom-display-regs-v1-7-daa54ab448a3@oss.qualcomm.com>
On 4/2/26 1:45 PM, Krzysztof Kozlowski wrote:
> VBIF register range is 0x3000 long, so correct the code even though
> missing part seems without practical impact.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Liu Ying @ 2026-04-07 9:15 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: imx, linux-arm-kernel, devicetree, linux-kernel, Liu Ying
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 +-------------------
.../freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso | 14 +++
4 files changed, 127 insertions(+), 105 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 711e36cc2c99..6315fb8390ff 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -455,9 +455,11 @@ dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb.dtb
imx93-9x9-qsb-can1-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-can1.dtbo
imx93-9x9-qsb-i3c-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-i3c.dtbo
imx93-9x9-qsb-ontat-kd50g21-40nt-a1-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo
+imx93-9x9-qsb-tianma-tm050rdh03-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-tianma-tm050rdh03.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-can1.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-i3c.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-tianma-tm050rdh03.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-frdm.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi
new file mode 100644
index 000000000000..d167c9fc3b8f
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "imx93-pinfunc.h"
+
+&{/} {
+ backlight: backlight {
+ compatible = "gpio-backlight";
+ gpios = <&pcal6524 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ panel {
+ compatible = "ontat,kd50g21-40nt-a1";
+ backlight = <&backlight>;
+ power-supply = <®_rpi_3v3>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dpi_to_panel>;
+ };
+ };
+ };
+};
+
+&dpi_bridge {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdif>;
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ dpi_to_panel: endpoint {
+ remote-endpoint = <&panel_in>;
+ bus-width = <18>;
+ };
+ };
+ };
+};
+
+&iomuxc {
+ pinctrl_lcdif: lcdifgrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO00__MEDIAMIX_DISP_CLK 0x31e
+ MX93_PAD_GPIO_IO01__MEDIAMIX_DISP_DE 0x31e
+ MX93_PAD_GPIO_IO02__MEDIAMIX_DISP_VSYNC 0x31e
+ MX93_PAD_GPIO_IO03__MEDIAMIX_DISP_HSYNC 0x31e
+ MX93_PAD_GPIO_IO04__MEDIAMIX_DISP_DATA00 0x31e
+ MX93_PAD_GPIO_IO05__MEDIAMIX_DISP_DATA01 0x31e
+ MX93_PAD_GPIO_IO06__MEDIAMIX_DISP_DATA02 0x31e
+ MX93_PAD_GPIO_IO07__MEDIAMIX_DISP_DATA03 0x31e
+ MX93_PAD_GPIO_IO08__MEDIAMIX_DISP_DATA04 0x31e
+ MX93_PAD_GPIO_IO09__MEDIAMIX_DISP_DATA05 0x31e
+ MX93_PAD_GPIO_IO10__MEDIAMIX_DISP_DATA06 0x31e
+ MX93_PAD_GPIO_IO11__MEDIAMIX_DISP_DATA07 0x31e
+ MX93_PAD_GPIO_IO12__MEDIAMIX_DISP_DATA08 0x31e
+ MX93_PAD_GPIO_IO13__MEDIAMIX_DISP_DATA09 0x31e
+ MX93_PAD_GPIO_IO14__MEDIAMIX_DISP_DATA10 0x31e
+ MX93_PAD_GPIO_IO15__MEDIAMIX_DISP_DATA11 0x31e
+ MX93_PAD_GPIO_IO16__MEDIAMIX_DISP_DATA12 0x31e
+ MX93_PAD_GPIO_IO17__MEDIAMIX_DISP_DATA13 0x31e
+ MX93_PAD_GPIO_IO18__MEDIAMIX_DISP_DATA14 0x31e
+ MX93_PAD_GPIO_IO19__MEDIAMIX_DISP_DATA15 0x31e
+ MX93_PAD_GPIO_IO20__MEDIAMIX_DISP_DATA16 0x31e
+ MX93_PAD_GPIO_IO21__MEDIAMIX_DISP_DATA17 0x31e
+ >;
+ };
+};
+
+&lcdif {
+ status = "okay";
+};
+
+&media_blk_ctrl {
+ status = "okay";
+};
+
+&pcal6524 {
+ /*
+ * exp-sel-hog has property 'output-low' while DT overlay doesn't
+ * support /delete-property/. Both 'output-low' and 'output-high'
+ * will exist under hog nodes if DT overlay file sets 'output-high'.
+ * Workaround is to disable this hog and create new hog with
+ * 'output-high'.
+ */
+ exp-sel-hog {
+ status = "disabled";
+ };
+
+ exp-high-sel-hog {
+ gpio-hog;
+ gpios = <22 GPIO_ACTIVE_HIGH>;
+ output-high;
+ };
+};
+
+&sai3 {
+ /* disable due to GPIO12 and GPIO17~20 pin conflicts with LCDIF */
+ status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso
index d167c9fc3b8f..356533a7b513 100644
--- a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso
+++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso
@@ -3,108 +3,4 @@
* Copyright 2026 NXP
*/
-/dts-v1/;
-/plugin/;
-
-#include <dt-bindings/gpio/gpio.h>
-#include "imx93-pinfunc.h"
-
-&{/} {
- backlight: backlight {
- compatible = "gpio-backlight";
- gpios = <&pcal6524 2 GPIO_ACTIVE_HIGH>;
- };
-
- panel {
- compatible = "ontat,kd50g21-40nt-a1";
- backlight = <&backlight>;
- power-supply = <®_rpi_3v3>;
-
- port {
- panel_in: endpoint {
- remote-endpoint = <&dpi_to_panel>;
- };
- };
- };
-};
-
-&dpi_bridge {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_lcdif>;
- status = "okay";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@1 {
- reg = <1>;
-
- dpi_to_panel: endpoint {
- remote-endpoint = <&panel_in>;
- bus-width = <18>;
- };
- };
- };
-};
-
-&iomuxc {
- pinctrl_lcdif: lcdifgrp {
- fsl,pins = <
- MX93_PAD_GPIO_IO00__MEDIAMIX_DISP_CLK 0x31e
- MX93_PAD_GPIO_IO01__MEDIAMIX_DISP_DE 0x31e
- MX93_PAD_GPIO_IO02__MEDIAMIX_DISP_VSYNC 0x31e
- MX93_PAD_GPIO_IO03__MEDIAMIX_DISP_HSYNC 0x31e
- MX93_PAD_GPIO_IO04__MEDIAMIX_DISP_DATA00 0x31e
- MX93_PAD_GPIO_IO05__MEDIAMIX_DISP_DATA01 0x31e
- MX93_PAD_GPIO_IO06__MEDIAMIX_DISP_DATA02 0x31e
- MX93_PAD_GPIO_IO07__MEDIAMIX_DISP_DATA03 0x31e
- MX93_PAD_GPIO_IO08__MEDIAMIX_DISP_DATA04 0x31e
- MX93_PAD_GPIO_IO09__MEDIAMIX_DISP_DATA05 0x31e
- MX93_PAD_GPIO_IO10__MEDIAMIX_DISP_DATA06 0x31e
- MX93_PAD_GPIO_IO11__MEDIAMIX_DISP_DATA07 0x31e
- MX93_PAD_GPIO_IO12__MEDIAMIX_DISP_DATA08 0x31e
- MX93_PAD_GPIO_IO13__MEDIAMIX_DISP_DATA09 0x31e
- MX93_PAD_GPIO_IO14__MEDIAMIX_DISP_DATA10 0x31e
- MX93_PAD_GPIO_IO15__MEDIAMIX_DISP_DATA11 0x31e
- MX93_PAD_GPIO_IO16__MEDIAMIX_DISP_DATA12 0x31e
- MX93_PAD_GPIO_IO17__MEDIAMIX_DISP_DATA13 0x31e
- MX93_PAD_GPIO_IO18__MEDIAMIX_DISP_DATA14 0x31e
- MX93_PAD_GPIO_IO19__MEDIAMIX_DISP_DATA15 0x31e
- MX93_PAD_GPIO_IO20__MEDIAMIX_DISP_DATA16 0x31e
- MX93_PAD_GPIO_IO21__MEDIAMIX_DISP_DATA17 0x31e
- >;
- };
-};
-
-&lcdif {
- status = "okay";
-};
-
-&media_blk_ctrl {
- status = "okay";
-};
-
-&pcal6524 {
- /*
- * exp-sel-hog has property 'output-low' while DT overlay doesn't
- * support /delete-property/. Both 'output-low' and 'output-high'
- * will exist under hog nodes if DT overlay file sets 'output-high'.
- * Workaround is to disable this hog and create new hog with
- * 'output-high'.
- */
- exp-sel-hog {
- status = "disabled";
- };
-
- exp-high-sel-hog {
- gpio-hog;
- gpios = <22 GPIO_ACTIVE_HIGH>;
- output-high;
- };
-};
-
-&sai3 {
- /* disable due to GPIO12 and GPIO17~20 pin conflicts with LCDIF */
- status = "disabled";
-};
+#include "imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi"
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>;
+ };
+};
---
base-commit: 816f193dd0d95246f208590924dd962b192def78
change-id: 20260407-tianma-tm050rdh03-imx93-9x9-qsb-6e4bbbde3d08
Best regards,
--
Liu Ying <victor.liu@nxp.com>
^ permalink raw reply related
* RE: [PATCH V10 03/13] PCI: dwc: Parse Root Port nodes in dw_pcie_host_init()
From: Sherry Sun @ 2026-04-07 9:18 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: <gxqcmujdzlzcoawn4rkttasftuyusqtvycu7oagogxaw4yggeo@ww6rjdwbyj2w>
> On Tue, Apr 07, 2026 at 03:21:30AM +0000, Sherry Sun wrote:
> > > On Thu, Apr 02, 2026 at 05:50:57PM +0800, Sherry Sun wrote:
> > > > Add support for parsing Root Port child nodes in
> > > > dw_pcie_host_init() using pci_host_common_parse_ports(). This
> > > > allows DWC-based drivers to specify Root Port properties (like
> > > > reset GPIOs) in individual Root Port nodes rather than in the host bridge
> node.
> > > >
> > > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > > ---
> > > > drivers/pci/controller/dwc/pcie-designware-host.c | 8 ++++++++
> > > > 1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > index da152c31bb2e..f6fca984fb34 100644
> > > > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > > @@ -20,6 +20,7 @@
> > > > #include <linux/platform_device.h>
> > > >
> > > > #include "../../pci.h"
> > > > +#include "../pci-host-common.h"
> > > > #include "pcie-designware.h"
> > > >
> > > > static struct pci_ops dw_pcie_ops; @@ -581,6 +582,13 @@ int
> > > > dw_pcie_host_init(struct dw_pcie_rp *pp)
> > > >
> > > > pp->bridge = bridge;
> > > >
> > > > + /* Parse Root Port nodes if present */
> > > > + ret = pci_host_common_parse_ports(dev, bridge);
> > > > + if (ret && ret != -ENOENT) {
> > > > + dev_err(dev, "Failed to parse Root Port nodes: %d\n", ret);
> > > > + return ret;
> > >
> > > Won't this change break drivers that parse Root Ports on their own?
> > > Either you need to modify them also in this change or call this API
> > > from imx6 driver and let other drivers switch to it in a phased manner.
> > >
> > > I perfer the latter.
> >
> > Hi Mani, sorry I didn't fully get your point here, there are no
> > changes to this part V10, for drivers that parse Root Ports on their
> > own, here pci_host_common_parse_ports() will return -ENOENT, so
> > nothing break as we discussed this in V8
> https://lore.ke/
> rnel.org%2Fall%2Fdcl3bdljrdzgeaybrg3dc5uaxkebkjns7pajix6mxxftao5g4m%40
> vm3ywyyp4ujh%2F&data=05%7C02%7Csherry.sun%40nxp.com%7Cd9faef64b
> 8154bdbc6ee08de94724b22%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7C639111415791802118%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1
> hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl
> dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=POsurqr9RqBCnaQyeXDK2HQTN
> a4Nc0tfl7thSiM9qHA%3D&reserved=0.
> >
>
> So if this API gets called first, it will acquire PERST# from the Root Port node
> and if the controller drivers try to do the same in their own parsing code,
> PERST# request will return -EBUSY and the probe will fail.
>
> On the other hand, if the controller drivers parse PERST# first, this API will
> return -EBUSY and will result in probe failure.
>
> Only way to fix this issue would be to call this API from imx6 driver for now
> and start migrating other drivers later.
>
Ok, get your point here. Your assumption is based on the premise that the controller
driver parse the reset-gpios in the Root Port node, not that most controller drivers
now use reset under the host bridge node. For reset-gpios in the Root Port node,
they should eventually switch to this common API.
Anyway, I will call this API in imx6 driver at this stage to avoid impact other platforms.
Best Regards
Sherry
^ permalink raw reply
* Re: [PATCH v4 3/6] arm64: dts: qcom: Add AYN QCS8550 Common
From: Konrad Dybcio @ 2026-04-07 9:20 UTC (permalink / raw)
To: Aaron Kling, Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Teguh Sobirin
In-Reply-To: <CALHNRZ9ZiENcXJn7SKuAoDWoBbuxWuOktBDF7FZob6xFH8A3=A@mail.gmail.com>
On 4/3/26 12:04 AM, Aaron Kling wrote:
> On Mon, Mar 30, 2026 at 6:32 AM Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>
>> On Mon, Mar 30, 2026 at 01:00:55PM +0200, Konrad Dybcio wrote:
>>> On 3/27/26 10:26 PM, Aaron Kling wrote:
>>>> On Tue, Mar 24, 2026 at 7:36 AM Konrad Dybcio
>>>> <konrad.dybcio@oss.qualcomm.com> wrote:
>>>>>
>>>>> On 3/23/26 5:27 PM, Aaron Kling via B4 Relay wrote:
>>>>>> From: Teguh Sobirin <teguh@sobir.in>
>>>>>>
>>>>>> This contains everything common between the AYN QCS8550 devices. It will
>>>>>> be included by device specific dts'.
>>>>>>
>>>>>> Signed-off-by: Teguh Sobirin <teguh@sobir.in>
>>>>>> Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
>>>>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
>>>>>> ---
>>>>>
>>>>> [...]
>>>>>
>>>>>> + sound {
>>>>>> + compatible = "qcom,sm8550-sndcard", "qcom,sm8450-sndcard";
>>>>>> + pinctrl-0 = <&lpi_i2s3_active>;
>>>>>> + pinctrl-names = "default";
>>>>>> +
>>>>>> + model = "AYN-Odin2";
>>>>>
>>>>> Is this enough of a distinction? Do you need to make any changes to the
>>>>> one with a HDMI bridge to get HDMI audio?
>>>>
>>>> After this quesstion, I tried to verify hdmi and am unable to even get
>>>> the connector to come up. The lt8912b driver complains that the
>>>> connector doesn't support edid read.
>>
>> Looking at the driver, please drop lt8912_bridge_edid_read(),
>> lt8912_bridge_detect() and lt->bridge.ops assignment. Those bits are
>> lame and useless.
>>
>>> Which per the current connector
>>>> node is correct, none of the devices list a ddc node. I am trying to
>>>> investigate this further, but vendor source release unfortunately
>>>> appears to be missing pieces related to this. And no other current
>>>> qcom device uses this bridge to take a guess at which controller the
>>>> ddc is on.
>>>
>>> Go through the I2C buses that are enabled on the vendor kernel and try
>>> inspecting them with toos like i2cdetect
>>
>> I'd second this suggestion. The chip doesn't support EDID reading, so it
>> is (hopefully) handled via some existing bus. Does downstream handle
>> EDID / HDMI at all?
>
> I have been unable to get the stock OS to display anything on hdmi at
> all. The downstream kernel reports the head as DSI, and is hardcoded
> to a 1920x1080 mode in the kernel dt. We have been unable to find any
> kernel handling of this bridge at all for downstream, in the source
> release or the prebuilt kernel shipped with the stock OS. Best I can
> tell, they just hardcode the one mode and nothing else will work.
> There are reports of hdmi audio working, though; which I'm not sure
> how if the bridge has no kernel driver at all.
>
> All i2c nodes used by downstream are already enabled. And when an hdmi
> cable is plugged in, I never see the ddc address, 0x50 if I understand
> correctly, show up on any of them. I tried enabling other i2c nodes to
> check if anything shows up on them, but that causes kernel panics
> during boot and without uart, I can't see why.
>
> This all seems rather broken, perhaps by odm design. Given this state,
> should I just drop all references to hdmi and leave a comment in the
> dts where the bridge should be to explain why?
That's definitely better than describing (for all we know) broken hw
We can always come back to that if a fix is found
Konrad
^ permalink raw reply
* Re: [PATCH v3 2/3] arm64: dts: qcom: kaanpaali: Add USB support for MTP platform
From: Konrad Dybcio @ 2026-04-07 9:31 UTC (permalink / raw)
To: Krishna Kurapati, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ronak Raheja,
Jingyi Wang
In-Reply-To: <20260406174613.3388987-3-krishna.kurapati@oss.qualcomm.com>
On 4/6/26 7:46 PM, Krishna Kurapati wrote:
> From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>
> Enable USB support on Kaanapali MTP variant. Enable USB controller in
> device mode till glink node is added.
>
> Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH 0/2] drm/panel: simple: Add Startek KD070HDFLD092 LVDS panel support
From: Stefan Kerkmann @ 2026-04-07 9:31 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg
Cc: dri-devel, devicetree, linux-kernel, Stefan Kerkmann
The Startek KD070HDFLD092 is a 7" WSVGA LVDS panel.
Signed-off-by: Stefan Kerkmann <s.kerkmann@pengutronix.de>
---
Stefan Kerkmann (2):
dt-bindings: display: simple: Add Startek KD070HDFLD092 panel
drm/panel: simple: Add Startek KD070HDFLD092 LVDS panel support
.../bindings/display/panel/panel-simple.yaml | 2 ++
drivers/gpu/drm/panel/panel-simple.c | 29 ++++++++++++++++++++++
2 files changed, 31 insertions(+)
---
base-commit: bfe62a454542cfad3379f6ef5680b125f41e20f4
change-id: 20260407-panel-simple-startek-upstream-7eddd07166c1
Best regards,
--
Stefan Kerkmann <s.kerkmann@pengutronix.de>
^ permalink raw reply
* [PATCH 2/2] drm/panel: simple: Add Startek KD070HDFLD092 LVDS panel support
From: Stefan Kerkmann @ 2026-04-07 9:31 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg
Cc: dri-devel, devicetree, linux-kernel, Stefan Kerkmann
In-Reply-To: <20260407-panel-simple-startek-upstream-v1-0-76721696655f@pengutronix.de>
The Startek KD070HDFLD092 is a 7" WSVGA LVDS panel.
Signed-off-by: Stefan Kerkmann <s.kerkmann@pengutronix.de>
---
drivers/gpu/drm/panel/panel-simple.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 91ab280869bac..737a1014f8112 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -4540,6 +4540,32 @@ static const struct panel_desc starry_kr070pe2t = {
.connector_type = DRM_MODE_CONNECTOR_DPI,
};
+static const struct display_timing startek_kd070hdfld092_timing = {
+ .pixelclock = { 40800000, 51200000, 67200000 },
+ .hactive = { 1024, 1024, 1024 },
+ .hfront_porch = { 40, 160, 216 },
+ .hback_porch = { 30, 140, 140 },
+ .hsync_len = { 20, 20, 20 },
+ .vactive = { 600, 600, 600 },
+ .vfront_porch = { 2, 12, 177 },
+ .vback_porch = { 5, 20, 20 },
+ .vsync_len = { 3, 3, 3 },
+ .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc startek_kd070hdfld092 = {
+ .timings = &startek_kd070hdfld092_timing,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct display_timing startek_kd070wvfpa_mode = {
.pixelclock = { 25200000, 27200000, 30500000 },
.hactive = { 800, 800, 800 },
@@ -5532,6 +5558,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "starry,kr070pe2t",
.data = &starry_kr070pe2t,
+ }, {
+ .compatible = "startek,kd070hdfld092",
+ .data = &startek_kd070hdfld092,
}, {
.compatible = "startek,kd070wvfpa",
.data = &startek_kd070wvfpa,
--
2.47.3
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: display: simple: Add Startek KD070HDFLD092 panel
From: Stefan Kerkmann @ 2026-04-07 9:31 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg
Cc: dri-devel, devicetree, linux-kernel, Stefan Kerkmann
In-Reply-To: <20260407-panel-simple-startek-upstream-v1-0-76721696655f@pengutronix.de>
Add Startek KD070HDFLD092 7" WSVGA LVDS panel compatible.
Signed-off-by: Stefan Kerkmann <s.kerkmann@pengutronix.de>
---
Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 868edb04989a5..2a6a41349e5f7 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -302,6 +302,8 @@ properties:
- shelly,sca07010-bfn-lnn
# Starry KR070PE2T 7" WVGA TFT LCD panel
- starry,kr070pe2t
+ # Startek KD070HDFLD092 7" WSVGA TFT LCD panel
+ - startek,kd070hdfld092
# Startek KD070WVFPA043-C069A 7" TFT LCD panel
- startek,kd070wvfpa
# Team Source Display Technology TST043015CMHX 4.3" WQVGA TFT LCD panel
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3 3/3] arm64: dts: qcom: kaanpaali: Add USB support for QRD platform
From: Konrad Dybcio @ 2026-04-07 9:32 UTC (permalink / raw)
To: Krishna Kurapati, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ronak Raheja,
Jingyi Wang
In-Reply-To: <20260406174613.3388987-4-krishna.kurapati@oss.qualcomm.com>
On 4/6/26 7:46 PM, Krishna Kurapati wrote:
> From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>
> Enable USB support on Kaanapali QRD variant. Enable USB controller in
> device mode till glink node is added.
>
> Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> +&usb_dp_qmpphy {
nit: the addition of the "_dp_" bit which is absent on other platforms
in the label made the reference unsorted
Konrad
> + vdda-phy-supply = <&vreg_l1d_1p2>;
> + vdda-pll-supply = <&vreg_l4f_0p8>;
> +
> + status = "okay";
> +};
^ permalink raw reply
* Re: [PATCH v3 1/3] arm64: dts: qcom: kaanapali: Add USB support for Kaanapali SoC
From: Konrad Dybcio @ 2026-04-07 9:32 UTC (permalink / raw)
To: Krishna Kurapati, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ronak Raheja,
Jingyi Wang
In-Reply-To: <20260406174613.3388987-2-krishna.kurapati@oss.qualcomm.com>
On 4/6/26 7:46 PM, Krishna Kurapati wrote:
> From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>
> Add the base USB devicetree definitions for Kaanapali platform. The overall
> chipset contains a single DWC3 USB3 controller (rev. 200a), SS QMP PHY
> (rev. v8) and M31 eUSB2 PHY.
>
> Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 5/7] arm64: dts: qcom: milos: Add WCN6755 WiFi node
From: Konrad Dybcio @ 2026-04-07 9:35 UTC (permalink / raw)
To: Luca Weiss, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alexander Koskovich,
Liam Girdwood, Mark Brown, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
Johannes Berg, Jeff Johnson
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-kernel, devicetree, linux-bluetooth, linux-wireless, ath11k
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-5-393322b27c5f@fairphone.com>
On 4/3/26 3:52 PM, Luca Weiss wrote:
> Add a node for the WCN6755 WiFi found with the Milos SoC.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* RE: [PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support
From: YH Chung @ 2026-04-07 9:36 UTC (permalink / raw)
To: Arnd Bergmann, Andrew Jeffery, Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Ryan Chen, Philipp Zabel, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, maciej.lawniczak@intel.com, Mark Brown
In-Reply-To: <KL1PR0601MB42763DAD359305DEBA4B769D9057A@KL1PR0601MB4276.apcprd06.prod.outlook.com>
Hi Arnd,
Thanks for the comments and questions.
> These all seem to be viable options, but I still think we should focus on
> agreeing on a design for the low-level hardware interface and whether this
> can or should be abstracted between SoC vendor specific drivers before
> trying to solve the user interface side.
Could you share your thoughts on whether it would make sense to accept our
eSPI driver as is, and whether it should live under the SoC vendor-specific
directories? Any comment would be greatly appreciated.
Thanks,
YunHsuan
^ permalink raw reply
* Re: [Upstream] Re: [PATCH] arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlay
From: Frank Li @ 2026-04-07 9:37 UTC (permalink / raw)
To: Primoz Fiser
Cc: Florijan Plohl, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
imx, linux-arm-kernel, devicetree, linux-kernel, upstream
In-Reply-To: <707e106b-f444-4c26-9816-c53c8eda8cbb@norik.com>
On Tue, Apr 07, 2026 at 08:14:08AM +0200, Primoz Fiser wrote:
> Hi Frank, Florijan,
>
> On 4/6/26 04:56, Frank Li wrote:
> > On Fri, Apr 03, 2026 at 10:29:00AM +0200, Florijan Plohl wrote:
> >> Hello,
> >>
> >> On 4/2/26 15:50, Frank Li wrote:
> >>> On Thu, Apr 02, 2026 at 09:08:26AM +0200, Florijan Plohl wrote:
> >>>> Add overlay for the PEB-AV-18 adapter on phyBOARD-Segin-i.MX91/93.
> >>> what's means PEB-AV-18? Is it random board name?
> >> The PEB-AV-18 is PHYTEC designation for Audio/Video adapter modules that can
> >> be used to connect displays on their boards.
> >>
> >> I will improve commit message to add more such information in v2.
> >>
> >>>
> >>>
> >>>> The supported LCD is Powertip PH800480T032-ZHC19 panel (AC220).
> >>>>
> >>>> Signed-off-by: Florijan Plohl <florijan.plohl@norik.com>
> >>>> ---
> >>>> arch/arm64/boot/dts/freescale/Makefile | 4 +
> >>>> .../imx91-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
> >>>> .../imx93-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
> >>> Any difference between 91 and 93, can use one overlay file?
> >>>
> >>> Frank
> >>
> >> Can you suggest how to do so?
> >>
> >> There are imx93-pinfunc.h and imx91-pinfunc.h which are not unified
> >> between imx91 and imx93.
> >
> > I suggest move pinmux setting to mainboard's dts files, which provide
> > plug adaptor header, signal should be descripted in mainboard's dts file,
> > which provide an unified label to overlay file.
>
> Yeah, that would be one way of doing it.
>
> However, the phycore dtsi and phyboard dts are kept simple by design
> choice. This way, all optional pinctrls and peripherals are kept
> separate from the board device-tree to maintain clutter low.
>
> For v2 I would prefer to keep as is (current downstream implementation)
> or at least use this approach:
>
> imx91-93-phyboard-segin-peb-av-18.dtsi
> |
> -> imx91-phyboard-segin-peb-av-18.dtso
> |
> -> imx93-phyboard-segin-peb-av-18.dtso
It is better than v1's method.
Frank
>
> BR,
> Primoz
>
> >
> > Frank
> >
> >>
> >> So we can only create common dtsi like so:
> >>
> >> imx91-93-phyboard-segin-peb-av-18.dtsi
> >>
> >> and still use separate dtsos:
> >>
> >> imx91-phyboard-segin-peb-av-18.dtso
> >> imx93-phyboard-segin-peb-av-18.dtso
> >>
> >> Is that your idea?
> >>
> >> BR,
> >>
> >> Florijan Plohl
> >>
> >>>> --
> >>>> 2.43.0
> >>>>
> > _______________________________________________
> > upstream mailing list -- upstream@lists.phytec.de
> > To unsubscribe send an email to upstream-leave@lists.phytec.de
>
> --
> Primoz Fiser
> phone: +386-41-390-545
> email: primoz.fiser@norik.com
> --
> Norik systems d.o.o.
> Your embedded software partner
> Slovenia, EU
> phone: +386-41-540-545
> email: info@norik.com
>
^ permalink raw reply
* Re: [PATCH v4 3/4] PCI: tegra: Add Tegra264 support
From: Thierry Reding @ 2026-04-07 9:38 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Karthikeyan Mitran, Hou Zhiqiang,
Thomas Petazzoni, Pali Rohár, Michal Simek, Kevin Xie,
linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding, Manikanta Maddireddy
In-Reply-To: <iaoee5r5e2w52fap7ex23wdikbuvpjpesinedgjkehsedszhzo@64yoo2avmxle>
[-- Attachment #1: Type: text/plain, Size: 12894 bytes --]
On Thu, Apr 02, 2026 at 11:02:02PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Apr 02, 2026 at 04:27:37PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Add a driver for the PCIe controller found on NVIDIA Tegra264 SoCs. The
> > driver is very small, with its main purpose being to set up the address
> > translation registers and then creating a standard PCI host using ECAM.
> >
> > Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
>
> What is the rationale for adding a new driver? Can't you reuse the existing one?
> If so, that should be mentioned in the description.
Which existing one? Tegra PCI controllers for previou generations
(Tegra194 and Tegra234) were DesignWare IP, but Tegra264 is an internal
IP, so the programming is entirely different. I'll add something to that
effect to the commit message.
> > diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> > index 5aaed8ac6e44..6ead04f7bd6e 100644
> > --- a/drivers/pci/controller/Kconfig
> > +++ b/drivers/pci/controller/Kconfig
> > @@ -254,7 +254,15 @@ config PCI_TEGRA
> > select IRQ_MSI_LIB
> > help
> > Say Y here if you want support for the PCIe host controller found
> > - on NVIDIA Tegra SoCs.
> > + on NVIDIA Tegra SoCs (Tegra20 through Tegra186).
> > +
> > +config PCIE_TEGRA264
> > + bool "NVIDIA Tegra264 PCIe controller"
>
> This driver seems to be using external MSI controller. So it can be built as a
> module. Also, you have the remove() callback for some reason.
Okay, I can turn this into a tristate symbol.
> > + depends on ARCH_TEGRA || COMPILE_TEST
> > + depends on PCI_MSI
>
> Why?
I suppose it's not necessary in the sense of it being a build
dependency. At runtime, however, the root complex is not useful if PCI
MSI is not enabled. We can drop this dependency and rely on .config to
have it enabled as needed.
> > diff --git a/drivers/pci/controller/pcie-tegra264.c b/drivers/pci/controller/pcie-tegra264.c
> > new file mode 100644
> > index 000000000000..3ce1ad971bdb
> > --- /dev/null
> > +++ b/drivers/pci/controller/pcie-tegra264.c
[...]
> > +struct tegra264_pcie {
> > + struct device *dev;
> > + bool link_up;
>
> Keep bool types at the end to avoid holes.
Done.
> > +static int tegra264_pcie_parse_dt(struct tegra264_pcie *pcie)
> > +{
> > + int err;
> > +
> > + pcie->wake_gpio = devm_gpiod_get_optional(pcie->dev, "nvidia,pex-wake",
>
> You should switch to standard 'wake-gpios' property.
Will do.
> > + GPIOD_IN);
> > + if (IS_ERR(pcie->wake_gpio))
> > + return PTR_ERR(pcie->wake_gpio);
> > +
> > + if (pcie->wake_gpio) {
>
> Since you are bailing out above, you don't need this check.
I think we still want to have this check to handle the case of optional
wake GPIOs. Not all controllers may have this wired up and
devm_gpiod_get_optional() will return NULL (not an ERR_PTR()-encoded
error) if the wake-gpios property is missing.
> > +static void tegra264_pcie_bpmp_set_rp_state(struct tegra264_pcie *pcie)
>
> I don't think this function name is self explanatory. Looks like it is turning
> off the PCIe controller, so how about tegra264_pcie_power_off()?
Agreed. The name is a relic from when this was potentially being used to
toggle on and off the controller. But it's only used for disabling, so
tegra264_pcie__power_off() sounds much better.
> > +{
> > + struct tegra_bpmp_message msg = {};
> > + struct mrq_pcie_request req = {};
> > + int err;
> > +
> > + req.cmd = CMD_PCIE_RP_CONTROLLER_OFF;
> > + req.rp_ctrlr_off.rp_controller = pcie->ctl_id;
> > +
> > + msg.mrq = MRQ_PCIE;
> > + msg.tx.data = &req;
> > + msg.tx.size = sizeof(req);
> > +
> > + err = tegra_bpmp_transfer(pcie->bpmp, &msg);
> > + if (err)
> > + dev_info(pcie->dev, "failed to turn off PCIe #%u: %pe\n",
>
> Why not dev_err()?
>
> > + pcie->ctl_id, ERR_PTR(err));
> > +
> > + if (msg.rx.ret)
> > + dev_info(pcie->dev, "failed to turn off PCIe #%u: %d\n",
>
> Same here.
These are not fatal errors and are safe to ignore. dev_err() seemed too
strong for this. They also really shouldn't happen. Though I now realize
that's a bad argument, or rather, actually an argument for making them
dev_err() so that they do stand out if they really should happen.
>
> > + pcie->ctl_id, msg.rx.ret);
> > +}
> > +
> > +static void tegra264_pcie_icc_set(struct tegra264_pcie *pcie)
> > +{
> > + u32 value, speed, width, bw;
> > + int err;
> > +
> > + value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_STATUS);
> > + speed = FIELD_GET(PCI_EXP_LNKSTA_CLS, value);
> > + width = FIELD_GET(PCI_EXP_LNKSTA_NLW, value);
> > +
> > + bw = width * (PCIE_SPEED2MBS_ENC(speed) / BITS_PER_BYTE);
> > + value = MBps_to_icc(bw);
>
> So this becomes, 'width * (PCIE_SPEED2MBS_ENC(speed) / 8) * 1000 / 8'. But don't
> you want, 'width * (PCIE_SPEED2MBS_ENC(speed)) * 1000 / 8'?
This is M*B*ps_to_icc(), not M*b*ps_to_icc(), so we do in fact get the
latter. I almost fell for this as well because I got confused by some of
these macros being all-caps and other times the case actually mattering.
> > + err = icc_set_bw(pcie->icc_path, bw, bw);
> > + if (err < 0)
> > + dev_err(pcie->dev,
> > + "failed to request bandwidth (%u MBps): %pe\n",
> > + bw, ERR_PTR(err));
>
> So you don't want to error out if this fails?
No. This is not a fatal error and the system will continue to work,
albeit perhaps at suboptimal performance. Given that Ethernet and mass
storage are connected to these, a failure to set the bandwidth and
erroring out here may leave the system unusable, but continuing on would
let the system boot and update firmware, kernel or whatever to recover.
I'll add a comment explaining this.
[...]
> > +static void tegra264_pcie_init(struct tegra264_pcie *pcie)
> > +{
> > + enum pci_bus_speed speed;
> > + unsigned int i;
> > + u32 value;
> > +
> > + /* bring the link out of reset */
>
> s/link/controller or endpoint?
This controls the PERST# signal, so I guess "endpoint" would be more
correct.
> > + value = readl(pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
> > + value |= XTL_RC_MGMT_PERST_CONTROL_PERST_O_N;
> > + writel(value, pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
> > +
> > + if (!tegra_is_silicon()) {
>
> This looks like some pre-silicon validation thing. Do you really want it to be
> present in the upstream driver?
At this point there is silicon for this chip, but we've been trying to
get some of the pre-silicon code merged upstream as well because
occasionally people will want to run upstream on simulation, even after
silicon is available. At other times we may want to reuse these drivers
on future chips during pre-silicon validation.
Obviously there needs to be a balance. We don't want to have excessive
amounts of code specifically for pre-silicon validation, but in
relatively simple cases like this it is useful.
>
> > + dev_info(pcie->dev,
> > + "skipping link state for PCIe #%u in simulation\n",
> > + pcie->ctl_id);
> > + pcie->link_up = true;
> > + return;
> > + }
> > +
> > + for (i = 0; i < PCIE_LINK_WAIT_MAX_RETRIES; i++) {
> > + if (tegra264_pcie_link_up(pcie, NULL))
> > + break;
> > +
> > + usleep_range(PCIE_LINK_WAIT_US_MIN, PCIE_LINK_WAIT_US_MAX);
> > + }
> > +
> > + if (tegra264_pcie_link_up(pcie, &speed)) {
>
> Why are you doing it for the second time?
It's just a last-resort check to see if it's really not come up after
the retries. Also, in this call we're actually interested in retrieving
the detected link speed.
>
> > + /* Per PCIe r5.0, 6.6.1 wait for 100ms after DLL up */
>
> No need of this comment.
Fair enough. This was perhaps more useful in earlier versions of the
patch before the line below used the standardize wait time.
[...]
> > +static int tegra264_pcie_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct pci_host_bridge *bridge;
> > + struct tegra264_pcie *pcie;
> > + struct resource_entry *bus;
> > + struct resource *res;
> > + int err;
> > +
> > + bridge = devm_pci_alloc_host_bridge(dev, sizeof(struct tegra264_pcie));
> > + if (!bridge)
> > + return dev_err_probe(dev, -ENOMEM,
> > + "failed to allocate host bridge\n");
> > +
> > + pcie = pci_host_bridge_priv(bridge);
> > + platform_set_drvdata(pdev, pcie);
> > + pcie->bridge = bridge;
> > + pcie->dev = dev;
> > +
> > + err = pinctrl_pm_select_default_state(dev);
>
> I questioned this before:
> https://lore.kernel.org/linux-pci/o5sxxdikdjwd76zsedvkpsl54nw6wrhopwsflt43y5st67mrub@uuw3yfjfqthd/
I'll remove this. Looks like we should be fine with just relying on the
default state being set by the pinctrl core. We might need to move it
into the resume callback.
> > + if (err < 0)
> > + return dev_err_probe(dev, err,
> > + "failed to configure sideband pins\n");
> > +
> > + err = tegra264_pcie_parse_dt(pcie);
> > + if (err < 0)
> > + return dev_err_probe(dev, err, "failed to parse device tree");
> > +
> > + pcie->xal = devm_platform_ioremap_resource_byname(pdev, "xal");
> > + if (IS_ERR(pcie->xal))
> > + return dev_err_probe(dev, PTR_ERR(pcie->xal),
> > + "failed to map XAL memory\n");
> > +
> > + pcie->xtl = devm_platform_ioremap_resource_byname(pdev, "xtl-pri");
> > + if (IS_ERR(pcie->xtl))
> > + return dev_err_probe(dev, PTR_ERR(pcie->xtl),
> > + "failed to map XTL-PRI memory\n");
> > +
> > + bus = resource_list_first_type(&bridge->windows, IORESOURCE_BUS);
> > + if (!bus)
> > + return dev_err_probe(dev, -ENODEV,
> > + "failed to get bus resources\n");
> > +
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam");
> > + if (!res)
> > + return dev_err_probe(dev, -ENXIO,
> > + "failed to get ECAM resource\n");
> > +
> > + pcie->icc_path = devm_of_icc_get(&pdev->dev, "write");
> > + if (IS_ERR(pcie->icc_path))
> > + return dev_err_probe(&pdev->dev, PTR_ERR(pcie->icc_path),
> > + "failed to get ICC");
> > +
> > + /*
> > + * Parse BPMP property only for silicon, as interaction with BPMP is
> > + * not needed for other platforms.
> > + */
> > + if (tegra_is_silicon()) {
> > + pcie->bpmp = tegra_bpmp_get_with_id(dev, &pcie->ctl_id);
> > + if (IS_ERR(pcie->bpmp))
> > + return dev_err_probe(dev, PTR_ERR(pcie->bpmp),
> > + "failed to get BPMP\n");
> > + }
> > +
>
> pm_runtime_set_active()
>
> > + pm_runtime_enable(dev);
>
> devm_pm_runtime_enable()?
Looks like I can even use devm_pm_runtime_set_active_enabled() to
combine the two.
>
> > + pm_runtime_get_sync(dev);
> > +
> > + /* sanity check that programmed ranges match what's in DT */
> > + if (!tegra264_pcie_check_ranges(pdev)) {
> > + err = -EINVAL;
> > + goto put_pm;
> > + }
> > +
> > + pcie->cfg = pci_ecam_create(dev, res, bus->res, &pci_generic_ecam_ops);
> > + if (IS_ERR(pcie->cfg)) {
> > + err = dev_err_probe(dev, PTR_ERR(pcie->cfg),
> > + "failed to create ECAM\n");
> > + goto put_pm;
> > + }
> > +
> > + bridge->ops = (struct pci_ops *)&pci_generic_ecam_ops.pci_ops;
> > + bridge->sysdata = pcie->cfg;
> > + pcie->ecam = pcie->cfg->win;
> > +
> > + tegra264_pcie_init(pcie);
> > +
> > + if (!pcie->link_up)
> > + goto free;
>
> goto free_ecam;
It's not clear to me, but are you suggesting to rename the existing
"free" label to "free_ecam"? I can do that.
> > + err = pci_host_probe(bridge);
> > + if (err < 0) {
> > + dev_err(dev, "failed to register host: %pe\n", ERR_PTR(err));
>
> dev_err_probe()
Okay.
>
> > + goto free;
> > + }
> > +
> > + return err;
>
> return 0;
Done.
[...]
> > +static int tegra264_pcie_resume_noirq(struct device *dev)
> > +{
> > + struct tegra264_pcie *pcie = dev_get_drvdata(dev);
> > + int err;
> > +
> > + if (pcie->wake_gpio && device_may_wakeup(dev)) {
> > + err = disable_irq_wake(pcie->wake_irq);
> > + if (err < 0)
> > + dev_err(dev, "failed to disable wake IRQ: %pe\n",
> > + ERR_PTR(err));
> > + }
> > +
> > + if (pcie->link_up == false)
> > + return 0;
> > +
> > + tegra264_pcie_init(pcie);
> > +
>
> Why do you need init() here without deinit() in tegra264_pcie_suspend_noirq()?
That's because when we come out of suspend the link may have gone down
again, so we need to take the endpoint out of reset to retrigger the
link training. I think we could possibly explicitly clear that PERST_O_N
bit in the PERST_CONTROL register in a new tegra264_pcie_deinit() to
mirror what tegra264_pcie_init() does, but it's automatically done by
firmware anyway, so not needed.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 01/19] dt-bindings: display/panel: himax,hx83102: describe Waveshare panel
From: Linus Walleij @ 2026-04-07 9:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Dmitry Baryshkov, 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: <20260402-sticky-wooden-silkworm-5bdff4@quoll>
On Thu, Apr 2, 2026 at 10:30 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Wed, Apr 01, 2026 at 10:26:20AM +0300, Dmitry Baryshkov wrote:
> > + # Waveshare 12.3-DSI-TOUCH-A panel
> > + - waveshare,12.3-dsi-touch-a
>
> I don't think we use '.' in compatibles, so waveshare,12-3-dsi-touch-a
Qualcomm happen to use periods in similar cases for their
"qualcomm universal peripheral":
Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml
I don't know if the policy changed since, but that's a big and widespread
platform and I never saw it challenged so I think it's kind of established
that we do.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 7/8] arm64: dts: qcom: sm8750: Correct and complete DP address spaces
From: Konrad Dybcio @ 2026-04-07 9:40 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kuogee Hsieh, Neil Armstrong, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
Krzysztof Kozlowski, Dmitry Baryshkov
In-Reply-To: <20260405-dts-qcom-display-regs-v2-7-34f4024c65dc@oss.qualcomm.com>
On 4/5/26 4:34 PM, Krzysztof Kozlowski wrote:
> DisplayPort block on Qualcomm SM8750 has few too short address space
> ranges and misses four more spaces. Complete the hardware description,
> which in the future might be important for full feature support.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 6/8] arm64: dts: qcom: sm8650: Correct and complete DP address spaces
From: Konrad Dybcio @ 2026-04-07 9:41 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kuogee Hsieh, Neil Armstrong, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
Krzysztof Kozlowski, Dmitry Baryshkov
In-Reply-To: <20260405-dts-qcom-display-regs-v2-6-34f4024c65dc@oss.qualcomm.com>
On 4/5/26 4:34 PM, Krzysztof Kozlowski wrote:
> DisplayPort block on Qualcomm SM8650 has few too short address space
> ranges and misses four more spaces. Complete the hardware description,
> which in the future might be important for full feature support.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH RFC v2 2/6] drm/msm/adreno: rename llc_mmio to cx_misc_mmio
From: Konrad Dybcio @ 2026-04-07 9:45 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: <20260402-adreno-810-v2-2-ce337ca87a9e@pm.me>
On 4/3/26 1:09 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.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 01/19] dt-bindings: display/panel: himax,hx83102: describe Waveshare panel
From: Krzysztof Kozlowski @ 2026-04-07 9:49 UTC (permalink / raw)
To: Linus Walleij
Cc: Dmitry Baryshkov, 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: <CAD++jL=T9eOXujPSpTp_uNJ2rxN9P9Ybt28+H-YF_=3+_RXCkQ@mail.gmail.com>
On 07/04/2026 11:38, Linus Walleij wrote:
> On Thu, Apr 2, 2026 at 10:30 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Wed, Apr 01, 2026 at 10:26:20AM +0300, Dmitry Baryshkov wrote:
>
>>> + # Waveshare 12.3-DSI-TOUCH-A panel
>>> + - waveshare,12.3-dsi-touch-a
>>
>> I don't think we use '.' in compatibles, so waveshare,12-3-dsi-touch-a
>
> Qualcomm happen to use periods in similar cases for their
> "qualcomm universal peripheral":
> Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml
>
> I don't know if the policy changed since, but that's a big and widespread
> platform and I never saw it challenged so I think it's kind of established
> that we do.
That example is ancient, but you are right that this is widespread
pattern. I wonder why this 'dot' here felt odd - assumed that 'dot' in
version is something else than 'dot' in other place.. dunno, it's fine.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: imx8mp-ab2: Correct interrupt flags
From: Shengjiu Wang @ 2026-04-07 9:49 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Marek Vasut,
Peng Fan, Fedor Ross, Shawn Guo, Shengjiu Wang, Viorel Suman,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260406063810.25531-6-krzysztof.kozlowski@oss.qualcomm.com>
On Mon, Apr 6, 2026 at 2:39 PM Krzysztof Kozlowski
<krzysztof.kozlowski@oss.qualcomm.com> wrote:
>
> GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
> These are simple defines so they could be used in DTS but they will not
> have the same meaning:
> 1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
> 2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
>
> Correct the interrupt flags, assuming the author of the code wanted the
> same logical behavior behind the name "ACTIVE_xxx", this is:
> ACTIVE_LOW => IRQ_TYPE_LEVEL_LOW
>
> Fixes: bf68c18150ef ("arm64: dts: imx8mp-ab2: add support for NXP i.MX8MP audio board (version 2)")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Thanks for the fix.
Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Best regards
Shengjiu Wang
> ---
> arch/arm64/boot/dts/freescale/imx8mp-ab2.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-ab2.dts b/arch/arm64/boot/dts/freescale/imx8mp-ab2.dts
> index dbbc0df0e3d1..443e4fd5b9bf 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-ab2.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-ab2.dts
> @@ -281,7 +281,7 @@ pca9450: pmic@25 {
> compatible = "nxp,pca9450c";
> reg = <0x25>;
> interrupt-parent = <&gpio1>;
> - interrupts = <3 GPIO_ACTIVE_LOW>;
> + interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> pinctrl-0 = <&pinctrl_pmic>;
>
> regulators {
> --
> 2.51.0
>
>
^ permalink raw reply
* Re: [PATCH 01/19] dt-bindings: display/panel: himax,hx83102: describe Waveshare panel
From: Krzysztof Kozlowski @ 2026-04-07 9:50 UTC (permalink / raw)
To: Dmitry Baryshkov, 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, Linus Walleij, Bartosz Golaszewski
Cc: dri-devel, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260401-waveshare-dsi-touch-v1-1-5e9119b5a014@oss.qualcomm.com>
On 01/04/2026 09:26, Dmitry Baryshkov wrote:
> Describe Waveshare 12.3-DSI-TOUCH-A panel which allegedly uses HX83102
> as a panel controller.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml | 2 ++
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 02/19] dt-bindings: display/panel: himax,hx8394: describe Waveshare panel
From: Krzysztof Kozlowski @ 2026-04-07 9:50 UTC (permalink / raw)
To: Dmitry Baryshkov, 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, Linus Walleij, Bartosz Golaszewski
Cc: dri-devel, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260401-waveshare-dsi-touch-v1-2-5e9119b5a014@oss.qualcomm.com>
On 01/04/2026 09:26, Dmitry Baryshkov wrote:
> Describe Waveshare 5" and 5" DSI panels which use HX9365-E as a panel
> controller.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] pinctrl: qcom: add the TLMM driver for the Nord platforms
From: Linus Walleij @ 2026-04-07 9:54 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Bartosz Golaszewski, Shawn Guo, Arnd Bergmann,
linux-arm-msm, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260403-nord-tlmm-v1-2-4864f400c700@oss.qualcomm.com>
Hi Bartosz,
thanks for your patch!
On Fri, Apr 3, 2026 at 3:28 PM Bartosz Golaszewski
<bartosz.golaszewski@oss.qualcomm.com> wrote:
> Add support for the TLMM controller on the Qualcomm Nord platform.
>
> Co-developed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
(...)
> +#define PINGROUP(id, f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11) \
> + { \
> + .grp = PINCTRL_PINGROUP("gpio" #id, \
> + gpio##id##_pins, \
> + ARRAY_SIZE(gpio##id##_pins)), \
> + .ctl_reg = REG_SIZE * id, \
> + .io_reg = 0x4 + REG_SIZE * id, \
> + .intr_cfg_reg = 0x8 + REG_SIZE * id, \
> + .intr_status_reg = 0xc + REG_SIZE * id, \
> + .intr_target_reg = 0x8 + REG_SIZE * id, \
You can drop .intr_target_reg as of:
commit 0720208b37ae4f1193dc7103ee269b180a8f8943
Author: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Date: Fri Mar 27 22:42:40 2026 +0530
pinctrl: qcom: Drop redundant intr_target_reg on modern SoCs
On all Qualcomm TLMM generations from APQ8084 onwards, the interrupt
target routing bits are located in the same register as the interrupt
configuration bits (intr_cfg_reg). Only five older SoCs — APQ8064,
IPQ8064, MDM9615, MSM8660 and MSM8960 — have a genuinely separate
interrupt target routing register at a different offset (0x400 + 0x4 * id).
Replace MSM_ACCESSOR(intr_target) with a custom accessor that falls back
to intr_cfg_reg when intr_target_reg is zero. Apply the same fallback in
the SCM path. Drop the now-redundant .intr_target_reg initializer from
all SoC drivers where it duplicated intr_cfg_reg, keeping it only in
the five drivers where it genuinely differs.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
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