* Re: [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Liu Ying @ 2026-04-08 6:02 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: <adTUkWvqVUhLiw_J@lizhi-Precision-Tower-5810>
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.
[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
^ permalink raw reply
* RE: [PATCH V11 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Sherry Sun @ 2026-04-08 6: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: <lnzprzrdwra7pn7d6m3sbj5pvjy64blwpjl6i3lmlnfbyho63b@czpyhpgz5vum>
> On Tue, Apr 07, 2026 at 06:41:44PM +0800, Sherry Sun wrote:
> > Introduce generic helper functions to parse Root Port device tree
> > nodes and extract common properties like reset GPIOs. This allows
> > multiple PCI host controller drivers to share the same parsing logic.
> >
> > Define struct pci_host_port to hold common Root Port properties
> > (currently only reset GPIO descriptor) and add
> > pci_host_common_parse_ports() to parse Root Port nodes from device
> tree.
> >
> > Also add the 'ports' list to struct pci_host_bridge for better
> > maintain parsed Root Port information.
> >
> > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > ---
> > drivers/pci/controller/pci-host-common.c | 77
> > ++++++++++++++++++++++++ drivers/pci/controller/pci-host-common.h |
> 16 +++++
> > drivers/pci/probe.c | 1 +
> > include/linux/pci.h | 1 +
> > 4 files changed, 95 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pci-host-common.c
> > b/drivers/pci/controller/pci-host-common.c
> > index d6258c1cffe5..0fb6991dde7b 100644
> > --- a/drivers/pci/controller/pci-host-common.c
> > +++ b/drivers/pci/controller/pci-host-common.c
> > @@ -9,6 +9,7 @@
> >
> > #include <linux/kernel.h>
> > #include <linux/module.h>
> > +#include <linux/gpio/consumer.h>
> > #include <linux/of.h>
> > #include <linux/of_address.h>
> > #include <linux/of_pci.h>
> > @@ -17,6 +18,82 @@
> >
> > #include "pci-host-common.h"
> >
> > +/**
> > + * pci_host_common_delete_ports - Cleanup function for port list
> > + * @data: Pointer to the port list head */ void
> > +pci_host_common_delete_ports(void *data) {
> > + struct list_head *ports = data;
> > + struct pci_host_port *port, *tmp;
> > +
> > + list_for_each_entry_safe(port, tmp, ports, list)
> > + list_del(&port->list);
> > +}
> > +EXPORT_SYMBOL_GPL(pci_host_common_delete_ports);
> > +
> > +/**
> > + * pci_host_common_parse_port - Parse a single Root Port node
> > + * @dev: Device pointer
> > + * @bridge: PCI host bridge
> > + * @node: Device tree node of the Root Port
> > + *
> > + * Returns: 0 on success, negative error code on failure */ static
> > +int pci_host_common_parse_port(struct device *dev,
> > + struct pci_host_bridge *bridge,
> > + struct device_node *node)
> > +{
> > + struct pci_host_port *port;
> > + struct gpio_desc *reset;
> > +
> > + reset = devm_fwnode_gpiod_get(dev, of_fwnode_handle(node),
> > + "reset", GPIOD_ASIS, "PERST#");
>
> Sorry, I missed this earlier.
>
> Since PERST# is optional, you cannot reliably detect whether the Root Port
> binding intentionally skipped the PERST# GPIO or legacy binding is used, just
> by checking for PERST# in Root Port node.
>
> So this helper should do 3 things:
>
> 1. If PERST# is found in Root Port node, use it.
> 2. If not, check the RC node and if present, return -ENOENT to fallback to the
> legacy binding.
> 3. If not found in both nodes, assume that the PERST# is not present in the
> design, and proceed with parsing Root Port binding further.
Hi Mani, understand, does the following code looks ok for above three cases?
/* Check if PERST# is present in Root Port node */
reset = devm_fwnode_gpiod_get(dev, of_fwnode_handle(node),
"reset", GPIOD_ASIS, "PERST#");
if (IS_ERR(reset)) {
/* If error is not -ENOENT, it's a real error */
if (PTR_ERR(reset) != -ENOENT)
return PTR_ERR(reset);
/* PERST# not found in Root Port node, check RC node */
rc_has_reset = of_property_read_bool(dev->of_node, "reset-gpios") ||
of_property_read_bool(dev->of_node, "reset-gpio");
if (rc_has_reset)
return -ENOENT;
/* No PERST# in either node, assume not present in design */
reset = NULL;
}
port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
if (!port)
return -ENOMEM;
...
>
> But there is one more important limitation here. Right now, this API only
> handles PERST#. But if another vendor tries to use it and if they need other
> properties such as PHY, clocks etc... those resources should be fetched
> optionally only by this helper. But if the controller has a hard dependency on
> those resources, the driver will fail to operate.
>
> I don't think we can fix this limitation though and those platforms should
> ensure that the resource dependency is correctly modeled in DT binding and
> the DTS is validated properly. It'd be good to mention this in the kernel doc of
> this API.
Ok, I will add a NOTE for this in this API description.
>
> > + if (IS_ERR(reset))
> > + return PTR_ERR(reset);
> > +
> > + 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 0;
> > +}
> > +
> > +/**
> > + * pci_host_common_parse_ports - Parse Root Port nodes from device
> > +tree
> > + * @dev: Device pointer
> > + * @bridge: PCI host bridge
> > + *
> > + * This function iterates through child nodes of the host bridge and
> > +parses
> > + * Root Port properties (currently only reset GPIO).
> > + *
> > + * Returns: 0 on success, -ENOENT if no ports found, other negative
> > +error codes
> > + * on failure
> > + */
> > +int pci_host_common_parse_ports(struct device *dev, struct
> > +pci_host_bridge *bridge) {
> > + int ret = -ENOENT;
> > +
> > + for_each_available_child_of_node_scoped(dev->of_node, of_port) {
> > + if (!of_node_is_type(of_port, "pci"))
> > + continue;
> > + ret = pci_host_common_parse_port(dev, bridge, of_port);
> > + if (ret)
> > + return ret;
>
> As Sashiko flagged, you need to make sure that devm_add_action_or_reset()
> is added even during the error path:
Yes, it needs to be fixed. We can handle it with the following two methods, I am not sure which method is better or more preferable?
#1: register cleanup action after first successful port parse and use cleanup_registered flag to avoid duplicate register.
int ret = -ENOENT;
bool cleanup_registered = false;
for_each_available_child_of_node_scoped(dev->of_node, of_port) {
if (!of_node_is_type(of_port, "pci"))
continue;
ret = pci_host_common_parse_port(dev, bridge, of_port);
if (ret)
return ret;
/* Register cleanup action after first successful port parse */
if (!cleanup_registered) {
ret = devm_add_action_or_reset(dev,
pci_host_common_delete_ports,
&bridge->ports);
if (ret)
return ret;
cleanup_registered = true;
}
}
#2: call devm_add_action to register cleanup action before the loop begins.
ret = devm_add_action(dev, pci_host_common_delete_ports,
&bridge->ports);
if (ret)
return ret;
ret = -ENOENT;
for_each_available_child_of_node_scoped(dev->of_node, of_port) {
if (!of_node_is_type(of_port, "pci"))
continue;
ret = pci_host_common_parse_port(dev, bridge, of_port);
if (ret)
return ret;
}
Best Regards
Sherry
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsashiko
> .dev%2F%23%2Fpatchset%2F20260407104154.2842132-1-
> sherry.sun%2540nxp.com%3Fpart%3D2&data=05%7C02%7Csherry.sun%40nx
> p.com%7Ca19d6997cb63454afd7808de94a961fe%7C686ea1d3bc2b4c6fa92cd
> 99c5c301635%7C0%7C0%7C639111652420710900%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI
> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=P4Vz%2B7kH
> i07bzBnR1w4smYzRWDKPbzQsEcJXqEGyzP4%3D&reserved=0
>
> - Mani
>
> > + }
> > +
> > + if (ret)
> > + return ret;
> > +
> > + return devm_add_action_or_reset(dev,
> pci_host_common_delete_ports,
> > + &bridge->ports);
> > +}
> > +EXPORT_SYMBOL_GPL(pci_host_common_parse_ports);
> > +
> > static void gen_pci_unmap_cfg(void *ptr) {
> > pci_ecam_free((struct pci_config_window *)ptr); diff --git
> > a/drivers/pci/controller/pci-host-common.h
> > b/drivers/pci/controller/pci-host-common.h
> > index b5075d4bd7eb..37714bedb625 100644
> > --- a/drivers/pci/controller/pci-host-common.h
> > +++ b/drivers/pci/controller/pci-host-common.h
> > @@ -12,6 +12,22 @@
> >
> > struct pci_ecam_ops;
> >
> > +/**
> > + * struct pci_host_port - Generic Root Port properties
> > + * @list: List node for linking multiple ports
> > + * @reset: GPIO descriptor for PERST# signal
> > + *
> > + * This structure contains common properties that can be parsed from
> > + * Root Port device tree nodes.
> > + */
> > +struct pci_host_port {
> > + struct list_head list;
> > + struct gpio_desc *reset;
> > +};
> > +
> > +void pci_host_common_delete_ports(void *data); int
> > +pci_host_common_parse_ports(struct device *dev, struct
> > +pci_host_bridge *bridge);
> > +
> > int pci_host_common_probe(struct platform_device *pdev); int
> > pci_host_common_init(struct platform_device *pdev,
> > struct pci_host_bridge *bridge,
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index
> > eaa4a3d662e8..629ae08b7d35 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -677,6 +677,7 @@ static void pci_init_host_bridge(struct
> > pci_host_bridge *bridge) {
> > INIT_LIST_HEAD(&bridge->windows);
> > INIT_LIST_HEAD(&bridge->dma_ranges);
> > + INIT_LIST_HEAD(&bridge->ports);
> >
> > /*
> > * We assume we can manage these PCIe features. Some systems
> may
> > diff --git a/include/linux/pci.h b/include/linux/pci.h index
> > 8f63de38f2d2..a73ea81ce88f 100644
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -636,6 +636,7 @@ struct pci_host_bridge {
> > int domain_nr;
> > struct list_head windows; /* resource_entry */
> > struct list_head dma_ranges; /* dma ranges resource list */
> > + struct list_head ports; /* Root Port list (pci_host_port) */
> > #ifdef CONFIG_PCI_IDE
> > u16 nr_ide_streams; /* Max streams possibly active in
> @ide_stream_ida */
> > struct ida ide_stream_ida;
> > --
> > 2.37.1
> >
>
> --
> மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v21 0/8] Initial support Cadence MHDP8501(HDMI/DP) for i.MX8MQ
From: Krzysztof Kozlowski @ 2026-04-08 6:38 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: imx, Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, dri-devel,
Alexander Stein, Dmitry Baryshkov, Ying Liu, Dmitry Baryshkov,
devicetree, linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <20260407-dcss-hdmi-upstreaming-v21-0-4681070ab82f@oss.nxp.com>
On Tue, Apr 07, 2026 at 02:31:24PM +0000, Laurentiu Palcu wrote:
> From: Sandor Yu <Sandor.yu@nxp.com>
>
> Hi,
>
> Since Sandor left NXP some time back, I'll be taking over this patchset
> and continue the upstreaming process from where he left off.
>
> The patchset adds initial support for Cadence MHDP8501(HDMI/DP) DRM bridge
> and Cadence HDP-TX PHY(HDMI/DP) for Freescale i.MX8MQ.
>
> I addressed all remaining reviewers' comments from v20 but I'm not sure
> whether Alexander's issue is still present. Alexander, let me know if
> you're still experiencing a black screen with this patch-set and I'll
> try to address it in the next revision.
>
> --
> Changes in v21:
> - Dropped "phy: Add HDMI configuration options" patch because it was
> already merged separately;
> - Rebased to latest linux-next (7.0-rc6) and fixed all issues
> introduced by API changes in DRM;
> - Addressed Maxime's comment on patch #5 and used debugfs file instead
> of sysfs for printing firmware version;
> - Addressed all Dmitry's comments: handled the
> cdns_mhdp_mailbox_send_recv_multi() error, removed the RGB 10bit
> unused code, added a dts property in order to get the bridge type (I
> couldn't find another way to do it...);
> - Dropped Krzysztof's r-b tag for patch #4 (which is now patch #3)
> since I added a new property;
Whych property? You really are not supposed to add new properties at
v21. This means your binding was incomplete while being discussed for
~20 revisions.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: dma: arm-dma350: document combined and per-channel IRQ topologies
From: Jun Guo @ 2026-04-08 6:39 UTC (permalink / raw)
To: Rob Herring
Cc: peter.chen, fugang.duan, krzk+dt, conor+dt, vkoul, ychuang3,
schung, robin.murphy, Frank.Li, dmaengine, devicetree,
linux-kernel, cix-kernel-upstream, linux-arm-kernel
In-Reply-To: <20260407172014.GA3090142-robh@kernel.org>
Hi Rob,
Thanks for your review. I have already resubmitted the V6 patch. Please
take a look at the latest v6 patch when you have time, as it includes
considerable changes compared to the v5 version.
On 4/8/2026 1:20 AM, Rob Herring wrote:
> EXTERNAL EMAIL
>
> On Tue, Mar 24, 2026 at 08:01:11PM +0800, Jun Guo wrote:
>> Document the interrupt topologies supported by DMA-350 integration:
>> - one combined interrupt for all channels, or
>> - one interrupt per channel (up to 8 channels).
>>
>> Assisted-by: Cursor:GPT-5.3-Codex
>> Signed-off-by: Jun Guo <jun.guo@cixtech.com>
>> ---
>> .../devicetree/bindings/dma/arm,dma-350.yaml | 25 ++++++++++++-------
>> 1 file changed, 16 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
>> index 429f682f15d8..bec9dc32541b 100644
>> --- a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
>> +++ b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
>> @@ -22,15 +22,22 @@ properties:
>>
>> interrupts:
>> minItems: 1
>> - items:
>> - - description: Channel 0 interrupt
>> - - description: Channel 1 interrupt
>> - - description: Channel 2 interrupt
>> - - description: Channel 3 interrupt
>> - - description: Channel 4 interrupt
>> - - description: Channel 5 interrupt
>> - - description: Channel 6 interrupt
>> - - description: Channel 7 interrupt
>> + maxItems: 8
>
> Don't need maxItems
>
>> + description:
>> + Either one interrupt per channel (8 interrupts), or one
>> + combined interrupt for all channels.
>> + oneOf:
>> + - items:
>> + - description: Channel 0 interrupt
>> + - description: Channel 1 interrupt
>> + - description: Channel 2 interrupt
>> + - description: Channel 3 interrupt
>> + - description: Channel 4 interrupt
>> + - description: Channel 5 interrupt
>> + - description: Channel 6 interrupt
>> + - description: Channel 7 interrupt
>> + - items:
>> + - description: Combined interrupt shared by all channels
>>
>> "#dma-cells":
>> const: 1
>> --
>> 2.34.1
>>
^ permalink raw reply
* [PATCH] drm/exynos/gem: Fix printk specifier for gem_object.size and dma_addr
From: Chen-Yu Tsai @ 2026-04-08 6:49 UTC (permalink / raw)
To: Inki Dae, Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski,
Alim Akhtar
Cc: Chen-Yu Tsai, David Airlie, Simona Vetter, dri-devel,
linux-samsung-soc, linux-arm-kernel, linux-kernel,
kernel test robot
In the recent change to use the GEM base object's size field instead of
the exynos_gem object's additional field, the printk format was not
adjusted for the change to size_t type. This causes a new warning on
platforms on which size_t is not unsigned long.
Fix this by using the correct "%zx" type.
While at it, fix the specifier for dma_addr so that the cast to unsigned
long is not longer needed.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202604081331.jSJQSVmg-lkp@intel.com/
Fixes: 11e898373fba ("drm/exynos: Drop exynos_drm_gem.size field")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
This is only compile tested. Build for ARM 32-bit confirms the warning
is fixed. Sorry for the noise.
The commit hash used in the Fixes tag is the current one seen in
exynos-drm-next.
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index d9d42809a1a9..f264e170bc26 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -66,8 +66,8 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem *exynos_gem, bool kvmap)
if (kvmap)
exynos_gem->kvaddr = exynos_gem->cookie;
- DRM_DEV_DEBUG_KMS(drm_dev_dma_dev(dev), "dma_addr(0x%lx), size(0x%lx)\n",
- (unsigned long)exynos_gem->dma_addr, exynos_gem->base.size);
+ DRM_DEV_DEBUG_KMS(drm_dev_dma_dev(dev), "dma_addr(%pad), size(0x%zx)\n",
+ &exynos_gem->dma_addr, exynos_gem->base.size);
return 0;
}
@@ -80,8 +80,8 @@ static void exynos_drm_free_buf(struct exynos_drm_gem *exynos_gem)
return;
}
- DRM_DEV_DEBUG_KMS(dev->dev, "dma_addr(0x%lx), size(0x%lx)\n",
- (unsigned long)exynos_gem->dma_addr, exynos_gem->base.size);
+ DRM_DEV_DEBUG_KMS(dev->dev, "dma_addr(%pad), size(0x%zx)\n",
+ &exynos_gem->dma_addr, exynos_gem->base.size);
dma_free_attrs(drm_dev_dma_dev(dev), exynos_gem->base.size, exynos_gem->cookie,
(dma_addr_t)exynos_gem->dma_addr,
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* [PATCH] drm/exynos/fimd: fix register offset type in fimd_trigger()
From: Chen-Yu Tsai @ 2026-04-08 6:50 UTC (permalink / raw)
To: Inki Dae, Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski,
Alim Akhtar
Cc: Chen-Yu Tsai, David Airlie, Simona Vetter, dri-devel,
linux-samsung-soc, linux-arm-kernel, linux-kernel
Sparse reports:
exynos_drm_fimd.c:992:39: warning: incorrect type in initializer (different address spaces)
exynos_drm_fimd.c:992:39: expected void *timing_base
exynos_drm_fimd.c:992:39: got void [noderef] __iomem *
exynos_drm_fimd.c:1005:33: warning: incorrect type in argument 1 (different address spaces)
exynos_drm_fimd.c:1005:33: expected void const volatile [noderef] __iomem *addr
exynos_drm_fimd.c:1005:33: got void *
exynos_drm_fimd.c:1007:33: warning: incorrect type in argument 2 (different address spaces)
exynos_drm_fimd.c:1007:33: expected void volatile [noderef] __iomem *addr
exynos_drm_fimd.c:1007:33: got void *
Add "__iomem" to *timing_base to fix its type.
Fixes: 3854fab24e89 ("drm/exynos: fimd: support LCD I80 interface")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
random warning I found while checking for the size_t warning.
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index b6abdc4f2b0a..695d3515d421 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -989,7 +989,7 @@ static void fimd_trigger(struct device *dev)
{
struct fimd_context *ctx = dev_get_drvdata(dev);
const struct fimd_driver_data *driver_data = ctx->driver_data;
- void *timing_base = ctx->regs + driver_data->timing_base;
+ void __iomem *timing_base = ctx->regs + driver_data->timing_base;
u32 reg;
/*
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* RE: [PATCH v4 net-next 03/14] net: enetc: add pre-boot initialization for i.MX94 switch
From: Wei Fang @ 2026-04-08 6:55 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: <20260403011723.1795349-1-kuba@kernel.org>
> > +static int imx94_switch_link_config(struct netc_blk_ctrl *priv,
> > + struct device_node *np,
> > + bool *swp2_en)
> > +{
> > + struct device_node *ports;
> > + int port_id, err = 0;
>
> Since of_property_read_u32() expects a u32 pointer, does passing a
> signed int pointer here trigger an incompatible pointer types warning
> during compilation?
>
Okay, I will change port_id to u32 type.
> > +
> > + ports = netc_get_switch_ports(np);
> > + if (!ports)
> > + return -ENODEV;
> > +
> > + for_each_available_child_of_node_scoped(ports, child) {
> > + if (of_property_read_u32(child, "reg", &port_id) < 0) {
>
> If the device tree provides a reg value with the MSB set, port_id
> would be evaluated as a negative number.
>
> [ ... ]
> > static int imx94_netcmix_init(struct platform_device *pdev)
> > {
> > struct netc_blk_ctrl *priv = platform_get_drvdata(pdev);
> > struct device_node *np = pdev->dev.of_node;
> > + bool enetc0_en = false, swp2_en = false;
> > u32 val;
> > int err;
> >
> > for_each_child_of_node_scoped(np, child) {
> > for_each_child_of_node_scoped(child, gchild) {
> > - if (!of_device_is_compatible(gchild, "pci1131,e101"))
> > - continue;
> > -
> > - err = imx94_enetc_link_config(priv, gchild);
> > - if (err)
> > - return err;
> > + if (of_device_is_compatible(gchild, "pci1131,e101")) {
> > + err = imx94_enetc_link_config(priv, gchild,
> > + &enetc0_en);
> > + if (err)
> > + return err;
> > + } else if (of_device_is_compatible(gchild,
> > + "pci1131,eef2")) {
>
> Is it possible for the switch node to be disabled in the device tree?
>
> If so, should we check of_device_is_available() for gchild before proceeding,
> similar to how it is checked for enetc0_en?
The switch may be owned by a guest OS, in this case, the switch node of the
host OS will be disabled, but we still hope that the host OS could do some
configurations for the switch, as the netc_blk_ctrl is owned by host OS, so
we cannot check of_device_is_available() for the switch node.
>
> Without checking availability, if the disabled switch lacks a ports subnode,
> imx94_switch_link_config() might return -ENODEV and abort the entire probe.
This is the expected behavior, only one of swp2 and enetc0 can be enabled,
as they share the same parallel interface. If all of them are enabled, the driver
will detect this incorrect DTS configuration and return a failure.
> Alternatively, if the disabled switch node has a ports subnode with an
> available port 2, it could spuriously set swp2_en = true and cause a false
> conflict with ENETC 0.
>
> > + err = imx94_switch_link_config(priv, gchild,
> > + &swp2_en);
> > + if (err)
> > + return err;
> > + }
> > }
> > }
^ permalink raw reply
* RE: [PATCH v4 net-next 04/14] net: enetc: add basic operations to the FDB table
From: Wei Fang @ 2026-04-08 7:04 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: <20260403011727.1795379-1-kuba@kernel.org>
> > @@ -116,6 +158,31 @@ static inline int ntmp_rsst_query_entry(struct
> ntmp_user *user,
> > return 0;
> > }
> >
> > +static inline int ntmp_fdbt_add_entry(struct ntmp_user *user, u32 *entry_id,
> > + const struct fdbt_keye_data *keye,
> > + const struct fdbt_cfge_data *data)
> > +{
> > + return 0;
> > +}
>
> If CONFIG_NXP_NETC_LIB is disabled, will returning 0 here cause callers to
> falsely assume the operation succeeded and proceed to use an uninitialized
> entry_id pointer? Would it be safer to return an error code such as
> -EOPNOTSUPP for stubs that have output parameters?
>
The ntmp_fdbt_add_entry() is only called by the netc switch driver,
and the driver will select CONFIG_NXP_NETC_LIB option, so actually
this inline function is not used by any drivers. I suppose such inline
functions could be removed. Thanks.
^ permalink raw reply
* Re: [PATCH net-next v4 1/2] dt-bindings: net: ti: k3-am654-cpsw-nuss: Add ti,j722s-cpsw-nuss compatible
From: Krzysztof Kozlowski @ 2026-04-08 7:06 UTC (permalink / raw)
To: Nora Schiffer
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux
In-Reply-To: <191e9f7e3a6c14eabe891a98c5fb646766479c0a.1775558273.git.nora.schiffer@ew.tq-group.com>
On Tue, Apr 07, 2026 at 12:48:01PM +0200, Nora Schiffer wrote:
> The J722S CPSW3G is mostly identical to the AM64's, but additionally
> supports SGMII. The AM64 compatible ti,am642-cpsw-nuss is used as a
> fallback.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
>
> v2: keep ti,am642-cpsw-nuss as a fallback
> v3: resubmission for net-next, no changes
> v4: remove redundant items: level
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 2/5] dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel compatible
From: Krzysztof Kozlowski @ 2026-04-08 7:06 UTC (permalink / raw)
To: Nora Schiffer
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Siddharth Vadapalli, Roger Quadros,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, netdev,
devicetree, linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <b67c8b0bc9cc918667e9329d79f617d033d025d5.1775559102.git.nora.schiffer@ew.tq-group.com>
On Tue, Apr 07, 2026 at 01:42:34PM +0200, Nora Schiffer wrote:
> The J722S gmii-sel is mostly identical to the AM64's, but additionally
> supports SGMII. The AM64 compatible ti,am654-phy-gmii-sel is used as a
> fallback.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
> .../bindings/phy/ti,phy-gmii-sel.yaml | 23 +++++++++++--------
> 1 file changed, 14 insertions(+), 9 deletions(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
From: Krzysztof Kozlowski @ 2026-04-08 7:07 UTC (permalink / raw)
To: Nora Schiffer
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Siddharth Vadapalli, Roger Quadros,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, netdev,
devicetree, linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <1ef8adf850f2fd41b6c4e3c89e4f4e6e0f469a0e.1775559102.git.nora.schiffer@ew.tq-group.com>
On Tue, Apr 07, 2026 at 01:42:33PM +0200, Nora Schiffer wrote:
> The J722S WIZ is mostly identical to the AM64's, but additionally supports
> SGMII. The AM64 compatible ti,am64-wiz-10g is used as a fallback.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
> .../bindings/phy/ti,phy-j721e-wiz.yaml | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: perf: marvell: Add CN20K DDR PMU binding
From: Krzysztof Kozlowski @ 2026-04-08 7:09 UTC (permalink / raw)
To: Geetha sowjanya
Cc: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree,
mark.rutland, will, krzk+dt
In-Reply-To: <20260407153511.4250-2-gakula@marvell.com>
On Tue, Apr 07, 2026 at 09:05:10PM +0530, Geetha sowjanya wrote:
> Marvell CN20K SoCs integrate a DDR Performance Monitoring Unit (PMU)
> associated with the DDR controller. The block provides hardware counters
> to monitor DDR traffic and performance events and is accessed via a
> dedicated MMIO region.
>
> The CN20K DDR PMU is functionally equivalent to the CN10K DDR PMU, with
> minor register offset differences. This binding documents the CN20K
> variant and introduces a specific compatible string to allow software
> to distinguish between the two implementations.
Drop last sentence, I already asked for that.
>
> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
> ---
> .../bindings/perf/marvell-cn20k-ddr-pmu.yaml | 39 +++++++++++++++++++
Still wrong filename.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v4 net-next 05/14] net: enetc: add support for the "Add" operation to VLAN filter table
From: Wei Fang @ 2026-04-08 7:12 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: <20260403011729.1795413-1-kuba@kernel.org>
> > diff --git a/drivers/net/ethernet/freescale/enetc/ntmp.c
> b/drivers/net/ethernet/freescale/enetc/ntmp.c
> > --- a/drivers/net/ethernet/freescale/enetc/ntmp.c
> > +++ b/drivers/net/ethernet/freescale/enetc/ntmp.c
>
> [ ... ]
>
> > @@ -652,5 +655,52 @@ int ntmp_fdbt_search_port_entry(struct ntmp_user
> *user, int port,
> > +int ntmp_vft_add_entry(struct ntmp_user *user, u16 vid,
> > + const struct vft_cfge_data *cfge)
> > +{
> > + struct ntmp_dma_buf data = {
> > + .dev = user->dev,
> > + .size = sizeof(struct vft_req_ua),
> > + };
> > + struct vft_req_ua *req;
> > + union netc_cbd cbd;
> > + u32 len;
> > + int err;
> > +
> > + err = ntmp_alloc_data_mem(&data, (void **)&req);
> > + if (err)
> > + return err;
> > +
> > + /* Request data */
> > + ntmp_fill_crd(&req->crd, user->tbl.vft_ver, 0,
> > + NTMP_GEN_UA_CFGEU);
> > + req->ak.exact.vid = cpu_to_le16(vid);
> > + req->cfge = *cfge;
> > +
> > + /* Request header */
> > + len = NTMP_LEN(data.size, NTMP_STATUS_RESP_LEN);
> > + ntmp_fill_request_hdr(&cbd, data.dma, len, NTMP_VFT_ID,
> > + NTMP_CMD_ADD, NTMP_AM_EXACT_KEY);
> > +
> > + err = netc_xmit_ntmp_cmd(user, &cbd);
> > + if (err)
> > + dev_err(user->dev,
> > + "Failed to add %s entry, vid: %u, err: %pe\n",
> > + ntmp_table_name(NTMP_VFT_ID), vid, ERR_PTR(err));
> > +
> > + ntmp_free_data_mem(&data);
>
> Does this code safely handle hardware timeouts?
>
> If netc_xmit_ntmp_cmd() times out and returns an error, the pending
> transaction is not explicitly aborted before ntmp_free_data_mem()
> unconditionally frees the DMA buffer.
>
> Could the hardware eventually process the pending command and perform a
> DMA write of the response to the physical address of the freed buffer?
>
> This might lead to silent memory corruption if that memory has already
> been reallocated to another subsystem. Would it be safer to explicitly
> abort the pending DMA transaction, reset the device on timeout, or
> intentionally delay freeing the buffer until it is proven safe?
This is indeed a potential issue, I will add a patch to fix it.
^ permalink raw reply
* RE: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Ryan Chen @ 2026-04-08 7:18 UTC (permalink / raw)
To: Rob Herring
Cc: Jeremy Kerr, Krzysztof Kozlowski,
andriy.shevchenko@linux.intel.com, Andi Shyti,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Philipp Zabel, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <20260407204402.GA3641251-robh@kernel.org>
> Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs
> and enable-dma properties
>
> On Tue, Mar 31, 2026 at 07:30:58AM +0000, Ryan Chen wrote:
> > > Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add
> > > global-regs and enable-dma properties
> > >
> > > Hi Ryan,
> > >
> > > > > Sounds reasonable, but before you do so, how are you planning to
> > > > > manage the allocation of DMA channels across multiple i2c
> peripherals?
> > > > >
> > > > The AST2600 I2C hardware has only one can use DMA at a time.
> > > > To avoid the complexity of managing DMA channel contention, I plan
> > > > to use buffer mode by default for all controllers, which still
> > > > provides better performance than byte mode without requiring DMA
> > > > channel
> > > allocation.
> > >
> > > OK, but your wording there ("by default") implies that DMA is still
> > > selectable for one controller peripheral. In which case: you still
> > > have the problem of managing DMA channel contention, but now it's at
> runtime instead.
> > >
> > > So my question still stands: how are you planning to enforce that
> > > DMA is only enabled for one controller?
> > >
> > > Or are you planning to disable I2C DMA entirely on AST2600?
> > Yes, This is my intent to do.
> > Disable I2C DMA entirely on AST2600.
> > If I remove DMA, should can I keep byte and buffer for sysfs?
>
> 28 versions and it's still not clear when you need what mode. Sigh. The only
> thing better about sysfs then it's not my problem, but that really doesn't sound
> much better.
>
> DMA is only going to be useful for transfers above a certain size. If you are
> doing the typical SMBus style register accesses, then DMA is completely
> useless. The setup DMA overhead is going to be greater than just directly
> reading/writing the I2C controller FIFOs.
Sorry, why you think DMA overhead is greater than read/write FIFO?
When enable DMA, all dma allocate will be initial in probe.
And the DMA mode data is going to dram, that will be read/write data from
dram. Compare with buffer mode, data is from FIFO register to read/write.
So DMA will not have overhead.
> What's the size that makes DMA
> useful? 16, 32, 64 bytes?
The i2c ast2600 can be 4096 byte for each tx/rx dma,
buffer mode is 32byte (16 byte for TX, 16 byte for RX).
>Something greater than the max size in buffer mode
> probably. Really, provide some data that DMA gives better performance
> and/or less CPU usage.
In general i2c transfer len < buffer size. dma did not gain.
But if large than buffer size (16 byte), it will reduce the cpu interrupt latency.
For example, mctp transfer :
https://github.com/torvalds/linux/blob/master/drivers/net/mctp/mctp-i2c.c#L29
mctp max len is 256, that will 1 interrupt for each package transfer.
But in fifo mode will be 256/16 = 16 interrupts.
Compare the smbus I2C_SMBUS_BLOCK_MAX is 32 byte + 2
https://github.com/torvalds/linux/blob/master/include/uapi/linux/i2c.h#L145
That is only (32 + 2)/16 = 2~3 interrupts. It may not gain more.
>If you set some minimum size and request DMA only
> above that size, is there really that much contention?
Sorry, I don't know your point here, could you give more your statement?
> If there's some specific
> device that really needs DMA, then make that device's driver request it and
> reserve it.
>
> For byte mode, there's not a clear need nor description of why. Someone once
> long ago asked for it... Who cares, if they really want it, then the issue needs to
> be described. If a certain device requires certain timing that byte mode
> provides, then that should be some property the driver for the device
> communicates to the controller. No need for DT nor sysfs in that case.
>
I agree with your point.
My proposal will remove byte mode. And keep dma/buffer. And remove sysfs for
transfer mode selection, default will be buffer mode. And keep properties
aspeed,enable-dma, which indicate the channel have DMA capability to use.
And if dts add aspeed,enable-dma, the i2c will use DMA otherwise will keep buffer
transfer, is it ok?
^ permalink raw reply
* [PATCH RESEND] arm64: dts: apple: fix spelling error
From: Axel Flordal @ 2026-04-08 7:21 UTC (permalink / raw)
To: asahi, linux-arm-kernel, devicetree, linux-kernel
Cc: Sven Peter, Janne Grunau, Neal Gompa, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Change "configiguration" to "configuration".
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Axel Flordal <axel@flordal.net>
---
Original patch: https://lore.kernel.org/asahi/CAEg-Je-KwNNGoi3mpPeNq3Jmtzj_5seuj1Qeh2_1dt994iCJSA@mail.gmail.com/T/#t
If this is unwanted I of course won't send again.
---
arch/arm64/boot/dts/apple/spi1-nvram.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/apple/spi1-nvram.dtsi b/arch/arm64/boot/dts/apple/spi1-nvram.dtsi
index 9740fbf200f0..d2720b307774 100644
--- a/arch/arm64/boot/dts/apple/spi1-nvram.dtsi
+++ b/arch/arm64/boot/dts/apple/spi1-nvram.dtsi
@@ -2,7 +2,7 @@
//
// Devicetree include for common spi-nor nvram flash.
//
-// Apple uses a consistent configiguration for the nvram on all known M1* and
+// Apple uses a consistent configuration for the nvram on all known M1* and
// M2* devices.
//
// Copyright The Asahi Linux Contributors
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] interconnect: imx: fix use-after-free in imx_icc_node_init_qos()
From: Frank Li @ 2026-04-08 7:24 UTC (permalink / raw)
To: Wentao Liang
Cc: Georgi Djakov, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-pm, imx, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <20260408031004.309483-1-vulab@iscas.ac.cn>
On Wed, Apr 08, 2026 at 03:10:04AM +0000, Wentao Liang wrote:
> Move of_node_put(dn) after the last use of dn, and add a missing put
> in the error path to avoid both use-after-free and reference leak.
>
> Fixes: f0d8048525d7 ("interconnect: Add imx core driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> drivers/interconnect/imx/imx.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/interconnect/imx/imx.c b/drivers/interconnect/imx/imx.c
> index 9511f80cf041..75431b5ccef8 100644
> --- a/drivers/interconnect/imx/imx.c
> +++ b/drivers/interconnect/imx/imx.c
> @@ -143,15 +143,16 @@ static int imx_icc_node_init_qos(struct icc_provider *provider,
> }
>
Please use auto cleanup to fix this problem
struct device_node * __free(device_nod) dn = of_parse_phandle(dev->of_node, adj->phandle_name, 0);
Frank
> pdev = of_find_device_by_node(dn);
> - of_node_put(dn);
> if (!pdev) {
> dev_warn(dev, "node %s[%d] missing device for %pOF\n",
> node->name, node->id, dn);
> + of_node_put(dn);
> return -EPROBE_DEFER;
> }
> node_data->qos_dev = &pdev->dev;
> dev_dbg(dev, "node %s[%d] has device node %pOF\n",
> node->name, node->id, dn);
> + of_node_put(dn);
> }
>
> return dev_pm_qos_add_request(node_data->qos_dev,
> --
> 2.34.1
>
^ permalink raw reply
* RE: [PATCH v4 net-next 06/14] net: enetc: add support for the "Update" operation to buffer pool table
From: Wei Fang @ 2026-04-08 7:25 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: <20260403011731.1795517-1-kuba@kernel.org>
> > @@ -702,5 +708,38 @@ int ntmp_vft_add_entry(struct ntmp_user *user,
> u16 vid,
> > }
> > EXPORT_SYMBOL_GPL(ntmp_vft_add_entry);
> >
> > +int ntmp_bpt_update_entry(struct ntmp_user *user, u32 entry_id,
> > + const struct bpt_cfge_data *cfge)
> > +{
> > + struct ntmp_dma_buf data = {
> > + .dev = user->dev,
> > + .size = sizeof(struct bpt_req_update),
> > + };
> > + struct bpt_req_update *req;
> > + union netc_cbd cbd;
> > + int err;
> > +
> > + err = ntmp_alloc_data_mem(&data, (void **)&req);
> > + if (err)
> > + return err;
> > +
> > + ntmp_fill_crd_eid(&req->rbe, user->tbl.bpt_ver, 0,
> > + NTMP_GEN_UA_CFGEU | BPT_UA_BPSEU, entry_id);
>
> Does this update action mask match the size of the request buffer?
>
> The mask includes both NTMP_GEN_UA_CFGEU and BPT_UA_BPSEU, which
> instructs
> the hardware to update both the configuration entry and the status entry.
> However, struct bpt_req_update only contains the configuration data,
> omitting the status data.
>
> If the hardware attempts to read the missing BPSE data, could it reject
> the command due to an undersized request length, or read beyond the
> intended payload into zero-initialized DMA padding? This might overwrite
> critical buffer pool tracking variables like amount_used_hwm.
>
> If only the configuration is being updated, should the BPT_UA_BPSEU flag
> be removed?
The BPSE_DATA is a set of statistics and status records kept by the hardware
(internal buffer), and does not require the user to provide additional data to
the hardware for updates. Therefore, for the 'update' operation, the request
buffer does not need to provide BPSE_DATA data.
^ permalink raw reply
* Re: [PATCH v2 4/4] arm64: dts: realtek: Add GPIO support for RTD1625
From: Bartosz Golaszewski @ 2026-04-08 7:28 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, james.tai, linusw,
brgl, robh, krzk+dt, conor+dt, afaerber, tychang
In-Reply-To: <20260408025243.1155482-5-eleanor.lin@realtek.com>
On Wed, 8 Apr 2026 04:52:43 +0200, Yu-Chun Lin <eleanor.lin@realtek.com> said:
> Add the GPIO node for the Realtek RTD1625 SoC.
>
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] interconnect: imx: fix use-after-free in imx_icc_node_init_qos()
From: Markus Elfring @ 2026-04-08 7:28 UTC (permalink / raw)
To: vulab, imx, linux-pm, linux-arm-kernel, Georgi Djakov,
Sascha Hauer, Shawn Guo
Cc: kernel, stable, LKML, Fabio Estevam
In-Reply-To: <20260408031004.309483-1-vulab@iscas.ac.cn>
> Move of_node_put(dn) after the last use of dn, and add a missing put
> in the error path to avoid both use-after-free and reference leak.
How do you think about to increase the application of scope-based resource management?
https://elixir.bootlin.com/linux/v7.0-rc7/source/include/linux/of.h#L138
https://elixir.bootlin.com/linux/v7.0-rc7/source/drivers/interconnect/imx/imx.c#L117-L160
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Bartosz Golaszewski @ 2026-04-08 7:31 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, james.tai, linusw,
brgl, robh, krzk+dt, conor+dt, afaerber, tychang
In-Reply-To: <20260408025243.1155482-4-eleanor.lin@realtek.com>
On Wed, 8 Apr 2026 04:52:42 +0200, Yu-Chun Lin <eleanor.lin@realtek.com> said:
> From: Tzuyi Chang <tychang@realtek.com>
>
> Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs.
>
> Unlike the existing Realtek GPIO driver (drivers/gpio/gpio-rtd.c),
> which manages pins via shared bank registers, the RTD1625 introduces
> a per-pin register architecture. Each GPIO line now has its own
> dedicated 32-bit control register to manage configuration independently,
> including direction, output value, input value, interrupt enable, and
> debounce. Therefore, this distinct hardware design requires a separate
> driver.
>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Signed-off-by: Tzuyi Chang <tychang@realtek.com>
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> ---
> Changes in v2:
> - Remove "default y".
> - Add base_offset member to struct rtd1625_gpio_info to handle merged regions.
> ---
> drivers/gpio/Kconfig | 11 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-rtd1625.c | 584 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 596 insertions(+)
> create mode 100644 drivers/gpio/gpio-rtd1625.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 5ee11a889867..281549ad72ac 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -638,6 +638,17 @@ config GPIO_RTD
> Say yes here to support GPIO functionality and GPIO interrupt on
> Realtek DHC SoCs.
>
> +config GPIO_RTD1625
> + tristate "Realtek DHC RTD1625 GPIO support"
> + depends on ARCH_REALTEK || COMPILE_TEST
> + select GPIOLIB_IRQCHIP
> + help
> + This option enables support for the GPIO controller on Realtek
> + DHC (Digital Home Center) RTD1625 SoC.
> +
> + Say yes here to support both basic GPIO line functionality
> + and GPIO interrupt handling capabilities for this platform.
> +
> config GPIO_SAMA5D2_PIOBU
> tristate "SAMA5D2 PIOBU GPIO support"
> depends on MFD_SYSCON
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index c05f7d795c43..c95ba218d53a 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -159,6 +159,7 @@ obj-$(CONFIG_GPIO_REALTEK_OTTO) += gpio-realtek-otto.o
> obj-$(CONFIG_GPIO_REG) += gpio-reg.o
> obj-$(CONFIG_GPIO_ROCKCHIP) += gpio-rockchip.o
> obj-$(CONFIG_GPIO_RTD) += gpio-rtd.o
> +obj-$(CONFIG_GPIO_RTD1625) += gpio-rtd1625.o
> obj-$(CONFIG_ARCH_SA1100) += gpio-sa1100.o
> obj-$(CONFIG_GPIO_SAMA5D2_PIOBU) += gpio-sama5d2-piobu.o
> obj-$(CONFIG_GPIO_SCH311X) += gpio-sch311x.o
> diff --git a/drivers/gpio/gpio-rtd1625.c b/drivers/gpio/gpio-rtd1625.c
> new file mode 100644
> index 000000000000..bcc1bbb115fa
> --- /dev/null
> +++ b/drivers/gpio/gpio-rtd1625.c
> @@ -0,0 +1,584 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Realtek DHC RTD1625 gpio driver
> + *
> + * Copyright (c) 2023 Realtek Semiconductor Corp.
No modifications since 2023?
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bitops.h>
> +#include <linux/gpio/driver.h>
> +#include <linux/interrupt.h>
> +#include <linux/irqchip.h>
> +#include <linux/irqchip/chained_irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/spinlock.h>
> +#include <linux/types.h>
> +
> +#define RTD1625_GPIO_DIR BIT(0)
> +#define RTD1625_GPIO_OUT BIT(2)
> +#define RTD1625_GPIO_IN BIT(4)
> +#define RTD1625_GPIO_EDGE_INT_DP BIT(6)
> +#define RTD1625_GPIO_EDGE_INT_EN BIT(8)
> +#define RTD1625_GPIO_LEVEL_INT_EN BIT(16)
> +#define RTD1625_GPIO_LEVEL_INT_DP BIT(18)
> +#define RTD1625_GPIO_DEBOUNCE GENMASK(30, 28)
> +#define RTD1625_GPIO_DEBOUNCE_WREN BIT(31)
> +
> +#define RTD1625_GPIO_WREN(x) ((x) << 1)
> +
> +/* Write-enable masks for all GPIO configs and reserved hardware bits */
> +#define RTD1625_ISO_GPIO_WREN_ALL 0x8000aa8a
> +#define RTD1625_ISOM_GPIO_WREN_ALL 0x800aaa8a
> +
> +#define RTD1625_GPIO_DEBOUNCE_1US 0
> +#define RTD1625_GPIO_DEBOUNCE_10US 1
> +#define RTD1625_GPIO_DEBOUNCE_100US 2
> +#define RTD1625_GPIO_DEBOUNCE_1MS 3
> +#define RTD1625_GPIO_DEBOUNCE_10MS 4
> +#define RTD1625_GPIO_DEBOUNCE_20MS 5
> +#define RTD1625_GPIO_DEBOUNCE_30MS 6
> +#define RTD1625_GPIO_DEBOUNCE_50MS 7
> +
> +#define GPIO_CONTROL(gpio) ((gpio) * 4)
> +
> +/**
> + * struct rtd1625_gpio_info - Specific GPIO register information
> + * @num_gpios: The number of GPIOs
> + * @irq_type_support: Supported IRQ types
> + * @gpa_offset: Offset for GPIO assert interrupt status registers
> + * @gpda_offset: Offset for GPIO deassert interrupt status registers
> + * @level_offset: Offset of level interrupt status register
> + * @write_en_all: Write-enable mask for all configurable bits
> + */
> +struct rtd1625_gpio_info {
> + unsigned int num_gpios;
> + unsigned int irq_type_support;
> + unsigned int base_offset;
> + unsigned int gpa_offset;
> + unsigned int gpda_offset;
> + unsigned int level_offset;
> + unsigned int write_en_all;
> +};
Please remove the tabs in the above struct.
> +
> +struct rtd1625_gpio {
> + struct gpio_chip gpio_chip;
> + const struct rtd1625_gpio_info *info;
> + void __iomem *base;
> + void __iomem *irq_base;
> + unsigned int irqs[3];
> + raw_spinlock_t lock;
> + unsigned int *save_regs;
> +};
I'd also personally remove these tabs here but won't die on that hill.
> +
> +static unsigned int rtd1625_gpio_gpa_offset(struct rtd1625_gpio *data, unsigned int offset)
> +{
> + return data->info->gpa_offset + ((offset / 32) * 4);
> +}
> +
> +static unsigned int rtd1625_gpio_gpda_offset(struct rtd1625_gpio *data, unsigned int offset)
> +{
> + return data->info->gpda_offset + ((offset / 32) * 4);
> +}
> +
> +static unsigned int rtd1625_gpio_level_offset(struct rtd1625_gpio *data, unsigned int offset)
> +{
> + return data->info->level_offset + ((offset / 32) * 4);
> +}
Looking at these, I'm under the impression that this driver could quite easily
be converted to using gpio-mmio or even gpio-regmap with an MMIO regmap, have
you looked into it by any chance?
Bart
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: clock: qcom: Add video clock controller on Eliza SoC
From: Taniya Das @ 2026-04-08 7:36 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Vladimir Zapolskiy
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <4c4e80be-4aeb-4275-977f-b3f8c6ab26b0@oss.qualcomm.com>
On 4/7/2026 7:10 PM, Krzysztof Kozlowski wrote:
> On 17/03/2026 18:14, Taniya Das wrote:
>> Add compatible string for Eliza video clock controller and the bindings
>> for Eliza Qualcomm SoC.
>>
>> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
>> ---
>> .../bindings/clock/qcom,sm8450-videocc.yaml | 16 ++++++++++
>> include/dt-bindings/clock/qcom,eliza-videocc.h | 37 ++++++++++++++++++++++
>> 2 files changed, 53 insertions(+)
>>
>
> Although I already suggested that this was not tested (and you never
> replied where did you test it), but I also checked and this fails checks
> - constraints are mismatched now.
I will update the bindings for videocc.
--
Thanks,
Taniya Das
^ permalink raw reply
* RE: [PATCH v4 net-next 07/14] net: enetc: add support for "Add" and "Delete" operations to IPFT
From: Wei Fang @ 2026-04-08 7:37 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: <20260403011734.1795551-1-kuba@kernel.org>
> > +int ntmp_ipft_add_entry(struct ntmp_user *user,
> > + struct ipft_entry_data *entry)
> > +{
> [ ... ]
> > + err = ntmp_alloc_data_mem(&data, (void **)&req);
> > + if (err)
> > + return err;
> > +
> > + ntmp_fill_crd(&req->crd, user->tbl.ipft_ver, NTMP_QA_ENTRY_ID,
> > + NTMP_GEN_UA_CFGEU | NTMP_GEN_UA_STSEU);
> > + req->ak.keye = entry->keye;
> > + req->cfge = entry->cfge;
>
> The request sets NTMP_GEN_UA_STSEU to indicate statistics data is present,
> but struct ipft_req_ua does not appear to contain a match_count or STSE data
> field before cfge.
>
> Since the hardware expects STSE data before CFGE data (as seen in
> struct ipft_resp_query), will this cause the hardware to misinterpret the
> first 8 bytes of cfge as the match_count, and then read the actual filter
> configuration from out-of-bounds or uninitialized memory?
Based on NETC manual, the STSE_DATA is present only for the commands
which perform a query. So for the 'add' command, we do not need to
provide the STSE_DATA buffer. And STSE_DATA is the statistics of the
entry, which is stored in the internal buffer of IPF table. Performing
NTMP_GEN_UA_STSEU is to reset the statistic counter when adding
an entry.
[...]
> > +struct ipft_pld_byte {
> > + u8 data;
> > + u8 mask;
> > +};
> > +
> > +struct ipft_keye_data {
> > + __le16 precedence;
> > + __le16 resv0[3];
> > + __le16 frm_attr_flags;
> > +#define IPFT_FAF_OVLAN BIT(2)
> > +#define IPFT_FAF_IVLAN BIT(3)
> > +#define IPFT_FAF_IP_HDR BIT(7)
> > +#define IPFT_FAF_IP_VER6 BIT(8)
> > +#define IPFT_FAF_L4_CODE GENMASK(11, 10)
> > +#define IPFT_FAF_TCP_HDR 1
> > +#define IPFT_FAF_UDP_HDR 2
> > +#define IPFT_FAF_SCTP_HDR 3
> > +#define IPFT_FAF_WOL_MAGIC BIT(12)
> > + __le16 frm_attr_flags_mask;
> > + __le16 dscp;
> > +#define IPFT_DSCP GENMASK(5, 0)
> > +#define IPFT_DSCP_MASK GENMASK(11, 0)
>
> Does IPFT_DSCP_MASK completely overlap with IPFT_DSCP?
>
> If it is defined as GENMASK(11, 0) instead of GENMASK(11, 6), using
> FIELD_PREP with this mask will not shift the value into the upper bits,
> which might overwrite the actual DSCP value in bits 0-5.
Thanks, this is a bug, I will fix it.
^ permalink raw reply
* Re: [PATCH] arm64: clear_page[s] using memset
From: Linus Walleij @ 2026-04-08 7:47 UTC (permalink / raw)
To: Catalin Marinas, Ryan Roberts
Cc: Will Deacon, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, linux-arm-kernel, kvmarm
In-Reply-To: <adULAT2xus5z3HdQ@arm.com>
On Tue, Apr 7, 2026 at 3:47 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Tue, Apr 07, 2026 at 11:25:55AM +0200, Linus Walleij wrote:
> > Quoting my own commit message hehe:
> >
> > > No performance regressions can be seen, the fastpath
> > > benchmarks differences are in the noise.
> >
> > This was tested on hardware with Ryan Robert's fastpath tool.
>
> BTW, have you tried the perf bench mmap test again with the new
> clear_page? Both with single page and multiple pages scenarios. And
> ideally on more than one platform.
>
> Will pointed out (in a private chat) that current clear_page() uses
> non-temporal stores while memset() doesn't. It may not make any
> difference in practice but it would be good to have some numbers.
Hm interesting point, the perf bench mmap test isn't specifically
in fastpath but since it tends to come up I guess we can add it?
Ryan: is it easy to add this test to fastpath? Or easy for me to do
myself? I looked at the instructions but they were a bit intimidating...
The test is the following:
We boot the kernel with cmdline like this:
"default_hugepagesz=1G hugepagesz=1G hugepages=32" to make sure
we have ample hugepages. This was then tested with the same
cmdline as the original series:
perf bench mem mmap -p 1GB -f demand -s 32GB -l 5
The first run was discarded as the memory hierarchy is cold on
the first run. Then I ran the above command 5 times and averaged
the throughput
The x86 commit cb431accb36e51b64ce34b5cc4d5ed292895fd84
also mentions this test:
perf bench mem memset -k 1GB -f default -s 16GB
I tried it on QEMU, no real benefits with either the previous or this
patch, and no regressions either. (x86 passes -f x86-64-stosq
which are some optimized memset instructions)
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] dmaengine: lpc18xx-dmamux: simplify allocation
From: Frank Li @ 2026-04-08 7:48 UTC (permalink / raw)
To: Rosen Penev
Cc: dmaengine, Vinod Koul, Frank Li, Vladimir Zapolskiy, Kees Cook,
Gustavo A. R. Silva, moderated list:ARM/LPC18XX ARCHITECTURE,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260407035132.99037-1-rosenp@gmail.com>
On Mon, Apr 06, 2026 at 08:51:32PM -0700, Rosen Penev wrote:
Subject need descript summary.
dmaengine: lpc18xx-dmamux: use flexible array to simplify allocation
Frank
^ permalink raw reply
* [PATCH 0/3] arm-smmu-v3: Add PMCG child support and update PMU MMIO mapping
From: Peng Fan (OSS) @ 2026-04-08 7:51 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mark Rutland
Cc: linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-perf-users, Peng Fan
This patch series adds proper support for describing and probing the
Arm SMMU v3 PMCG (Performance Monitor Control Group) as a child node of
the SMMU in Devicetree, and updates the relevant drivers accordingly.
The SMMU v3 architecture allows an optional PMCG block, typically
associated with TCUs, to be implemented within the SMMU register
address space. For example, mmu700 PMCG is at the offset 0x2000 of the
TCU page 0.
Patch 1 updates the SMMU v3 Devicetree binding to allow PMCG child nodes,
referencing the existing arm,smmu-v3-pmcg binding.
Patch 2 updates the arm-smmu-v3 driver to populate platform devices for
child nodes described in DT once the SMMU probe succeeds.
Patch 3 updates the SMMUv3 PMU driver to correctly handle MMIO mapping when
PMCG is described as a child node. The PMCG registers occupy a sub-region
of the parent SMMU MMIO window, which is already requested by the SMMU
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Peng Fan (3):
dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
iommu/arm-smmu-v3: Populate PMU child devices from Devicetree
perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG
.../devicetree/bindings/iommu/arm,smmu-v3.yaml | 10 ++++++++++
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 +++
drivers/perf/arm_smmuv3_pmu.c | 19 ++++++++++++++++---
3 files changed, 29 insertions(+), 3 deletions(-)
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260408-smmu-perf-754367fe66c8
Best regards,
--
Peng Fan <peng.fan@nxp.com>
^ 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