* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Geert Uytterhoeven @ 2026-06-29 15:29 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Walleij, Bartosz Golaszewski, Arnd Bergmann,
Marcel Holtmann, MyungJoo Ham, Chanwoo Choi, Geert Uytterhoeven,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, linux-bluetooth,
linux-kernel, linux-gpio, dri-devel, linux-i2c, linux-iio,
linux-input, linux-mmc, linux-arm-kernel, linux-pm, linux-usb
In-Reply-To: <20260629135917.1308621-1-arnd@kernel.org>
Hi Arnd,
On Mon, 29 Jun 2026 at 15:59, Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Most remaining users of desc_to_gpio() only call it for printing debug
> information.
>
> Replace this with a new gpiod_name() helper that returns the
> gpio_desc->name string after checking the gpio_desc pointer.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks for your patch!
> Not sure if this the way we want to take this, or if the gpio name is
> an appropriate replacement in debug printk.
>
> Since most of the callers of desc_to_gpio() and gpio_to_desc() are
> otherwise in drivers that already depend on CONFIG_GPIOLIB_LEGACY and
> include linux/gpio/legacy.h, only a handful of instances remain that
> are otherwise in files that otherwise only use the descriptor interfaces:
> --- a/drivers/gpio/gpio-aggregator.c
> +++ b/drivers/gpio/gpio-aggregator.c
> @@ -758,8 +758,8 @@ int gpiochip_fwd_desc_add(struct gpiochip_fwd *fwd, struct gpio_desc *desc,
>
> fwd->descs[offset] = desc;
>
> - dev_dbg(chip->parent, "%u => gpio %d irq %d\n", offset,
> - desc_to_gpio(desc), gpiod_to_irq(desc));
> + dev_dbg(chip->parent, "%u => gpio %s irq %d\n", offset,
> + gpiod_name(desc), gpiod_to_irq(desc));
>
> return 0;
> }
Before, this printed:
gpio-aggregator gpio-aggregator.1: 0 => gpio 589 irq 188
gpio-aggregator gpio-aggregator.1: 1 => gpio 590 irq 189
After, this prints:
gpio-aggregator gpio-aggregator.1: 0 => gpio (null) irq 188
gpio-aggregator gpio-aggregator.1: 1 => gpio (null) irq 189
Same results for instantiation using sysfs or configfs[1], although
the latter does have optional support for specifying the name.
[1] Documentation/admin-guide/gpio/gpio-aggregator.rst
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: (subset) [PATCH v6 0/4] Update the thermal support for imx93
From: Frank.Li @ 2026-06-29 15:36 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Fabio Estevam, Pengutronix Kernel Team, Jacky Bai
Cc: Frank Li, linux-pm, devicetree, imx, linux-arm-kernel,
Conor Dooley, Alice Guo
In-Reply-To: <20260430-imx93_tmu-v6-0-485459d7b54f@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Thu, 30 Apr 2026 10:53:29 +0800, Jacky Bai wrote:
> The TMU (Thermal Monitoring Unit) on the i.MX93 requires specific
> configurations and workarounds that differ from previous implementations.
> So, using the 'fsl,qoriq-tmu' compatible string is not appropriate.
> To address this, a dedicated compatible string and corresponding driver
> changes need to be introduced to properly support the i.MX93 TMU.
>
>
> [...]
Applied, thanks!
[4/4] arm64: dts: imx93: update the tmu compatible string
commit: d911a33fa8e9fd4c691bc8429180fe1885bc3f2f
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v2 2/6] clk: sunxi-ng: sun6i-rtc: clean up DT usage
From: Chen-Yu Tsai @ 2026-06-29 15:37 UTC (permalink / raw)
To: Jerome Brunet
Cc: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jernej Skrabec, Samuel Holland, Michael Turquette,
Stephen Boyd, Maxime Ripard, linux-rtc, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-clk
In-Reply-To: <20260629-a733-rtc-v2-2-7b72112784f8@baylibre.com>
On Mon, Jun 29, 2026 at 8:42 PM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> With sun6i-rtc compatible devices, the "ext-osc32k" clock input
> is optional for the devices that support this input (r329 and onward).
>
> Probably preparing for older SoC support, the driver does something funny
> when parsing DT. It check if "ext-osc32k" is present in the clock-names and
> if it is not, it uses the first clock as "ext-osc32k". This clock will
> actually be the rtc bus clock so what the driver does is wrong.
>
> At the moment, the driver does not support the older SoCs that would have
> an external 32k clock provided on index #0 so just remove this quirk.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: RE: [PATCH v3 01/10] mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()
From: Sebastian Andrzej Siewior @ 2026-06-29 15:38 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-rt-devel@lists.linux.dev, Bjorn Andersson, Clark Williams,
Fabio Estevam, Frank Li, Jassi Brar, Mathieu Poirier,
Pengutronix Kernel Team, Sascha Hauer, Steven Rostedt
In-Reply-To: <MRWPR04MB12330C5851B5421F8EE723F1A88EB2@MRWPR04MB12330.eurprd04.prod.outlook.com>
On 2026-06-26 09:00:04 [+0000], Peng Fan (OSS) wrote:
> > > If you would like to address the AI reported issue further, you may
> > > update readl_poll_timeout to readl_poll_timeout_atomic.
> >
> > What about the timeout value? Keep it as-is or reduce to?
>
> Let's keep it as-is.
The call is
readl_poll_timeout(, , , delay_us = 0, timeout_us = 10000);
so it will _not_ trigger the might_sleep() splat and will compare the
timeout value against ktime_get() so it will loop worst case for 10ms.
If I change it as-is to
readl_poll_timeout_atomic(, , , delay_us = 0, timeout_us = 10000);
then the result is slightly different: The clocksource is not used
(because it also works in suspend path where it is gone) and so the
timeout_us value is decremented based on the delay_us. If it is 0 then
it only subtracts 1ns per iteration. So the worst case delay becomes now
10.000.000 iterations.
I don't think this is an improvement: In the worst case the delay is
much longer and if there is a watch in that period, it will fire. So it
does not accomplish anything.
Having something like
readl_poll_timeout_atomic(, , , delay_us = 2, timeout_us = 100);
would lower the delay to 100us max (which is below the 1000HZ tick) and
would spin for 2us between register pools. But I have no idea what is
the expected delay and if it depends on the remote side.
Please be aware that this series except for the remoteproc/ imx_rproc)
has been merged as of v7.2-rc1. I can still send an update to the poll
in imx_mu_generic_tx() but I would prefer an improvement ;)
> Thanks,
> Peng.
Sebastian
^ permalink raw reply
* Re: (subset) [PATCH v6 0/7] pinctrl: Add generic pinctrl for board-level mux chips
From: Frank.Li @ 2026-06-29 15:43 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Peter Rosin, Frank Li
Cc: linux-kernel, linux-gpio, devicetree, imx, linux-arm-kernel,
Haibo Chen, Conor Dooley, Ahmad Fatoum
In-Reply-To: <20260504-pinctrl-mux-v6-0-8ea858ba3a5b@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Mon, 04 May 2026 19:54:34 -0400, Frank Li wrote:
> Add a generic pinctrl binding for board-level pinmux chips that are
> controlled through the multiplexer subsystem.
>
> On some boards, especially development boards, external mux chips are used
> to switch SoC signals between different peripherals (e.g. MMC and UART).
> The mux select lines are often driven by a GPIO expander over I2C,
> as illustrated below:
>
> [...]
Applied, thanks!
[6/7] arm64: dts: imx8mp-evk: add board-level mux for CAN2 and MICFIL
commit: ec5c75673cb9d4c9a2a55a70d54a6ccb254f4ba4
[7/7] arm64: dts: imx8mp-evk: add flexcan2 overlay file
commit: 368eb597c6ef0263931a3922648e8c7b83cd0536
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH] remoteproc: xlnx: refactor start & stop ops
From: Mathieu Poirier @ 2026-06-29 15:44 UTC (permalink / raw)
To: Tanmay Shah
Cc: michal.simek, andersson, linux-arm-kernel, linux-kernel,
linux-remoteproc
In-Reply-To: <20260619163854.410392-1-tanmay.shah@amd.com>
On Fri, Jun 19, 2026 at 09:38:54AM -0700, Tanmay Shah wrote:
> Current _start and _stop ops are implemented using various APIs from the
> platform management firmware driver. Instead provide respective RPU
> start and stop API in the firmware driver and move the logic to interact
> with the PM firmware in the firmware driver. The remoteproc driver doesn't
> need to know actual logic, but only the final result i.e. RPU start/stop
> was success or not. This refactor keeps the remoteproc driver simple and
> moves firmware interaction logic to the firmware driver.
>
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> ---
> drivers/firmware/xilinx/zynqmp.c | 93 +++++++++++++++++++++++++
> drivers/remoteproc/xlnx_r5_remoteproc.c | 68 ++----------------
> include/linux/firmware/xlnx-zynqmp.h | 12 ++++
> 3 files changed, 110 insertions(+), 63 deletions(-)
>
Applied.
Thanks,
Mathieu
> diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
> index af838b2dc327..f9a3a95b0638 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -1513,6 +1513,99 @@ int zynqmp_pm_request_wake(const u32 node,
> }
> EXPORT_SYMBOL_GPL(zynqmp_pm_request_wake);
>
> +/**
> + * zynqmp_pm_start_rpu - Boot Real-time Processing Unit (Cortex-R) on SoC
> + *
> + * @node: power-domains id of the core
> + * @bootaddr: Boot address of elf
> + *
> + * Return: status, either success or error+reason
> + */
> +int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr)
> +{
> + enum rpu_boot_mem bootmem;
> + int ret;
> +
> + /*
> + * The exception vector pointers (EVP) refer to the base-address of
> + * exception vectors (for reset, IRQ, FIQ, etc). The reset-vector
> + * starts at the base-address and subsequent vectors are on 4-byte
> + * boundaries.
> + *
> + * Exception vectors can start either from 0x0000_0000 (LOVEC) or
> + * from 0xFFFF_0000 (HIVEC) which is mapped in the OCM (On-Chip Memory)
> + *
> + * Usually firmware will put Exception vectors at LOVEC.
> + *
> + * It is not recommend that you change the exception vector.
> + * Changing the EVP to HIVEC will result in increased interrupt latency
> + * and jitter. Also, if the OCM is secured and the Cortex-R5F processor
> + * is non-secured, then the Cortex-R5F processor cannot access the
> + * HIVEC exception vectors in the OCM.
> + */
> + bootmem = (bootaddr >= 0xFFFC0000) ?
> + PM_RPU_BOOTMEM_HIVEC : PM_RPU_BOOTMEM_LOVEC;
> +
> + pr_debug("RPU boot addr 0x%llx from %s.", bootaddr,
> + bootmem == PM_RPU_BOOTMEM_HIVEC ? "OCM" : "TCM");
> +
> + /* Request node before starting RPU core if new version of API is supported */
> + if (zynqmp_pm_feature(PM_REQUEST_NODE) > PM_API_VERSION_1) {
> + ret = zynqmp_pm_request_node(node,
> + ZYNQMP_PM_CAPABILITY_ACCESS, 0,
> + ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> + if (ret < 0) {
> + pr_err("failed to request 0x%x", node);
> + return ret;
> + }
> + }
> +
> + ret = zynqmp_pm_request_wake(node, true,
> + bootmem, ZYNQMP_PM_REQUEST_ACK_NO);
> + if (ret)
> + pr_err("failed to start RPU = 0x%x\n", node);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(zynqmp_pm_start_rpu);
> +
> +/**
> + * zynqmp_pm_stop_rpu - Stop Real-time Processing Unit (Cortex-R) on SoC
> + *
> + * @node: power-domains id of the core
> + *
> + * Return: status, either success or error+reason
> + */
> +int zynqmp_pm_stop_rpu(const u32 node)
> +{
> + int ret;
> +
> + /* Use release node API to stop core if new version of API is supported */
> + if (zynqmp_pm_feature(PM_RELEASE_NODE) > PM_API_VERSION_1) {
> + ret = zynqmp_pm_release_node(node);
> + if (ret)
> + pr_err("failed to stop remoteproc RPU %d\n", ret);
> + return ret;
> + }
> +
> + /*
> + * Check expected version of EEMI call before calling it. This avoids
> + * any error or warning prints from firmware as it is expected that fw
> + * doesn't support it.
> + */
> + if (zynqmp_pm_feature(PM_FORCE_POWERDOWN) != PM_API_VERSION_1) {
> + pr_debug("EEMI interface %d ver 1 not supported\n",
> + PM_FORCE_POWERDOWN);
> + return -EOPNOTSUPP;
> + }
> +
> + /* maintain force pwr down for backward compatibility */
> + ret = zynqmp_pm_force_pwrdwn(node, ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> + if (ret)
> + pr_err("core force power down failed\n");
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(zynqmp_pm_stop_rpu);
> +
> /**
> * zynqmp_pm_set_requirement() - PM call to set requirement for PM slaves
> * @node: Node ID of the slave
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 3349d1877751..dcd8a93f031c 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -364,49 +364,12 @@ static void zynqmp_r5_rproc_kick(struct rproc *rproc, int vqid)
> static int zynqmp_r5_rproc_start(struct rproc *rproc)
> {
> struct zynqmp_r5_core *r5_core = rproc->priv;
> - enum rpu_boot_mem bootmem;
> int ret;
>
> - /*
> - * The exception vector pointers (EVP) refer to the base-address of
> - * exception vectors (for reset, IRQ, FIQ, etc). The reset-vector
> - * starts at the base-address and subsequent vectors are on 4-byte
> - * boundaries.
> - *
> - * Exception vectors can start either from 0x0000_0000 (LOVEC) or
> - * from 0xFFFF_0000 (HIVEC) which is mapped in the OCM (On-Chip Memory)
> - *
> - * Usually firmware will put Exception vectors at LOVEC.
> - *
> - * It is not recommend that you change the exception vector.
> - * Changing the EVP to HIVEC will result in increased interrupt latency
> - * and jitter. Also, if the OCM is secured and the Cortex-R5F processor
> - * is non-secured, then the Cortex-R5F processor cannot access the
> - * HIVEC exception vectors in the OCM.
> - */
> - bootmem = (rproc->bootaddr >= 0xFFFC0000) ?
> - PM_RPU_BOOTMEM_HIVEC : PM_RPU_BOOTMEM_LOVEC;
> -
> - dev_dbg(r5_core->dev, "RPU boot addr 0x%llx from %s.", rproc->bootaddr,
> - bootmem == PM_RPU_BOOTMEM_HIVEC ? "OCM" : "TCM");
> -
> - /* Request node before starting RPU core if new version of API is supported */
> - if (zynqmp_pm_feature(PM_REQUEST_NODE) > 1) {
> - ret = zynqmp_pm_request_node(r5_core->pm_domain_id,
> - ZYNQMP_PM_CAPABILITY_ACCESS, 0,
> - ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> - if (ret < 0) {
> - dev_err(r5_core->dev, "failed to request 0x%x",
> - r5_core->pm_domain_id);
> - return ret;
> - }
> - }
> -
> - ret = zynqmp_pm_request_wake(r5_core->pm_domain_id, 1,
> - bootmem, ZYNQMP_PM_REQUEST_ACK_NO);
> + ret = zynqmp_pm_start_rpu(r5_core->pm_domain_id, rproc->bootaddr);
> if (ret)
> - dev_err(r5_core->dev,
> - "failed to start RPU = 0x%x\n", r5_core->pm_domain_id);
> + dev_err(&rproc->dev, "failed to start RPU\n");
> +
> return ret;
> }
>
> @@ -423,30 +386,9 @@ static int zynqmp_r5_rproc_stop(struct rproc *rproc)
> struct zynqmp_r5_core *r5_core = rproc->priv;
> int ret;
>
> - /* Use release node API to stop core if new version of API is supported */
> - if (zynqmp_pm_feature(PM_RELEASE_NODE) > 1) {
> - ret = zynqmp_pm_release_node(r5_core->pm_domain_id);
> - if (ret)
> - dev_err(r5_core->dev, "failed to stop remoteproc RPU %d\n", ret);
> - return ret;
> - }
> -
> - /*
> - * Check expected version of EEMI call before calling it. This avoids
> - * any error or warning prints from firmware as it is expected that fw
> - * doesn't support it.
> - */
> - if (zynqmp_pm_feature(PM_FORCE_POWERDOWN) != 1) {
> - dev_dbg(r5_core->dev, "EEMI interface %d ver 1 not supported\n",
> - PM_FORCE_POWERDOWN);
> - return -EOPNOTSUPP;
> - }
> -
> - /* maintain force pwr down for backward compatibility */
> - ret = zynqmp_pm_force_pwrdwn(r5_core->pm_domain_id,
> - ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> + ret = zynqmp_pm_stop_rpu(r5_core->pm_domain_id);
> if (ret)
> - dev_err(r5_core->dev, "core force power down failed\n");
> + dev_err(&rproc->dev, "failed to stop RPU\n");
>
> return ret;
> }
> diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
> index 7e27b0f7bf7e..347df66ee176 100644
> --- a/include/linux/firmware/xlnx-zynqmp.h
> +++ b/include/linux/firmware/xlnx-zynqmp.h
> @@ -644,6 +644,8 @@ int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
> u32 *const requirements, u32 *const usage);
> int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
> u32 *const requirements, u32 *const usage);
> +int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr);
> +int zynqmp_pm_stop_rpu(const u32 node);
> int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config, u32 value);
> int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config,
> u32 value);
> @@ -960,6 +962,16 @@ static inline int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const statu
> return -ENODEV;
> }
>
> +static inline int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr)
> +{
> + return -ENODEV;
> +}
> +
> +static inline int zynqmp_pm_stop_rpu(const u32 node)
> +{
> + return -ENODEV;
> +}
> +
> static inline int zynqmp_pm_set_sd_config(u32 node,
> enum pm_sd_config_type config,
> u32 value)
>
> base-commit: 721396afea31eac476d88f5db10ba111ba4b8382
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Arnd Bergmann @ 2026-06-29 15:45 UTC (permalink / raw)
To: Andy Shevchenko, Arnd Bergmann
Cc: Linus Walleij, Bartosz Golaszewski, Marcel Holtmann, MyungJoo Ham,
Chanwoo Choi, Geert Uytterhoeven, Andy Shevchenko,
Dmitry Torokhov, Ulf Hansson, linux-bluetooth, linux-kernel,
open list:GPIO SUBSYSTEM, dri-devel, linux-i2c, linux-iio,
linux-input, linux-mmc @ vger . kernel . org, linux-arm-kernel,
linux-pm, linux-usb
In-Reply-To: <akKN59lv55CXS3HU@ashevche-desk.local>
On Mon, Jun 29, 2026, at 17:23, Andy Shevchenko wrote:
> On Mon, Jun 29, 2026 at 03:56:29PM +0200, Arnd Bergmann wrote:
>> +const char *gpiod_name(const struct gpio_desc *desc)
>> +{
>> + return desc ? desc->name : "(no gpio)";
>
> Can we get into here with wrong (error pointer descriptor)? Shouldn't you call
> one of validate_desc() / VALIDATE_DESC()?
Since all the callers previously call desc_to_gpio and that does
not even check desc at all, it would be a preexisting bug if
any caller passed an error pointer.
I added the NULL pointer check since many callers had that
part originally, like
tsdata->wake_gpio ? desc_to_gpio(tsdata->wake_gpio) : -1,
> Also not sure if "(no gpio)" is a good choice. "not requested"? "not provided"?
Any of those seem fine to me, not sure.
>> +static inline const char *gpiod_name(const struct gpio_desc *desc)
>> +{
>> + WARN_ON(desc);
>> + return "(no gpio)";
>
> Hmm... This will be a second copy with a slight potential of going apart from
> the other case. Perhaps a #define? (Yes, yes, I understand that there are pros
> and cons, in particular readability with define is questionable.)
I was mostly trying to optimize for consistency with the other
stub functions here. Since it should not actually be used at all
without gpiolib, returning NULL or an empty string here would
also work.
Arnd
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Arnd Bergmann @ 2026-06-29 15:48 UTC (permalink / raw)
To: Geert Uytterhoeven, Arnd Bergmann
Cc: Linus Walleij, Bartosz Golaszewski, Marcel Holtmann, MyungJoo Ham,
Chanwoo Choi, Geert Uytterhoeven, Andy Shevchenko,
Dmitry Torokhov, Ulf Hansson, linux-bluetooth, linux-kernel,
open list:GPIO SUBSYSTEM, dri-devel, linux-i2c, linux-iio,
linux-input, linux-mmc @ vger . kernel . org, linux-arm-kernel,
linux-pm, linux-usb
In-Reply-To: <CAMuHMdXhsM4JzArRuB=A46N-Ogbn2Fans+PVJVA-hEytFq=DeQ@mail.gmail.com>
On Mon, Jun 29, 2026, at 17:29, Geert Uytterhoeven wrote:
> On Mon, 29 Jun 2026 at 15:59, Arnd Bergmann <arnd@kernel.org> wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> Most remaining users of desc_to_gpio() only call it for printing debug
>> information.
>>
>> Replace this with a new gpiod_name() helper that returns the
>> gpio_desc->name string after checking the gpio_desc pointer.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Thanks for your patch!
Thanks for testing!
>> --- a/drivers/gpio/gpio-aggregator.c
>> +++ b/drivers/gpio/gpio-aggregator.c
>> @@ -758,8 +758,8 @@ int gpiochip_fwd_desc_add(struct gpiochip_fwd *fwd, struct gpio_desc *desc,
>>
>> fwd->descs[offset] = desc;
>>
>> - dev_dbg(chip->parent, "%u => gpio %d irq %d\n", offset,
>> - desc_to_gpio(desc), gpiod_to_irq(desc));
>> + dev_dbg(chip->parent, "%u => gpio %s irq %d\n", offset,
>> + gpiod_name(desc), gpiod_to_irq(desc));
>>
>> return 0;
>> }
>
> Before, this printed:
>
> gpio-aggregator gpio-aggregator.1: 0 => gpio 589 irq 188
> gpio-aggregator gpio-aggregator.1: 1 => gpio 590 irq 189
>
> After, this prints:
>
> gpio-aggregator gpio-aggregator.1: 0 => gpio (null) irq 188
> gpio-aggregator gpio-aggregator.1: 1 => gpio (null) irq 189
>
> Same results for instantiation using sysfs or configfs[1], although
> the latter does have optional support for specifying the name.
I wonder how many of the other instances have the same problem
then. Would it be appropriate for gpiochip_fwd_desc_add() to set
a name itself to address this one?
Arnd
^ permalink raw reply
* Re: [PATCH RFC v5 00/12] ZTE zx297520v3 clock bindings and driver
From: Conor Dooley @ 2026-06-29 15:49 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260628-zx29clk-v5-0-79ff044e4192@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]
On Sun, Jun 28, 2026 at 10:58:55PM +0300, Stefan Dösinger wrote:
> Hi,
>
> I am sending version 5 of my zx297520v3 clock patch. The major change is
> using regmaps rather than raw mmio to access the clocks and moving reset
> handling into its own mfd/aux bus driver.
>
> I think the list of clocks in my driver is fairly complete; It is
> certainly a lot better than what the downstream ZTE drivers have. I
> deduced a lot of it by trial and error. I am sure there are some clocks
> missing that will need to be added to the binding later. Afaiu adding
> clocks is not an issue, but removing or reordering them is an ABI break.
Correct, you can add whatever you want as long as the existing defines
do not change.
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
> ---
> Changes in v5:
> *) Use MFD instead of aux bus for top and matrix clocks
> *) Move top and matrix bindings to soc/zte
> *) Give USB PHY its own resets
> *) Other localized changes are noted in the individual patches
> - Link to v4: https://lore.kernel.org/r/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com
Bindings seem fine to me, I'll be happy to give you some r-b tags when
you go non-RFC. To be frank, I think you should drop them as you've got
no significant questions here I think and you'll be taken a bt more
seriously.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: (subset) [PATCH v5 0/6] Add support for Baijie Helper A133 board
From: Chen-Yu Tsai @ 2026-06-29 15:51 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland, Hans de Goede, Dmitry Torokhov, Andre Przywara,
Jun Yan, Lukas Schmid, J. Neuschäfer, Eric Biggers,
Michal Simek, Luca Weiss, Sven Peter, Maxime Ripard, devicetree,
linux-kernel, linux-input
In-Reply-To: <20260623204824.691832-1-alexander.sverdlin@gmail.com>
On Tue, 23 Jun 2026 22:48:12 +0200, Alexander Sverdlin wrote:
> Baijie Helper A133 board is a development board around Baijie A133 Core
> SBC. Features:
>
> - 1/2/4GiB LPDDR4 DRAM
> - 8/16/32GiB eMMC
> - AXP707 PMIC
> - USB-C OTG port in peripheral mode (via onboard hub)
> - 2 USB 2.0 ports
> - MicroSD slot and on-board eMMC module
> - Gigabit Ethernet
> - Bluetooth
> - WiFi
>
> [...]
Applied to sunxi/config-for-7.3 in local tree, thanks!
[1/6] arm64: defconfig: Enable Allwinner LRADC input driver
commit: b4158103c45386ab30ba7624bee17ebf33940baa
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 0/4] arm64: cross-CPU NMI via SDEI
From: Catalin Marinas @ 2026-06-29 15:54 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Will Deacon, James Morse, Mark Rutland, Marc Zyngier,
Doug Anderson, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel
In-Reply-To: <akJsQK2iG2oZ3vYE@thinkstation>
On Mon, Jun 29, 2026 at 02:05:14PM +0100, Kiryl Shutsemau wrote:
> On Fri, Jun 26, 2026 at 08:40:57PM +0100, Kiryl Shutsemau wrote:
> > But I have not tried calling CPU_OFF directly, without completing the
> > event. I assumed it is required. Will give it a try when I have time.
>
> Tried it now, and it doesn't work either -- in a more interesting way.
>
> Calling PSCI CPU_OFF directly from the SDEI handler (event left
> uncompleted) reproducibly breaks the kdump capture kernel, and this
> reproduces under QEMU's TF-A, not just on Grace -- so it isn't a Grace
> firmware quirk.
I had a quick grep (with the help of claude) through the TF-A code and
it doesn't seem to be compliant with the spec. It should subscribe to
the PSCI CPU_OFF event and complete the SDEI but it doesn't. It seems to
handle CPU_ON but that may not be sufficient. It only EIOs the SGI once
the OS completed the event, which doesn't happen if you issue CPU_OFF.
> The test: a CPU wedged with interrupts masked is stopped via the SDEI
> rung; its handler calls __cpu_try_die() instead of parking. A/B in QEMU,
> changing only that wedged CPU's handling (everything else identical):
>
> - park it (current series): capture kernel boots fully to a shell.
> - CPU_OFF from the handler: capture kernel hangs in early boot, around
> SDEI re-init, never reaches a shell.
>
> Powering the PE off while its SDEI event is still active leaves EL3's
> dispatch state dangling, and the capture kernel trips over it. Completing
> the event first and then CPU_OFF -- what I tried originally -- silently
> wedges EL3 on Grace instead.
>
> So both routes off fail, and the CPU stays parked. The dump is complete
> either way; only re-onlining the stopped CPU in an SMP capture kernel is
> lost. It's a cheap QEMU repro now if anyone wants to dig into the EL3
> side.
Have you tried SDEI_EVENT_COMPLETE_AND_RESUME instead? Just COMPLETE
won't return to the kernel. We have sdei_handler_abort() to complete the
event and, hopefully, you can continue with the CPU_OFF. It's a work
around the TF-A non-compliance but I think this is useful even if you
don't issue the CPU_OFF (e.g. no CPU hotplug, just the park loop).
--
Catalin
^ permalink raw reply
* Re: [PATCH 0/2] CPPC: reduce FFH feedback-counter sampling skew on arm64
From: Sumit Gupta @ 2026-06-29 15:54 UTC (permalink / raw)
To: Pengjie Zhang, catalin.marinas, will, rafael, lenb, robert.moore,
beata.michalska, zhenglifeng1, zhanjie9, cuiyunhui
Cc: linux-arm-kernel, linux-kernel, linux-acpi, acpica-devel,
linuxarm, jonathan.cameron, prime.zeng, wanghuiqiang, xuwei5,
lihuisong, yubowen8, wangzhi12, linux-tegra@vger.kernel.org
In-Reply-To: <20260410094145.4132082-1-zhangpengjie2@huawei.com>
On 10/04/26 15:11, Pengjie Zhang wrote:
> External email: Use caution opening links or attachments
>
>
> The legacy CPPC feedback-counter path reads the delivered and reference
> performance counters separately.
>
> On arm64 systems using AMU-backed CPPC FFH counters, each FFH read is
> served through a cross-CPU counter read helper. Reading the counters
> separately therefore widens the sampling window between them and can
> skew the delivered/reference ratio used by cpuinfo_cur_freq. Under heavy
> load, the skew is observable as transient values that may exceed the
> platform maximum, as discussed in [1] and [2].
>
> This series adds a small generic hook for architectures that can obtain
> both FFH feedback counters in one operation, while preserving the
> existing per-register read path as the fallback.
>
> Patch 1 adds the generic CPPC hook and uses it from cppc_get_perf_ctrs().
> Patch 2 implements the hook on arm64 by sampling both AMU counters in a
> single operation on the target CPU.
>
> [1] https://lore.kernel.org/all/20231025093847.3740104-4-zengheng4@huawei.com/
> [2] https://lore.kernel.org/all/20231212072617.14756-1-lihuisong@huawei.com/
>
> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
>
> Pengjie Zhang (2):
> ACPI: CPPC: add paired FFH feedback-counter read hook
> arm64: topology: read CPPC FFH feedback counters in one operation
>
> arch/arm64/kernel/topology.c | 75 ++++++++++++++++++++++++++++++++----
> drivers/acpi/cppc_acpi.c | 58 +++++++++++++++++++++++++---
> include/acpi/cppc_acpi.h | 7 ++++
> 3 files changed, 127 insertions(+), 13 deletions(-)
>
> --
Hi Pengjie,
Thanks for the patches.
The series looks good to me, and it fixes the cpuinfo_cur_freq
spikes on an NVIDIA Vera (FFH) platform.
Just one nit on patch 2 (counter read order), noted there.
Tested-by: Sumit Gupta <sumitg@nvidia.com>
Reviewed-by: Sumit Gupta <sumitg@nvidia.com>
Thanks,
Sumit
^ permalink raw reply
* [PATCH] raspberrypi: vchiq: free recycle buffer on thread exit
From: Yousef Alhouseen @ 2026-06-29 16:03 UTC (permalink / raw)
To: Florian Fainelli
Cc: Broadcom internal kernel review list, linux-rpi-kernel,
linux-arm-kernel, linux-kernel, Yousef Alhouseen
recycle_func() allocates a bitmap used while processing the free queue,
but returns directly when remote_event_wait() fails. The normal
kthread-stop path also exits without releasing the allocation.
Break out of the loop on wait errors, free the bitmap, and return the
saved status so both the error and stop paths release the per-thread
buffer.
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
---
drivers/platform/raspberrypi/vchiq-interface/vchiq_core.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/raspberrypi/vchiq-interface/vchiq_core.c b/drivers/platform/raspberrypi/vchiq-interface/vchiq_core.c
index 48d6b1d74329..f8b2d4b1a30e 100644
--- a/drivers/platform/raspberrypi/vchiq-interface/vchiq_core.c
+++ b/drivers/platform/raspberrypi/vchiq-interface/vchiq_core.c
@@ -2346,7 +2346,7 @@ recycle_func(void *v)
struct vchiq_shared_state *local = state->local;
u32 *found;
size_t length;
- int ret;
+ int ret = 0;
length = sizeof(*found) * BITSET_SIZE(VCHIQ_MAX_SERVICES);
@@ -2358,11 +2358,12 @@ recycle_func(void *v)
while (!kthread_should_stop()) {
ret = remote_event_wait(&state->recycle_event, &local->recycle);
if (ret)
- return ret;
+ break;
process_free_queue(state, found, length);
}
- return 0;
+ kfree(found);
+ return ret;
}
/* Called by the sync thread */
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v5 0/5] Add support for AAEON SRG-IMX8P MCU
From: Thomas Perrot @ 2026-06-29 16:04 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Lee Jones
Cc: thomas.perrot@bootlin.com, devicetree, linux-kernel, linux-gpio,
imx, linux-arm-kernel, linux-watchdog, Thomas Petazzoni,
Miquel Raynal, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski
In-Reply-To: <b4396f57-3501-4e89-9cf3-8dc5d7cad9b7@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 3120 bytes --]
Hello Guenter,
On Sat, 2026-04-11 at 17:12 -0700, Guenter Roeck wrote:
> snip
>
> Sashiko has some interesting feedback that might be worth looking
> into.
>
> https://sashiko.dev/#/patchset/20260408-dev-b4-aaeon-mcu-driver-v5-0-ad98bd481668%40bootlin.com
>
Thanks for the pointer. I went through all findings and addressed the
valid ones in v6:
MFD driver:
- Set I2C_M_DMA_SAFE on all i2c_msg flags. The buffers were already
heap-allocated for DMA safety but the flag was missing, which
would have caused unnecessary bounce-buffering by the host driver.
- Add select REGMAP to config MFD_AAEON_MCU
- "Kconfig COMPILE_TEST link failure": I2C || COMPILE_TEST lets
MFD_AAEON_MCU=y even when I2C=m (tristate OR caps to y), which
would fail to link since i2c_transfer(), only exist when I2C
itself is built in. Will drop the COMPILE_TEST escape and just use
depends on I2C, matching the other I2C MFD drivers in this file.
GPIO driver:
- Replace __set_bit/__clear_bit/__assign_bit with their atomic
counterparts. gpiolib does not serialize across pins, so
concurrent direction changes on different pins could race on the
shared bitmaps.
- Reverse the order in aaeon_mcu_gpio_config_output_cmd(): write the
output value first, then switch the pin to output mode, to avoid a
potential glitch if the previously latched value differs.
- Add MODULE_ALIAS("platform:aaeon-mcu-gpio") for udev auto-loading.
Watchdog driver:
- Add WDIOF_SETTIMEOUT and watchdog_init_timeout() so the software
timeout is configurable via ioctl, DT timeout-sec, or the
watchdog_timeout boot parameter. This also addresses the concern
you raised about the hardcoded 240s timeout.
- Add watchdog_stop_on_reboot() so the MCU watchdog is stopped
during system shutdown, preventing a spurious reset from the
external MCU.
- Add MODULE_ALIAS("platform:aaeon-mcu-wdt") for udev auto-loading.
The following findings were considered false positives:
- "Heap buffer overflow during bulk writes": with reg_bits=16 and
val_bits=8, regcache_sync() calls _regmap_write() per register, so
the write callback always receives exactly 3 bytes (2 reg + 1
val).
No bulk path reaches the custom bus callback.
- "Stack DMA violation in read path": val_buf comes from regmap's
own
heap-allocated work_buf, not a stack pointer, so DMA safety is
guaranteed by the regmap core.
- "I2C interleaving race": Concurrent access from child drivers
(GPIO and watchdog) is serialized by regmap's internal mutex,
which is held for the entire bus transaction ; both i2c_transfer()
calls complete under that lock before another caller can enter.
- "Missing PM suspend/resume callbacks": the watchdog core already
handles this via watchdog_pm_ops, which calls wdt->ops->stop() on
system suspend.
Kind regards,
Thomas
> Guenter
>
--
Thomas Perrot, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply
* Re: (subset) [PATCH v5 0/6] Add support for Baijie Helper A133 board
From: Chen-Yu Tsai @ 2026-06-29 16:08 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland, Hans de Goede, Dmitry Torokhov, Andre Przywara,
Jun Yan, Lukas Schmid, J. Neuschäfer, Eric Biggers,
Michal Simek, Luca Weiss, Sven Peter, Maxime Ripard, devicetree,
linux-kernel, linux-input
In-Reply-To: <20260623204824.691832-1-alexander.sverdlin@gmail.com>
On Tue, 23 Jun 2026 22:48:12 +0200, Alexander Sverdlin wrote:
> Baijie Helper A133 board is a development board around Baijie A133 Core
> SBC. Features:
>
> - 1/2/4GiB LPDDR4 DRAM
> - 8/16/32GiB eMMC
> - AXP707 PMIC
> - USB-C OTG port in peripheral mode (via onboard hub)
> - 2 USB 2.0 ports
> - MicroSD slot and on-board eMMC module
> - Gigabit Ethernet
> - Bluetooth
> - WiFi
>
> [...]
Applied to sunxi/dt-for-7.3 in local tree, thanks!
[2/6] dt-bindings: vendor-prefixes: Add Shenzhen Baijie Technology Co., Ltd.
commit: c3600c97eb9c1a20a933a7fba08272955f7a7ccc
[3/6] dt-bindings: arm: sunxi: Add Baijie HelperBoard A133 compatible
commit: 1d81cb06c30746448deb73b6ce9ceccc9fb6ca37
[4/6] dt-bindings: input: sun4i-lradc-keys: Add A100/A133 compatible
commit: 5e5e8a2e5a5e31fbe8858f08ef7ac44dff9ee351
[5/6] arm64: dts: allwinner: a100: Add LRADC node
commit: 8fa3a2bf77f0adb5440f25c3e2951543691e1536
[6/6] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
commit: 7204944dcb8f1131b6303a5e9ca11128eb20ac21
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 1/2] arm64: dts: imx94: Correct PCIe outbound address space configuration
From: Frank.Li @ 2026-06-29 16:11 UTC (permalink / raw)
To: sherry.sun, robh, krzk+dt, conor+dt, frank.li, s.hauer, festevam,
hongxing.zhu
Cc: Frank Li, kernel, devicetree, imx, linux-arm-kernel, linux-kernel,
Richard Zhu
In-Reply-To: <20260604023821.134372-1-hongxing.zhu@oss.nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Thu, 04 Jun 2026 10:38:20 +0800, hongxing.zhu@oss.nxp.com wrote:
> Fix the PCIe outbound memory ranges for both pcie0 controllers on i.MX94.
>
> The memory window size was incorrectly set to 256MB during initial
> bring-up, but the hardware supports up to 4GB of outbound address space
> per controller.
>
> Additionally, the ECAM region cannot be mapped as I/O space. Use a
> memory-mapped region for I/O space instead, and relocate the 1MB I/O
> region to immediately follow the memory region at offset 0xf0000000
> within each window.
>
> [...]
Applied, thanks!
[1/2] arm64: dts: imx94: Correct PCIe outbound address space configuration
commit: ffccbd6804e885f0fc23f0005f6bee7789a7a887
[2/2] arm64: dts: imx943: Correct PCIe outbound address space configuration
commit: 6de3a7d7a4f653be4901d07425719c4e55805167
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: (subset) [PATCH V3 0/8] PCI: imx6: Integrate pwrctrl API and update device trees
From: Frank.Li @ 2026-06-29 16:15 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam, lpieralisi,
kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach,
Sherry Sun (OSS)
Cc: Frank Li, imx, linux-pci, linux-arm-kernel, devicetree,
linux-kernel, sherry.sun
In-Reply-To: <20260520084904.2424253-1-sherry.sun@oss.nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Wed, 20 May 2026 16:48:56 +0800, Sherry Sun (OSS) wrote:
> From: Sherry Sun <sherry.sun@nxp.com>
>
> This series integrates the PCI pwrctrl framework into the pci-imx6
> driver and updates i.MX EVK board device trees to support it.
>
> Patches 2-8 update device trees for i.MX EVK boards which maintained
> by NXP to move power supply properties from the PCIe controller node
> to the Root Port child node, which is required for pwrctrl framework.
> Affected boards:
> - i.MX6Q/DL SABRESD
> - i.MX6SX SDB
> - i.MX8MM EVK
> - i.MX8MP EVK
> - i.MX8MQ EVK
> - i.MX8DXL/QM/QXP EVK
> - i.MX95 15x15/19x19 EVK
>
> [...]
Applied, thanks!
[4/8] arm64: dts: imx8mm-evk: Move power supply property to Root Port node
commit: 1d054c3d7ba2acf95140d2296a7500c44b28756f
[5/8] arm64: dts: imx8mp-evk: Move power supply properties to Root Port node
commit: 6be00d898ed3bf5cacc90bc58b8ab760ad5f26a2
[6/8] arm64: dts: imx8mq-evk: Move power supply properties to Root Port node
commit: d6dd43676b6acb4967060a27c711a482b687142a
[7/8] arm64: dts: imx8dxl/qm/qxp: Move power supply properties to Root Port node
commit: b3731b730e6f0256bed55562cef39e61aea006be
[8/8] arm64: dts: imx95: Move power supply properties to Root Port node
commit: 0ac3b96903603e3a0c9e0ce732716837ddd86c7b
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* [PATCH net-next v6 0/2] airoha: add the capability to configure GDM3/GDM4 as WAN/LAN on demand
From: Lorenzo Bianconi @ 2026-06-29 16:17 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: Simon Horman, Alexander Lobakin, linux-arm-kernel, linux-mediatek,
netdev, Madhur Agrawal
Add the capability to configure GDM3/GDM4 as WAN/LAN on demand when QoS
offload is created or destroyed.
Make dev->qdma an RCU pointer so the TX path can safely dereference it
without holding RTNL.
Introduce airoha_qdma_start() and airoha_qdma_stop() helpers.
---
Changes in v6:
- Rebase on top of next-next
- Add patch 1/3: "rename airoha_priv_flags to airoha_dev_flags"
- Drop patch 2/3: "refactor QDMA start/stop into reusable helpers"
- Link to v5: https://lore.kernel.org/r/20260611-airoha-ethtool-priv_flags-v5-0-c11de08486d1@kernel.org
Changes in v5:
- Add patch 1/3: use int instead of atomic_t for qdma users counter
- Protect dev->flags with flow_offload_mutex mutex.
- Introduce AIROHA_PRIV_F_QOS in order to handle better WAN/LAN
switching.
- Link to v4: https://lore.kernel.org/r/20260610-airoha-ethtool-priv_flags-v4-0-60e89cf28fea@kernel.org
Changes in v4:
- Move back QDMA TX/RX DMA enable to airoha_dev_open()/airoha_dev_stop().
- Configure GDM3/4 as WAN if GDM2 is not available in ndo_init()
callback.
- Protect qdma pointer in airoha_gdm_dev struct using RCU.
- Rely on rtnl_dereference() to access qdma pointer in the control path.
- Add airoha_qdma_start() and airoha_qdma_stop() utility routines in
patch 1/2
- Link to v3: https://lore.kernel.org/r/20260608-airoha-ethtool-priv_flags-v3-1-3e8e3dc3f715@kernel.org
Changes in v3:
- Do not introduce ethtool private flags support to configure LAN/WAN
for GDM3/4 and rely on tc qdisc offload for it instead.
- Set GDM3/4 ports as LAN by default.
- Move QDMA TX/RX DMA enable from airoha_dev_open() to airoha_probe()
and the corresponding disable from airoha_dev_stop() to airoha_qdma_cleanup().
- Link to v2: https://lore.kernel.org/r/20260607-airoha-ethtool-priv_flags-v2-1-742c7aa1e182@kernel.org
Changes in v2:
- Rework airoha_dev_set_wan_flag routine
- Enable GDM_STRIP_CRC_MASK in airoha_disable_gdm2_loopback()
- Do not always reset REG_SRC_PORT_FC_MAP6 in
airoha_disable_gdm2_loopback() but use the same condition used in
airoha_enable_gdm2_loopback().
- Link to v1: https://lore.kernel.org/r/20260606-airoha-ethtool-priv_flags-v1-1-401b2c9fe9f1@kernel.org
---
Lorenzo Bianconi (2):
net: airoha: rename airoha_priv_flags to airoha_dev_flags
net: airoha: defer GDM3/GDM4 WAN mode and GDM2 loopback to QoS offload
drivers/net/ethernet/airoha/airoha_eth.c | 231 ++++++++++++++++++++++++++----
drivers/net/ethernet/airoha/airoha_eth.h | 19 ++-
drivers/net/ethernet/airoha/airoha_ppe.c | 9 +-
drivers/net/ethernet/airoha/airoha_regs.h | 1 +
4 files changed, 223 insertions(+), 37 deletions(-)
---
base-commit: 805185b7c7a1069e407b6f7b3bc98e44d415f484
change-id: 20260606-airoha-ethtool-priv_flags-b6aa70caa780
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply
* [PATCH net-next v6 1/2] net: airoha: rename airoha_priv_flags to airoha_dev_flags
From: Lorenzo Bianconi @ 2026-06-29 16:17 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: Simon Horman, Alexander Lobakin, linux-arm-kernel, linux-mediatek,
netdev
In-Reply-To: <20260629-airoha-ethtool-priv_flags-v6-0-86bc600d31bc@kernel.org>
Rename the airoha_priv_flags enum to airoha_dev_flags and the
AIROHA_PRIV_F_WAN flag to AIROHA_DEV_F_WAN. The "priv_flags" naming
dates back to an earlier design that used ethtool private flags; since
this series switched to tc qdisc offload for LAN/WAN configuration,
align the naming to reflect that these are per-device flags rather than
ethtool private flags. No functional change.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
drivers/net/ethernet/airoha/airoha_eth.h | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 932b3a3df2e5..8bba54ebcf07 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -2048,7 +2048,7 @@ static int airoha_dev_init(struct net_device *netdev)
fallthrough;
case AIROHA_GDM2_IDX:
/* GDM2 is always used as wan */
- dev->flags |= AIROHA_PRIV_F_WAN;
+ dev->flags |= AIROHA_DEV_F_WAN;
break;
default:
break;
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index d7ff8c5200e2..87ab3ea10664 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -535,8 +535,8 @@ struct airoha_qdma {
DECLARE_BITMAP(qos_channel_map, AIROHA_NUM_QOS_CHANNELS);
};
-enum airoha_priv_flags {
- AIROHA_PRIV_F_WAN = BIT(0),
+enum airoha_dev_flags {
+ AIROHA_DEV_F_WAN = BIT(0),
};
struct airoha_gdm_dev {
@@ -659,7 +659,7 @@ static inline u16 airoha_qdma_get_txq(struct airoha_qdma *qdma, u16 qid)
static inline bool airoha_is_lan_gdm_dev(struct airoha_gdm_dev *dev)
{
- return !(dev->flags & AIROHA_PRIV_F_WAN);
+ return !(dev->flags & AIROHA_DEV_F_WAN);
}
static inline bool airoha_is_7581(struct airoha_eth *eth)
--
2.54.0
^ permalink raw reply related
* [PATCH net-next v6 2/2] net: airoha: defer GDM3/GDM4 WAN mode and GDM2 loopback to QoS offload
From: Lorenzo Bianconi @ 2026-06-29 16:17 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: Simon Horman, Alexander Lobakin, linux-arm-kernel, linux-mediatek,
netdev, Madhur Agrawal
In-Reply-To: <20260629-airoha-ethtool-priv_flags-v6-0-86bc600d31bc@kernel.org>
GDM3 and GDM4 ports require GDM2 loopback to be enabled for hardware
QoS offload to function. Without it, HTB and ETS offload on these ports
do not work.
Previously, GDM3/GDM4 ports were automatically configured as WAN with
GDM2 loopback enabled during ndo_init(). Add the capability to configure
GDM3/GDM4 as WAN/LAN on demand when QoS offload is created or destroyed.
Hook airoha_enable_qos_for_gdm34() into TC_HTB_CREATE so that requesting
HTB offload on a GDM3/GDM4 LAN port switches it to WAN mode and enables
GDM2 loopback, with proper rollback on failure. Introduce the
AIROHA_DEV_F_QOS flag to track whether a device has an active HTB
qdisc; clear it on TC_HTB_DESTROY. The device keeps its WAN role after
qdisc teardown so that its configuration is preserved until another
device explicitly needs the WAN role for QoS offload.
If another GDM3/GDM4 device already holds the WAN role without an active
QoS qdisc, demote it to LAN before promoting the requesting device. Skip
the demotion when the requesting device is itself already the WAN device.
Since airoha_dev_set_qdma() can now be called on a running device to
migrate between QDMA blocks, make dev->qdma an RCU pointer so the TX
path can safely dereference it without holding RTNL.
Hold flow_offload_mutex in airoha_enable_qos_for_gdm34() and
airoha_disable_qos_for_gdm34() around the dev->flags update,
airoha_dev_set_qdma() and GDM2 loopback configuration, serializing
against concurrent airoha_ppe_hw_init() in the TC_SETUP_CLSFLOWER
offload path.
Introduce airoha_qdma_deref() helper that wraps rcu_dereference_protected()
with a lockdep condition accepting either rtnl_lock or flow_offload_mutex,
and use it across all control-path dereferences of the RCU-protected
dev->qdma pointer.
Add airoha_disable_gdm2_loopback() to disable GDM2 hw loopback.
Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 229 ++++++++++++++++++++++++++----
drivers/net/ethernet/airoha/airoha_eth.h | 13 +-
drivers/net/ethernet/airoha/airoha_ppe.c | 9 +-
drivers/net/ethernet/airoha/airoha_regs.h | 1 +
4 files changed, 219 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 8bba54ebcf07..231c8f2f20dd 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -929,7 +929,7 @@ static void airoha_qdma_wake_netdev_txqs(struct airoha_queue *q)
if (!dev)
continue;
- if (dev->qdma != qdma)
+ if (rcu_access_pointer(dev->qdma) != qdma)
continue;
netdev = netdev_from_priv(dev);
@@ -1837,13 +1837,14 @@ static int airoha_dev_open(struct net_device *netdev)
struct airoha_gdm_dev *dev = netdev_priv(netdev);
struct airoha_gdm_port *port = dev->port;
u32 cur_len, pse_port = FE_PSE_PORT_PPE1;
- struct airoha_qdma *qdma = dev->qdma;
+ struct airoha_qdma *qdma;
netif_tx_start_all_queues(netdev);
err = airoha_set_vip_for_gdm_port(dev, true);
if (err)
return err;
+ qdma = airoha_qdma_deref(dev);
if (netdev_uses_dsa(netdev))
airoha_fe_set(qdma->eth, REG_GDM_INGRESS_CFG(port->id),
GDM_STAG_EN_MASK);
@@ -1903,7 +1904,6 @@ static int airoha_dev_stop(struct net_device *netdev)
{
struct airoha_gdm_dev *dev = netdev_priv(netdev);
struct airoha_gdm_port *port = dev->port;
- struct airoha_qdma *qdma = dev->qdma;
netif_tx_disable(netdev);
airoha_set_vip_for_gdm_port(dev, false);
@@ -1911,7 +1911,7 @@ static int airoha_dev_stop(struct net_device *netdev)
if (--port->users)
airoha_set_port_mtu(dev->eth, port);
else
- airoha_set_gdm_port_fwd_cfg(qdma->eth,
+ airoha_set_gdm_port_fwd_cfg(dev->eth,
REG_GDM_FWD_CFG(port->id),
FE_PSE_PORT_DROP);
return 0;
@@ -1998,6 +1998,53 @@ static int airoha_enable_gdm2_loopback(struct airoha_gdm_dev *dev)
return 0;
}
+static int airoha_disable_gdm2_loopback(struct airoha_gdm_dev *dev)
+{
+ struct airoha_gdm_port *port = dev->port;
+ struct airoha_eth *eth = dev->eth;
+ int i, src_port;
+ u32 pse_port;
+
+ src_port = eth->soc->ops.get_sport(dev->port, dev->nbq);
+ if (src_port < 0)
+ return src_port;
+
+ airoha_fe_clear(eth,
+ REG_SP_DFT_CPORT(src_port >> fls(SP_CPORT_DFT_MASK)),
+ SP_CPORT_MASK(src_port & SP_CPORT_DFT_MASK));
+
+ airoha_fe_set(eth, REG_GDM_FWD_CFG(AIROHA_GDM2_IDX),
+ GDM_STRIP_CRC_MASK);
+ airoha_set_gdm_port_fwd_cfg(eth, REG_GDM_FWD_CFG(AIROHA_GDM2_IDX),
+ FE_PSE_PORT_DROP);
+ airoha_fe_clear(eth, REG_GDM_LPBK_CFG(AIROHA_GDM2_IDX),
+ LPBK_CHAN_MASK | LPBK_MODE_MASK | LPBK_EN_MASK);
+ pse_port = airoha_ppe_is_enabled(eth, 1) ? FE_PSE_PORT_PPE2
+ : FE_PSE_PORT_PPE1;
+ airoha_set_gdm_port_fwd_cfg(eth, REG_GDM_FWD_CFG(AIROHA_GDM2_IDX),
+ pse_port);
+
+ airoha_fe_rmw(eth, REG_FE_WAN_PORT, WAN0_MASK,
+ FIELD_PREP(WAN0_MASK, AIROHA_GDM2_IDX));
+
+ for (i = 0; i < eth->soc->num_ppe; i++)
+ airoha_fe_clear(eth, REG_PPE_DFT_CPORT(i, AIROHA_GDM2_IDX),
+ DFT_CPORT_MASK(AIROHA_GDM2_IDX));
+
+ /* Enable VIP and IFC for GDM2 */
+ airoha_fe_set(eth, REG_FE_VIP_PORT_EN, BIT(AIROHA_GDM2_IDX));
+ airoha_fe_set(eth, REG_FE_IFC_PORT_EN, BIT(AIROHA_GDM2_IDX));
+
+ if (port->id == AIROHA_GDM4_IDX && airoha_is_7581(eth)) {
+ u32 mask = FC_ID_OF_SRC_PORT_MASK(dev->nbq);
+
+ airoha_fe_rmw(eth, REG_SRC_PORT_FC_MAP6, mask,
+ FC_MAP6_DEF_VALUE & mask);
+ }
+
+ return 0;
+}
+
static struct airoha_gdm_dev *
airoha_get_wan_gdm_dev(struct airoha_eth *eth)
{
@@ -2024,15 +2071,25 @@ airoha_get_wan_gdm_dev(struct airoha_eth *eth)
static void airoha_dev_set_qdma(struct airoha_gdm_dev *dev)
{
struct net_device *netdev = netdev_from_priv(dev);
+ struct airoha_qdma *cur_qdma, *qdma;
struct airoha_eth *eth = dev->eth;
int ppe_id;
/* QDMA0 is used for lan ports while QDMA1 is used for WAN ports */
- dev->qdma = ð->qdma[!airoha_is_lan_gdm_dev(dev)];
- netdev->irq = dev->qdma->irq_banks[0].irq;
+ qdma = ð->qdma[!airoha_is_lan_gdm_dev(dev)];
+ cur_qdma = airoha_qdma_deref(dev);
+
+ rcu_assign_pointer(dev->qdma, qdma);
+ netdev->irq = qdma->irq_banks[0].irq;
ppe_id = !airoha_is_lan_gdm_dev(dev) && airoha_ppe_is_enabled(eth, 1);
airoha_ppe_set_cpu_port(dev, ppe_id, airoha_get_fe_port(dev));
+
+ if (!cur_qdma)
+ return;
+
+ synchronize_rcu();
+ netif_tx_wake_all_queues(netdev);
}
static int airoha_dev_init(struct net_device *netdev)
@@ -2187,9 +2244,9 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
struct net_device *netdev)
{
struct airoha_gdm_dev *dev = netdev_priv(netdev);
- struct airoha_qdma *qdma = dev->qdma;
u32 nr_frags, tag, msg0, msg1, len;
struct airoha_queue_entry *e;
+ struct airoha_qdma *qdma;
struct netdev_queue *txq;
struct airoha_queue *q;
LIST_HEAD(tx_list);
@@ -2198,6 +2255,8 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
u16 index;
u8 fport;
+ rcu_read_lock();
+ qdma = rcu_dereference(dev->qdma);
qid = airoha_qdma_get_txq(qdma, skb_get_queue_mapping(skb));
tag = airoha_get_dsa_tag(skb, netdev);
@@ -2247,6 +2306,8 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
netif_tx_stop_queue(txq);
q->txq_stopped = true;
spin_unlock_bh(&q->lock);
+ rcu_read_unlock();
+
return NETDEV_TX_BUSY;
}
@@ -2309,6 +2370,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
FIELD_PREP(TX_RING_CPU_IDX_MASK, index));
spin_unlock_bh(&q->lock);
+ rcu_read_unlock();
return NETDEV_TX_OK;
@@ -2324,6 +2386,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
error:
dev_kfree_skb_any(skb);
netdev->stats.tx_dropped++;
+ rcu_read_unlock();
return NETDEV_TX_OK;
}
@@ -2403,17 +2466,19 @@ static int airoha_qdma_set_chan_tx_sched(struct net_device *netdev,
const u16 *weights, u8 n_weights)
{
struct airoha_gdm_dev *dev = netdev_priv(netdev);
+ struct airoha_qdma *qdma;
int i;
+ qdma = airoha_qdma_deref(dev);
for (i = 0; i < AIROHA_NUM_QOS_QUEUES; i++)
- airoha_qdma_clear(dev->qdma, REG_QUEUE_CLOSE_CFG(channel),
+ airoha_qdma_clear(qdma, REG_QUEUE_CLOSE_CFG(channel),
TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i));
for (i = 0; i < n_weights; i++) {
u32 status;
int err;
- airoha_qdma_wr(dev->qdma, REG_TXWRR_WEIGHT_CFG,
+ airoha_qdma_wr(qdma, REG_TXWRR_WEIGHT_CFG,
TWRR_RW_CMD_MASK |
FIELD_PREP(TWRR_CHAN_IDX_MASK, channel) |
FIELD_PREP(TWRR_QUEUE_IDX_MASK, i) |
@@ -2421,12 +2486,12 @@ static int airoha_qdma_set_chan_tx_sched(struct net_device *netdev,
err = read_poll_timeout(airoha_qdma_rr, status,
status & TWRR_RW_CMD_DONE,
USEC_PER_MSEC, 10 * USEC_PER_MSEC,
- true, dev->qdma, REG_TXWRR_WEIGHT_CFG);
+ true, qdma, REG_TXWRR_WEIGHT_CFG);
if (err)
return err;
}
- airoha_qdma_rmw(dev->qdma, REG_CHAN_QOS_MODE(channel >> 3),
+ airoha_qdma_rmw(qdma, REG_CHAN_QOS_MODE(channel >> 3),
CHAN_QOS_MODE_MASK(channel),
__field_prep(CHAN_QOS_MODE_MASK(channel), mode));
@@ -2490,13 +2555,15 @@ static int airoha_qdma_get_tx_ets_stats(struct net_device *netdev, int channel,
struct tc_ets_qopt_offload *opt)
{
struct airoha_gdm_dev *dev = netdev_priv(netdev);
- struct airoha_qdma *qdma = dev->qdma;
+ u64 cpu_tx_packets, fwd_tx_packets, tx_packets;
+ struct airoha_qdma *qdma;
- u64 cpu_tx_packets = airoha_qdma_rr(qdma, REG_CNTR_VAL(channel << 1));
- u64 fwd_tx_packets = airoha_qdma_rr(qdma,
- REG_CNTR_VAL((channel << 1) + 1));
- u64 tx_packets = (cpu_tx_packets - dev->cpu_tx_packets) +
- (fwd_tx_packets - dev->fwd_tx_packets);
+ qdma = airoha_qdma_deref(dev);
+ cpu_tx_packets = airoha_qdma_rr(qdma, REG_CNTR_VAL(channel << 1));
+ fwd_tx_packets = airoha_qdma_rr(qdma,
+ REG_CNTR_VAL((channel << 1) + 1));
+ tx_packets = (cpu_tx_packets - dev->cpu_tx_packets) +
+ (fwd_tx_packets - dev->fwd_tx_packets);
_bstats_update(opt->stats.bstats, 0, tx_packets);
dev->cpu_tx_packets = cpu_tx_packets;
@@ -2756,16 +2823,18 @@ static int airoha_qdma_set_tx_rate_limit(struct net_device *netdev,
u32 bucket_size)
{
struct airoha_gdm_dev *dev = netdev_priv(netdev);
+ struct airoha_qdma *qdma;
int i, err;
+ qdma = airoha_qdma_deref(dev);
for (i = 0; i <= TRTCM_PEAK_MODE; i++) {
- err = airoha_qdma_set_trtcm_config(dev->qdma, channel,
+ err = airoha_qdma_set_trtcm_config(qdma, channel,
REG_EGRESS_TRTCM_CFG, i,
!!rate, TRTCM_METER_MODE);
if (err)
return err;
- err = airoha_qdma_set_trtcm_token_bucket(dev->qdma, channel,
+ err = airoha_qdma_set_trtcm_token_bucket(qdma, channel,
REG_EGRESS_TRTCM_CFG,
i, rate, bucket_size);
if (err)
@@ -2801,11 +2870,12 @@ static int airoha_tc_htb_alloc_leaf_queue(struct net_device *netdev,
u32 channel = TC_H_MIN(opt->classid) % AIROHA_NUM_QOS_CHANNELS;
int err, num_tx_queues = AIROHA_NUM_TX_RING + channel + 1;
struct airoha_gdm_dev *dev = netdev_priv(netdev);
- struct airoha_qdma *qdma = dev->qdma;
+ struct airoha_qdma *qdma;
/* Here we need to check the requested QDMA channel is not already
* in use by another net_device running on the same QDMA block.
*/
+ qdma = airoha_qdma_deref(dev);
if (test_and_set_bit(channel, qdma->qos_channel_map)) {
NL_SET_ERR_MSG_MOD(opt->extack,
"qdma qos channel already in use");
@@ -2841,7 +2911,7 @@ static int airoha_qdma_set_rx_meter(struct airoha_gdm_dev *dev,
u32 rate, u32 bucket_size,
enum trtcm_unit_type unit_type)
{
- struct airoha_qdma *qdma = dev->qdma;
+ struct airoha_qdma *qdma = airoha_qdma_deref(dev);
int i;
for (i = 0; i < ARRAY_SIZE(qdma->q_rx); i++) {
@@ -3016,10 +3086,11 @@ static void airoha_tc_remove_htb_queue(struct net_device *netdev, int queue)
{
struct airoha_gdm_dev *dev = netdev_priv(netdev);
int num_tx_queues = AIROHA_NUM_TX_RING;
- struct airoha_qdma *qdma = dev->qdma;
+ struct airoha_qdma *qdma;
airoha_qdma_set_tx_rate_limit(netdev, queue, 0, 0);
+ qdma = airoha_qdma_deref(dev);
clear_bit(queue, qdma->qos_channel_map);
clear_bit(queue, dev->qos_sq_bmap);
@@ -3045,6 +3116,95 @@ static int airoha_tc_htb_delete_leaf_queue(struct net_device *netdev,
return 0;
}
+static void airoha_disable_qos_for_gdm34(struct net_device *netdev)
+{
+ struct airoha_gdm_dev *dev = netdev_priv(netdev);
+ struct airoha_gdm_port *port = dev->port;
+ int err;
+
+ if (port->id != AIROHA_GDM3_IDX &&
+ port->id != AIROHA_GDM4_IDX)
+ return;
+
+ err = airoha_disable_gdm2_loopback(dev);
+ if (err)
+ netdev_warn(netdev,
+ "failed disabling GDM2 loopback: %d\n", err);
+
+ dev->flags &= ~AIROHA_DEV_F_WAN;
+ airoha_dev_set_qdma(dev);
+
+ airoha_set_macaddr(dev, netdev->dev_addr);
+ if (netif_running(netdev))
+ airoha_set_gdm_port_fwd_cfg(dev->eth,
+ REG_GDM_FWD_CFG(port->id),
+ FE_PSE_PORT_PPE1);
+}
+
+static int airoha_enable_qos_for_gdm34(struct net_device *netdev,
+ struct netlink_ext_ack *extack)
+{
+ struct airoha_gdm_dev *wan_dev, *dev = netdev_priv(netdev);
+ struct airoha_gdm_port *port = dev->port;
+ struct airoha_eth *eth = dev->eth;
+ int err = -EBUSY;
+
+ if (port->id != AIROHA_GDM3_IDX &&
+ port->id != AIROHA_GDM4_IDX) {
+ /* HW QoS is always supported by GDM1 and GDM2 */
+ return 0;
+ }
+
+ if (!airoha_is_lan_gdm_dev(dev)) /* Already enabled */
+ return 0;
+
+ mutex_lock(&flow_offload_mutex);
+
+ wan_dev = airoha_get_wan_gdm_dev(eth);
+ if (wan_dev) {
+ if ((wan_dev->flags & AIROHA_DEV_F_QOS) ||
+ wan_dev->port->id == AIROHA_GDM2_IDX) {
+ NL_SET_ERR_MSG_MOD(extack,
+ "QoS configured for WAN device");
+ goto error_unlock;
+ }
+ airoha_disable_qos_for_gdm34(netdev_from_priv(wan_dev));
+ }
+
+ dev->flags |= AIROHA_DEV_F_WAN;
+ airoha_dev_set_qdma(dev);
+ err = airoha_enable_gdm2_loopback(dev);
+ if (err)
+ goto error_disable_wan;
+
+ err = airoha_set_macaddr(dev, netdev->dev_addr);
+ if (err)
+ goto error_disable_loopback;
+
+ if (netif_running(netdev)) {
+ u32 pse_port;
+
+ pse_port = airoha_ppe_is_enabled(eth, 1) ? FE_PSE_PORT_PPE2
+ : FE_PSE_PORT_PPE1;
+ airoha_set_gdm_port_fwd_cfg(eth, REG_GDM_FWD_CFG(port->id),
+ pse_port);
+ }
+
+ mutex_unlock(&flow_offload_mutex);
+
+ return 0;
+
+error_disable_loopback:
+ airoha_disable_gdm2_loopback(dev);
+error_disable_wan:
+ dev->flags &= ~AIROHA_DEV_F_WAN;
+ airoha_dev_set_qdma(dev);
+error_unlock:
+ mutex_unlock(&flow_offload_mutex);
+
+ return err;
+}
+
static int airoha_tc_htb_destroy(struct net_device *netdev)
{
struct airoha_gdm_dev *dev = netdev_priv(netdev);
@@ -3053,6 +3213,8 @@ static int airoha_tc_htb_destroy(struct net_device *netdev)
for_each_set_bit(q, dev->qos_sq_bmap, AIROHA_NUM_QOS_CHANNELS)
airoha_tc_remove_htb_queue(netdev, q);
+ dev->flags &= ~AIROHA_DEV_F_QOS;
+
return 0;
}
@@ -3072,24 +3234,33 @@ static int airoha_tc_get_htb_get_leaf_queue(struct net_device *netdev,
return 0;
}
-static int airoha_tc_setup_qdisc_htb(struct net_device *dev,
+static int airoha_tc_setup_qdisc_htb(struct net_device *netdev,
struct tc_htb_qopt_offload *opt)
{
switch (opt->command) {
- case TC_HTB_CREATE:
+ case TC_HTB_CREATE: {
+ struct airoha_gdm_dev *dev = netdev_priv(netdev);
+ int err;
+
+ err = airoha_enable_qos_for_gdm34(netdev, opt->extack);
+ if (err)
+ return err;
+
+ dev->flags |= AIROHA_DEV_F_QOS;
break;
+ }
case TC_HTB_DESTROY:
- return airoha_tc_htb_destroy(dev);
+ return airoha_tc_htb_destroy(netdev);
case TC_HTB_NODE_MODIFY:
- return airoha_tc_htb_modify_queue(dev, opt);
+ return airoha_tc_htb_modify_queue(netdev, opt);
case TC_HTB_LEAF_ALLOC_QUEUE:
- return airoha_tc_htb_alloc_leaf_queue(dev, opt);
+ return airoha_tc_htb_alloc_leaf_queue(netdev, opt);
case TC_HTB_LEAF_DEL:
case TC_HTB_LEAF_DEL_LAST:
case TC_HTB_LEAF_DEL_LAST_FORCE:
- return airoha_tc_htb_delete_leaf_queue(dev, opt);
+ return airoha_tc_htb_delete_leaf_queue(netdev, opt);
case TC_HTB_LEAF_QUERY_QUEUE:
- return airoha_tc_get_htb_get_leaf_queue(dev, opt);
+ return airoha_tc_get_htb_get_leaf_queue(netdev, opt);
default:
return -EOPNOTSUPP;
}
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index 87ab3ea10664..b97224a5495c 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -537,11 +537,12 @@ struct airoha_qdma {
enum airoha_dev_flags {
AIROHA_DEV_F_WAN = BIT(0),
+ AIROHA_DEV_F_QOS = BIT(1),
};
struct airoha_gdm_dev {
+ struct airoha_qdma __rcu *qdma;
struct airoha_gdm_port *port;
- struct airoha_qdma *qdma;
struct airoha_eth *eth;
DECLARE_BITMAP(qos_sq_bmap, AIROHA_NUM_QOS_CHANNELS);
@@ -676,6 +677,16 @@ int airoha_get_fe_port(struct airoha_gdm_dev *dev);
bool airoha_is_valid_gdm_dev(struct airoha_eth *eth,
struct airoha_gdm_dev *dev);
+extern struct mutex flow_offload_mutex;
+
+static inline struct airoha_qdma *
+airoha_qdma_deref(struct airoha_gdm_dev *dev)
+{
+ return rcu_dereference_protected(dev->qdma,
+ lockdep_rtnl_is_held() ||
+ lockdep_is_held(&flow_offload_mutex));
+}
+
void airoha_ppe_set_cpu_port(struct airoha_gdm_dev *dev, u8 ppe_id, u8 fport);
bool airoha_ppe_is_enabled(struct airoha_eth *eth, int index);
void airoha_ppe_check_skb(struct airoha_ppe_dev *dev, struct sk_buff *skb,
diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
index 42f4b0f21d17..0f260c50ac3c 100644
--- a/drivers/net/ethernet/airoha/airoha_ppe.c
+++ b/drivers/net/ethernet/airoha/airoha_ppe.c
@@ -15,7 +15,10 @@
#include "airoha_regs.h"
#include "airoha_eth.h"
-static DEFINE_MUTEX(flow_offload_mutex);
+/* Serialize airoha_gdm_dev flags, QDMA pointer and PPE CPU port
+ * configuration.
+ */
+DEFINE_MUTEX(flow_offload_mutex);
static DEFINE_SPINLOCK(ppe_lock);
static const struct rhashtable_params airoha_flow_table_params = {
@@ -86,8 +89,8 @@ static u32 airoha_ppe_get_timestamp(struct airoha_ppe *ppe)
void airoha_ppe_set_cpu_port(struct airoha_gdm_dev *dev, u8 ppe_id, u8 fport)
{
- struct airoha_qdma *qdma = dev->qdma;
- struct airoha_eth *eth = qdma->eth;
+ struct airoha_qdma *qdma = airoha_qdma_deref(dev);
+ struct airoha_eth *eth = dev->eth;
u8 qdma_id = qdma - ð->qdma[0];
u32 fe_cpu_port;
diff --git a/drivers/net/ethernet/airoha/airoha_regs.h b/drivers/net/ethernet/airoha/airoha_regs.h
index 436f3c8779c1..4e17dfbcf2b8 100644
--- a/drivers/net/ethernet/airoha/airoha_regs.h
+++ b/drivers/net/ethernet/airoha/airoha_regs.h
@@ -376,6 +376,7 @@
#define REG_SRC_PORT_FC_MAP6 0x2298
#define FC_ID_OF_SRC_PORT_MASK(_n) GENMASK(4 + ((_n) << 3), ((_n) << 3))
+#define FC_MAP6_DEF_VALUE 0x1b1a1918
#define REG_CDM5_RX_OQ1_DROP_CNT 0x29d4
--
2.54.0
^ permalink raw reply related
* Re: (subset) [PATCH V3 0/8] PCI: imx6: Integrate pwrctrl API and update device trees
From: Frank.Li @ 2026-06-29 16:18 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam, lpieralisi,
kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach,
Sherry Sun (OSS)
Cc: Frank Li, imx, linux-pci, linux-arm-kernel, devicetree,
linux-kernel, sherry.sun
In-Reply-To: <20260520084904.2424253-1-sherry.sun@oss.nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Wed, 20 May 2026 16:48:56 +0800, Sherry Sun (OSS) wrote:
> From: Sherry Sun <sherry.sun@nxp.com>
>
> This series integrates the PCI pwrctrl framework into the pci-imx6
> driver and updates i.MX EVK board device trees to support it.
>
> Patches 2-8 update device trees for i.MX EVK boards which maintained
> by NXP to move power supply properties from the PCIe controller node
> to the Root Port child node, which is required for pwrctrl framework.
> Affected boards:
> - i.MX6Q/DL SABRESD
> - i.MX6SX SDB
> - i.MX8MM EVK
> - i.MX8MP EVK
> - i.MX8MQ EVK
> - i.MX8DXL/QM/QXP EVK
> - i.MX95 15x15/19x19 EVK
>
> [...]
Applied, thanks!
[2/8] arm: dts: imx6qdl-sabresd: Move power supply property to Root Port node
commit: 6ae623838bba6b1d7dab2164bd12a166eae670b7
[3/8] arm: dts: imx6sx-sdb: Move power supply property to Root Port node
commit: 090ca78c5f5b8b475d51d729a7b79c5b7d8bbc47
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH rc v6 5/7] iommu/arm-smmu-v3: Retain CR0_SMMUEN during kdump device reset
From: Pranjal Shrivastava @ 2026-06-29 16:24 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, jgg, joro, kees, baolu.lu, kevin.tian,
miko.lenczewski, smostafa, linux-arm-kernel, iommu, linux-kernel,
stable, jamien
In-Reply-To: <f3866cc84cde2108b28c35b570ae502384e84c2a.1779265413.git.nicolinc@nvidia.com>
On Wed, May 20, 2026 at 10:03:22AM -0700, Nicolin Chen wrote:
> When ARM_SMMU_OPT_KDUMP_ADOPT is detected, do not disable SMMUEN and skip
> the CR1/CR2/STRTAB_BASE update sequence in arm_smmu_device_reset(). Those
> register writes are all CONSTRAINED UNPREDICTABLE while CR0_SMMUEN==1, so
> leaving them intact lets in-flight DMAs continue to be translated by the
> adopted stream table.
>
> Initialize 'enables' to 0 so it can carry CR0_SMMUEN in kdump case. Then,
> preserve that when enabling the command queue.
>
> Clear latched gerror bits if necessary.
>
> Fixes: b63b3439b856 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel")
> Cc: stable@vger.kernel.org # v6.12+
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Thanks,
Praan
^ permalink raw reply
* [PATCH v5 0/2] dt-bindings: mmc: st,sdhci: convert STMicroelectronics SDHCI-ST MMC/SD Controller controller binding to YAML
From: Charan Pedumuru @ 2026-06-29 16:26 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Griffin, Patrice Chotard
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
Charan Pedumuru
This patch series converts the legacy text-based Device Tree binding for
STMicroelectronics SDHCI-ST MMC/SD controller to DT schema (YAML) format.
Note:
The patch "dt-bindings: mmc: st,sdhci: convert to DT schema"
depends on the patch "arm: dts: st: align node patterns with established
convention". If the DT schema patch is applied before the DTS
cleanup patch, `dtbs_check` will fail due to the presence of the removed
properties in the existing DTS.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
Changes in v5:
- Rename the sdhci@9060000 and sdhci@9080000 device tree nodes to mmc@9060000
and mmc@9080000, respectively.
- Introduce the max-frequency property and add conditional logic to include
reg-names when the reg property contains two entries.
- Modify the commit message to explain the changes done for both YAML and DTS files.
- Link to v4: https://patch.msgid.link/20260613-st-mmc-v4-0-b3c385617c16@gmail.com
Changes in v4:
- st,sdhci: Add minItems: 1 to clock-names and reg-names to allow single-entry
configurations, fixing dtbs_check failures on nodes that omit the
optional 'icn' clock or 'top-mmc-delay' register region.
- st,sdhci: Modify the commit message to explain the changes.
- Link to v3: https://patch.msgid.link/20260508-st-mmc-v3-0-81c329ed28e8@gmail.com
Changes in v3:
- st,sdhci: Edit description of reg property. Modify reg-names. Add
"minItems" for clocks and clock-names properties.
- Modify the commit message to match with the updated changes.
- Link to v2: https://patch.msgid.link/20260503-st-mmc-v2-0-11ae3216d2ce@gmail.com
Changes in v2:
- Fix node name in DTS for the MMC to match with the estableshed convention.
- st,sdhci: drop unnecessary properties, modify "reg", "reg-names" and
"clock-names" properties, include an allOf with $ref to mmc-controller.
- Link to v1: https://patch.msgid.link/20260409-st-mmc-v1-1-4c54321c3535@gmail.com
---
Charan Pedumuru (2):
arm: dts: st: align MMC node names with established convention
dt-bindings: mmc: st,sdhci: Convert to DT schema
Documentation/devicetree/bindings/mmc/sdhci-st.txt | 110 ---------------------
.../devicetree/bindings/mmc/st,sdhci.yaml | 105 ++++++++++++++++++++
arch/arm/boot/dts/st/stih407-family.dtsi | 4 +-
arch/arm/boot/dts/st/stih410-b2260.dts | 4 +-
arch/arm/boot/dts/st/stih418-b2199.dts | 4 +-
arch/arm/boot/dts/st/stih418.dtsi | 2 +-
6 files changed, 112 insertions(+), 117 deletions(-)
---
base-commit: cf2cd8efd046c561191b8541d32a8bfe845bf06b
change-id: 20260327-st-mmc-c906ad95ff83
Best regards,
--
Charan Pedumuru <charan.pedumuru@gmail.com>
^ permalink raw reply
* [PATCH v5 1/2] arm: dts: st: align MMC node names with established convention
From: Charan Pedumuru @ 2026-06-29 16:26 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Griffin, Patrice Chotard
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
Charan Pedumuru
In-Reply-To: <20260629-st-mmc-v5-0-3cf0e639bff8@gmail.com>
Rename sdhci@9060000 and sdhci@9080000 nodes to mmc@9060000 and
mmc@9080000 in stih407-family.dtsi and update all derived board files
atomically to prevent orphaned node overrides.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
arch/arm/boot/dts/st/stih407-family.dtsi | 4 ++--
arch/arm/boot/dts/st/stih410-b2260.dts | 4 ++--
arch/arm/boot/dts/st/stih418-b2199.dts | 4 ++--
arch/arm/boot/dts/st/stih418.dtsi | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/st/stih407-family.dtsi b/arch/arm/boot/dts/st/stih407-family.dtsi
index 3e6a0542e3ae..08acba209c56 100644
--- a/arch/arm/boot/dts/st/stih407-family.dtsi
+++ b/arch/arm/boot/dts/st/stih407-family.dtsi
@@ -596,7 +596,7 @@ spi@9542000 {
status = "disabled";
};
- mmc0: sdhci@9060000 {
+ mmc0: mmc@9060000 {
compatible = "st,sdhci-stih407", "st,sdhci";
status = "disabled";
reg = <0x09060000 0x7ff>, <0x9061008 0x20>;
@@ -611,7 +611,7 @@ mmc0: sdhci@9060000 {
bus-width = <8>;
};
- mmc1: sdhci@9080000 {
+ mmc1: mmc@9080000 {
compatible = "st,sdhci-stih407", "st,sdhci";
status = "disabled";
reg = <0x09080000 0x7ff>;
diff --git a/arch/arm/boot/dts/st/stih410-b2260.dts b/arch/arm/boot/dts/st/stih410-b2260.dts
index 736b1e059b0a..44048a98648e 100644
--- a/arch/arm/boot/dts/st/stih410-b2260.dts
+++ b/arch/arm/boot/dts/st/stih410-b2260.dts
@@ -141,14 +141,14 @@ i2c3: i2c@9843000 {
status = "okay";
};
- mmc0: sdhci@9060000 {
+ mmc0: mmc@9060000 {
pinctrl-0 = <&pinctrl_sd0>;
bus-width = <4>;
status = "okay";
};
/* high speed expansion connector */
- mmc1: sdhci@9080000 {
+ mmc1: mmc@9080000 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/st/stih418-b2199.dts b/arch/arm/boot/dts/st/stih418-b2199.dts
index 53ac6c2b7b7d..4ea174597365 100644
--- a/arch/arm/boot/dts/st/stih418-b2199.dts
+++ b/arch/arm/boot/dts/st/stih418-b2199.dts
@@ -82,11 +82,11 @@ i2c@9541000 {
st,i2c-min-sda-pulse-width-us = <5>;
};
- mmc1: sdhci@9080000 {
+ mmc1: mmc@9080000 {
status = "okay";
};
- mmc0: sdhci@9060000 {
+ mmc0: mmc@9060000 {
status = "okay";
max-frequency = <200000000>;
sd-uhs-sdr50;
diff --git a/arch/arm/boot/dts/st/stih418.dtsi b/arch/arm/boot/dts/st/stih418.dtsi
index 8fb8b3af5e49..1a5fbbedc8cd 100644
--- a/arch/arm/boot/dts/st/stih418.dtsi
+++ b/arch/arm/boot/dts/st/stih418.dtsi
@@ -136,7 +136,7 @@ ehci1: usb@9a83e00 {
phy-names = "usb";
};
- mmc0: sdhci@9060000 {
+ mmc0: mmc@9060000 {
assigned-clocks = <&clk_s_c0_flexgen CLK_MMC_0>;
assigned-clock-parents = <&clk_s_c0_pll1 0>;
assigned-clock-rates = <200000000>;
--
2.54.0
^ permalink raw reply related
* [PATCH v5 2/2] dt-bindings: mmc: st,sdhci: Convert to DT schema
From: Charan Pedumuru @ 2026-06-29 16:26 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Griffin, Patrice Chotard
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
Charan Pedumuru
In-Reply-To: <20260629-st-mmc-v5-0-3cf0e639bff8@gmail.com>
Convert STMicroelectronics sdhci-st MMC/SD controller binding from
text format to YAML DT schema.
Changes during conversion:
- Preserve optional 'icn' clock and 'top-mmc-delay' register region
via minItems: 1 on their respective properties.
- Conditionally require reg-names when two reg entries are present
via an allOf if/then block, preventing silent runtime failure in
devm_platform_ioremap_resource_byname().
- Constrain max-frequency to enum [200000000, 100000000, 50000000]
with a default of 50000000, matching the driver's behaviour in
sdhci-st.c.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
Documentation/devicetree/bindings/mmc/sdhci-st.txt | 110 ---------------------
.../devicetree/bindings/mmc/st,sdhci.yaml | 105 ++++++++++++++++++++
2 files changed, 105 insertions(+), 110 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-st.txt b/Documentation/devicetree/bindings/mmc/sdhci-st.txt
deleted file mode 100644
index ccf82b4ee838..000000000000
--- a/Documentation/devicetree/bindings/mmc/sdhci-st.txt
+++ /dev/null
@@ -1,110 +0,0 @@
-* STMicroelectronics sdhci-st MMC/SD controller
-
-This file documents the differences between the core properties in
-Documentation/devicetree/bindings/mmc/mmc.txt and the properties
-used by the sdhci-st driver.
-
-Required properties:
-- compatible: Must be "st,sdhci" and it can be compatible to "st,sdhci-stih407"
- to set the internal glue logic used for configuring the MMC
- subsystem (mmcss) inside the FlashSS (available in STiH407 SoC
- family).
-
-- clock-names: Should be "mmc" and "icn". (NB: The latter is not compulsory)
- See: Documentation/devicetree/bindings/resource-names.txt
-- clocks: Phandle to the clock.
- See: Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-- interrupts: One mmc interrupt should be described here.
-- interrupt-names: Should be "mmcirq".
-
-- pinctrl-names: A pinctrl state names "default" must be defined.
-- pinctrl-0: Phandle referencing pin configuration of the sd/emmc controller.
- See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
-- reg: This must provide the host controller base address and it can also
- contain the FlashSS Top register for TX/RX delay used by the driver
- to configure DLL inside the flashSS, if so reg-names must also be
- specified.
-
-Optional properties:
-- reg-names: Should be "mmc" and "top-mmc-delay". "top-mmc-delay" is optional
- for eMMC on stih407 family silicon to configure DLL inside FlashSS.
-
-- non-removable: Non-removable slot. Also used for configuring mmcss in STiH407 SoC
- family.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- bus-width: Number of data lines.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- max-frequency: Can be 200MHz, 100MHz or 50MHz (default) and used for
- configuring the CCONFIG3 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- resets: Phandle and reset specifier pair to softreset line of HC IP.
- See: Documentation/devicetree/bindings/reset/reset.txt
-
-- vqmmc-supply: Phandle to the regulator dt node, mentioned as the vcc/vdd
- supply in eMMC/SD specs.
-
-- sd-uhs-sdr50: To enable the SDR50 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- sd-uhs-sdr104: To enable the SDR104 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- sd-uhs-ddr50: To enable the DDR50 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-Example:
-
-/* Example stih416e eMMC configuration */
-
-mmc0: sdhci@fe81e000 {
- compatible = "st,sdhci";
- reg = <0xfe81e000 0x1000>;
- interrupts = <GIC_SPI 127 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_mmc0>;
- clock-names = "mmc";
- clocks = <&clk_s_a1_ls 1>;
- bus-width = <8>
-
-/* Example SD stih407 family configuration */
-
-mmc1: sdhci@9080000 {
- compatible = "st,sdhci-stih407", "st,sdhci";
- reg = <0x09080000 0x7ff>;
- reg-names = "mmc";
- interrupts = <GIC_SPI 90 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_sd1>;
- clock-names = "mmc";
- clocks = <&clk_s_c0_flexgen CLK_MMC_1>;
- resets = <&softreset STIH407_MMC1_SOFTRESET>;
- bus-width = <4>;
-};
-
-/* Example eMMC stih407 family configuration */
-
-mmc0: sdhci@9060000 {
- compatible = "st,sdhci-stih407", "st,sdhci";
- reg = <0x09060000 0x7ff>, <0x9061008 0x20>;
- reg-names = "mmc", "top-mmc-delay";
- interrupts = <GIC_SPI 92 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_mmc0>;
- clock-names = "mmc";
- clocks = <&clk_s_c0_flexgen CLK_MMC_0>;
- vqmmc-supply = <&vmmc_reg>;
- max-frequency = <200000000>;
- bus-width = <8>;
- non-removable;
- sd-uhs-sdr50;
- sd-uhs-sdr104;
- sd-uhs-ddr50;
-};
diff --git a/Documentation/devicetree/bindings/mmc/st,sdhci.yaml b/Documentation/devicetree/bindings/mmc/st,sdhci.yaml
new file mode 100644
index 000000000000..798af599d374
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/st,sdhci.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/st,sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics SDHCI-ST MMC/SD Controller
+
+maintainers:
+ - Peter Griffin <peter.griffin@linaro.org>
+
+description:
+ The STMicroelectronics SDHCI-ST MMC/SD host controller is compliant with
+ the SD Host Controller Interface (SDHCI) specification and is used to
+ interface with MMC, SD and SDIO cards. The ST SDHCI controller extends the
+ standard SDHCI capabilities with platform-specific configurations such as
+ additional register regions, clock inputs, and delay control mechanisms
+ required for signal timing adjustments to support high-speed modes across
+ different ST SoCs.
+
+allOf:
+ - $ref: mmc-controller.yaml#
+ - if:
+ properties:
+ reg:
+ minItems: 2
+ required:
+ - reg
+ then:
+ required:
+ - reg-names
+
+properties:
+ compatible:
+ oneOf:
+ - const: st,sdhci
+ - items:
+ - const: st,sdhci-stih407
+ - const: st,sdhci
+
+ reg:
+ minItems: 1
+ items:
+ - description: MMC controller base registers
+ - description: FlashSS Top registers for TX/RX DLL delay configuration
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: mmc
+ - const: top-mmc-delay
+
+ clocks:
+ minItems: 1
+ items:
+ - description: Clock for the MMC controller
+ - description: Interconnect (ICN) clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: mmc
+ - const: icn
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: mmcirq
+
+ resets:
+ maxItems: 1
+
+ max-frequency:
+ enum: [200000000, 100000000, 50000000]
+ default: 50000000
+
+required:
+ - reg
+ - compatible
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/stih407-clks.h>
+ mmc@9060000 {
+ compatible = "st,sdhci-stih407", "st,sdhci";
+ reg = <0x09060000 0x7ff>, <0x9061008 0x20>;
+ reg-names = "mmc", "top-mmc-delay";
+ interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "mmcirq";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc0>;
+ clock-names = "mmc", "icn";
+ clocks = <&clk_s_c0_flexgen CLK_MMC_0>,
+ <&clk_s_c0_flexgen CLK_RX_ICN_HVA>;
+ bus-width = <8>;
+ };
+...
--
2.54.0
^ 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