* Re: [PATCH] Bluetooth: btmtk: hide unused btmtk_mt6639_devs[] array
From: patchwork-bot+bluetooth @ 2026-04-02 17:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: marcel, luiz.dentz, matthias.bgg, angelogioacchino.delregno,
floss, arnd, chris.lu, kees, johan, sean.wang, jiande.lu,
linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260402141119.2732591-1-arnd@kernel.org>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Thu, 2 Apr 2026 16:11:15 +0200 you wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> When USB support is disabled, the array is not referenced anywhere,
> causing a warning:
>
> drivers/bluetooth/btmtk.c:35:3: error: 'btmtk_mt6639_devs' defined but not used [-Werror=unused-const-variable=]
> 35 | } btmtk_mt6639_devs[] = {
> | ^~~~~~~~~~~~~~~~~
>
> [...]
Here is the summary with links:
- Bluetooth: btmtk: hide unused btmtk_mt6639_devs[] array
https://git.kernel.org/bluetooth/bluetooth-next/c/a6e00a811c87
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v4 0/2] stmmac crash/stall fixes when under memory pressure
From: Sam Edwards @ 2026-04-02 17:39 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, Maxime Chevallier,
Ovidiu Panait, Vladimir Oltean, Baruch Siach, Serge Semin,
Giuseppe Cavallaro, netdev, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <ac6kfQ98Xjt3dCGj@shell.armlinux.org.uk>
On Thu, Apr 2, 2026 at 10:16 AM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
> I've tested this on my Jetson Xavier platform. One of the issues I've
> had is that running iperf3 results in the receive side stalling because
> it runs out of descriptors. However, despite the receive ring
> eventually being re-filled and the hardware appropriately prodded, it
> steadfastly refuses to restart, despite the descriptors having been
> updated.
Hi Russell,
Just to make sure I understand correctly: before my patches, you've
been observing this problem on Xavier for a while (no interrupts, ring
goes dry); with my patches, the ring is refilled, but the dwmac5
doesn't resume DMA. (Ah, just saw your follow-up email.)
> Any ideas?
Off the top of my head, my hypothesis is that dwmac5 has an additional
tripwire when the receive DMA is exhausted, and the
stmmac_set_rx_tail_ptr()/stmmac_enable_dma_reception() at the end of
stmmac_rx_refill() aren't sufficient to wake it back up.
I think this is new to dwmac5, because my RK3588 (dwmac4.20 iirc)
happily resumes after the same condition.
You gave a lot of info; thanks! I'll try to scrape up some
documentation on dwmac5 to see if there's something more
stmmac_rx_refill() ought to be doing. I think I have a Xavier NX
around here somewhere, I'll see if I can repro the problem.
Cheers,
Sam
^ permalink raw reply
* Re: [PATCH v5 4/4] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
From: Dmitry Torokhov @ 2026-04-02 17:32 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Kevin Hilman, Arnd Bergmann, brgl, driver-core, linux-kernel,
linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <20260402-nokia770-gpio-swnodes-v5-4-d730db3dd299@oss.qualcomm.com>
On Thu, Apr 02, 2026 at 04:15:05PM +0200, Bartosz Golaszewski wrote:
> @@ -244,6 +263,13 @@ static int __init omap16xx_gpio_init(void)
> iounmap(base);
>
> platform_device_register(omap16xx_gpio_dev[i]);
> +
> + ret = device_add_software_node(&omap16xx_gpio_dev[i]->dev,
> + omap16xx_gpio_swnodes[i]);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to add software node.\n");
> + return ret;
> + }
I think the best and safest way is to convert to using
platform_driver_register_full() and set swnode in the relevant "info"
instance.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 3/4] PCI: tegra: Add Tegra264 support
From: Manivannan Sadhasivam @ 2026-04-02 17:32 UTC (permalink / raw)
To: Thierry Reding
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: <20260402-tegra264-pcie-v4-3-21e2e19987e8@nvidia.com>
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.
> ---
> Changes in v2:
> - specify generations applicable for PCI_TEGRA driver to avoid confusion
> - drop SPDX-FileCopyrightText tag
> - rename link_state to link_up to clarify meaning
> - replace memset() by an empty initializer
> - sanity-check only enable BAR regions
> - bring PCI link out of reset in case firmware didn't
> - use common wait times instead of defining our own
> - use core helpers to parse and print PCI link speed
> - fix multi-line comment
> - use dev_err_probe() more ubiquitously
> - fix probe sequence and error cleanup
> - use DEFINE_NOIRQ_DEV_PM_OPS() to avoid warnings for !PM_SUSPEND
> - reuse more standard registers and remove unused register definitions
> - use %pe and ERR_PTR() to print symbolic errors
> - add signed-off-by from Manikanta as the original author
> - add myself as author after significantly modifying the driver
> ---
> drivers/pci/controller/Kconfig | 10 +-
> drivers/pci/controller/Makefile | 1 +
> drivers/pci/controller/pcie-tegra264.c | 527 +++++++++++++++++++++++++++++++++
> 3 files changed, 537 insertions(+), 1 deletion(-)
>
> 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.
> + depends on ARCH_TEGRA || COMPILE_TEST
> + depends on PCI_MSI
Why?
> + help
> + Say Y here if you want support for the PCIe host controller found
> + on NVIDIA Tegra264 SoCs.
>
> config PCIE_RCAR_HOST
> bool "Renesas R-Car PCIe controller (host mode)"
> diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
> index ac8db283f0fe..d478743b5142 100644
> --- a/drivers/pci/controller/Makefile
> +++ b/drivers/pci/controller/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_PCI_HYPERV_INTERFACE) += pci-hyperv-intf.o
> obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
> obj-$(CONFIG_PCI_AARDVARK) += pci-aardvark.o
> obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
> +obj-$(CONFIG_PCIE_TEGRA264) += pcie-tegra264.o
> obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
> obj-$(CONFIG_PCIE_RCAR_HOST) += pcie-rcar.o pcie-rcar-host.o
> obj-$(CONFIG_PCIE_RCAR_EP) += pcie-rcar.o pcie-rcar-ep.o
> 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
> @@ -0,0 +1,527 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * PCIe host controller driver for Tegra264 SoC
> + *
> + * Copyright (c) 2022-2026, NVIDIA CORPORATION. All rights reserved.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/init.h>
> +#include <linux/interconnect.h>
> +#include <linux/interrupt.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/of.h>
> +#include <linux/of_pci.h>
> +#include <linux/of_platform.h>
> +#include <linux/pci-ecam.h>
> +#include <linux/pci.h>
> +#include <linux/pinctrl/consumer.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +
> +#include <soc/tegra/bpmp.h>
> +#include <soc/tegra/bpmp-abi.h>
> +#include <soc/tegra/fuse.h>
> +
> +#include "../pci.h"
> +
> +/* XAL registers */
> +#define XAL_RC_ECAM_BASE_HI 0x00
> +#define XAL_RC_ECAM_BASE_LO 0x04
> +#define XAL_RC_ECAM_BUSMASK 0x08
> +#define XAL_RC_IO_BASE_HI 0x0c
> +#define XAL_RC_IO_BASE_LO 0x10
> +#define XAL_RC_IO_LIMIT_HI 0x14
> +#define XAL_RC_IO_LIMIT_LO 0x18
> +#define XAL_RC_MEM_32BIT_BASE_HI 0x1c
> +#define XAL_RC_MEM_32BIT_BASE_LO 0x20
> +#define XAL_RC_MEM_32BIT_LIMIT_HI 0x24
> +#define XAL_RC_MEM_32BIT_LIMIT_LO 0x28
> +#define XAL_RC_MEM_64BIT_BASE_HI 0x2c
> +#define XAL_RC_MEM_64BIT_BASE_LO 0x30
> +#define XAL_RC_MEM_64BIT_LIMIT_HI 0x34
> +#define XAL_RC_MEM_64BIT_LIMIT_LO 0x38
> +#define XAL_RC_BAR_CNTL_STANDARD 0x40
> +#define XAL_RC_BAR_CNTL_STANDARD_IOBAR_EN BIT(0)
> +#define XAL_RC_BAR_CNTL_STANDARD_32B_BAR_EN BIT(1)
> +#define XAL_RC_BAR_CNTL_STANDARD_64B_BAR_EN BIT(2)
> +
> +/* XTL registers */
> +#define XTL_RC_PCIE_CFG_LINK_STATUS 0x5a
> +
> +#define XTL_RC_MGMT_PERST_CONTROL 0x218
> +#define XTL_RC_MGMT_PERST_CONTROL_PERST_O_N BIT(0)
> +
> +#define XTL_RC_MGMT_CLOCK_CONTROL 0x47c
> +#define XTL_RC_MGMT_CLOCK_CONTROL_PEX_CLKREQ_I_N_PIN_USE_CONV_TO_PRSNT BIT(9)
> +
> +struct tegra264_pcie {
> + struct device *dev;
> + bool link_up;
Keep bool types at the end to avoid holes.
> +
> + /* I/O memory */
> + void __iomem *xal;
> + void __iomem *xtl;
> + void __iomem *ecam;
> +
> + /* bridge configuration */
> + struct pci_config_window *cfg;
> + struct pci_host_bridge *bridge;
> +
> + /* wake IRQ */
> + struct gpio_desc *wake_gpio;
> + unsigned int wake_irq;
> +
> + /* BPMP and bandwidth management */
> + struct icc_path *icc_path;
> + struct tegra_bpmp *bpmp;
> + u32 ctl_id;
> +};
> +
> +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.
> + 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.
> + device_init_wakeup(pcie->dev, true);
> +
> + err = gpiod_to_irq(pcie->wake_gpio);
> + if (err < 0) {
> + dev_err(pcie->dev, "failed to get wake IRQ: %pe\n",
> + ERR_PTR(err));
> + return err;
> + }
> +
> + pcie->wake_irq = (unsigned int)err;
> + }
> +
> + return 0;
> +}
> +
> +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()?
> +{
> + 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.
> + 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'?
> +
> + 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?
> +}
> +
> +/*
> + * The various memory regions used by the controller (I/O, memory, ECAM) are
> + * set up during early boot and have hardware-level protections in place. If
> + * the DT ranges don't match what's been setup, the controller won't be able
> + * to write the address endpoints properly, so make sure to validate that DT
> + * and firmware programming agree on these ranges.
> + */
> +static bool tegra264_pcie_check_ranges(struct platform_device *pdev)
> +{
> + struct tegra264_pcie *pcie = platform_get_drvdata(pdev);
> + struct device_node *np = pcie->dev->of_node;
> + struct of_pci_range_parser parser;
> + phys_addr_t phys, limit, hi, lo;
> + struct of_pci_range range;
> + struct resource *res;
> + bool status = true;
> + u32 value;
> + int err;
> +
> + err = of_pci_range_parser_init(&parser, np);
> + if (err < 0)
> + return false;
> +
> + for_each_of_pci_range(&parser, &range) {
> + unsigned int addr_hi, addr_lo, limit_hi, limit_lo, enable;
> + unsigned long type = range.flags & IORESOURCE_TYPE_BITS;
> + phys_addr_t start, end, mask;
> + const char *region = NULL;
> +
> + end = range.cpu_addr + range.size - 1;
> + start = range.cpu_addr;
> +
> + switch (type) {
> + case IORESOURCE_IO:
> + addr_hi = XAL_RC_IO_BASE_HI;
> + addr_lo = XAL_RC_IO_BASE_LO;
> + limit_hi = XAL_RC_IO_LIMIT_HI;
> + limit_lo = XAL_RC_IO_LIMIT_LO;
> + enable = XAL_RC_BAR_CNTL_STANDARD_IOBAR_EN;
> + mask = SZ_64K - 1;
> + region = "I/O";
> + break;
> +
> + case IORESOURCE_MEM:
> + if (range.flags & IORESOURCE_PREFETCH) {
> + addr_hi = XAL_RC_MEM_64BIT_BASE_HI;
> + addr_lo = XAL_RC_MEM_64BIT_BASE_LO;
> + limit_hi = XAL_RC_MEM_64BIT_LIMIT_HI;
> + limit_lo = XAL_RC_MEM_64BIT_LIMIT_LO;
> + enable = XAL_RC_BAR_CNTL_STANDARD_64B_BAR_EN;
> + region = "prefetchable memory";
> + } else {
> + addr_hi = XAL_RC_MEM_32BIT_BASE_HI;
> + addr_lo = XAL_RC_MEM_32BIT_BASE_LO;
> + limit_hi = XAL_RC_MEM_32BIT_LIMIT_HI;
> + limit_lo = XAL_RC_MEM_32BIT_LIMIT_LO;
> + enable = XAL_RC_BAR_CNTL_STANDARD_32B_BAR_EN;
> + region = "memory";
> + }
> +
> + mask = SZ_1M - 1;
> + break;
> + }
> +
> + /* not interested in anything that's not I/O or memory */
> + if (!region)
> + continue;
> +
> + /* don't check regions that haven't been enabled */
> + value = readl(pcie->xal + XAL_RC_BAR_CNTL_STANDARD);
> + if ((value & enable) == 0)
> + continue;
> +
> + hi = readl(pcie->xal + addr_hi);
> + lo = readl(pcie->xal + addr_lo);
> + phys = hi << 32 | lo;
> +
> + hi = readl(pcie->xal + limit_hi);
> + lo = readl(pcie->xal + limit_lo);
> + limit = hi << 32 | lo | mask;
> +
> + if (phys != start || limit != end) {
> + dev_err(pcie->dev,
> + "%s region mismatch: %pap-%pap -> %pap-%pap\n",
> + region, &phys, &limit, &start, &end);
> + status = false;
> + }
> + }
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam");
> + if (!res)
> + return false;
> +
> + hi = readl(pcie->xal + XAL_RC_ECAM_BASE_HI);
> + lo = readl(pcie->xal + XAL_RC_ECAM_BASE_LO);
> + phys = hi << 32 | lo;
> +
> + value = readl(pcie->xal + XAL_RC_ECAM_BUSMASK);
> + limit = phys + ((value + 1) << 20) - 1;
> +
> + if (phys != res->start || limit != res->end) {
> + dev_err(pcie->dev,
> + "ECAM region mismatch: %pap-%pap -> %pap-%pap\n",
> + &phys, &limit, &res->start, &res->end);
> + status = false;
> + }
> +
> + return status;
> +}
> +
> +static bool tegra264_pcie_link_up(struct tegra264_pcie *pcie,
> + enum pci_bus_speed *speed)
> +{
> + u16 value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_STATUS);
> +
> + if (value & PCI_EXP_LNKSTA_DLLLA) {
> + if (speed)
> + *speed = pcie_link_speed[FIELD_GET(PCI_EXP_LNKSTA_CLS,
> + value)];
> +
> + return true;
> + }
> +
> + return false;
> +}
> +
> +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?
> + 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?
> + 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?
> + /* Per PCIe r5.0, 6.6.1 wait for 100ms after DLL up */
No need of this comment.
> + msleep(PCIE_RESET_CONFIG_WAIT_MS);
> +
> + dev_info(pcie->dev, "PCIe #%u link is up (speed: %s)\n",
> + pcie->ctl_id, pci_speed_string(speed));
> + tegra264_pcie_icc_set(pcie);
> + pcie->link_up = true;
> + } else {
> + dev_info(pcie->dev, "PCIe #%u link is down\n", pcie->ctl_id);
> +
> + value = readl(pcie->xtl + XTL_RC_MGMT_CLOCK_CONTROL);
> +
> + /*
> + * Set link state only when link fails and no hot-plug feature
> + * is present.
> + */
> + if ((value & XTL_RC_MGMT_CLOCK_CONTROL_PEX_CLKREQ_I_N_PIN_USE_CONV_TO_PRSNT) == 0) {
> + dev_info(pcie->dev,
> + "PCIe #%u link is down and not hotplug-capable, turning off\n",
> + pcie->ctl_id);
> + tegra264_pcie_bpmp_set_rp_state(pcie);
> + pcie->link_up = false;
> + } else {
> + pcie->link_up = true;
> + }
> + }
> +}
> +
> +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/
> + 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()?
> + 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;
> +
> + err = pci_host_probe(bridge);
> + if (err < 0) {
> + dev_err(dev, "failed to register host: %pe\n", ERR_PTR(err));
dev_err_probe()
> + goto free;
> + }
> +
> + return err;
return 0;
> +
> +free:
> + pci_ecam_free(pcie->cfg);
> +put_pm:
> + pm_runtime_put_sync(dev);
> + pm_runtime_disable(dev);
> +
> + if (tegra_is_silicon())
> + tegra_bpmp_put(pcie->bpmp);
> +
> + return err;
> +}
> +
> +static void tegra264_pcie_remove(struct platform_device *pdev)
> +{
> + struct tegra264_pcie *pcie = platform_get_drvdata(pdev);
> +
> + /*
> + * If we undo tegra264_pcie_init() then link goes down and need
> + * controller reset to bring up the link again. Remove intention is
> + * to clean up the root bridge and re-enumerate during bind.
> + */
> + pci_lock_rescan_remove();
> + pci_stop_root_bus(pcie->bridge->bus);
> + pci_remove_root_bus(pcie->bridge->bus);
> + pci_unlock_rescan_remove();
> +
> + pm_runtime_put_sync(&pdev->dev);
> + pm_runtime_disable(&pdev->dev);
> +
> + if (tegra_is_silicon())
> + tegra_bpmp_put(pcie->bpmp);
> +
> + pci_ecam_free(pcie->cfg);
> +}
> +
> +static int tegra264_pcie_suspend_noirq(struct device *dev)
> +{
> + struct tegra264_pcie *pcie = dev_get_drvdata(dev);
> + int err;
> +
> + if (pcie->wake_gpio && device_may_wakeup(dev)) {
> + err = enable_irq_wake(pcie->wake_irq);
> + if (err < 0)
> + dev_err(dev, "failed to enable wake IRQ: %pe\n",
> + ERR_PTR(err));
> + }
> +
> + return 0;
> +}
> +
> +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()?
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH net v4 0/2] stmmac crash/stall fixes when under memory pressure
From: Russell King (Oracle) @ 2026-04-02 17:26 UTC (permalink / raw)
To: Sam Edwards
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, Maxime Chevallier,
Ovidiu Panait, Vladimir Oltean, Baruch Siach, Serge Semin,
Giuseppe Cavallaro, netdev, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <ac6kfQ98Xjt3dCGj@shell.armlinux.org.uk>
On Thu, Apr 02, 2026 at 06:16:45PM +0100, Russell King (Oracle) wrote:
> On Tue, Mar 31, 2026 at 09:19:27PM -0700, Sam Edwards wrote:
> > Hi netdev,
> >
> > This is v4 of my series containing a pair of bugfixes for the stmmac driver's
> > receive pipeline. These issues occur when stmmac_rx_refill() does not (fully)
> > succeed, which happens more frequently when free memory is low.
> >
> > The first patch closes Bugzilla bug #221010 [1], where stmmac_rx() can circle
> > around to a still-dirty descriptor (with a NULL buffer pointer), mistake it for
> > a filled descriptor (due to OWN=0), and attempt to dereference the buffer.
> >
> > In testing that patch, I discovered a second issue: starvation of available RX
> > buffers causes the NIC to stop sending interrupts; if the driver stops polling,
> > it will wait indefinitely for an interrupt that will never come. (Note: the
> > first patch makes this issue more prominent -- mostly because it lets the
> > system survive long enough to exhibit it -- but doesn't *cause* it.) The second
> > patch addresses that problem as well.
> >
> > Both patches are minimal, appropriate for stable, and designated to `net`. My
> > focus is on small, obviously-correct, easy-to-explain changes: I'll follow up
> > with another patch/series (something like [2]) for `net-next` that fixes the
> > ring in a more robust way.
> >
> > The tx and zc paths seem to have similar low-memory bugs, to be addressed in
> > separate series.
>
> I've tested this on my Jetson Xavier platform. One of the issues I've
> had is that running iperf3 results in the receive side stalling because
> it runs out of descriptors. However, despite the receive ring
> eventually being re-filled and the hardware appropriately prodded, it
> steadfastly refuses to restart, despite the descriptors having been
> updated.
I'll make it clear: this problem exists without your patches, so it
is not a regression.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH RESEND] thermal/drivers/brcmstb_thermal: Use max to simplify brcmstb_get_temp
From: Daniel Lezcano @ 2026-04-02 17:24 UTC (permalink / raw)
To: Thorsten Blum, Markus Mayer, Broadcom internal kernel review list,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Florian Fainelli
Cc: linux-pm, linux-arm-kernel, linux-kernel
In-Reply-To: <20260402165616.895305-3-thorsten.blum@linux.dev>
On 4/2/26 18:56, Thorsten Blum wrote:
> Use max() to simplify brcmstb_get_temp() and improve its readability.
> Since avs_tmon_code_to_temp() returns an int, change the data type of
> the local variable 't' from long to int. No functional changes.
>
> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
Applied, thanks
^ permalink raw reply
* Re: [PATCH net v4 0/2] stmmac crash/stall fixes when under memory pressure
From: Russell King (Oracle) @ 2026-04-02 17:16 UTC (permalink / raw)
To: Sam Edwards
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, Maxime Chevallier,
Ovidiu Panait, Vladimir Oltean, Baruch Siach, Serge Semin,
Giuseppe Cavallaro, netdev, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260401041929.12392-1-CFSworks@gmail.com>
On Tue, Mar 31, 2026 at 09:19:27PM -0700, Sam Edwards wrote:
> Hi netdev,
>
> This is v4 of my series containing a pair of bugfixes for the stmmac driver's
> receive pipeline. These issues occur when stmmac_rx_refill() does not (fully)
> succeed, which happens more frequently when free memory is low.
>
> The first patch closes Bugzilla bug #221010 [1], where stmmac_rx() can circle
> around to a still-dirty descriptor (with a NULL buffer pointer), mistake it for
> a filled descriptor (due to OWN=0), and attempt to dereference the buffer.
>
> In testing that patch, I discovered a second issue: starvation of available RX
> buffers causes the NIC to stop sending interrupts; if the driver stops polling,
> it will wait indefinitely for an interrupt that will never come. (Note: the
> first patch makes this issue more prominent -- mostly because it lets the
> system survive long enough to exhibit it -- but doesn't *cause* it.) The second
> patch addresses that problem as well.
>
> Both patches are minimal, appropriate for stable, and designated to `net`. My
> focus is on small, obviously-correct, easy-to-explain changes: I'll follow up
> with another patch/series (something like [2]) for `net-next` that fixes the
> ring in a more robust way.
>
> The tx and zc paths seem to have similar low-memory bugs, to be addressed in
> separate series.
I've tested this on my Jetson Xavier platform. One of the issues I've
had is that running iperf3 results in the receive side stalling because
it runs out of descriptors. However, despite the receive ring
eventually being re-filled and the hardware appropriately prodded, it
steadfastly refuses to restart, despite the descriptors having been
updated.
What I can see is there's 40 packets in the internal FIFOs via the
PRXQ[13:0] field of the ETH_MTLRXQxDR register.
With your patches applied:
root@tegra-ubuntu:~# iperf3 -c 192.168.248.1 -R
Connecting to host 192.168.248.1, port 5201
Reverse mode, remote host 192.168.248.1 is sending
[ 5] local 192.168.248.174 port 43728 connected to 192.168.248.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 30.3 MBytes 254 Mbits/sec
[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec
...
The remote system says:
Accepted connection from 192.168.248.174, port 43720
[ 5] local 192.168.248.1 port 5201 connected to 192.168.248.174 port 43728
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 31.8 MBytes 266 Mbits/sec 1 1.41 KBytes
[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
This is a dwmac v5.0. I think the relevant registers are:
ETH_MTLQxICSR: Value at address 0x02490d2c: 0x00000002
ETH_MTLRXQxDR: Value at address 0x02490d38: 0x00280020
PRXQ[13:0]: Number of Packets in Receive Queue = 40
RXQSTS[1:0]: MTL Rx Queue Fill-Level status = 2 (Rx queue fill-level
above flow-control activate threshold)
RRXSTS[1:0]: MTL Rx Queue Read Controller State = 0 (Idle)
RWCSTS: MTL Rx Queue Write Controller Active Status = 0
ETH_DMADS1R: Value at address 0x0249100c: 0x00006300
RPS0[3:0]: DMA Channel Receive Process State = Running (Waiting for Rx
packet)
ETH_DMACxRXDTPR: Value at address 0x02491128: 0xffffe7d0
RDT[31:0]: Receive Descriptor Tail Pointer (writes should apparently
trigger DMA to start, but doesn't seem to)
ETH_DMACxCARXDR: Value at address 0x0249114c: 0xffffe7d0
CURRDESAPTR[31:0]: Application receive descriptor address pointer
ETH_DMACxCARXBR: Value at address 0x0249115c: 0xffb55040
CURRBUFAPTR[31:0]: Application receive buffer address pointer
This makes it look like it's read the descriptor at 0x7fffffe7d0.
ETH_DMAC0SR: Value at address 0x02491160: 0x00000484
ETI (early transmit interrupt)=1 RBU (receive buffer unavailable)=1
TBU (transmit buffer unavailable)=1
Clearing RBU doesn't seem to help.
Descriptors:
123 [0x0000007fffffe7b0]: 0xffbba040 0x7f 0x0 0x81000000
124 [0x0000007fffffe7c0]: 0xffbb9040 0x7f 0x0 0x81000000
125 [0x0000007fffffe7d0]: 0xffb55040 0x7f 0x0 0x81000000 <---
126 [0x0000007fffffe7e0]: 0xffc26040 0x7f 0x0 0x81000000
127 [0x0000007fffffe7f0]: 0xfff95040 0x7f 0x0 0x81000000
So they're all refilled.
Any ideas?
Full register dump via devmem2 (ethtool -d doesn't dump all registers):
Value at address 0x02490000: 0x08072203
Value at address 0x02490004: 0x00200000
Value at address 0x02490008: 0x00010404
Value at address 0x0249000c: 0x00000000
Value at address 0x02490010: 0x00040008
Value at address 0x02490014: 0x20000008
Value at address 0x02490018: 0x00000001
Value at address 0x0249001c: 0x00000001
Value at address 0x02490020: 0x00000000
Value at address 0x02490024: 0x00000000
Value at address 0x02490028: 0x00000000
Value at address 0x0249002c: 0x00000000
Value at address 0x02490030: 0x00000000
Value at address 0x02490034: 0x00000000
Value at address 0x02490038: 0x00000000
Value at address 0x0249003c: 0x00000000
Value at address 0x02490040: 0x00000000
Value at address 0x02490044: 0x00000000
Value at address 0x02490048: 0x00000000
Value at address 0x0249004c: 0x00000000
Value at address 0x02490050: 0x01600000
Value at address 0x02490054: 0x00000000
Value at address 0x02490058: 0x00000000
Value at address 0x0249005c: 0x00000000
Value at address 0x02490060: 0x00120000
Value at address 0x02490064: 0x00000000
Value at address 0x02490068: 0x00000000
Value at address 0x0249006c: 0x00000000
Value at address 0x02490070: 0xffff0002
Value at address 0x02490074: 0x00000000
Value at address 0x02490078: 0x00000000
Value at address 0x0249007c: 0x00000000
Value at address 0x02490080: 0x00000000
Value at address 0x02490084: 0x00000000
Value at address 0x02490088: 0x00000000
Value at address 0x0249008c: 0x00000000
Value at address 0x02490090: 0x00000001
Value at address 0x02490094: 0x00000000
Value at address 0x02490098: 0x00000000
Value at address 0x0249009c: 0x00000000
Value at address 0x024900a0: 0x00000002
Value at address 0x024900a4: 0x00000000
Value at address 0x024900a8: 0x00000000
Value at address 0x024900ac: 0x00000000
Value at address 0x024900b0: 0x00000001
Value at address 0x024900b4: 0x00001030
Value at address 0x024900b8: 0x00000000
Value at address 0x024900bc: 0x00000000
Value at address 0x024900c0: 0x00000000
Value at address 0x024900c4: 0x00000000
Value at address 0x024900c8: 0x00000000
Value at address 0x024900cc: 0x00000000
Value at address 0x024900d0: 0x003b0200
Value at address 0x024900d4: 0x03e8001e
Value at address 0x024900d8: 0x000f4240
Value at address 0x024900dc: 0x0000007c
Value at address 0x024900e0: 0x00000000
Value at address 0x024900e4: 0x00000000
Value at address 0x024900e8: 0x00000000
Value at address 0x024900ec: 0x00000000
Value at address 0x024900f0: 0x00000000
Value at address 0x024900f4: 0x00000000
Value at address 0x024900f8: 0x000d0000
Value at address 0x024900fc: 0x00000000
Value at address 0x02490100: 0x00000000
Value at address 0x02490104: 0x00000000
Value at address 0x02490108: 0x00000000
Value at address 0x0249010c: 0x00000000
Value at address 0x02490110: 0x00001050
Value at address 0x02490114: 0x00000000
Value at address 0x02490118: 0x00000000
Value at address 0x0249011c: 0x1bfd73f7
Value at address 0x02490120: 0x421e7a49
Value at address 0x02490124: 0x100c30c3
Value at address 0x02490128: 0x00320220
Value at address 0x02490200: 0x000e010c
Value at address 0x02490204: 0x00000006
Value at address 0x02490208: 0x00000000
Value at address 0x0249020c: 0x00000000
Value at address 0x02490210: 0x00000000
Value at address 0x02490214: 0x00000000
Value at address 0x02490218: 0x00000000
Value at address 0x0249021c: 0x00000000
Value at address 0x02490220: 0x00000000
Value at address 0x02490224: 0x00000000
Value at address 0x02490228: 0x00000000
Value at address 0x0249022c: 0x00000000
Value at address 0x02490230: 0x00000000
Value at address 0x02490234: 0x00000000
Value at address 0x02490238: 0x00000102
Value at address 0x02490d00: 0x00ff000a
Value at address 0x02490d04: 0x00000000
Value at address 0x02490d08: 0x00000000
Value at address 0x02490d0c: 0x00000000
Value at address 0x02490d10: 0x00000000
Value at address 0x02490d14: 0x00000030
Value at address 0x02490d18: 0x00000000
Value at address 0x02490d1c: 0x00000000
Value at address 0x02490d20: 0x00000000
Value at address 0x02490d24: 0x00000000
Value at address 0x02490d28: 0x00000000
Value at address 0x02490d2c: 0x00000002
Value at address 0x02490d30: 0x0ff1c4e0
Value at address 0x02490d34: 0x00000000
Value at address 0x02490d38: 0x00280020
Value at address 0x02490d3c: 0x00000000
Value at address 0x02491000: 0x00000000
Value at address 0x02491004: 0x0002180e
Value at address 0x02491008: 0x00000000
Value at address 0x0249100c: 0x00006300
Value at address 0x02491010: 0x00000000
Value at address 0x02491014: 0x00000000
Value at address 0x02491018: 0x00000000
Value at address 0x0249101c: 0x00000000
Value at address 0x02491020: 0x00000000
Value at address 0x02491024: 0x00000000
Value at address 0x02491028: 0x00000000
Value at address 0x0249102c: 0x00000000
Value at address 0x02491030: 0x00000000
Value at address 0x02491034: 0x00000000
Value at address 0x02491038: 0x00000000
Value at address 0x0249103c: 0x00000000
Value at address 0x02491040: 0x00000000
Value at address 0x02491044: 0x00000000
Value at address 0x02491048: 0x00000000
Value at address 0x0249104c: 0x00000000
Value at address 0x02491050: 0x00000000
Value at address 0x02491054: 0x00000000
Value at address 0x02491100: 0x00010000
Value at address 0x02491104: 0x00101011
Value at address 0x02491108: 0x00080c01
Value at address 0x0249110c: 0x00000000
Value at address 0x02491110: 0x0000007f
Value at address 0x02491114: 0xffffc000
Value at address 0x02491118: 0x0000007f
Value at address 0x0249111c: 0xffffe000
Value at address 0x02491120: 0xffffc500
Value at address 0x02491124: 0x00000000
Value at address 0x02491128: 0xffffe7d0
Value at address 0x0249112c: 0x000001ff
Value at address 0x02491130: 0x000001ff
Value at address 0x02491134: 0x0000d041
Value at address 0x02491138: 0x000000a0
Value at address 0x0249113c: 0x000d07c0
Value at address 0x02491140: 0x00000000
Value at address 0x02491144: 0xffffc500
Value at address 0x02491148: 0x00000000
Value at address 0x0249114c: 0xffffe7d0
Value at address 0x02491150: 0x0000007f
Value at address 0x02491154: 0xffc45b02
Value at address 0x02491158: 0x0000007f
Value at address 0x0249115c: 0xffb55040
Value at address 0x02491160: 0x00000484
Value at address 0x02491164: 0x00000000
Value at address 0x02491168: 0x00000000
Value at address 0x0249116c: 0x00000000
Value at address 0x02491170: 0x00000000
Value at address 0x02491174: 0x00000000
Value at address 0x02491178: 0x00000000
Value at address 0x0249117c: 0x00000000
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* [PATCH v3 2/2] mailbox: Make mbox_send_message() return error code when tx fails
From: Joonwon Kang @ 2026-04-02 17:06 UTC (permalink / raw)
To: jassisinghbrar, matthias.bgg, angelogioacchino.delregno,
thierry.reding, jonathanh
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, linux-tegra,
Joonwon Kang, stable
In-Reply-To: <20260402170641.2082547-1-joonwonkang@google.com>
When the mailbox controller failed transmitting message, the error code
was only passed to the client's tx done handler and not to
mbox_send_message(). For this reason, the function could return a false
success. This commit resolves the issue by introducing the tx status and
checking it before mbox_send_message() returns.
Cc: stable@vger.kernel.org
Signed-off-by: Joonwon Kang <joonwonkang@google.com>
---
drivers/mailbox/mailbox.c | 20 +++++++++++++++-----
include/linux/mailbox_controller.h | 2 ++
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index d63386468982..ea9aec9dc947 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -21,7 +21,10 @@
static LIST_HEAD(mbox_cons);
static DEFINE_MUTEX(con_mutex);
-static int add_to_rbuf(struct mbox_chan *chan, void *mssg, struct completion *tx_complete)
+static int add_to_rbuf(struct mbox_chan *chan,
+ void *mssg,
+ struct completion *tx_complete,
+ int *tx_status)
{
int idx;
@@ -34,6 +37,7 @@ static int add_to_rbuf(struct mbox_chan *chan, void *mssg, struct completion *tx
idx = chan->msg_free;
chan->msg_data[idx].data = mssg;
chan->msg_data[idx].tx_complete = tx_complete;
+ chan->msg_data[idx].tx_status = tx_status;
chan->msg_count++;
if (idx == MBOX_TX_QUEUE_LEN - 1)
@@ -91,12 +95,13 @@ static void msg_submit(struct mbox_chan *chan)
static void tx_tick(struct mbox_chan *chan, int r, int idx)
{
- struct mbox_message mssg = {MBOX_NO_MSG, NULL};
+ struct mbox_message mssg = {MBOX_NO_MSG, NULL, NULL};
scoped_guard(spinlock_irqsave, &chan->lock) {
if (idx >= 0 && idx != chan->active_req) {
chan->msg_data[idx].data = MBOX_NO_MSG;
chan->msg_data[idx].tx_complete = NULL;
+ chan->msg_data[idx].tx_status = NULL;
return;
}
@@ -116,8 +121,10 @@ static void tx_tick(struct mbox_chan *chan, int r, int idx)
if (chan->cl->tx_done)
chan->cl->tx_done(chan->cl, mssg.data, r);
- if (r != -ETIME && chan->cl->tx_block)
+ if (r != -ETIME && chan->cl->tx_block) {
+ *mssg.tx_status = r;
complete(mssg.tx_complete);
+ }
}
static enum hrtimer_restart txdone_hrtimer(struct hrtimer *hrtimer)
@@ -286,15 +293,16 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
int t;
int idx;
struct completion tx_complete;
+ int tx_status = 0;
if (!chan || !chan->cl || mssg == MBOX_NO_MSG)
return -EINVAL;
if (chan->cl->tx_block) {
init_completion(&tx_complete);
- t = add_to_rbuf(chan, mssg, &tx_complete);
+ t = add_to_rbuf(chan, mssg, &tx_complete, &tx_status);
} else {
- t = add_to_rbuf(chan, mssg, NULL);
+ t = add_to_rbuf(chan, mssg, NULL, NULL);
}
if (t < 0) {
@@ -318,6 +326,8 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
idx = t;
t = -ETIME;
tx_tick(chan, t, idx);
+ } else if (tx_status < 0) {
+ t = tx_status;
}
}
diff --git a/include/linux/mailbox_controller.h b/include/linux/mailbox_controller.h
index 912499ad08ed..890da97bcb50 100644
--- a/include/linux/mailbox_controller.h
+++ b/include/linux/mailbox_controller.h
@@ -117,10 +117,12 @@ struct mbox_controller {
* struct mbox_message - Internal representation of a mailbox message
* @data: Data packet
* @tx_complete: Pointer to the transmission completion
+ * @tx_status: Pointer to the transmission status
*/
struct mbox_message {
void *data;
struct completion *tx_complete;
+ int *tx_status;
};
/**
--
2.53.0.1185.g05d4b7b318-goog
^ permalink raw reply related
* [PATCH v3 1/2] mailbox: Use per-thread completion to fix wrong completion order
From: Joonwon Kang @ 2026-04-02 17:06 UTC (permalink / raw)
To: jassisinghbrar, matthias.bgg, angelogioacchino.delregno,
thierry.reding, jonathanh
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, linux-tegra,
Joonwon Kang, stable
In-Reply-To: <20260402170641.2082547-1-joonwonkang@google.com>
Previously, a sender thread in mbox_send_message() could be woken up at
a wrong time in blocking mode. It is because there was only a single
completion for a channel whereas messages from multiple threads could be
sent in any order; since the shared completion could be signalled in any
order, it could wake up a wrong sender thread.
This commit resolves the false wake-up issue with the following changes:
- Completions are created just as many as the number of concurrent sender
threads
- A completion is created on a sender thread's stack
- Each slot of the message queue, i.e. `msg_data`, contains a pointer to
its target completion
- tx_tick() signals the completion of the currently active slot of the
message queue
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/1490809381-28869-1-git-send-email-jaswinder.singh@linaro.org
Signed-off-by: Joonwon Kang <joonwonkang@google.com>
---
drivers/mailbox/mailbox.c | 86 +++++++++++++++++++-----------
drivers/mailbox/mtk-vcp-mailbox.c | 2 +-
drivers/mailbox/tegra-hsp.c | 2 +-
include/linux/mailbox_controller.h | 20 ++++---
4 files changed, 72 insertions(+), 38 deletions(-)
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 138ffbcd4fde..d63386468982 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -21,7 +21,7 @@
static LIST_HEAD(mbox_cons);
static DEFINE_MUTEX(con_mutex);
-static int add_to_rbuf(struct mbox_chan *chan, void *mssg)
+static int add_to_rbuf(struct mbox_chan *chan, void *mssg, struct completion *tx_complete)
{
int idx;
@@ -32,7 +32,8 @@ static int add_to_rbuf(struct mbox_chan *chan, void *mssg)
return -ENOBUFS;
idx = chan->msg_free;
- chan->msg_data[idx] = mssg;
+ chan->msg_data[idx].data = mssg;
+ chan->msg_data[idx].tx_complete = tx_complete;
chan->msg_count++;
if (idx == MBOX_TX_QUEUE_LEN - 1)
@@ -50,24 +51,33 @@ static void msg_submit(struct mbox_chan *chan)
int err = -EBUSY;
scoped_guard(spinlock_irqsave, &chan->lock) {
- if (!chan->msg_count || chan->active_req != MBOX_NO_MSG)
+ if (chan->active_req >= 0)
break;
- count = chan->msg_count;
- idx = chan->msg_free;
- if (idx >= count)
- idx -= count;
- else
- idx += MBOX_TX_QUEUE_LEN - count;
+ while (chan->msg_count > 0) {
+ count = chan->msg_count;
+ idx = chan->msg_free;
+ if (idx >= count)
+ idx -= count;
+ else
+ idx += MBOX_TX_QUEUE_LEN - count;
- data = chan->msg_data[idx];
+ data = chan->msg_data[idx].data;
+ if (data != MBOX_NO_MSG)
+ break;
+
+ chan->msg_count--;
+ }
+
+ if (!chan->msg_count)
+ break;
if (chan->cl->tx_prepare)
chan->cl->tx_prepare(chan->cl, data);
/* Try to submit a message to the MBOX controller */
err = chan->mbox->ops->send_data(chan, data);
if (!err) {
- chan->active_req = data;
+ chan->active_req = idx;
chan->msg_count--;
}
}
@@ -79,27 +89,35 @@ static void msg_submit(struct mbox_chan *chan)
}
}
-static void tx_tick(struct mbox_chan *chan, int r)
+static void tx_tick(struct mbox_chan *chan, int r, int idx)
{
- void *mssg;
+ struct mbox_message mssg = {MBOX_NO_MSG, NULL};
scoped_guard(spinlock_irqsave, &chan->lock) {
- mssg = chan->active_req;
- chan->active_req = MBOX_NO_MSG;
+ if (idx >= 0 && idx != chan->active_req) {
+ chan->msg_data[idx].data = MBOX_NO_MSG;
+ chan->msg_data[idx].tx_complete = NULL;
+ return;
+ }
+
+ if (chan->active_req >= 0) {
+ mssg = chan->msg_data[chan->active_req];
+ chan->active_req = -1;
+ }
}
/* Submit next message */
msg_submit(chan);
- if (mssg == MBOX_NO_MSG)
+ if (mssg.data == MBOX_NO_MSG)
return;
/* Notify the client */
if (chan->cl->tx_done)
- chan->cl->tx_done(chan->cl, mssg, r);
+ chan->cl->tx_done(chan->cl, mssg.data, r);
if (r != -ETIME && chan->cl->tx_block)
- complete(&chan->tx_complete);
+ complete(mssg.tx_complete);
}
static enum hrtimer_restart txdone_hrtimer(struct hrtimer *hrtimer)
@@ -112,10 +130,10 @@ static enum hrtimer_restart txdone_hrtimer(struct hrtimer *hrtimer)
for (i = 0; i < mbox->num_chans; i++) {
struct mbox_chan *chan = &mbox->chans[i];
- if (chan->active_req != MBOX_NO_MSG && chan->cl) {
+ if (chan->active_req >= 0 && chan->cl) {
txdone = chan->mbox->ops->last_tx_done(chan);
if (txdone)
- tx_tick(chan, 0);
+ tx_tick(chan, 0, -1);
else
resched = true;
}
@@ -168,7 +186,7 @@ void mbox_chan_txdone(struct mbox_chan *chan, int r)
return;
}
- tx_tick(chan, r);
+ tx_tick(chan, r, -1);
}
EXPORT_SYMBOL_GPL(mbox_chan_txdone);
@@ -188,7 +206,7 @@ void mbox_client_txdone(struct mbox_chan *chan, int r)
return;
}
- tx_tick(chan, r);
+ tx_tick(chan, r, -1);
}
EXPORT_SYMBOL_GPL(mbox_client_txdone);
@@ -266,11 +284,19 @@ EXPORT_SYMBOL_GPL(mbox_chan_tx_slots_available);
int mbox_send_message(struct mbox_chan *chan, void *mssg)
{
int t;
+ int idx;
+ struct completion tx_complete;
if (!chan || !chan->cl || mssg == MBOX_NO_MSG)
return -EINVAL;
- t = add_to_rbuf(chan, mssg);
+ if (chan->cl->tx_block) {
+ init_completion(&tx_complete);
+ t = add_to_rbuf(chan, mssg, &tx_complete);
+ } else {
+ t = add_to_rbuf(chan, mssg, NULL);
+ }
+
if (t < 0) {
dev_err(chan->mbox->dev, "Try increasing MBOX_TX_QUEUE_LEN\n");
return t;
@@ -287,10 +313,11 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
else
wait = msecs_to_jiffies(chan->cl->tx_tout);
- ret = wait_for_completion_timeout(&chan->tx_complete, wait);
+ ret = wait_for_completion_timeout(&tx_complete, wait);
if (ret == 0) {
+ idx = t;
t = -ETIME;
- tx_tick(chan, t);
+ tx_tick(chan, t, idx);
}
}
@@ -321,7 +348,7 @@ int mbox_flush(struct mbox_chan *chan, unsigned long timeout)
ret = chan->mbox->ops->flush(chan, timeout);
if (ret < 0)
- tx_tick(chan, ret);
+ tx_tick(chan, ret, -1);
return ret;
}
@@ -340,9 +367,8 @@ static int __mbox_bind_client(struct mbox_chan *chan, struct mbox_client *cl)
scoped_guard(spinlock_irqsave, &chan->lock) {
chan->msg_free = 0;
chan->msg_count = 0;
- chan->active_req = MBOX_NO_MSG;
+ chan->active_req = -1;
chan->cl = cl;
- init_completion(&chan->tx_complete);
if (chan->txdone_method == TXDONE_BY_POLL && cl->knows_txdone)
chan->txdone_method = TXDONE_BY_ACK;
@@ -498,7 +524,7 @@ void mbox_free_channel(struct mbox_chan *chan)
/* The queued TX requests are simply aborted, no callbacks are made */
scoped_guard(spinlock_irqsave, &chan->lock) {
chan->cl = NULL;
- chan->active_req = MBOX_NO_MSG;
+ chan->active_req = -1;
if (chan->txdone_method == TXDONE_BY_ACK)
chan->txdone_method = TXDONE_BY_POLL;
}
@@ -553,7 +579,7 @@ int mbox_controller_register(struct mbox_controller *mbox)
chan->cl = NULL;
chan->mbox = mbox;
- chan->active_req = MBOX_NO_MSG;
+ chan->active_req = -1;
chan->txdone_method = txdone;
spin_lock_init(&chan->lock);
}
diff --git a/drivers/mailbox/mtk-vcp-mailbox.c b/drivers/mailbox/mtk-vcp-mailbox.c
index 1b291b8ea15a..a7bab06ac686 100644
--- a/drivers/mailbox/mtk-vcp-mailbox.c
+++ b/drivers/mailbox/mtk-vcp-mailbox.c
@@ -84,7 +84,7 @@ static int mtk_vcp_mbox_send_data(struct mbox_chan *chan, void *data)
static bool mtk_vcp_mbox_last_tx_done(struct mbox_chan *chan)
{
- struct mtk_ipi_info *ipi_info = chan->active_req;
+ struct mtk_ipi_info *ipi_info = chan->msg_data[chan->active_req].data;
struct mtk_vcp_mbox *priv = chan->con_priv;
return !(readl(priv->base + priv->cfg->set_in) & BIT(ipi_info->index));
diff --git a/drivers/mailbox/tegra-hsp.c b/drivers/mailbox/tegra-hsp.c
index 7b1e1b83ea29..efe0033cb5c5 100644
--- a/drivers/mailbox/tegra-hsp.c
+++ b/drivers/mailbox/tegra-hsp.c
@@ -495,7 +495,7 @@ static int tegra_hsp_mailbox_flush(struct mbox_chan *chan,
mbox_chan_txdone(chan, 0);
/* Wait until channel is empty */
- if (chan->active_req != MBOX_NO_MSG)
+ if (chan->active_req >= 0)
continue;
return 0;
diff --git a/include/linux/mailbox_controller.h b/include/linux/mailbox_controller.h
index e3896b08f22e..912499ad08ed 100644
--- a/include/linux/mailbox_controller.h
+++ b/include/linux/mailbox_controller.h
@@ -113,16 +113,25 @@ struct mbox_controller {
*/
#define MBOX_TX_QUEUE_LEN 20
+/**
+ * struct mbox_message - Internal representation of a mailbox message
+ * @data: Data packet
+ * @tx_complete: Pointer to the transmission completion
+ */
+struct mbox_message {
+ void *data;
+ struct completion *tx_complete;
+};
+
/**
* struct mbox_chan - s/w representation of a communication chan
* @mbox: Pointer to the parent/provider of this channel
* @txdone_method: Way to detect TXDone chosen by the API
* @cl: Pointer to the current owner of this channel
- * @tx_complete: Transmission completion
- * @active_req: Currently active request hook
+ * @active_req: Index of the currently active slot in the queue
* @msg_count: No. of mssg currently queued
* @msg_free: Index of next available mssg slot
- * @msg_data: Hook for data packet
+ * @msg_data: Queue of data packets
* @lock: Serialise access to the channel
* @con_priv: Hook for controller driver to attach private data
*/
@@ -130,10 +139,9 @@ struct mbox_chan {
struct mbox_controller *mbox;
unsigned txdone_method;
struct mbox_client *cl;
- struct completion tx_complete;
- void *active_req;
+ int active_req;
unsigned msg_count, msg_free;
- void *msg_data[MBOX_TX_QUEUE_LEN];
+ struct mbox_message msg_data[MBOX_TX_QUEUE_LEN];
spinlock_t lock; /* Serialise access to the channel */
void *con_priv;
};
--
2.53.0.1185.g05d4b7b318-goog
^ permalink raw reply related
* [PATCH v3 0/2] mailbox: Fix wrong completion order and improper send result in the blocking mode send API
From: Joonwon Kang @ 2026-04-02 17:06 UTC (permalink / raw)
To: jassisinghbrar, matthias.bgg, angelogioacchino.delregno,
thierry.reding, jonathanh
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, linux-tegra,
Joonwon Kang
Hi team,
This patch series fixes the two major issues in blocking mode.
1) Wrong completion order in the send API as described in [1]:
Thread#1(T1) Thread#2(T2)
mbox_send_message mbox_send_message
| |
V |
add_to_rbuf(M1) V
| add_to_rbuf(M2)
| |
| V
V msg_submit(picks M1)
msg_submit |
| V
V wait_for_completion(on M2)
wait_for_completion(on M1) | (1st in waitQ)
| (2nd in waitQ) V
V wake_up(on completion of M1)<--incorrect
2) Send API does not return the actual send result.
This patch series contains two patches for each issue:
0001-mailbox-Use-per-thread-completion-to-fix-wrong-co.patch
0002-mailbox-Make-mbox_send_message-return-error-code-.patch
The first issue has to do with multi-threads support. Given the
discussion in [1] with the mailbox framework maintainer, it has been
long thought that the mailbox framework is designed to support
multi-threads although it missed the completion order issue at its
introduction. The first patch of this series is to fix it.
Alternatively, we could instead declare that the mailbox API does not
support multi-threads [2]. However, it would be a sudden big change to
the mailbox users after the long standing implication of supporting
multi-threads. Plus, it would have disparity with the non-blocking mode
which supports multi-threads already, which could also lead to confusion
to the users by saying "non-blocking mode supports multi-threads whereas
blocking mode doesn't". For this reason, the first patch in this series
does not choose this alternative.
The patch series rules out the case where tx_tick() is called twice or
more for a sent message on the same channel. In theory, it could happen
when timeout occurs. For example, one tx_tick() by the mailbox core due
to timeout and another tx_tick() by the mailbox controller or client by
accident or for any other reason. If it happens, the internal mailbox
state could become inconsistent even on a single thread. Thus, this
issue should be handled in an orthogonal effort later on.
The second issue forces users to register tx done callback to get the
actual send result although they are using the blocking mode send API.
This behavior is different from typical blocking send APIs, which just
return the actual send result directly, and so confusing to the users.
Without knowing this additional requirement of the API, it would be
prone to miss the send result check entirely. The second patch is to fix
it by making the blocking mode send API return the actual send result.
Change log of the first patch:
- v3: Rebase on the latest for-next branch.
- v2: Consider the case where timeout occurs and so tx_tick() is called
for a channel by one thread while another thread is having an active
request on the same channel. In that case, we mark the inactive
request as canceled and do not send it to the controller.
- v1: The previous solution in v0 tries to have per-message completion:
`tx_cmpl[MBOX_TX_QUEUE_LEN]`; each completion belongs to each slot of
the message queue: `msg_data[i]`. Those completions take up additional
memory even when they are not used. Instead, this patch tries to have
per-"thread" completion; each completion belongs to each sender thread
and each slot of the message queue has a pointer to that completion;
`struct mbox_message` has the "pointer" field
`struct completion *tx_complete` which points to the completion which
is created on the stack of the sender, instead of owning the
completion by `struct completion tx_complete`. This way, we could
avoid additional memory use since a completion will be allocated only
when necessary. Plus, more importantly, we could avoid the window
where the same completion is reused by different sender threads, which
the previous solution still has.
- v0: This first attempt tries to have per-message completion: [1].
Change log of the second patch:
- No major change from v1.
References:
- [1]: https://lore.kernel.org/all/1490809381-28869-1-git-send-email-jaswinder.singh@linaro.org
- [2]: https://lore.kernel.org/all/CABb+yY39rhTZbtA21MecYk-R9fh7VQQr5kZUgCw4z92mWhZ1Rg@mail.gmail.com/
Joonwon Kang (2):
mailbox: Use per-thread completion to fix wrong completion order
mailbox: Make mbox_send_message() return error code when tx fails
drivers/mailbox/mailbox.c | 98 ++++++++++++++++++++----------
drivers/mailbox/mtk-vcp-mailbox.c | 2 +-
drivers/mailbox/tegra-hsp.c | 2 +-
include/linux/mailbox_controller.h | 22 +++++--
4 files changed, 85 insertions(+), 39 deletions(-)
Thanks,
Joonwon Kang
--
2.53.0.1185.g05d4b7b318-goog
^ permalink raw reply
* [GIT PULL] Reset controller updates for v7.1
From: Philipp Zabel @ 2026-04-02 17:05 UTC (permalink / raw)
To: soc; +Cc: linux-arm-kernel, kernel, Philipp Zabel
Dear arm-soc maintainers,
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.pengutronix.de/git/pza/linux.git tags/reset-for-v7.1
for you to fetch changes up to d373605cd514837d8a6de3d00c786d4bae6dbaf8:
Merge tag 'reset-fixes-for-v7.0-2' into reset/next (2026-04-02 18:32:53 +0200)
----------------------------------------------------------------
Reset controller updates for v7.1
* Rework the reset core to support firmware nodes, add more fine
grained locking, and use guard() helpers.
* Change the reset-gpio driver to use firmware nodes.
* Add support for the Cix Sky1 SoC reset controller.
* Add support for the RZ/G3E SoC to the reset-rzv2h-usb2phy driver and
convert it to regmap. Prepare registering a VBUS mux controller.
* Replace use of the deprecated register_restart_handler() function in
the ath79, intel-gw, lpc18xx, ma35d1, npcm, and sunplus reset drivers.
* Combine two allocations into one in the sti/reset-syscfg driver.
* Fix the reset-rzg2l-usbphy-ctrl MODULE_AUTHOR email.
* Fix the reset_control_rearm() kerneldoc comment.
The last commit is a merge of reset-fixes-for-v7.0-2 into reset/next,
to solve a merge conflict between commits a9b95ce36de4 ("reset: gpio: add a
devlink between reset-gpio and its consumer") and fbffb8c7c7bb ("reset: gpio:
fix double free in reset_add_gpio_aux_device() error path").
----------------------------------------------------------------
Andrew Davis (6):
reset: ath79: Use devm_register_restart_handler()
reset: intel: Use devm_register_restart_handler()
reset: lpc18xx: Use devm_register_sys_off_handler()
reset: ma35d1: Use devm_register_sys_off_handler()
reset: npcm: Use devm_register_sys_off_handler()
reset: sunplus: Use devm_register_sys_off_handler()
Bartosz Golaszewski (15):
reset: gpio: remove unneeded OF-node put
reset: gpio: add a devlink between reset-gpio and its consumer
reset: gpio: simplify fallback device matching
reset: gpio: remove unneeded auxiliary_set_drvdata()
reset: warn on reset-gpio release
reset: fold ida_alloc() into reset_create_gpio_aux_device()
reset: use lock guards in reset core
reset: handle removing supplier before consumers
reset: protect struct reset_controller_dev with its own mutex
reset: protect struct reset_control with its own mutex
reset: convert of_reset_control_get_count() to using firmware nodes
reset: convert the core API to using firmware nodes
reset: convert reset core to using firmware nodes
reset: gpio: make the driver fwnode-agnostic
reset: don't overwrite fwnode_reset_n_cells
Biju Das (1):
reset: rzg2l-usbphy-ctrl: Fix malformed MODULE_AUTHOR string
Claudiu Beznea (2):
reset: rzg2l-usbphy-ctrl: Check pwrrdy is valid before using it
reset: core: Drop unnecessary double quote
Gary Yang (2):
dt-bindings: soc: cix: document the syscon on Sky1 SoC
reset: add Sky1 soc reset support
Guangshuo Li (1):
reset: gpio: fix double free in reset_add_gpio_aux_device() error path
Philipp Zabel (2):
reset: core: Fix indentation
Merge tag 'reset-fixes-for-v7.0-2' into reset/next
Rosen Penev (1):
reset: sti: kzalloc + kcalloc to kzalloc
Tommaso Merciai (5):
reset: rzv2h-usb2phy: Keep PHY clock enabled for entire device lifetime
dt-bindings: reset: renesas,rzv2h-usb2phy: Add '#mux-state-cells' property
dt-bindings: reset: renesas,rzv2h-usb2phy: Document RZ/G3E USB2PHY reset
reset: rzv2h-usb2phy: Convert to regmap API
reset: rzv2h-usb2phy: Add support for VBUS mux controller registration
Yixun Lan (1):
reset: spacemit: k3: Decouple composite reset lines
.../reset/renesas,rzv2h-usb2phy-reset.yaml | 9 +-
.../bindings/soc/cix/cix,sky1-system-control.yaml | 42 ++
Documentation/driver-api/reset.rst | 1 -
drivers/reset/Kconfig | 9 +
drivers/reset/Makefile | 1 +
drivers/reset/core.c | 518 ++++++++++++++-------
drivers/reset/reset-ath79.c | 12 +-
drivers/reset/reset-gpio.c | 27 +-
drivers/reset/reset-intel-gw.c | 11 +-
drivers/reset/reset-lpc18xx.c | 12 +-
drivers/reset/reset-ma35d1.c | 11 +-
drivers/reset/reset-npcm.c | 12 +-
drivers/reset/reset-rzg2l-usbphy-ctrl.c | 5 +-
drivers/reset/reset-rzv2h-usb2phy.c | 197 ++++----
drivers/reset/reset-sky1.c | 367 +++++++++++++++
drivers/reset/reset-sunplus.c | 12 +-
drivers/reset/spacemit/reset-spacemit-k3.c | 60 ++-
drivers/reset/sti/reset-syscfg.c | 9 +-
.../dt-bindings/reset/cix,sky1-s5-system-control.h | 163 +++++++
.../dt-bindings/reset/cix,sky1-system-control.h | 41 ++
include/dt-bindings/reset/spacemit,k3-resets.h | 48 +-
include/linux/reset-controller.h | 21 +-
include/linux/reset.h | 43 +-
23 files changed, 1223 insertions(+), 408 deletions(-)
create mode 100644 Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.yaml
create mode 100644 drivers/reset/reset-sky1.c
create mode 100644 include/dt-bindings/reset/cix,sky1-s5-system-control.h
create mode 100644 include/dt-bindings/reset/cix,sky1-system-control.h
^ permalink raw reply
* Re: [PATCH 5/8] thermal: khadas-mcu-fan: Add fan config from platform data Add regulator support
From: Ronald Claveau @ 2026-04-02 17:00 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm
In-Reply-To: <5e3e8684-f893-4fb0-879e-9661820f72dd@linaro.org>
On 4/2/26 5:39 PM, Neil Armstrong wrote:
> On 4/2/26 16:27, Ronald Claveau wrote:
>> Replace the hardcoded MAX_LEVEL constant and fan register
>> with values read from platform_data (fan_reg, max_level),
>> as new MCUs need different values.
>>
>> Optionally acquire and enable a "fan" regulator supply
>> at probe time and on resume,
>> so boards that gate fan power through a regulator are handled.
>>
>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>> ---
>> drivers/thermal/khadas_mcu_fan.c | 43 ++++++++++++++++++++++++++++++
>> ++++------
>> 1 file changed, 37 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/thermal/khadas_mcu_fan.c b/drivers/thermal/
>> khadas_mcu_fan.c
>> index d35e5313bea41..55b496625e3bd 100644
>> --- a/drivers/thermal/khadas_mcu_fan.c
>> +++ b/drivers/thermal/khadas_mcu_fan.c
>> @@ -13,13 +13,15 @@
>> #include <linux/regmap.h>
>> #include <linux/sysfs.h>
>> #include <linux/thermal.h>
>> -
>> -#define MAX_LEVEL 3
>> +#include <linux/regulator/consumer.h>
>> struct khadas_mcu_fan_ctx {
>> struct khadas_mcu *mcu;
>> + unsigned int fan_reg;
>> unsigned int level;
>> + unsigned int max_level;
>> struct thermal_cooling_device *cdev;
>> + struct regulator *power;
>> };
>> static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
>> @@ -27,8 +29,7 @@ static int khadas_mcu_fan_set_level(struct
>> khadas_mcu_fan_ctx *ctx,
>> {
>> int ret;
>> - ret = regmap_write(ctx->mcu->regmap,
>> KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
>> - level);
>> + ret = regmap_write(ctx->mcu->regmap, ctx->fan_reg, level);
>> if (ret)
>> return ret;
>> @@ -40,7 +41,9 @@ static int khadas_mcu_fan_set_level(struct
>> khadas_mcu_fan_ctx *ctx,
>> static int khadas_mcu_fan_get_max_state(struct
>> thermal_cooling_device *cdev,
>> unsigned long *state)
>> {
>> - *state = MAX_LEVEL;
>> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
>> +
>> + *state = ctx->max_level;
>> return 0;
>> }
>> @@ -61,7 +64,7 @@ khadas_mcu_fan_set_cur_state(struct
>> thermal_cooling_device *cdev,
>> {
>> struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
>> - if (state > MAX_LEVEL)
>> + if (state > ctx->max_level)
>> return -EINVAL;
>> if (state == ctx->level)
>> @@ -83,11 +86,32 @@ static int khadas_mcu_fan_probe(struct
>> platform_device *pdev)
>> struct device *dev = &pdev->dev;
>> struct khadas_mcu_fan_ctx *ctx;
>> int ret;
>> + const struct khadas_mcu_fan_pdata *pdata =
>> dev_get_platdata(&pdev->dev);
>> ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
>> if (!ctx)
>> return -ENOMEM;
>> +
>> ctx->mcu = mcu;
>> + ctx->fan_reg = pdata->fan_reg;
>> + ctx->max_level = pdata->max_level;
>> +
>> + ctx->power = devm_regulator_get_optional(dev->parent, "fan");
>> + if (IS_ERR(ctx->power)) {
>> + if (PTR_ERR(ctx->power) == -ENODEV)
>> + ctx->power = NULL;
>> + else
>> + return PTR_ERR(ctx->power);
>> + }
>> +
>> + if (ctx->power) {
>> + ret = regulator_enable(ctx->power);
>> + if (ret) {
>> + dev_err(dev, "Failed to enable fan power supply: %d\n",
>> ret);
>> + return ret;
>> + }
>> + }
>> +
>> platform_set_drvdata(pdev, ctx);
>> cdev = devm_thermal_of_cooling_device_register(dev->parent,
>> @@ -130,6 +154,13 @@ static int khadas_mcu_fan_suspend(struct device
>> *dev)
>> static int khadas_mcu_fan_resume(struct device *dev)
>> {
>> struct khadas_mcu_fan_ctx *ctx = dev_get_drvdata(dev);
>> + int ret;
>> +
>> + if (ctx->power) {
>> + ret = regulator_enable(ctx->power);
>
> Seems you're missing a regulator_disable() on suspend.
>
> Neil
>
You right, I will add the regulator_disable on suspend for next version.
Thanks for your feedback.
>> + if (ret)
>> + return ret;
>> + }
>> return khadas_mcu_fan_set_level(ctx, ctx->level);
>> }
>>
>
--
Best regards,
Ronald
^ permalink raw reply
* [PATCH RESEND 2/2] stm class: Replace kzalloc + copy_from_user with memdup_user_nul
From: Thorsten Blum @ 2026-04-02 16:59 UTC (permalink / raw)
To: Alexander Shishkin, Maxime Coquelin, Alexandre Torgue
Cc: Thorsten Blum, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260402165933.895706-4-thorsten.blum@linux.dev>
Replace kzalloc() followed by copy_from_user() with memdup_user_nul() to
simplify and improve stm_char_policy_set_ioctl(). Remove the obsolete
comment.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/hwtracing/stm/core.c | 15 +++------------
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index 49791024bb86..f2c0f2b8f7b1 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -733,18 +733,9 @@ static int stm_char_policy_set_ioctl(struct stm_file *stmf, void __user *arg)
if (size < sizeof(*id) || size >= PATH_MAX + sizeof(*id))
return -EINVAL;
- /*
- * size + 1 to make sure the .id string at the bottom is terminated,
- * which is also why memdup_user() is not useful here
- */
- id = kzalloc(size + 1, GFP_KERNEL);
- if (!id)
- return -ENOMEM;
-
- if (copy_from_user(id, arg, size)) {
- ret = -EFAULT;
- goto err_free;
- }
+ id = memdup_user_nul(arg, size);
+ if (IS_ERR(id))
+ return PTR_ERR(id);
if (id->__reserved_0 || id->__reserved_1)
goto err_free;
^ permalink raw reply related
* [PATCH RESEND 1/2] stm class: Replace kmalloc + copy_from_user with memdup_user
From: Thorsten Blum @ 2026-04-02 16:59 UTC (permalink / raw)
To: Alexander Shishkin, Maxime Coquelin, Alexandre Torgue
Cc: Thorsten Blum, linux-stm32, linux-arm-kernel, linux-kernel
Replace kmalloc() followed by copy_from_user() with memdup_user() to
simplify and improve stm_char_write().
Allocate and copy only 'count' bytes instead of 'count + 1' since the
extra byte is unused.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/hwtracing/stm/core.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index 37584e786bb5..49791024bb86 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -645,15 +645,9 @@ static ssize_t stm_char_write(struct file *file, const char __user *buf,
return err;
}
- kbuf = kmalloc(count + 1, GFP_KERNEL);
- if (!kbuf)
- return -ENOMEM;
-
- err = copy_from_user(kbuf, buf, count);
- if (err) {
- kfree(kbuf);
- return -EFAULT;
- }
+ kbuf = memdup_user(buf, count);
+ if (IS_ERR(kbuf))
+ return PTR_ERR(kbuf);
pm_runtime_get_sync(&stm->dev);
^ permalink raw reply related
* Re: [PATCH v3] PCI: imx6: Don't remove MSI capability for i.MX7D/i.MX8M
From: Manivannan Sadhasivam @ 2026-04-02 16:57 UTC (permalink / raw)
To: frank.li, l.stach, lpieralisi, kwilczynski, robh, bhelgaas,
s.hauer, kernel, festevam, Richard Zhu
Cc: linux-pci, linux-arm-kernel, imx, linux-kernel, stable
In-Reply-To: <20260331085252.1243108-1-hongxing.zhu@nxp.com>
On Tue, 31 Mar 2026 16:52:52 +0800, Richard Zhu wrote:
> The MSI trigger mechanism for endpoint devices connected to i.MX7D,
> i.MX8MM, and i.MX8MQ PCIe root complex ports depends on the MSI
> capability register settings in the root complex. Removing the MSI
> capability breaks MSI functionality for these endpoints.
>
> Add keep_rp_msi_en flag to indicate platforms (i.MX7D, i.MX8MM, i.MX8MQ)
> that should preserve the MSI capability during initialization.
>
> [...]
Applied, thanks!
[1/1] PCI: imx6: Don't remove MSI capability for i.MX7D/i.MX8M
commit: a9de12c04779729f6d404192a5320c2e4dac0968
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* [PATCH RESEND] thermal/drivers/brcmstb_thermal: Use max to simplify brcmstb_get_temp
From: Thorsten Blum @ 2026-04-02 16:56 UTC (permalink / raw)
To: Markus Mayer, Broadcom internal kernel review list,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Florian Fainelli
Cc: Thorsten Blum, linux-pm, linux-arm-kernel, linux-kernel
Use max() to simplify brcmstb_get_temp() and improve its readability.
Since avs_tmon_code_to_temp() returns an int, change the data type of
the local variable 't' from long to int. No functional changes.
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/thermal/broadcom/brcmstb_thermal.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/thermal/broadcom/brcmstb_thermal.c b/drivers/thermal/broadcom/brcmstb_thermal.c
index f46f2ddc174e..a9ffa596f7c0 100644
--- a/drivers/thermal/broadcom/brcmstb_thermal.c
+++ b/drivers/thermal/broadcom/brcmstb_thermal.c
@@ -16,6 +16,7 @@
#include <linux/irqreturn.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
+#include <linux/minmax.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/platform_device.h>
@@ -154,7 +155,7 @@ static int brcmstb_get_temp(struct thermal_zone_device *tz, int *temp)
{
struct brcmstb_thermal_priv *priv = thermal_zone_device_priv(tz);
u32 val;
- long t;
+ int t;
val = __raw_readl(priv->tmon_base + AVS_TMON_STATUS);
@@ -164,10 +165,7 @@ static int brcmstb_get_temp(struct thermal_zone_device *tz, int *temp)
val = (val & AVS_TMON_STATUS_data_msk) >> AVS_TMON_STATUS_data_shift;
t = avs_tmon_code_to_temp(priv, val);
- if (t < 0)
- *temp = 0;
- else
- *temp = t;
+ *temp = max(0, t);
return 0;
}
^ permalink raw reply related
* Re: [PATCH net v4 0/2] stmmac crash/stall fixes when under memory pressure
From: Sam Edwards @ 2026-04-02 16:53 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Maxime Coquelin, Alexandre Torgue, Russell King (Oracle),
Maxime Chevallier, Ovidiu Panait, Vladimir Oltean, Baruch Siach,
Serge Semin, Giuseppe Cavallaro, netdev, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260402080542.293e8729@kernel.org>
On Thu, Apr 2, 2026 at 8:05 AM Jakub Kicinski <kuba@kernel.org> wrote:
> I meant we need both a threshold, and a delay :(
Hi Jakub - got it: when the critical threshold is reached, allow the
NAPI instance to sleep and start a timer instead.
1) We'd either have to leave interrupts masked or let them race
against the timer. Either one is manageable, but I feel like those
interactions carry *just* enough regression risk to bump that patch to
-next.
2) Could you point out which NAPI driver best handles this situation?
I'd like to replicate its approach.
Thanks,
Sam
^ permalink raw reply
* Re: [PATCH v2] iommu: Always fill in gather when unmapping
From: Jason Gunthorpe @ 2026-04-02 16:51 UTC (permalink / raw)
To: Robin Murphy
Cc: Alexandre Ghiti, AngeloGioacchino Del Regno, Albert Ou, asahi,
Baolin Wang, iommu, Janne Grunau, Jernej Skrabec, Joerg Roedel,
Jean-Philippe Brucker, linux-arm-kernel, linux-mediatek,
linux-riscv, linux-sunxi, Matthias Brugger, Neal Gompa,
Orson Zhai, Palmer Dabbelt, Paul Walmsley, Samuel Holland,
Sven Peter, virtualization, Chen-Yu Tsai, Will Deacon, Yong Wu,
Chunyan Zhang, Lu Baolu, Janusz Krzysztofik, Joerg Roedel,
Jon Hunter, patches, Pranjal Shrivastava, Samiullah Khawaja,
stable, Vasant Hegde
In-Reply-To: <70a128f9-d6f0-41b6-8fef-e249c0507149@arm.com>
On Thu, Apr 02, 2026 at 04:59:29PM +0100, Robin Murphy wrote:
> > @@ -666,9 +666,22 @@ static size_t __arm_lpae_unmap(struct arm_lpae_io_pgtable *data,
> > /* Clear the remaining entries */
> > __arm_lpae_clear_pte(ptep, &iop->cfg, i);
> > - if (gather && !iommu_iotlb_gather_queued(gather))
> > - for (int j = 0; j < i; j++)
> > - io_pgtable_tlb_add_page(iop, gather, iova + j * size, size);
> > + if (gather && !iommu_iotlb_gather_queued(gather)) {
> > + if (iop->cfg.tlb && iop->cfg.tlb->tlb_add_range) {
> > + iop->cfg.tlb->tlb_add_range(gather, iova,
> > + i * size, size,
> > + iop->cookie);
> > +
> > + } else {
> > + iommu_iotlb_gather_add_range(gather, iova,
> > + i * size);
> > +
> > + for (int j = 0; j < i; j++)
> > + io_pgtable_tlb_add_page(iop, gather,
> > + iova + j * size,
> > + size);
> > + }
> > + }
>
> NAK, this is insane.
This quite an optimization for SMMUv3 so it doesn't have to fit into
the ill fitting add_page api. What is "insane" here?
> If you'd rather make gathers mandatory for all drivers than fix it in the
> core code, then for goodness' sake just add the trivial one-liner to the
> handful of .unamp_pages implementations which need it,
Do I understand this right, you want to not touch io-pgtable and
instead the unmap trampolines will fix the gather like mkt is doing?
Jason
^ permalink raw reply
* Re: [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA
From: Paul Kocialkowski @ 2026-04-02 16:50 UTC (permalink / raw)
To: Krzysztof Hałasa
Cc: dri-devel, imx, linux-arm-kernel, linux-kernel, Marek Vasut,
Stefan Agner, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lucas Stach, Marco Felsch,
Liu Ying
In-Reply-To: <m3y0j8mhoz.fsf@t19.piap.pl>
[-- Attachment #1: Type: text/plain, Size: 9092 bytes --]
Hi Krzysztof,
On Tue 31 Mar 26, 12:11, Krzysztof Hałasa wrote:
> Paul Kocialkowski writes:
> > It is necessary to wait for the full frame to finish streaming
> > through the DMA engine before we can safely disable it by removing
> > the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
> > hardware confused and unable to resume streaming for the next frame.
> >
> > This causes the FIFO underrun and empty status bits to be set and
> > a single solid color to be shown on the display, coming from one of
> > the pixels of the previous frame. The issue occurs sporadically when
> > a new mode is set, which triggers the crtc disable and enable paths.
> >
> > Setting the shadow load bit and waiting for it to be cleared by the
> > DMA engine allows waiting for completion.
> >
> > The NXP BSP driver addresses this issue with a hardcoded 25 ms sleep.
>
> ...or "addressed" in the previous version :-)
>
> Test results: it works for me: at 1080p60 and 2160p30. I.e. it fixed the
> underrun problem. It's interesting how a CRTC shutdown can affect it's
> subsequent start following an SW_RESET.
Thanks for confirming! Indeed it's a bit surprising. I'm not sure what SW_RESET
does exactly but it may not concern the DMA part. I've tried using it in the
irq handler when the underrun is reported and it didn't do anything at all.
> Or... perhaps it has something to do with the clocks? Also see below.
> If somehow the DMA engine was "running" with it's clock disabled, it
> would result in an underrun, or worse.
Interestingly I tried to keep the clocks always on as an experiment and it
had the opposite effect: the DMA engine would get confused every time after the
first mode set and disable. So for some reason the disabling of the clocks seems
to mitigate the issue rather than aggravate it.
I think the issue probably boils down to a corrupted internal state of the DMA
engine if it is disabled while streaming pixels. This is more or less what the
comment from NXP suggests.
> BTW apparently something converted your tab characters into spaces.
Ah good to know, thanks!
> > --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > @@ -393,6 +393,22 @@ static void lcdif_disable_controller(struct lcdif_drm_private *lcdif)
> > if (ret)
> > drm_err(lcdif->drm, "Failed to disable controller!\n");
> >
> > + /*
> > + * It is necessary to wait for the full frame to finish streaming
> > + * through the DMA engine before we can safely disable it by removing
> > + * the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
> > + * hardware confused and unable to resume streaming for the next frame.
> > + */
> > + reg = readl(lcdif->base + LCDC_V8_CTRLDESCL0_5);
> > + reg |= CTRLDESCL0_5_SHADOW_LOAD_EN;
> > + writel(reg, lcdif->base + LCDC_V8_CTRLDESCL0_5);
> > +
> > + ret = readl_poll_timeout(lcdif->base + LCDC_V8_CTRLDESCL0_5,
> > + reg, !(reg & CTRLDESCL0_5_SHADOW_LOAD_EN),
> > + 0, 36000); /* Wait ~2 frame times max */
>
> I guess this comment is not necessarily correct - at 2160p30 one frame =
> ca. 33 ms. Still works, though (I guess anything more than one frame is
> enough). I don't know how long a frame on HDMI (or LVDS, MIPI etc.) can
> take. 30 FPS on 2160p is common because the i.MX8MP can't display 2160p60.
Honestly I think we're good assuming 30 fps (33 ms) is a lower bound.
And the current 36 ms goes even beyond, so I think it's fine.
> Also, found an issue. Perhaps unrelated? Powered the board without HDMI
> connected. Then connected 1080p60 display. It came in 1024x768, console
> 64x24 :-)
That looks more related to a failure to fetch the EDID from the monitor.
1024x768 is the default fallback that is used in this situation.
Maybe check if there is something wrong with the DDC lines from the hdmi
controller, maybe pinmux etc.
> Run weston. Pressed ctrl-alt-backspace. It deadlocked. Sysrq (serial
> console, show blocked state) showed (with *lcdif* in it):
> task:systemd-logind state:D stack:0 pid:253 tgid:253 ppid:1 task_flags:0x400100 flags:0x00000800
> Call trace:
> ...
> schedule+0x34/0x118
> rpm_resume+0x188/0x678
> __pm_runtime_resume+0x4c/0x98
> clk_pm_runtime_get.part.0.isra.0+0x1c/0x94
> clk_core_set_rate_nolock+0xd0/0x2fc
> clk_set_rate+0x38/0x158
> lcdif_crtc_atomic_enable+0x74/0x8d0
> drm_atomic_helper_commit_crtc_enable+0xac/0x104
> drm_atomic_helper_commit_tail_rpm+0x68/0xd8
> commit_tail+0xa4/0x1a4
> drm_atomic_helper_commit+0x178/0x1a0
> drm_atomic_commit+0x8c/0xcc
> drm_client_modeset_commit_atomic+0x1f8/0x25c
> drm_client_modeset_commit_locked+0x60/0x17c
> __drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0x2c/0x8c
> drm_fb_helper_set_par+0x5c/0x78
> fb_set_var+0x190/0x35c
> fbcon_blank+0x178/0x24c
> do_unblank_screen+0xa8/0x19c
> vt_ioctl+0x4fc/0x14c0
> tty_ioctl+0x228/0xb88
> __arm64_sys_ioctl+0x90/0xe4
> ...
>
> This is reproducible, though not always.
That seems to be in the enable path and related to runtime pm.
I don't think it is related to my patch at all.
> It seems it locks on some mutex - the shell works until I do 'cat
> log.txt' or similar. Now (with std output/error redirection?), weston
> doesn't even start.
>
> dmesg doesn't show anything of interest.
> weston: 14.0.2
> using /dev/dri/card1
> DRM: supports atomic modesetting
> DRM: supports GBM modifiers
> DRM: does not support Atomic async page flip
> DRM: supports picture aspect ratio
> Loading module '/usr/lib64/libweston-14/gl-renderer.so'
> Using rendering device: /dev/dri/renderD128
> EGL version: 1.5
> EGL vendor: Mesa Project
> EGL client APIs: OpenGL OpenGL_ES
> ...
> Registered plugin API 'weston_drm_output_api_v1' of size 40
> Registered plugin API 'weston_drm_virtual_output_api_v2' of size 48
> Color manager: no-op
> protocol support: no
> Output 'HDMI-A-1' attempts EOTF mode SDR and colorimetry mode default.
> Output 'HDMI-A-1' using color profile: stock sRGB color profile
> Chosen EGL config details: id: 17 rgba: 8 8 8 0 buf: 24 dep: 0 stcl: 0 int: 1-1 type: win vis_id: XRGB8
> )
> Output HDMI-A-1 (crtc 37) video modes:
> 1920x1080@60.0, preferred, current, 148.5 MHz
>
> Output 'HDMI-A-1' enabled with head(s) HDMI-A-1
> Loading module '/usr/lib64/weston/desktop-shell.so'
> launching '/usr/libexec/weston-keyboard'
> launching '/usr/libexec/weston-desktop-shell'
> Warning: computed repaint delay for output [HDMI-A-1] is abnormal: -69164 msec (happens always)
>
> could not load cursor 'dnd-copy'
> could not load cursor 'dnd-copy'
> could not load cursor 'dnd-none'
> could not load cursor 'dnd-none'
>
> Why all these clk* mutexes? Perhaps something didn't work out as it
> should there? clk_set_rate isn't supposed to take much time, is it?
Maybe something to do with the clock driver.
It seems pretty much unrelated to the lcdif driver.
All the best,
Paul
> $ grep clk /tmp/minicom.cap -C1
> [ 728.310054] __pm_runtime_resume+0x4c/0x98
> [ 728.310059] clk_pm_runtime_get.part.0.isra.0+0x1c/0x94
> [ 728.310065] clk_core_set_rate_nolock+0xd0/0x2fc
> [ 728.310071] clk_set_rate+0x38/0x158
> [ 728.310076] lcdif_crtc_atomic_enable+0x74/0x8d0
> --
> [ 728.310210] mutex_lock+0x48/0x58
> [ 728.310216] clk_prepare_lock+0x80/0xc0
> [ 728.310223] clk_unprepare+0x28/0x44
> [ 728.310227] fsl_samsung_hdmi_phy_suspend+0x24/0x40
> --
> [ 728.310344] mutex_lock+0x48/0x58
> [ 728.310350] clk_prepare_lock+0x80/0xc0
> [ 728.310359] clk_unprepare+0x28/0x44
> [ 728.310364] etnaviv_gpu_clk_disable.isra.0+0x28/0x80
> [ 728.310372] etnaviv_gpu_rpm_suspend+0x78/0x1dc
> --
> [ 728.310494] mutex_lock+0x48/0x58
> [ 728.310499] clk_prepare_lock+0x80/0xc0
> [ 728.310506] clk_unprepare+0x28/0x44
> [ 728.310512] sdhci_esdhc_runtime_suspend+0x7c/0x198
> --
> [ 728.310627] mutex_lock+0x48/0x58
> [ 728.310632] clk_prepare_lock+0x80/0xc0
> [ 728.310639] clk_round_rate+0x38/0x1d8
> [ 728.310646] dev_pm_opp_set_rate+0xe4/0x2e0
> --
> [ 728.310760] mutex_lock+0x48/0x58
> [ 728.310765] clk_prepare_lock+0x80/0xc0
> [ 728.310771] clk_prepare+0x1c/0x50
> [ 728.310778] sdhci_esdhc_runtime_resume+0x34/0x180
> --
> [ 728.311286] mutex_lock+0x48/0x58
> [ 728.311292] clk_prepare_lock+0x80/0xc0
> [ 728.311298] clk_prepare+0x1c/0x50
> [ 728.311303] sdhci_esdhc_runtime_resume+0x34/0x180
>
> Something fishy here.
> --
> Krzysztof "Chris" Hałasa
>
> Sieć Badawcza Łukasiewicz
> Przemysłowy Instytut Automatyki i Pomiarów PIAP
> Al. Jerozolimskie 202, 02-486 Warszawa
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 3/8] firmware: sysfb: Make CONFIG_SYSFB a user-selectable option
From: Arnd Bergmann @ 2026-04-02 16:47 UTC (permalink / raw)
To: Thomas Zimmermann, Javier Martinez Canillas, Ard Biesheuvel,
Ilias Apalodimas, Huacai Chen, WANG Xuerui, Maarten Lankhorst,
Maxime Ripard, Dave Airlie, Simona Vetter, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, longli, Helge Deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev
In-Reply-To: <001efe27-9cbb-4a89-8d2d-a1f3ae15e505@suse.de>
On Thu, Apr 2, 2026, at 17:27, Thomas Zimmermann wrote:
> Am 02.04.26 um 16:59 schrieb Arnd Bergmann:
>> On Thu, Apr 2, 2026, at 16:10, Thomas Zimmermann wrote:
>>> Am 02.04.26 um 15:08 schrieb Arnd Bergmann:
>>>> On Thu, Apr 2, 2026, at 11:09, Thomas Zimmermann wrote:
>>>> I don't really like this part of the series and would prefer
>>>> to keep CONFIG_SYSFB hidden as much as possible as an x86
>>>> (and EFI) specific implementation detail, with the hope
>>>> of eventually seperating out the x86 bits from the EFI ones.
>>> You mean, you want to use the EFI-provided framebuffers without the
>>> intermediate step of going through sysfb_primary_display?
>>>
>>> In that case, CONFIG_SYSFB would become an x86-internal thing, right?
>> The part that is still needed from sysfb is the arbitration
>> between DRM_EFI and the PCI device driver for the same hardware,
>> so I think some part of sysfb is clearly needed, in particular
>> the sysfb_disable() function that removes the EFI framebuffer
>> when there is a conflicting simpledrm or hardware specific
>> driver.
>
> We do most of that in the aperture-helper module. (see
> <linux/aperture.h>). Calling sysfb_disable() from there is a workaround
> for some corner cases. We can have an EFI-specific function that does
> the same.
That sounds good, yes. The same change would need to go into
of_platform_default_populate_init() then.
> BTW, simpledrm-on-EFI/VESA is considered obsolete and should preferably
> be removed from that driver. Simpledrm should become a driver for
> Devicetree nodes of type simple-framebuffer (as it originally has been
> intended).
Sure, I was only thinking of the case where there are both
sysfb (from Arm/riscv UEFI) and simpledrm (from devicetree)
objects referring to the same one, not the simpledrm
device created by sysfb_simplefb.
>> The parts that I want to keep out of that is anything
>> related to the x86 boot protocol, non-EFI framebuffers,
>> text console, and kexec handoff, which we don't need on
>> non-x86 UEFI systems.
>>
>> I don't mind the idea of having a sysfb_primary_display
>> in the EFI code if that helps keep EFI sane on x86,
>> but it would be good to make that local to
>> drivers/firmware/efi and (eventually) detached from
>> include/uapi/linux/screen_info.h.
>
> Efidrm retrieves the framebuffer settings from the contained struct
> screen_info. Disconnecting from screen_info would require separate
> graphics drivers for x86 and non-x86. If we split off EFI from sysfb,
> we'd likely need a sysfbdrm driver of some sort. Just saying.
Yes, I saw that as well and don't have an immediate idea for how
to best do it. I saw that you already abstracted the access to
the screen_info members in drm_sysfb_screen_info.c, which I think
is a step in that direction.
I also noticed that efidrm is mostly a subset of vesadrm, so
in theory they could be merged back into an x86 drm driver
along with the drm_sysfb_screen_info helpers, and have a non-x86
driver that constructs a drm_sysfb_device directly from the
EFI structures.
> I think we'd also have to duplicate the framebuffer-relocation code that
> currently works on anything using struct screen_info (see patch 5).
You mean the code from include/linux/screen_info.h? I think
it would make sense to have an x86 specific version of that
to operate on the x86 screen_info, and a simpler version
that just updates the resource for the efirdrm driver, but
that could also be done one level higher or lower.
>>>> In general, I am always in favor of properly using Kconfig
>>>> dependencies over 'select' statements, for the same reasons
>>>> you describe, but I don't want the the x86 logic for
>>>> the legacy VESA and VGA console handling to leak into more
>>>> architectures than necessary.
>>>>
>>>> Do you think we could instead move the sysfb_init()
>>>> function into the same two places that contain the
>>>> sysfb_primary_display definition (arch/x86/kernel/setup.c,
>>>> drivers/firmware/efi/efi-init.c) and simplify the efi version
>>>> to take out the x86 bits? That would reduce the rest
>>>> of sysfb-primary.c to the logic to unregister the device,
>>>> and that could then be selected by both x86 and EFI.
>>> No, I'm more than happy that sysfb finally consolidates all the
>>> init-framebuffer setup and detection that floated around in the kernel.
>>> I would not want it to be duplicated again.
>>>
>>> For now, we could certainly keep CONFIG_SYSFB hidden and autoselected.
>>> Although I think this will require soem sort of solution at a later point.
>> Can you clarify which problem you are trying to solve
>> with that?
>
> One thing is that some users simply what control over their kernel build.
>
> I also think that there might be systems that want to use
> sysfb_primary_display (plus the relocation feature), but not create the
> framebuffer device. Say for efi-earlycon. It needs user-control over the
> SYSFB option to do that.
I'm still not following, sorry. efi-earlycon doesn't require
CONFIG_SYSFB today, and I don't see why that would need to change,
or why it couldn't just 'select SYSFB' if it it does change.
> As a side-effect, user-configurable SYSFB gives us a nice place to put
> SYSFB_SIMPLEFB and FIRMWARE_EDID; two options that currently float
> around in the config somewhat arbitrarily.
You said that SYSFB_SIMPLEFB should get phased out in the future,
right?
I'm also missing your plan for CONFIG_FIRMWARE_EDID. I only
see three legacy drivers using the old fb_firmware_edid()
interface, so I assume this is not what you are interested in.
For the global copy that is filled by x86 and efi, and
consumed by vesadrm and efidrm, does that even need to
be a configuration option rather than get always enabled?
Arnd
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: gpio: Add eio gpio node to gpio-zynq
From: Krzysztof Kozlowski @ 2026-04-02 16:48 UTC (permalink / raw)
To: Shubhrajyoti Datta, linux-kernel
Cc: git, shubhrajyoti.datta, Srinivas Neeli, Michal Simek,
Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <c28e97b2-4266-4a32-b70d-049518c606fe@kernel.org>
On 02/04/2026 18:46, Krzysztof Kozlowski wrote:
> On 02/04/2026 18:38, Shubhrajyoti Datta wrote:
>> Add the EIO gpio node to the device tree.
>
> What is EIO? A name of new SoC? Or you forgot to include the SoC here?
>
>
>> The EIO GPIO block exposes only bank 0 and bank 1 to
>> multiplexed I/O pins, providing a fixed total of 52 GPIO lines
>> (2 banks × 26 pins). Enforce this hardware constraint by requiring
>> exactly 52 entries in gpio-line-names for the EIO variant.
>
> Don't describe the syntax. We can read the diff.
>
I also receive immediate Out of office bounces when replying. Please do
not cc addresses of people who cannot set up correctly their
autoresponder and send to open source Out of office messages.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: gpio: Add eio gpio node to gpio-zynq
From: Krzysztof Kozlowski @ 2026-04-02 16:46 UTC (permalink / raw)
To: Shubhrajyoti Datta, linux-kernel
Cc: git, shubhrajyoti.datta, Srinivas Neeli, Michal Simek,
Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <20260402163840.938417-2-shubhrajyoti.datta@amd.com>
On 02/04/2026 18:38, Shubhrajyoti Datta wrote:
> Add the EIO gpio node to the device tree.
What is EIO? A name of new SoC? Or you forgot to include the SoC here?
> The EIO GPIO block exposes only bank 0 and bank 1 to
> multiplexed I/O pins, providing a fixed total of 52 GPIO lines
> (2 banks × 26 pins). Enforce this hardware constraint by requiring
> exactly 52 entries in gpio-line-names for the EIO variant.
Don't describe the syntax. We can read the diff.
>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
> ---
>
> .../devicetree/bindings/gpio/gpio-zynq.yaml | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
> index 5e2496379a3c..b8dd279753a5 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
> +++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
> @@ -16,6 +16,7 @@ properties:
> - xlnx,zynqmp-gpio-1.0
> - xlnx,versal-gpio-1.0
> - xlnx,pmc-gpio-1.0
> + - xlnx,eio-gpio-1.0
Please keep some sane ordering.
>
Best regards,
Krzysztof
^ permalink raw reply
* ✅ PASS: Test report for for-kernelci (7.0.0-rc6, upstream-arm-next, 2465c01b)
From: cki-project @ 2026-04-02 16:43 UTC (permalink / raw)
To: will, linux-arm-kernel, catalin.marinas
Hi, we tested your kernel and here are the results:
Overall result: PASSED
Merge: OK
Compile: OK
Test: OK
Tested-by: CKI Project <cki-project@redhat.com>
Kernel information:
Commit message: Merge remote-tracking branch 'origin/nocache-cleanup' into for-kernelci
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:2425851817
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
^ permalink raw reply
* Re: [PATCH v5 1/4] kernel: ksysfs: initialize kernel_kobj earlier
From: Bartosz Golaszewski @ 2026-04-02 16:40 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann, driver-core,
linux-kernel, linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <DHITFGL3J4IE.2WZU3K2CSYL7I@kernel.org>
On Thu, Apr 2, 2026 at 6:39 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Thu Apr 2, 2026 at 4:15 PM CEST, Bartosz Golaszewski wrote:
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 0f258aeeacba184d2025b932d90280cf2aabf4b0..8bc934162e712cf8ddf033e53bf3481054cfb7fe 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -7843,6 +7843,7 @@ F: include/linux/debugfs.h
> > F: include/linux/device.h
> > F: include/linux/fwnode.h
> > F: include/linux/kobj*
> > +F: include/linux/ksysfs.h
>
> Currently, kernel/ksysfs.c is not listed in the driver core entry (it is not in
> any entry), but I guess that would make sense.
>
> So, we should probably also add kernel/ksysfs.c. :) But this can be a separate
> patch independent of this series.
Ok, I take it no need to resend this?
Bart
^ permalink raw reply
* [PATCH 2/2] gpio: zynq: Add eio gpio support
From: Shubhrajyoti Datta @ 2026-04-02 16:38 UTC (permalink / raw)
To: linux-kernel
Cc: git, shubhrajyoti.datta, Shubhrajyoti Datta, Srinivas Neeli,
Michal Simek, Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <20260402163840.938417-1-shubhrajyoti.datta@amd.com>
Add support for the EIO GPIO controller found on
xa2ve3288 silicon.
The EIO GPIO block provides access to multiplexed I/O pins exposed
through the EIO interface. Only bank 0 and bank 1 are connected to
external MIO pins, with 26 GPIOs per bank (52 GPIOs total). This
change extends the Zynq GPIO driver to support the EIO GPIO
variant.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
---
drivers/gpio/gpio-zynq.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
index 571e366624d2..8118ae3412c2 100644
--- a/drivers/gpio/gpio-zynq.c
+++ b/drivers/gpio/gpio-zynq.c
@@ -25,6 +25,7 @@
#define VERSAL_GPIO_MAX_BANK 4
#define PMC_GPIO_MAX_BANK 5
#define VERSAL_UNUSED_BANKS 2
+#define EIO_GPIO_MAX_BANK 2
#define ZYNQ_GPIO_BANK0_NGPIO 32
#define ZYNQ_GPIO_BANK1_NGPIO 22
@@ -818,6 +819,16 @@ static const struct dev_pm_ops zynq_gpio_dev_pm_ops = {
RUNTIME_PM_OPS(zynq_gpio_runtime_suspend, zynq_gpio_runtime_resume, NULL)
};
+static const struct zynq_platform_data eio_gpio_def = {
+ .label = "eio_gpio",
+ .ngpio = 52,
+ .max_bank = EIO_GPIO_MAX_BANK,
+ .bank_min[0] = 0,
+ .bank_max[0] = 25, /* 0 to 25 are connected to MIOs (26 pins) */
+ .bank_min[1] = 26,
+ .bank_max[1] = 51, /* Bank 1 are connected to MIOs (26 pins) */
+};
+
static const struct zynq_platform_data versal_gpio_def = {
.label = "versal_gpio",
.quirks = GPIO_QUIRK_VERSAL,
@@ -882,6 +893,7 @@ static const struct of_device_id zynq_gpio_of_match[] = {
{ .compatible = "xlnx,zynqmp-gpio-1.0", .data = &zynqmp_gpio_def },
{ .compatible = "xlnx,versal-gpio-1.0", .data = &versal_gpio_def },
{ .compatible = "xlnx,pmc-gpio-1.0", .data = &pmc_gpio_def },
+ { .compatible = "xlnx,eio-gpio-1.0", .data = &eio_gpio_def },
{ /* end of table */ }
};
MODULE_DEVICE_TABLE(of, zynq_gpio_of_match);
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox