* Re: Re: [PATCH] ASoC: imx-rpmsg: Fix ignore-suspend-widgets only applied to codec DAPM
From: Mark Brown @ 2026-04-14 13:57 UTC (permalink / raw)
To: Chancel Liu
Cc: shengjiu.wang@gmail.com, Xiubo.Lee@gmail.com, festevam@gmail.com,
nicoleotsuka@gmail.com, lgirdwood@gmail.com, perex@perex.cz,
tiwai@suse.com, Frank Li, s.hauer@pengutronix.de,
kernel@pengutronix.de, linux-sound@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <AM9PR04MB83539BD1328151697DA85859E3242@AM9PR04MB8353.eurprd04.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]
On Mon, Apr 13, 2026 at 03:13:51AM +0000, Chancel Liu wrote:
> Thanks for pointing this out. I really appreciate your suggestion to
> move this functionality into core-level. Several machine drivers could
> benefit if there's an unified ignore‑suspend mechanism.
> I have an idea to make it support a generic and reusable mechanism in
> the core rather than something each machine driver has to re‑implement.
> The design follows a simple structure:
> 1. Parse and store the name of widgets to ignore suspend in
> struct snd_soc_card
> The name list of widgets to ignore suspend can come either from DT or
> from the machine driver. Different boards/machines have different
> routing and power requirements. So allowing DT to specify
> "ignore-suspend-widgets" is important. It enables each device to define
> its own policy rather than forcing hard‑coded rules. To support this, a
> helper such as snd_soc_of_parse_ignore_suspend_widgets() can be defined
> in core and provided.
> 2. Apply ignore_suspend flags during snd_soc_bind_card()
> After all components have been probed and all DAPM widgets are
> registered in snd_soc_bind_card(), perform a unified search through
> the card’s widget list and mark matching widgets with
> ignore_suspend = 1. Any runtime prefixing applied during widget
> creation should be handled well by the lookup.
That sounds like a reasonable plan.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 1/3] dt-bindings: gpio: add Axiado SGPIO controller
From: Petar Stepanovic @ 2026-04-14 13:48 UTC (permalink / raw)
To: Petar Stepanovic, Tzu-Hao Wei, Swark Yang, Prasad Bolisetty,
Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Harshit Shah, SriNavmani A
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260414-axiado-ax3000-sgpio-controller-v1-0-b5c7e4c2e69b@axiado.com>
Add device tree binding for the Axiado SGPIO controller.
The SGPIO controller provides a serialized interface for
controlling multiple GPIO signals over a limited number of
physical lines. It supports configurable data direction and
interrupt handling.
The binding describes the properties required to instantiate
the controller and register it as a GPIO provider.
Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
---
.../devicetree/bindings/gpio/axiado,sgpio.yaml | 98 ++++++++++++++++++++++
1 file changed, 98 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/axiado,sgpio.yaml b/Documentation/devicetree/bindings/gpio/axiado,sgpio.yaml
new file mode 100644
index 000000000000..1533446d69f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/axiado,sgpio.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/axiado,sgpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Axiado SGPIO Controller
+
+maintainers:
+ - Petar Stepanovic <pstepanovic@axiado.com>
+ - SriNavmani A <srinavmani@axiado.com>
+ - Prasad Bolisetty <pbolisetty@axiado.com>
+
+description: |
+ The SGPIO controller provides a serialized interface for controlling
+ multiple GPIO signals over a limited number of physical lines.
+ It supports configurable data direction and interrupt handling.
+
+properties:
+ compatible:
+ enum:
+ - axiado,sgpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ design-variant:
+ description: SGPIO design variant size in bits (e.g. 128 or 512).
+ enum: [128, 512]
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ ngpios:
+ description: The number of gpios this controller has.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ bus-frequency:
+ description: The SGPIO shift clock frequency in Hz.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ apb-frequency:
+ description: The APB bus frequency in Hz.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ dout-init:
+ description: Initial values for the dout registers.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 4
+ maxItems: 4
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - design-variant
+ - ngpios
+ - bus-frequency
+ - apb-frequency
+ - dout-init
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ sgpio@a000 {
+ compatible = "axiado,sgpio";
+ reg = <0xa000 0x800>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <17 IRQ_TYPE_LEVEL_HIGH>;
+ design-variant = <128>;
+ ngpios = <128>;
+ bus-frequency = <1000000>;
+ apb-frequency = <100000000>;
+ dout-init = <0x00300000 0x00006371 0x00003800 0x00000000>;
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH 0/3] Subject: [PATCH 0/3] gpio: add support for Axiado SGPIO controller
From: Petar Stepanovic @ 2026-04-14 13:48 UTC (permalink / raw)
To: Petar Stepanovic, Tzu-Hao Wei, Swark Yang, Prasad Bolisetty,
Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Harshit Shah, SriNavmani A
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-kernel
The SGPIO controller provides a serialized interface for
controlling multiple GPIO signals over a limited number of
physical lines. It supports configurable data direction and
interrupt handling.
This series adds support for the Axiado SGPIO controller.
The series includes:
- Device tree binding documentation
- GPIO driver implementation
- MAINTAINERS entry
The driver integrates with the Linux GPIO subsystem and
registers the controller as a gpio_chip.
Tested on Axiado platforms.
---
Patch 1: dt-bindings: gpio: add Axiado SGPIO controller
Patch 2: gpio: axiado: add SGPIO controller support
Patch 3: MAINTAINERS: add Axiado SGPIO controller
Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
---
Petar Stepanovic (3):
dt-bindings: gpio: add Axiado SGPIO controller
gpio: axiado: add SGPIO controller support
MAINTAINERS: add Axiado SGPIO controller
.../devicetree/bindings/gpio/axiado,sgpio.yaml | 98 +++
MAINTAINERS | 9 +
drivers/gpio/Kconfig | 18 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-axiado-sgpio.c | 780 +++++++++++++++++++++
5 files changed, 906 insertions(+)
---
base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
change-id: 20260320-axiado-ax3000-sgpio-controller-00f6e1db6ce9
Best regards,
--
Petar Stepanovic <pstepanovic@axiado.com>
^ permalink raw reply
* [PATCH 3/3] MAINTAINERS: add Axiado SGPIO controller
From: Petar Stepanovic @ 2026-04-14 13:48 UTC (permalink / raw)
To: Petar Stepanovic, Tzu-Hao Wei, Swark Yang, Prasad Bolisetty,
Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Harshit Shah, SriNavmani A
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260414-axiado-ax3000-sgpio-controller-v1-0-b5c7e4c2e69b@axiado.com>
Add MAINTAINERS entry for the Axiado SGPIO controller driver
and corresponding device tree binding.
Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 67db88b04537..56835c0a1863 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4234,6 +4234,15 @@ S: Maintained
F: Documentation/devicetree/bindings/sound/axentia,*
F: sound/soc/atmel/tse850-pcm5142.c
+AXIADO SGPIO DRIVER
+M: Petar Stepanovic <pstepanovic@axiado.com>
+M: SriNavmani A <srinavmani@axiado.com>
+M: Prasad Bolisetty <pbolisetty@axiado.com>
+L: linux-gpio@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/gpio/axiado,sgpio.yaml
+F: drivers/gpio/gpio-axiado-sgpio.c
+
AXIS ARTPEC ARM64 SoC SUPPORT
M: Jesper Nilsson <jesper.nilsson@axis.com>
M: Lars Persson <lars.persson@axis.com>
--
2.34.1
^ permalink raw reply related
* [PATCH 2/3] gpio: axiado: add SGPIO controller support
From: Petar Stepanovic @ 2026-04-14 13:48 UTC (permalink / raw)
To: Petar Stepanovic, Tzu-Hao Wei, Swark Yang, Prasad Bolisetty,
Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Harshit Shah, SriNavmani A
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260414-axiado-ax3000-sgpio-controller-v1-0-b5c7e4c2e69b@axiado.com>
Add support for the Axiado SGPIO controller.
The controller provides a serialized interface for GPIOs with
configurable direction and interrupt support.
The driver registers the controller as a gpio_chip and uses
regmap for register access.
Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
---
drivers/gpio/Kconfig | 18 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-axiado-sgpio.c | 780 +++++++++++++++++++++++++++++++++++++++
3 files changed, 799 insertions(+)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index bd185482a7fd..42c56d157092 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -198,6 +198,24 @@ config GPIO_ATH79
Select this option to enable GPIO driver for
Atheros AR71XX/AR724X/AR913X SoC devices.
+config GPIO_AXIADO_SGPIO
+ bool "Axiado SGPIO support"
+ depends on OF_GPIO
+ depends on ARCH_AXIADO || COMPILE_TEST
+ select GPIO_GENERIC
+ select GPIOLIB_IRQCHIP
+ select REGMAP
+ help
+ Enable support for the Axiado Serial GPIO (SGPIO) controller.
+
+ The SGPIO controller provides a serialized interface for
+ controlling multiple GPIO signals over a limited number of
+ physical lines. It supports configurable data direction and
+ interrupt handling.
+
+ This driver integrates with the Linux GPIO subsystem and
+ exposes the controller as a standard GPIO provider.
+
config GPIO_RASPBERRYPI_EXP
tristate "Raspberry Pi 3 GPIO Expander"
default RASPBERRYPI_FIRMWARE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 2421a8fd3733..909a97551807 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
obj-$(CONFIG_GPIO_ASPEED) += gpio-aspeed.o
obj-$(CONFIG_GPIO_ASPEED_SGPIO) += gpio-aspeed-sgpio.o
obj-$(CONFIG_GPIO_ATH79) += gpio-ath79.o
+obj-$(CONFIG_GPIO_AXIADO_SGPIO) += gpio-axiado-sgpio.o
obj-$(CONFIG_GPIO_BCM_KONA) += gpio-bcm-kona.o
obj-$(CONFIG_GPIO_BCM_XGS_IPROC) += gpio-xgs-iproc.o
obj-$(CONFIG_GPIO_BD71815) += gpio-bd71815.o
diff --git a/drivers/gpio/gpio-axiado-sgpio.c b/drivers/gpio/gpio-axiado-sgpio.c
new file mode 100644
index 000000000000..8cd349ec6f53
--- /dev/null
+++ b/drivers/gpio/gpio-axiado-sgpio.c
@@ -0,0 +1,780 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2022-2026 Axiado Corporation
+ */
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/module.h>
+
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/spinlock.h>
+
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+
+#include <linux/gpio/driver.h>
+
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
+
+#include <linux/regmap.h>
+
+struct sgpio_reg_offsets {
+ u32 mux_0;
+ u32 preset_0;
+ u32 count_0;
+ u32 pos_0;
+
+ u32 mux_1;
+ u32 ld;
+ u32 ld_ss;
+
+ u32 preset_1;
+ u32 count_1;
+ u32 pos_1;
+
+ u32 mux_2;
+ u32 dout;
+ u32 dout_ss;
+
+ u32 preset_2;
+ u32 count_2;
+ u32 pos_2;
+
+ u32 mux_3;
+ u32 preset_3;
+ u32 count_3;
+ u32 pos_3;
+
+ u32 mux_4;
+ u32 oe;
+ u32 oe_ss;
+
+ u32 preset_4;
+ u32 count_4;
+ u32 pos_4;
+
+ u32 mask;
+ u32 ctrl_en;
+ u32 ctrl_en_pos;
+
+ u32 din_ss;
+ u32 status;
+};
+
+static const struct sgpio_reg_offsets sgpio_offsets_512 = {
+ .mux_0 = 0x000,
+ .preset_0 = 0x1dc,
+ .count_0 = 0x1f0,
+ .pos_0 = 0x204,
+
+ .mux_1 = 0x004,
+ .ld = 0x014,
+ .ld_ss = 0x0d8,
+
+ .preset_1 = 0x1e0,
+ .count_1 = 0x1f4,
+ .pos_1 = 0x208,
+
+ .mux_2 = 0x008,
+ .dout = 0x054,
+ .dout_ss = 0x158,
+
+ .preset_2 = 0x1e4,
+ .count_2 = 0x1f8,
+ .pos_2 = 0x20c,
+
+ .mux_3 = 0x00c,
+ .preset_3 = 0x1e8,
+ .count_3 = 0x1fc,
+ .pos_3 = 0x210,
+
+ .mux_4 = 0x010,
+ .oe = 0x0d4,
+ .oe_ss = 0x1d8,
+
+ .preset_4 = 0x1ec,
+ .count_4 = 0x200,
+ .pos_4 = 0x214,
+
+ .mask = 0x224,
+ .ctrl_en = 0x218,
+ .ctrl_en_pos = 0x21c,
+
+ .din_ss = 0x198,
+ .status = 0x228,
+};
+
+static const struct sgpio_reg_offsets sgpio_offsets_128 = {
+ .mux_0 = 0x000,
+ .preset_0 = 0x08c,
+ .count_0 = 0x0a0,
+ .pos_0 = 0x0b4,
+
+ .mux_1 = 0x004,
+ .ld = 0x014,
+ .ld_ss = 0x048,
+
+ .preset_1 = 0x090,
+ .count_1 = 0x0a4,
+ .pos_1 = 0x0b8,
+
+ .mux_2 = 0x008,
+ .dout = 0x024,
+ .dout_ss = 0x068,
+
+ .preset_2 = 0x094,
+ .count_2 = 0x0a8,
+ .pos_2 = 0x0bc,
+
+ .mux_3 = 0x00c,
+ .preset_3 = 0x098,
+ .count_3 = 0x0ac,
+ .pos_3 = 0x0c0,
+
+ .mux_4 = 0x010,
+ .oe = 0x044,
+ .oe_ss = 0x088,
+
+ .preset_4 = 0x09c,
+ .count_4 = 0x0b0,
+ .pos_4 = 0x0c4,
+
+ .mask = 0x0d4,
+ .ctrl_en = 0x0c8,
+ .ctrl_en_pos = 0x0cc,
+
+ .din_ss = 0x078,
+ .status = 0x0d8,
+};
+
+#define MAX_SGPIO_PINS 512
+#define MAX_OFFSET_REG 16
+#define MAX_SLICE_COUNT 5
+
+struct ax3000_slice_info {
+ u32 out_mux;
+ u32 sgpio_mux;
+ u32 slice_mux;
+ u32 reg[MAX_OFFSET_REG];
+ u32 reg_ss[MAX_OFFSET_REG];
+ u32 preset;
+ u32 count;
+ u32 pos;
+};
+
+struct ax3000_sgpio {
+ u32 preset_value;
+ u32 count_value;
+ u32 pos_reg;
+ struct ax3000_slice_info
+ slices[MAX_SLICE_COUNT]; /* 0=clk,1=load,2=out,3=in,4=oe */
+ spinlock_t lock;
+ int ngpios;
+ int max_sgpio_pins;
+ int max_offset_regs;
+ struct gpio_chip chip;
+ u32 irq_unmasked[MAX_SGPIO_PINS];
+ int parent_irq;
+ struct regmap *regmap;
+ u32 regmap_base_offset;
+ struct sgpio_reg_offsets *regs;
+};
+
+static int sgpio_set_irq_type(struct irq_data *d, unsigned int type);
+static void sgpio_mask_irq(struct irq_data *d);
+static void sgpio_unmask_irq(struct irq_data *d);
+static void sgpio_irq_shutdown(struct irq_data *d);
+
+static const struct irq_chip axiado_sgpio_irqchip = {
+ .name = "axiado-sgpio",
+ .irq_mask = sgpio_mask_irq,
+ .irq_unmask = sgpio_unmask_irq,
+ .irq_set_type = sgpio_set_irq_type,
+ .irq_shutdown = sgpio_irq_shutdown,
+ .flags = IRQCHIP_IMMUTABLE | IRQCHIP_MASK_ON_SUSPEND,
+};
+
+static void ax3000_sgpio_set(struct gpio_chip *chip, unsigned int offset,
+ int value)
+{
+ struct ax3000_sgpio *sgpio = gpiochip_get_data(chip);
+ unsigned long flags;
+ u32 bank = (offset / 2) / 32;
+ u32 position = (offset / 2) % 32;
+
+ spin_lock_irqsave(&sgpio->lock, flags);
+ if (value)
+ sgpio->slices[2].reg_ss[bank] |= BIT(position);
+ else
+ sgpio->slices[2].reg_ss[bank] &= ~BIT(position);
+
+ spin_unlock_irqrestore(&sgpio->lock, flags);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->dout_ss +
+ (bank * 4),
+ sgpio->slices[2].reg_ss[bank]);
+}
+
+static int ax3000_sgpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+ struct ax3000_sgpio *sgpio = gpiochip_get_data(chip);
+ u32 bank = (offset / 2) / 32;
+ u32 position = (offset / 2) % 32;
+
+ if (offset % 2 == 0)
+ return !!(sgpio->slices[3].reg_ss[bank] & BIT(position));
+ else
+ return !!(sgpio->slices[2].reg_ss[bank] & BIT(position));
+}
+
+static int ax3000_sgpio_dir_in(struct gpio_chip *chip, unsigned int offset)
+{
+ if (!(offset % 2))
+ return 0;
+ else
+ return -EINVAL;
+}
+
+static int ax3000_sgpio_dir_out(struct gpio_chip *chip, unsigned int offset,
+ int value)
+{
+ if (offset % 2) {
+ if (chip->set)
+ chip->set(chip, offset, value);
+ return 0;
+ } else {
+ return -EINVAL;
+ }
+}
+
+static irqreturn_t sgpio_irq_handler(int irq, void *arg)
+{
+ struct ax3000_sgpio *sgpio = (struct ax3000_sgpio *)arg;
+ unsigned long flags;
+ u32 status, new_value;
+ u32 changed_value;
+ int i, bit, reg_ptr;
+
+ /* Read-on-clear (ACK) parent cause */
+ regmap_read(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->status, &status);
+ status >>= 16;
+
+ bool has_shifted_layout = (sgpio->max_offset_regs == MAX_OFFSET_REG);
+
+ reg_ptr = has_shifted_layout ? 16 - DIV_ROUND_UP(sgpio->ngpios, 32) : 0;
+
+ for (i = 0; i < DIV_ROUND_UP(sgpio->ngpios, 32); i++, reg_ptr++) {
+ if (status & BIT(reg_ptr)) {
+ regmap_read(sgpio->regmap,
+ sgpio->regmap_base_offset +
+ sgpio->regs->din_ss + (reg_ptr * 4),
+ &new_value);
+ spin_lock_irqsave(&sgpio->lock, flags);
+ changed_value = sgpio->slices[3].reg_ss[i] ^ new_value;
+ sgpio->slices[3].reg_ss[i] = new_value;
+ spin_unlock_irqrestore(&sgpio->lock, flags);
+
+ while (changed_value) {
+ bit = __ffs(changed_value);
+ changed_value &= ~BIT(bit);
+
+ irq_hw_number_t hwirq = i * 32 + bit;
+
+ if (sgpio->irq_unmasked[hwirq]) {
+ unsigned int child_irq;
+
+ child_irq = irq_find_mapping(sgpio->chip.irq.domain,
+ hwirq);
+
+ if (child_irq)
+ handle_nested_irq(child_irq);
+ }
+ }
+ }
+ }
+
+ return IRQ_HANDLED;
+}
+
+static void sgpio_hw_init(struct ax3000_sgpio *sgpio)
+{
+ u32 bank;
+ u32 position;
+ int i = 0;
+ bool has_shifted_layout = (sgpio->max_offset_regs == MAX_OFFSET_REG);
+
+ /* slice A0, Clock Pin - 0 */
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->mux_0, 0x306);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->preset_0,
+ sgpio->preset_value);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->count_0,
+ sgpio->count_value);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->pos_0, 0x1f001f);
+
+ /* Slice B1, Data Load Pin - 1 */
+ bank = (sgpio->ngpios - 1) / 32;
+ position = (sgpio->ngpios - 1) % 32;
+
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->mux_1,
+ has_shifted_layout ? 0x30c : 0x304);
+
+ for (i = 0; i < bank; i++) {
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->ld +
+ (i * 4),
+ 0xffffffff);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->ld_ss +
+ (i * 4),
+ 0xffffffff);
+ }
+
+ if (position) {
+ u32 val;
+
+ val = sgpio->slices[1].reg_ss[i];
+ val |= GENMASK(position - 1, 0);
+
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->ld +
+ (i * 4),
+ val);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->ld_ss +
+ (i * 4),
+ val);
+ }
+
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->preset_1,
+ sgpio->preset_value);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->count_1,
+ sgpio->count_value);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->pos_1,
+ sgpio->pos_reg);
+
+ /* Slice C2, Data Out Pin - 2 */
+ bank = sgpio->ngpios / 32;
+ position = sgpio->ngpios % 32;
+
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->mux_2,
+ has_shifted_layout ? 0x30c : 0x304);
+
+ for (i = 0; i < bank; i++) {
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->dout +
+ (i * 4),
+ sgpio->slices[2].reg_ss[i]);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->dout_ss +
+ (i * 4),
+ sgpio->slices[2].reg_ss[i]);
+ }
+
+ if (position) {
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->dout +
+ (i * 4),
+ sgpio->slices[2].reg_ss[i]);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->dout_ss +
+ (i * 4),
+ sgpio->slices[2].reg_ss[i]);
+ }
+
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->preset_2,
+ sgpio->preset_value);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->count_2,
+ sgpio->count_value);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->pos_2,
+ sgpio->pos_reg);
+
+ /* Slice D3, Data In Pin - 3 */
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->mux_3, 0x14C);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->preset_3,
+ sgpio->preset_value);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->count_3,
+ sgpio->count_value);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->pos_3,
+ sgpio->pos_reg);
+
+ /* Slice E4, Output Enable for respective pins */
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->mux_4,
+ has_shifted_layout ? 0x10c : 0x104);
+ regmap_write(sgpio->regmap, sgpio->regmap_base_offset + sgpio->regs->oe,
+ 0xffffffff);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->oe_ss,
+ 0xffffffff);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->preset_4,
+ sgpio->preset_value);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->count_4,
+ sgpio->count_value);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->pos_4, 0x1f001f);
+
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->mask, 0xdfff);
+
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->ctrl_en, 0xffff);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->ctrl_en_pos,
+ 0xffff);
+}
+
+static int sgpio_set_irq_type(struct irq_data *d, unsigned int type)
+{
+ switch (type) {
+ case IRQ_TYPE_EDGE_BOTH:
+ case IRQ_TYPE_EDGE_RISING:
+ case IRQ_TYPE_EDGE_FALLING:
+ irq_set_handler_locked(d, handle_edge_irq);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void sgpio_mask_irq(struct irq_data *d)
+{
+ struct gpio_chip *chip;
+ struct ax3000_sgpio *sgpio;
+ u32 irq_num;
+
+ chip = irq_data_get_irq_chip_data(d);
+ if (!chip) {
+ pr_err("Unable to get gpio_chip for IRQ\n");
+ return;
+ }
+
+ sgpio = gpiochip_get_data(chip);
+ if (!sgpio) {
+ pr_err("Unable to get chip data\n");
+ return;
+ }
+
+ irq_num = irqd_to_hwirq(d);
+ sgpio->irq_unmasked[irq_num / 2] = 0;
+}
+
+static void sgpio_unmask_irq(struct irq_data *d)
+{
+ struct gpio_chip *chip;
+ struct ax3000_sgpio *sgpio;
+ u32 irq_num;
+
+ chip = irq_data_get_irq_chip_data(d);
+ if (!chip) {
+ pr_err("Unable to get gpio_chip for IRQ\n");
+ return;
+ }
+
+ sgpio = gpiochip_get_data(chip);
+ if (!sgpio) {
+ pr_err("Unable to get chip data\n");
+ return;
+ }
+
+ irq_num = irqd_to_hwirq(d);
+ sgpio->irq_unmasked[irq_num / 2] = 1;
+}
+
+static void sgpio_irq_shutdown(struct irq_data *d)
+{
+ sgpio_mask_irq(d);
+}
+
+static int sgpio_probe(struct platform_device *pdev)
+{
+ int rc;
+ int irq;
+ int i;
+ const __be32 *prop;
+ struct gpio_irq_chip *girq;
+ struct ax3000_sgpio *sgpio;
+ u32 variant;
+ u32 dout_value;
+ u32 bus_frequency;
+ u32 apb_frequency;
+ int dout_reverse;
+
+ void __iomem *base;
+
+ const struct regmap_config regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ };
+
+ sgpio = devm_kzalloc(&pdev->dev, sizeof(*sgpio), GFP_KERNEL);
+ if (!sgpio)
+ return -ENOMEM;
+
+ spin_lock_init(&sgpio->lock);
+
+ sgpio->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+
+ if (sgpio->regmap) {
+ rc = of_property_read_u32(pdev->dev.of_node, "reg",
+ &sgpio->regmap_base_offset);
+ if (rc) {
+ dev_err(&pdev->dev, "Failed to read reg property: %d\n",
+ rc);
+ return rc;
+ }
+ dev_info(&pdev->dev, "Using regmap with base offset: 0x%x\n",
+ sgpio->regmap_base_offset);
+ } else {
+ base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ sgpio->regmap =
+ devm_regmap_init_mmio(&pdev->dev, base, ®map_config);
+
+ if (IS_ERR(sgpio->regmap))
+ return PTR_ERR(sgpio->regmap);
+
+ sgpio->regmap_base_offset = 0;
+
+ dev_info(&pdev->dev, "Using MMIO regmap\n");
+ }
+
+ rc = device_property_read_u32(&pdev->dev, "ngpios", &sgpio->ngpios);
+ if (rc < 0) {
+ dev_err(&pdev->dev, "Could not read ngpios property\n");
+ return -EINVAL;
+ }
+
+ if (device_property_read_u32(&pdev->dev, "design-variant", &variant)) {
+ dev_err(&pdev->dev, "design-variant not specified in DT\n");
+ return -EINVAL;
+ }
+
+ if (variant == 128) {
+ sgpio->regs = &sgpio_offsets_128;
+ sgpio->max_sgpio_pins = 128;
+ sgpio->max_offset_regs = 4;
+ } else if (variant == 512) {
+ sgpio->regs = &sgpio_offsets_512;
+ sgpio->max_sgpio_pins = 512;
+ sgpio->max_offset_regs = 16;
+ } else {
+ return -EINVAL;
+ }
+
+ if (sgpio->ngpios > sgpio->max_sgpio_pins) {
+ dev_err(&pdev->dev, "ngpio is greater than 512 pins\n");
+ return -EINVAL;
+ }
+
+ rc = device_property_read_u32(&pdev->dev, "bus-frequency",
+ &bus_frequency);
+ if (rc < 0) {
+ dev_err(&pdev->dev, "Could not read bus-frequency property\n");
+ return -EINVAL;
+ }
+
+ rc = device_property_read_u32(&pdev->dev, "apb-frequency",
+ &apb_frequency);
+ if (rc < 0) {
+ dev_err(&pdev->dev, "Could not read apb-frequency property\n");
+ return -EINVAL;
+ }
+
+ sgpio->preset_value = (apb_frequency / bus_frequency) - 1;
+ sgpio->count_value = sgpio->preset_value;
+
+ u32 pos;
+
+ pos = sgpio->ngpios - 1;
+ sgpio->pos_reg = (pos << 16) | pos;
+
+ prop = of_get_property(pdev->dev.of_node, "dout-init", NULL);
+ if (!prop) {
+ dev_err(&pdev->dev, "Failed to get dout-init\n");
+ return -EINVAL;
+ }
+
+ for (i = 0; i < sgpio->max_offset_regs; i++) {
+ sgpio->slices[2].reg_ss[i] = 0;
+ dout_value = be32_to_cpu(prop[i]);
+
+ for (dout_reverse = 0; dout_reverse < 32; ++dout_reverse) {
+ sgpio->slices[2].reg_ss[i] <<= 1;
+ sgpio->slices[2].reg_ss[i] |= (dout_value & 1);
+ dout_value >>= 1;
+ }
+ }
+
+ sgpio_hw_init(sgpio);
+
+ irq = platform_get_irq(pdev, 0);
+
+ if (irq < 0) {
+ dev_err(&pdev->dev, "Failed to get parent IRQ: %d\n", irq);
+ return irq;
+ }
+ /* Store parent IRQ for cleanup */
+ sgpio->parent_irq = irq;
+
+ rc = devm_request_threaded_irq(&pdev->dev, irq, NULL, sgpio_irq_handler,
+ IRQF_ONESHOT, "axiado-sgpio", sgpio);
+
+ if (rc < 0) {
+ dev_err(&pdev->dev, "Failed to request threaded IRQ %d: %d\n",
+ irq, rc);
+ return rc;
+ }
+
+ sgpio->chip.parent = &pdev->dev;
+ sgpio->chip.ngpio = sgpio->ngpios * 2;
+ sgpio->chip.owner = THIS_MODULE;
+ sgpio->chip.direction_input = ax3000_sgpio_dir_in;
+ sgpio->chip.direction_output = ax3000_sgpio_dir_out;
+ sgpio->chip.get = ax3000_sgpio_get;
+ sgpio->chip.set = ax3000_sgpio_set;
+ sgpio->chip.label = dev_name(&pdev->dev);
+ sgpio->chip.base = -1;
+
+ girq = &sgpio->chip.irq;
+
+ girq->chip = &axiado_sgpio_irqchip;
+ girq->handler = handle_edge_irq;
+ girq->default_type = IRQ_TYPE_NONE;
+ girq->num_parents = 1;
+ girq->parents =
+ devm_kcalloc(&pdev->dev, 1, sizeof(*girq->parents), GFP_KERNEL);
+ if (!girq->parents) {
+ dev_err(&pdev->dev, "Failed to allocate parents array\n");
+ return -ENOMEM;
+ }
+ girq->parents[0] = irq;
+
+ rc = devm_gpiochip_add_data(&pdev->dev, &sgpio->chip, sgpio);
+ if (rc < 0) {
+ dev_err(&pdev->dev, "Could not register gpiochip, %d\n", rc);
+ return rc;
+ }
+
+ /* Store driver data for remove() */
+ platform_set_drvdata(pdev, sgpio);
+ dev_info(&pdev->dev, "SGPIO registered with %d GPIOs\n",
+ sgpio->chip.ngpio);
+
+ return 0;
+}
+
+static int sgpio_remove(struct platform_device *pdev)
+{
+ struct ax3000_sgpio *sgpio = platform_get_drvdata(pdev);
+ int i;
+
+ if (!sgpio)
+ return 0;
+
+ /* Disable interrupts in hardware */
+ if (sgpio->regs) {
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->mask,
+ 0x0);
+ regmap_write(sgpio->regmap,
+ sgpio->regmap_base_offset + sgpio->regs->ctrl_en,
+ 0x0);
+ }
+
+ /* Disable and synchronize parent IRQ to avoid races with handlers */
+ if (sgpio->parent_irq >= 0) {
+ disable_irq(sgpio->parent_irq);
+ synchronize_irq(sgpio->parent_irq);
+ }
+
+ /* Ensure all GPIO IRQ handlers complete before removal */
+ if (sgpio->chip.irq.domain) {
+ struct irq_domain *domain = sgpio->chip.irq.domain;
+ unsigned int irq;
+ int hwirq;
+
+ for (hwirq = 0; hwirq < sgpio->chip.ngpio; hwirq++) {
+ irq = irq_find_mapping(domain, hwirq);
+ if (irq) {
+ disable_irq(irq);
+ synchronize_irq(irq);
+ }
+ }
+ }
+
+ /* Clear internal IRQ state */
+ for (i = 0; i < sgpio->max_sgpio_pins; i++)
+ sgpio->irq_unmasked[i] = 0;
+
+ return 0;
+}
+
+static const struct of_device_id ax_sgpio_match[] = {
+ { .compatible = "axiado,sgpio" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, ax_sgpio_match);
+
+static struct platform_driver sgpio_driver = {
+ .driver = {
+ .name = "sgpio",
+ .owner = THIS_MODULE,
+ .of_match_table = ax_sgpio_match,
+ },
+ .probe = sgpio_probe,
+ .remove = sgpio_remove,
+};
+
+static int __init ax_sgpio_init(void)
+{
+ int ret;
+
+ ret = platform_driver_register(&sgpio_driver);
+ if (ret < 0) {
+ pr_err("Failed to register SGPIO driver\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static void __exit ax_sgpio_exit(void)
+{
+ platform_driver_unregister(&sgpio_driver);
+}
+
+module_init(ax_sgpio_init);
+module_exit(ax_sgpio_exit);
+
+MODULE_DESCRIPTION("Axiado Serial GPIO Driver");
+MODULE_AUTHOR("Axiado Corporation");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [GIT PULL] arm64 updates for 7.1
From: Catalin Marinas @ 2026-04-14 13:47 UTC (permalink / raw)
To: Linus Torvalds
Cc: Will Deacon, Thomas Gleixner, James Morse, Ben Horgan,
linux-arm-kernel, linux-kernel
Hi Linus,
Please pull the first round of arm64 updates for 7.1. The biggest
changes are MPAM enablement in drivers/resctrl and new PMU support under
drivers/perf. On the core side, FEAT_LSUI lets futex atomic operations
with EL0 permissions, avoiding PAN toggling. The rest is mostly TLB
invalidation refactoring, further generic entry work, sysreg updates and
a few fixes. More details in the tag.
The generic entry patches touch include/linux/*entry* and kernel/entry/*
as they are based on a tag from tip. Not sure when Thomas will send them
your way, so sending the arm64 pull request in the meantime.
There are a couple of trivial conflicts against mainline with the KVM
tree and an arm64 fix. I solved them as below:
-------------8<-----------------------------
diff --cc arch/arm64/kernel/rsi.c
index 9e846ce4ef9c,6e883bc43186..92160f2e57ff
--- a/arch/arm64/kernel/rsi.c
+++ b/arch/arm64/kernel/rsi.c
@@@ -145,9 -144,9 +145,9 @@@ void __init arm64_rsi_init(void
return;
if (!rsi_version_matches())
return;
- if (WARN_ON(rsi_get_realm_config(&config)))
+ if (WARN_ON(rsi_get_realm_config(lm_alias(&config))))
return;
- prot_ns_shared = BIT(config.ipa_bits - 1);
+ prot_ns_shared = __phys_to_pte_val(BIT(config.ipa_bits - 1));
if (arm64_ioremap_prot_hook_register(realm_ioremap_hook))
return;
diff --cc arch/arm64/kvm/at.c
index a024d9a770dc,1adf88a57328..9f8f0ae8e86e
--- a/arch/arm64/kvm/at.c
+++ b/arch/arm64/kvm/at.c
@@@ -1753,8 -1785,10 +1783,10 @@@ int __kvm_at_swap_desc(struct kvm *kvm
if (!writable)
return -EPERM;
- ptep = (u64 __user *)hva + offset;
+ ptep = (void __user *)hva + offset;
- if (cpus_have_final_cap(ARM64_HAS_LSE_ATOMICS))
+ if (cpus_have_final_cap(ARM64_HAS_LSUI))
+ r = __lsui_swap_desc(ptep, old, new);
+ else if (cpus_have_final_cap(ARM64_HAS_LSE_ATOMICS))
r = __lse_swap_desc(ptep, old, new);
else
r = __llsc_swap_desc(ptep, old, new);
-------------8<-----------------------------
Thanks.
The following changes since commit 1f318b96cc84d7c2ab792fcc0bfd42a7ca890681:
Linux 7.0-rc3 (2026-03-08 16:56:54 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-upstream
for you to fetch changes up to 480a9e57cceaf42db6ff874dbfe91de201935035:
Merge branches 'for-next/misc', 'for-next/tlbflush', 'for-next/ttbr-macros-cleanup', 'for-next/kselftest', 'for-next/feat_lsui', 'for-next/mpam', 'for-next/hotplug-batched-tlbi', 'for-next/bbml2-fixes', 'for-next/sysreg', 'for-next/generic-entry' and 'for-next/acpi', remote-tracking branches 'arm64/for-next/perf' and 'arm64/for-next/read-once' into for-next/core (2026-04-10 14:22:24 +0100)
----------------------------------------------------------------
arm64 updates for 7.1:
Core features:
- Add support for FEAT_LSUI, allowing futex atomic operations without
toggling Privileged Access Never (PAN)
- Further refactor the arm64 exception handling code towards the
generic entry infrastructure
- Optimise __READ_ONCE() with CONFIG_LTO=y and allow alias analysis
through it
Memory management:
- Refactor the arm64 TLB invalidation API and implementation for better
control over barrier placement and level-hinted invalidation
- Enable batched TLB flushes during memory hot-unplug
- Fix rodata=full block mapping support for realm guests (when
BBML2_NOABORT is available)
Perf and PMU:
- Add support for a whole bunch of system PMUs featured in NVIDIA's
Tegra410 SoC (cspmu extensions for the fabric and PCIe, new drivers
for CPU/C2C memory latency PMUs)
- Clean up iomem resource handling in the Arm CMN driver
- Fix signedness handling of AA64DFR0.{PMUVer,PerfMon}
MPAM (Memory Partitioning And Monitoring):
- Add architecture context-switch and hiding of the feature from KVM
- Add interface to allow MPAM to be exposed to user-space using resctrl
- Add errata workaround for some existing platforms
- Add documentation for using MPAM and what shape of platforms can use
resctrl
Miscellaneous:
- Check DAIF (and PMR, where relevant) at task-switch time
- Skip TFSR_EL1 checks and barriers in synchronous MTE tag check mode
(only relevant to asynchronous or asymmetric tag check modes)
- Remove a duplicate allocation in the kexec code
- Remove redundant save/restore of SCS SP on entry to/from EL0
- Generate the KERNEL_HWCAP_ definitions from the arm64 hwcap
descriptions
- Add kselftest coverage for cmpbr_sigill()
- Update sysreg definitions
----------------------------------------------------------------
Aneesh Kumar K.V (Arm) (1):
arm64: rsi: use linear-map alias for realm config buffer
Anshuman Khandual (5):
arm64/mm: Describe TTBR1_BADDR_4852_OFFSET
arm64/mm: Directly use TTBRx_EL1_ASID_MASK
arm64/mm: Directly use TTBRx_EL1_CnP
arm64/mm: Enable batched TLB flush in unmap_hotplug_range()
arm64/mm: Reject memory removal that splits a kernel leaf mapping
Ben Horgan (11):
arm_mpam: Reset when feature configuration bit unset
arm64/sysreg: Add MPAMSM_EL1 register
KVM: arm64: Preserve host MPAM configuration when changing traps
KVM: arm64: Make MPAMSM_EL1 accesses UNDEF
arm64: mpam: Drop the CONFIG_EXPERT restriction
arm64: mpam: Initialise and context switch the MPAMSM_EL1 register
arm_mpam: resctrl: Hide CDP emulation behind CONFIG_EXPERT
arm_mpam: resctrl: Add rmid index helpers
arm_mpam: resctrl: Wait for cacheinfo to be ready
arm_mpam: resctrl: Add monitor initialisation and domain boilerplate
arm64: mpam: Add initial MPAM documentation
Besar Wicaksono (7):
perf/arm_cspmu: nvidia: Rename doc to Tegra241
perf/arm_cspmu: nvidia: Add Tegra410 UCF PMU
perf/arm_cspmu: Add arm_cspmu_acpi_dev_get
perf/arm_cspmu: nvidia: Add Tegra410 PCIE PMU
perf/arm_cspmu: nvidia: Add Tegra410 PCIE-TGT PMU
perf: add NVIDIA Tegra410 CPU Memory Latency PMU
perf: add NVIDIA Tegra410 C2C PMU
Catalin Marinas (1):
Merge branches 'for-next/misc', 'for-next/tlbflush', 'for-next/ttbr-macros-cleanup', 'for-next/kselftest', 'for-next/feat_lsui', 'for-next/mpam', 'for-next/hotplug-batched-tlbi', 'for-next/bbml2-fixes', 'for-next/sysreg', 'for-next/generic-entry' and 'for-next/acpi', remote-tracking branches 'arm64/for-next/perf' and 'arm64/for-next/read-once' into for-next/core
Chen Ni (1):
perf/arm-cmn: Fix incorrect error check for devm_ioremap()
Dave Martin (2):
arm_mpam: resctrl: Convert to/from MPAMs fixed-point formats
arm_mpam: resctrl: Add kunit test for control format conversions
Haoyu Lu (1):
ACPI: AGDI: fix missing newline in error message
James Clark (3):
KVM: arm64: Read PMUVer as unsigned
arm64: cpufeature: Make PMUVer and PerfMon unsigned
arm64: cpufeature: Use pmuv3_implemented() function
James Morse (22):
arm64: mpam: Context switch the MPAM registers
arm64: mpam: Re-initialise MPAM regs when CPU comes online
arm64: mpam: Advertise the CPUs MPAM limits to the driver
arm64: mpam: Add cpu_pm notifier to restore MPAM sysregs
arm64: mpam: Add helpers to change a task or cpu's MPAM PARTID/PMG values
KVM: arm64: Force guest EL1 to use user-space's partid configuration
arm_mpam: resctrl: Add boilerplate cpuhp and domain allocation
arm_mpam: resctrl: Pick the caches we will use as resctrl resources
arm_mpam: resctrl: Implement resctrl_arch_reset_all_ctrls()
arm_mpam: resctrl: Add resctrl_arch_get_config()
arm_mpam: resctrl: Implement helpers to update configuration
arm_mpam: resctrl: Add plumbing against arm64 task and cpu hooks
arm_mpam: resctrl: Add CDP emulation
arm_mpam: resctrl: Add support for 'MB' resource
arm_mpam: resctrl: Add support for csu counters
arm_mpam: resctrl: Allow resctrl to allocate monitors
arm_mpam: resctrl: Add resctrl_arch_rmid_read()
arm_mpam: resctrl: Update the rmid reallocation limit
arm_mpam: resctrl: Add empty definitions for assorted resctrl functions
arm64: mpam: Select ARCH_HAS_CPU_RESCTRL
arm_mpam: resctrl: Call resctrl_init() on platforms that can support resctrl
arm_mpam: Quirk CMN-650's CSU NRDY behaviour
Jisheng Zhang (1):
arm64: remove ARCH_INLINE_*
Kevin Brodsky (1):
arm64: mm: Use generic enum pgtable_level
Marco Elver (2):
arm64: Optimize __READ_ONCE() with CONFIG_LTO=y
arm64, compiler-context-analysis: Permit alias analysis through __READ_ONCE() with CONFIG_LTO=y
Mark Brown (7):
arm64/sysreg: Update SMIDR_EL1 to DDI0601 2025-06
arm64/hwcap: Generate the KERNEL_HWCAP_ definitions for the hwcaps
arm64/sysreg: Update ID_AA64ISAR0_EL1 description to DDI0601 2025-12
arm64/sysreg: Update ID_AA64ISAR2_EL1 description to DDI0601 2025-12
arm64/sysreg: Update ID_AA64FPFR0_EL1 description to DDI0601 2025-12
arm64/sysreg: Update ID_AA64ZFR0_EL1 description to DDI0601 2025-12
arm64/sysreg: Update ID_AA64SMFR0_EL1 description to DDI0601 2025-12
Mark Rutland (10):
entry: Fix stale comment for irqentry_enter()
entry: Remove local_irq_{enable,disable}_exit_to_user()
entry: Move irqentry_enter() prototype later
entry: Split kernel mode logic from irqentry_{enter,exit}()
entry: Split preemption from irqentry_exit_to_kernel_mode()
arm64: entry: Don't preempt with SError or Debug masked
arm64: entry: Consistently prefix arm64-specific wrappers
arm64: entry: Use irqentry_{enter_from,exit_to}_kernel_mode()
arm64: entry: Use split preemption logic
arm64: Check DAIF (and PMR) at task-switch time
Michael Ugrin (1):
arm64: Kconfig: fix duplicate word in CMDLINE help text
Muhammad Usama Anjum (1):
arm64: mte: Skip TFSR_EL1 checks and barriers in synchronous tag check mode
Nathan Chancellor (1):
perf/arm-cmn: Fix resource_size_t printk specifier in arm_cmn_init_dtc()
Robin Murphy (1):
perf/arm-cmn: Stop claiming entire iomem region
Ryan Roberts (13):
arm64: mm: Re-implement the __tlbi_level macro as a C function
arm64: mm: Introduce a C wrapper for by-range TLB invalidation
arm64: mm: Implicitly invalidate user ASID based on TLBI operation
arm64: mm: Re-implement the __flush_tlb_range_op macro in C
arm64: mm: Refactor flush_tlb_page() to use __tlbi_level_asid()
arm64: mm: Refactor __flush_tlb_range() to take flags
arm64: mm: More flags for __flush_tlb_range()
arm64: mm: Wrap flush_tlb_page() around __do_flush_tlb_range()
arm64: mm: Provide level hint for flush_tlb_page()
arm64: mm: __ptep_set_access_flags must hint correct TTL
arm64: mm: Fix rodata=full block mapping support for realm guests
arm64: mm: Handle invalid large leaf mappings correctly
arm64: mm: Remove pmd_sect() and pud_sect()
Shanker Donthineni (4):
arm_mpam: Add quirk framework
arm_mpam: Add workaround for T241-MPAM-1
arm_mpam: Add workaround for T241-MPAM-4
arm_mpam: Add workaround for T241-MPAM-6
Wang Wensheng (1):
arm64: kexec: Remove duplicate allocation for trans_pgd
Will Deacon (5):
arm64: scs: Remove redundant save/restore of SCS SP on entry to/from EL0
arm64: mm: Push __TLBI_VADDR() into __tlbi_level()
arm64: mm: Inline __TLBI_VADDR_RANGE() into __tlbi_range()
arm64: mm: Simplify __TLBI_RANGE_NUM() macro
arm64: mm: Simplify __flush_tlb_range_limit_excess()
Yeoreum Yun (8):
arm64: cpufeature: Add FEAT_LSUI
KVM: arm64: Expose FEAT_LSUI to guests
KVM: arm64: kselftest: set_id_regs: Add test for FEAT_LSUI
arm64: futex: Refactor futex atomic operation
arm64: futex: Support futex with FEAT_LSUI
KVM: arm64: Use CAST instruction for swapping guest descriptor
arm64: Kconfig: Add support for LSUI
arm64: armv8_deprecated: Disable swp emulation when FEAT_LSUI present
Yifan Wu (1):
selftests/arm64: Implement cmpbr_sigill() to hwcap test
Zeng Heng (1):
arm_mpam: Ensure in_reset_state is false after applying configuration
Documentation/admin-guide/perf/index.rst | 3 +-
.../{nvidia-pmu.rst => nvidia-tegra241-pmu.rst} | 8 +-
.../admin-guide/perf/nvidia-tegra410-pmu.rst | 522 ++++++
Documentation/arch/arm64/index.rst | 1 +
Documentation/arch/arm64/mpam.rst | 72 +
Documentation/arch/arm64/silicon-errata.rst | 9 +
arch/arm/include/asm/arm_pmuv3.h | 7 +
arch/arm64/Kconfig | 54 +-
arch/arm64/include/asm/asm-uaccess.h | 2 +-
arch/arm64/include/asm/cpucaps.h | 2 +
arch/arm64/include/asm/el2_setup.h | 3 +-
arch/arm64/include/asm/futex.h | 311 +++-
arch/arm64/include/asm/hugetlb.h | 12 +-
arch/arm64/include/asm/hwcap.h | 120 +-
arch/arm64/include/asm/lsui.h | 27 +
arch/arm64/include/asm/mmu.h | 10 +-
arch/arm64/include/asm/mmu_context.h | 3 +-
arch/arm64/include/asm/mpam.h | 96 ++
arch/arm64/include/asm/mte.h | 6 +
arch/arm64/include/asm/pgtable-hwdef.h | 9 +-
arch/arm64/include/asm/pgtable-prot.h | 2 +
arch/arm64/include/asm/pgtable.h | 60 +-
arch/arm64/include/asm/resctrl.h | 2 +
arch/arm64/include/asm/rwonce.h | 24 +-
arch/arm64/include/asm/scs.h | 8 +
arch/arm64/include/asm/thread_info.h | 3 +
arch/arm64/include/asm/tlb.h | 6 +-
arch/arm64/include/asm/tlbflush.h | 471 +++---
arch/arm64/include/asm/uaccess.h | 6 +-
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/armv8_deprecated.c | 14 +
arch/arm64/kernel/cpufeature.c | 47 +-
arch/arm64/kernel/entry-common.c | 52 +-
arch/arm64/kernel/entry.S | 6 +-
arch/arm64/kernel/machine_kexec.c | 3 -
arch/arm64/kernel/mpam.c | 62 +
arch/arm64/kernel/mte.c | 10 +-
arch/arm64/kernel/process.c | 32 +
arch/arm64/kernel/rsi.c | 2 +-
arch/arm64/kernel/sys_compat.c | 2 +-
arch/arm64/kvm/at.c | 34 +-
arch/arm64/kvm/debug.c | 5 +-
arch/arm64/kvm/hyp/include/hyp/switch.h | 12 +-
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 4 +-
arch/arm64/kvm/hyp/nvhe/mm.c | 2 +-
arch/arm64/kvm/hyp/nvhe/tlb.c | 2 -
arch/arm64/kvm/hyp/pgtable.c | 4 +-
arch/arm64/kvm/hyp/vhe/sysreg-sr.c | 16 +
arch/arm64/kvm/hyp/vhe/tlb.c | 2 -
arch/arm64/kvm/sys_regs.c | 5 +-
arch/arm64/mm/context.c | 8 +-
arch/arm64/mm/contpte.c | 12 +-
arch/arm64/mm/fault.c | 30 +-
arch/arm64/mm/hugetlbpage.c | 10 +-
arch/arm64/mm/init.c | 9 +-
arch/arm64/mm/mmu.c | 286 +++-
arch/arm64/mm/pageattr.c | 50 +-
arch/arm64/mm/trans_pgd.c | 42 +-
arch/arm64/tools/Makefile | 8 +-
arch/arm64/tools/cpucaps | 1 +
arch/arm64/tools/gen-kernel-hwcaps.sh | 23 +
arch/arm64/tools/sysreg | 36 +-
drivers/acpi/arm64/agdi.c | 2 +-
drivers/perf/Kconfig | 14 +
drivers/perf/Makefile | 2 +
drivers/perf/arm-cmn.c | 70 +-
drivers/perf/arm_cspmu/arm_cspmu.c | 19 +-
drivers/perf/arm_cspmu/arm_cspmu.h | 17 +-
drivers/perf/arm_cspmu/nvidia_cspmu.c | 618 ++++++-
drivers/perf/nvidia_t410_c2c_pmu.c | 1051 ++++++++++++
drivers/perf/nvidia_t410_cmem_latency_pmu.c | 736 +++++++++
drivers/resctrl/Kconfig | 9 +-
drivers/resctrl/Makefile | 1 +
drivers/resctrl/mpam_devices.c | 305 +++-
drivers/resctrl/mpam_internal.h | 108 +-
drivers/resctrl/mpam_resctrl.c | 1704 ++++++++++++++++++++
drivers/resctrl/test_mpam_resctrl.c | 315 ++++
include/linux/arm_mpam.h | 32 +
include/linux/entry-common.h | 2 +-
include/linux/irq-entry-common.h | 256 ++-
kernel/entry/common.c | 107 +-
tools/testing/selftests/arm64/abi/hwcap.c | 3 +-
tools/testing/selftests/kvm/arm64/set_id_regs.c | 1 +
83 files changed, 7117 insertions(+), 946 deletions(-)
rename Documentation/admin-guide/perf/{nvidia-pmu.rst => nvidia-tegra241-pmu.rst} (98%)
create mode 100644 Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
create mode 100644 Documentation/arch/arm64/mpam.rst
create mode 100644 arch/arm64/include/asm/lsui.h
create mode 100644 arch/arm64/include/asm/mpam.h
create mode 100644 arch/arm64/include/asm/resctrl.h
create mode 100644 arch/arm64/kernel/mpam.c
create mode 100644 arch/arm64/tools/gen-kernel-hwcaps.sh
create mode 100644 drivers/perf/nvidia_t410_c2c_pmu.c
create mode 100644 drivers/perf/nvidia_t410_cmem_latency_pmu.c
create mode 100644 drivers/resctrl/mpam_resctrl.c
create mode 100644 drivers/resctrl/test_mpam_resctrl.c
--
Catalin
^ permalink raw reply
* Re: [PATCH RFC bpf-next 8/8] selftests/bpf: add tests to validate KASAN on JIT programs
From: Alexis Lothoré @ 2026-04-14 13:43 UTC (permalink / raw)
To: Andrey Konovalov, Alexis Lothoré (eBPF Foundation)
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
David S. Miller, David Ahern, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Shuah Khan,
Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, linux-kernel, netdev, linux-kselftest,
linux-stm32, linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CA+fCnZekgcEgsZnRrOB=+HoG=neRg=oLTt2jStyrPJ6mYf2ctQ@mail.gmail.com>
On Tue Apr 14, 2026 at 12:20 AM CEST, Andrey Konovalov wrote:
> On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation)
> <alexis.lothore@bootlin.com> wrote:
>>
>> Add a basic KASAN test runner that loads and test-run programs that can
>> trigger memory management bugs. The test captures kernel logs and ensure
>> that the expected KASAN splat is emitted by searching for the
>> corresponding first lines in the report.
>>
>> This version implements two faulty programs triggering either a
>> user-after-free, or an out-of-bounds memory usage. The bugs are
>> triggered thanks to some dedicated kfuncs in bpf_testmod.c, but two
>> different techniques are used, as some cases can be quite hard to
>> trigger in a pure "black box" approach:
>> - for reads, we can make the used kfuncs return some faulty pointers
>> that ebpf programs will manipulate, they will generate legitimate
>> kasan reports as a consequence
>> - applying the same trick for faulty writes is harder, as ebpf programs
>> can't write kernel data freely. So ebpf programs can call another
>> specific testing kfunc that will alter the shadow memory matching the
>> passed memory (eg: a map). When the program will try to write to the
>> corresponding memory, it will trigger a report as well.
>>
>> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
>> ---
>> The way of bringing kasan_poison into bpf_testmod is definitely not
>> ideal. But I would like to validate the testing approach (triggering
>> real faulty accesses, which is hard on some cases, VS manually poisoning
>> BPF-manipulated memory) before eventually making clean bridges between
>> KASAN APIs and bpf_testmod.c, if the latter approach is the valid one.
>
> Would it make sense to put these tests into KASAN KUnit tests in
> mm/kasan/kasan_test_c.c? I assume there is a kernel API to JIT BPF
> programs from the kernel itself?
Possibly indeed, but I think one important use case will be the
possibility to run those tests in BPF CI ([1]), and this depends on
those tests being integrated in the test_progs framework
(tools/testing/selftests/bpf)
[1] https://github.com/kernel-patches/bpf/pulls
> There, you can just call kasan_poison(), some tests already do this.
> And you can also extend the KASAN KUnit test framework to find out
> whether the bad access is a read or write, if you want to check this.
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 2/3] pmdomain: core: add support for power-domains-child-ids
From: Ulf Hansson @ 2026-04-14 13:42 UTC (permalink / raw)
To: Kevin Hilman
Cc: Rob Herring, Geert Uytterhoeven, linux-pm, devicetree,
linux-kernel, arm-scmi, linux-arm-kernel
In-Reply-To: <7hqzomqwpv.fsf@baylibre.com>
On Sat, 11 Apr 2026 at 00:25, Kevin Hilman <khilman@baylibre.com> wrote:
>
> Ulf Hansson <ulf.hansson@linaro.org> writes:
>
> > On Fri, 10 Apr 2026 at 02:45, Kevin Hilman <khilman@baylibre.com> wrote:
> >>
> >> Ulf Hansson <ulf.hansson@linaro.org> writes:
> >>
> >> > On Wed, 11 Mar 2026 at 01:19, Kevin Hilman (TI) <khilman@baylibre.com> wrote:
> >> >>
> >> >> Currently, PM domains can only support hierarchy for simple
> >> >> providers (e.g. ones with #power-domain-cells = 0).
> >> >>
> >> >> Add support for oncell providers as well by adding a new property
> >> >> `power-domains-child-ids` to describe the parent/child relationship.
> >> >>
> >> >> For example, an SCMI PM domain provider has multiple domains, each of
> >> >> which might be a child of diffeent parent domains. In this example,
> >> >> the parent domains are MAIN_PD and WKUP_PD:
> >> >>
> >> >> scmi_pds: protocol@11 {
> >> >> reg = <0x11>;
> >> >> #power-domain-cells = <1>;
> >> >> power-domains = <&MAIN_PD>, <&WKUP_PD>;
> >> >> power-domains-child-ids = <15>, <19>;
> >> >> };
> >> >>
> >> >> With this example using the new property, SCMI PM domain 15 becomes a
> >> >> child domain of MAIN_PD, and SCMI domain 19 becomes a child domain of
> >> >> WKUP_PD.
> >> >>
> >> >> To support this feature, add two new core functions
> >> >>
> >> >> - of_genpd_add_child_ids()
> >> >> - of_genpd_remove_child_ids()
> >> >>
> >> >> which can be called by pmdomain providers to add/remove child domains
> >> >> if they support the new property power-domains-child-ids.
> >> >>
> >> >> Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
> >> >
> >> > Thanks for working on this! It certainly is a missing feature!
> >>
> >> You're welcome, thanks for the detailed review.
> >>
> >> >> ---
> >> >> drivers/pmdomain/core.c | 169 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> include/linux/pm_domain.h | 16 ++++++++++++++++
> >> >> 2 files changed, 185 insertions(+)
> >> >>
> >> >> diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
> >> >> index 61c2277c9ce3..acb45dd540b7 100644
> >> >> --- a/drivers/pmdomain/core.c
> >> >> +++ b/drivers/pmdomain/core.c
> >> >> @@ -2909,6 +2909,175 @@ static struct generic_pm_domain *genpd_get_from_provider(
> >> >> return genpd;
> >> >> }
> >> >>
> >> >> +/**
> >> >> + * of_genpd_add_child_ids() - Parse power-domains-child-ids property
> >> >> + * @np: Device node pointer associated with the PM domain provider.
> >> >> + * @data: Pointer to the onecell data associated with the PM domain provider.
> >> >> + *
> >> >> + * Parse the power-domains and power-domains-child-ids properties to establish
> >> >> + * parent-child relationships for PM domains. The power-domains property lists
> >> >> + * parent domains, and power-domains-child-ids lists which child domain IDs
> >> >> + * should be associated with each parent.
> >> >> + *
> >> >> + * Returns 0 on success, -ENOENT if properties don't exist, or negative error code.
> >> >
> >> > I think we should avoid returning specific error codes for specific
> >> > errors, simply because it usually becomes messy.
> >> >
> >> > If I understand correctly the intent here is to allow the caller to
> >> > check for -ENOENT and potentially avoid bailing out as it may not
> >> > really be an error, right?
> >>
> >> Right, -ENOENT is not an error of parsing, it's to indicate that there
> >> are no child-ids to be parsed.
> >>
> >> > Perhaps a better option is to return the number of children for whom
> >> > we successfully assigned parents. Hence 0 or a positive value allows
> >> > the caller to understand what happened. More importantly, a negative
> >> > error code then really becomes an error for the caller to consider.
> >>
> >> I explored this a bit, but it gets messy quick. It means we have to
> >> track cases where only some of the children were added as well as when
> >> all children were added. Personally, I think this should be an "all or
> >> nothing" thing. If all the children cannot be parsed/added, then none
> >> of them should be added.
> >>
> >> This also allows the remove to not have to care about how many were
> >> added, and just remove them all, with the additional benefit of not
> >> having to track the state of how many children were successfully added.
> >>
> >
> > I fully agree, it should be all or nothing. Failing with one
> > child/parent should end up with an error code being returned.
> >
> > That said, it still seems to make perfect sense to return the number
> > of children for whom we assigned parents for, no?
>
> No, because what will the caller use that number for? If we are
> assuming "all or nothing", what would we use it for (other than a debug print?)
>
> It also makes it a bit confusing what a zero return value means. Does
> that mean success? Or that zero children were added (which would be
> fail.)
>
> I prefer to keep it as is.
In that case, how should we treat the scenario where the device node
lacks a "power-domains-child-ids" property? In some cases it is
probably fine, while in others it may not be.
I guess the caller of of_genpd_add_child_ids(), would then need to
pre-parse for the "power-domains-child-ids" property before deciding
to call of_genpd_add_child_ids().
At least, we don't of_genpd_add_child_ids() to return an error code if
there is no "power-domains-child-ids" in the device node, as that
would just confuse the caller.
Kind regards
Uffe
^ permalink raw reply
* [PATCH v3] arm64: defconfig: Enable Rockchip video decoder
From: Detlev Casanova @ 2026-04-14 13:37 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, kernel, linux-rockchip; +Cc: Detlev Casanova
The Rockchip video decoder (rkvdec) provides hardware-accelerated video
decoding on Rockchip SoCs. Enable it as a module so that users of these
widely used platforms get video decoding support out of the box.
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
---
Changes in v3:
- Update commit message
- Link to v2: https://patch.msgid.link/20260326-rkvdec-add-defconfig-v2-1-d65c296da9ba@collabora.com
Changes in v2:
- Update commit message
- Add missing CCs
- Link to v1: https://patch.msgid.link/20260325-rkvdec-add-defconfig-v1-1-89a55d3bb5c4@collabora.com
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b67d5b1fc45b..4b3f31cb4a94 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -931,6 +931,7 @@ CONFIG_VIDEO_RENESAS_VSP1=m
CONFIG_VIDEO_RCAR_DRIF=m
CONFIG_VIDEO_ROCKCHIP_CIF=m
CONFIG_VIDEO_ROCKCHIP_RGA=m
+CONFIG_VIDEO_ROCKCHIP_VDEC=m
CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC=m
CONFIG_VIDEO_SAMSUNG_S5P_JPEG=m
CONFIG_VIDEO_SAMSUNG_S5P_MFC=m
---
base-commit: bbeb83d3182abe0d245318e274e8531e5dd7a948
change-id: 20260325-rkvdec-add-defconfig-eaa11ab14f1f
Best regards,
--
Detlev Casanova <detlev.casanova@collabora.com>
^ permalink raw reply related
* Re: [PATCH 0/3] arm64/virt: Add Arm CCA measurement register support
From: Jason Gunthorpe @ 2026-04-14 13:35 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Sami Mujawar, Dan Williams, linux-arm-kernel, linux-kernel,
catalin.marinas, will, thuth, steven.price, gshan, YeoReum.Yun,
cedric.xing, Dan Williams, Dionna Glaze, Aneesh Kumar K . V,
Alexey Kardashevskiy, linux-coco@lists.linux.dev
In-Reply-To: <a1831d3d-af31-4fa7-b107-f4001841f051@arm.com>
On Tue, Apr 14, 2026 at 02:26:58PM +0100, Suzuki K Poulose wrote:
> On 14/04/2026 13:29, Jason Gunthorpe wrote:
> > On Tue, Apr 14, 2026 at 11:10:51AM +0100, Suzuki K Poulose wrote:
> >
> > > > Isn't this also sort of incomplete? Doesn't anything serious need
> > > > signed measurements? Isnt't there alot more data that comes out of RMM
> > > > than just a few measurement registers?
> > > As mentioned above, this series adds the support for Runtime Extendible
> > > Measurements (REM in CCA, RTMR on TDX). The RIM+Platform Attestation is
> > > already provided via the TSM_REPORT
> >
> > Okay, but what actual use is this?
> >
>
> Good point. This REMs are planned to be used for EFI_CC_MEASUREMENT_PROTOCOL
> as described below:
>
> https://github.com/tianocore/edk2/issues/11383
So this is tying it to the same FW event log that TPM uses.
I think that strengthens my point this should all be uninform. TPM
drivers are directly exposing the event log today, but I guess that
needs generalization if non-TPM drivers are going to present it as
well.
How do you imagine getting and manipulating the EFI event log to use
with this?
Jason
^ permalink raw reply
* Re: [PATCH v1 1/2] arm_mpam: resctrl: Fix broken error path in mpam_resctrl_alloc_domain()
From: Ben Horgan @ 2026-04-14 13:31 UTC (permalink / raw)
Cc: Dan Carpenter, Dan Carpenter, James Morse, Reinette Chatre,
Fenghua Yu, lkml, linux-arm-kernel
In-Reply-To: <20260414132758.196874-2-ben.horgan@arm.com>
Apologies, I just sent the same patch twice with different subjects. This one can be ignored.
Thanks,
Ben
On 4/14/26 14:27, Ben Horgan wrote:
> Dan Carpenter reports that, in mpam_resctrl_alloc_domain(), any_mon_comp is
> used in an 'if' condition when it may be uninitialized. Initialize it to
> NULL so that the check behaves correctly when no monitor components are
> found.
>
> Reported-by: Dan Carpenter <error27@gmail.com>
> Fixes: 264c285999fc ("arm_mpam: resctrl: Add monitor initialisation and domain boilerplate")
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> drivers/resctrl/mpam_resctrl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
> index a9938006d0e6..d80df486a313 100644
> --- a/drivers/resctrl/mpam_resctrl.c
> +++ b/drivers/resctrl/mpam_resctrl.c
> @@ -1399,7 +1399,7 @@ mpam_resctrl_alloc_domain(unsigned int cpu, struct mpam_resctrl_res *res)
> }
>
> if (r->mon_capable) {
> - struct mpam_component *any_mon_comp;
> + struct mpam_component *any_mon_comp = NULL;
> struct mpam_resctrl_mon *mon;
> enum resctrl_event_id eventid;
>
^ permalink raw reply
* [PATCH v1 2/2] arm_mpam: resctrl: Make resctrl_mon_ctx_waiters static
From: Ben Horgan @ 2026-04-14 13:27 UTC (permalink / raw)
To: ben.horgan
Cc: Dan Carpenter, Dan Carpenter, James Morse, Reinette Chatre,
Fenghua Yu, lkml, linux-arm-kernel, kernel test robot
In-Reply-To: <20260414132758.196874-1-ben.horgan@arm.com>
resctrl_mon_ctx_waiters is not used outside of this file, so make it
static. This fixes the sparse warning:
drivers/resctrl/mpam_resctrl.c:25:1: warning: symbol 'resctrl_mon_ctx_waiters' was not declared. Should it be static?
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603281842.c2K96tJA-lkp@intel.com/
Fixes: 2a3c79c61539 ("arm_mpam: resctrl: Allow resctrl to allocate monitors")
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
---
drivers/resctrl/mpam_resctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
index d80df486a313..bb933b224851 100644
--- a/drivers/resctrl/mpam_resctrl.c
+++ b/drivers/resctrl/mpam_resctrl.c
@@ -22,7 +22,7 @@
#include "mpam_internal.h"
-DECLARE_WAIT_QUEUE_HEAD(resctrl_mon_ctx_waiters);
+static DECLARE_WAIT_QUEUE_HEAD(resctrl_mon_ctx_waiters);
/*
* The classes we've picked to map to resctrl resources, wrapped
--
2.43.0
^ permalink raw reply related
* [PATCH v1 1/2] arm_mpam: resctrl: Fix the check for no monitor components found
From: Ben Horgan @ 2026-04-14 13:27 UTC (permalink / raw)
To: ben.horgan
Cc: Dan Carpenter, Dan Carpenter, James Morse, Reinette Chatre,
Fenghua Yu, lkml, linux-arm-kernel
In-Reply-To: <20260414132758.196874-1-ben.horgan@arm.com>
Dan Carpenter reports that, in mpam_resctrl_alloc_domain(), any_mon_comp is
used in an 'if' condition when it may be uninitialized. Initialize it to
NULL so that the check behaves correctly when no monitor components are
found.
Reported-by: Dan Carpenter <error27@gmail.com>
Fixes: 264c285999fc ("arm_mpam: resctrl: Add monitor initialisation and domain boilerplate")
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
---
drivers/resctrl/mpam_resctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
index a9938006d0e6..d80df486a313 100644
--- a/drivers/resctrl/mpam_resctrl.c
+++ b/drivers/resctrl/mpam_resctrl.c
@@ -1399,7 +1399,7 @@ mpam_resctrl_alloc_domain(unsigned int cpu, struct mpam_resctrl_res *res)
}
if (r->mon_capable) {
- struct mpam_component *any_mon_comp;
+ struct mpam_component *any_mon_comp = NULL;
struct mpam_resctrl_mon *mon;
enum resctrl_event_id eventid;
--
2.43.0
^ permalink raw reply related
* [PATCH v1 1/2] arm_mpam: resctrl: Fix broken error path in mpam_resctrl_alloc_domain()
From: Ben Horgan @ 2026-04-14 13:27 UTC (permalink / raw)
To: ben.horgan
Cc: Dan Carpenter, Dan Carpenter, James Morse, Reinette Chatre,
Fenghua Yu, lkml, linux-arm-kernel
In-Reply-To: <20260414132758.196874-1-ben.horgan@arm.com>
Dan Carpenter reports that, in mpam_resctrl_alloc_domain(), any_mon_comp is
used in an 'if' condition when it may be uninitialized. Initialize it to
NULL so that the check behaves correctly when no monitor components are
found.
Reported-by: Dan Carpenter <error27@gmail.com>
Fixes: 264c285999fc ("arm_mpam: resctrl: Add monitor initialisation and domain boilerplate")
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
---
drivers/resctrl/mpam_resctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
index a9938006d0e6..d80df486a313 100644
--- a/drivers/resctrl/mpam_resctrl.c
+++ b/drivers/resctrl/mpam_resctrl.c
@@ -1399,7 +1399,7 @@ mpam_resctrl_alloc_domain(unsigned int cpu, struct mpam_resctrl_res *res)
}
if (r->mon_capable) {
- struct mpam_component *any_mon_comp;
+ struct mpam_component *any_mon_comp = NULL;
struct mpam_resctrl_mon *mon;
enum resctrl_event_id eventid;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 0/3] arm64/virt: Add Arm CCA measurement register support
From: Suzuki K Poulose @ 2026-04-14 13:26 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Sami Mujawar, Dan Williams, linux-arm-kernel, linux-kernel,
catalin.marinas, will, thuth, steven.price, gshan, YeoReum.Yun,
cedric.xing, Dan Williams, Dionna Glaze, Aneesh Kumar K . V,
Alexey Kardashevskiy, linux-coco@lists.linux.dev
In-Reply-To: <20260414122950.GW3694781@ziepe.ca>
On 14/04/2026 13:29, Jason Gunthorpe wrote:
> On Tue, Apr 14, 2026 at 11:10:51AM +0100, Suzuki K Poulose wrote:
>
>>> Isn't this also sort of incomplete? Doesn't anything serious need
>>> signed measurements? Isnt't there alot more data that comes out of RMM
>>> than just a few measurement registers?
>> As mentioned above, this series adds the support for Runtime Extendible
>> Measurements (REM in CCA, RTMR on TDX). The RIM+Platform Attestation is
>> already provided via the TSM_REPORT
>
> Okay, but what actual use is this?
>
Good point. This REMs are planned to be used for
EFI_CC_MEASUREMENT_PROTOCOL as described below:
https://github.com/tianocore/edk2/issues/11383
At the moment they are exposed as raw, similar to the Intel TDX RTMRs.
This may eventually need to be connected to IMA subsystem.
> Extendable measrements with no log
> Measurement read back without signature
>
> What is the use case? What do you imagine any userspace will do with
> this? Put it in the cover letter.
Agreed.
>
> I don't think the raw rmm calls are sufficiently developed to be
> usable directly by userspace. They are less capable than TPM and even
> TPM has a lot of software around it to make it useful.
See above.
Kind regards
Suzuki
>
> Jason
^ permalink raw reply
* [PATCH v1 0/2] arm_mpam: resctrl: mpam resctrl glue code fixes
From: Ben Horgan @ 2026-04-14 13:27 UTC (permalink / raw)
To: ben.horgan
Cc: Dan Carpenter, Dan Carpenter, James Morse, Reinette Chatre,
Fenghua Yu, lkml, linux-arm-kernel
A couple of minor fixes for the new mpam resctrl glue code. These fix
a sparse warning and and use of an unitialized variable in an
unexpected error case.
Thanks for the bug reports.
Based on arm64 for-next/mpam.
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/mpam
Ben Horgan (2):
arm_mpam: resctrl: Fix the check for no monitor components found
arm_mpam: resctrl: Make resctrl_mon_ctx_waiters static
drivers/resctrl/mpam_resctrl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH RFC bpf-next 3/8] bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs
From: Alexis Lothoré @ 2026-04-14 13:24 UTC (permalink / raw)
To: Andrey Konovalov, Alexis Lothoré (eBPF Foundation)
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
David S. Miller, David Ahern, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Shuah Khan,
Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, linux-kernel, netdev, linux-kselftest,
linux-stm32, linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CA+fCnZf-o8tiv_tX9YB5eBUGx17OpztKZsEB6Awjw3WAqBAiUw@mail.gmail.com>
On Tue Apr 14, 2026 at 12:20 AM CEST, Andrey Konovalov wrote:
> On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation)
> <alexis.lothore@bootlin.com> wrote:
>>
>> Add a new Kconfig option CONFIG_BPF_JIT_KASAN that automatically enables
>> KASAN (Kernel Address Sanitizer) memory access checks for JIT-compiled
>> BPF programs, when both KASAN and JIT compiler are enabled. When
>> enabled, the JIT compiler will emit shadow memory checks before memory
>> loads and stores to detect use-after-free, out-of-bounds, and other
>> memory safety bugs at runtime. The option is gated behind
>> HAVE_EBPF_JIT_KASAN, as it needs proper arch-specific implementation.
>>
>> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
>> ---
>> kernel/bpf/Kconfig | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig
>> index eb3de35734f0..28392adb3d7e 100644
>> --- a/kernel/bpf/Kconfig
>> +++ b/kernel/bpf/Kconfig
>> @@ -17,6 +17,10 @@ config HAVE_CBPF_JIT
>> config HAVE_EBPF_JIT
>> bool
>>
>> +# KASAN support for JIT compiler
>> +config HAVE_EBPF_JIT_KASAN
>> + bool
>> +
>> # Used by archs to tell that they want the BPF JIT compiler enabled by
>> # default for kernels that were compiled with BPF JIT support.
>> config ARCH_WANT_DEFAULT_BPF_JIT
>> @@ -101,4 +105,9 @@ config BPF_LSM
>>
>> If you are unsure how to answer this question, answer N.
>>
>> +config BPF_JIT_KASAN
>> + bool
>> + depends on HAVE_EBPF_JIT_KASAN
>> + default y if BPF_JIT && KASAN_GENERIC
>
> Should this be "depends on KASAN && KASAN_GENERIC"?
Meaning, making it an explicit user-selectable option ?
If so, the current design choice is voluntary and based on the feedback
received on the original RFC, where I have been suggested to
automatically enable the KASAN instrumentation in BPF programs if KASAN
support is enabled in the kernel ([1]). But if a user-selectable toggle
is eventually a better solution, I'm fine with changing it.
[1] https://lore.kernel.org/bpf/CAADnVQLX7RSnOqQuU32Cgq-e0MVqyeNrtCQSBbk0W2xGkE-ZNw@mail.gmail.com/
>
>
>> +
>> endmenu # "BPF subsystem"
>>
>> --
>> 2.53.0
>>
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net] net: airoha: Add missing PPE configurations in airoha_ppe_hw_init()
From: patchwork-bot+netdevbpf @ 2026-04-14 13:20 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260412-airoha_ppe_hw_init-missing-bits-v1-1-06ac670819e3@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Sun, 12 Apr 2026 10:43:26 +0200 you wrote:
> Add the following PPE configuration in airoha_ppe_hw_init routine:
> - 6RD hw offloading is currently not supported by Netfilter flowtable.
> Disable explicitly PPE 6RD offloading in order to prevent PPE to learn
> 6RD flows and eventually interrupt the traffic.
> - Add missing PPE bind rate configuration for L3 and L2 traffic.
> PPE bind rate configuration specifies the pps threshold to move a PPE
> entry state from UNBIND to BIND. Without this configuration this value
> is random.
> - Set ageing thresholds to the values used in the vendor SDK in order to
> improve connection stability under load and avoid packet loss caused by
> fast aging.
>
> [...]
Here is the summary with links:
- [net] net: airoha: Add missing PPE configurations in airoha_ppe_hw_init()
https://git.kernel.org/netdev/net/c/b9d8b856689d
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] net: airoha: Wait for NPU PPE configuration to complete in airoha_ppe_offload_setup()
From: Lorenzo Bianconi @ 2026-04-14 13:15 UTC (permalink / raw)
To: Simon Horman
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260414124641.754059-1-horms@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2536 bytes --]
> From: 'Simon Horman' <horms@kernel.org>
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://sashiko.dev
> ---
> net: airoha: Wait for NPU PPE configuration to complete in airoha_ppe_offload_setup()
>
> This commit adds a poll loop in airoha_ppe_offload_setup() to wait for the NPU
> PPE configuration to complete before running airoha_ppe_hw_init().
>
> > diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> > index c2c32b6833df9..52199f6b39f9b 100644
> > --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> > +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> [ ... ]
> > @@ -1340,6 +1341,13 @@ static int airoha_ppe_offload_setup(struct airoha_eth *eth)
> > if (err)
> > goto error_npu_put;
> >
> > + /* Wait for NPU PPE configuration to complete */
> > + err = read_poll_timeout(airoha_fe_rr, val, val, USEC_PER_MSEC,
> > + 100 * USEC_PER_MSEC, false, eth,
> > + REG_PPE_PPE_FLOW_CFG(0));
>
> If the SoC has multiple PPE instances, is it sufficient to only wait for
> REG_PPE_PPE_FLOW_CFG(0)?
>
> Later in airoha_ppe_hw_init(), the code iterates up to eth->soc->num_ppe,
> initializing all available instances:
>
> drivers/net/ethernet/airoha/airoha_ppe.c:airoha_ppe_hw_init() {
> ...
> for (i = 0; i < eth->soc->num_ppe; i++) {
> ...
> airoha_fe_wr(eth, REG_PPE_TB_BASE(i),
> ppe->foe_dma + sram_tb_size);
> ...
> }
ack, let me look into it, I will post a v2.
>
> If we only poll PPE 0, could the driver race with the NPU firmware's
> initialization of subsequent PPEs?
>
> Additionally, does this poll condition properly ensure the hardware is ready?
> Since the break condition is simply `val`, it exits immediately if the register
> contains any non-zero value.
>
> If the register retains a non-zero value from a previous session (like across
> driver reloads), or if an unclocked domain returns 0xFFFFFFFF, this poll might
> succeed immediately and bypass the wait.
>
> Could we clear the register before polling, or wait for a specific bit instead?
I guess check val != 0 is enough since we reset the FE block and defualt
register value is 0 for both REG_PPE_PPE_FLOW_CFG(0) and
REG_PPE_PPE_FLOW_CFG(1).
Regards,
Lorenzo
>
> > + if (err)
> > + goto error_npu_put;
> > +
> > ppe_num_stats_entries = airoha_ppe_get_total_num_stats_entries(ppe);
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC] ACPI: processor: idle: Do not propagate acpi_processor_ffh_lpi_probe() -ENODEV
From: Breno Leitao @ 2026-04-14 13:14 UTC (permalink / raw)
To: Sudeep Holla
Cc: lihuisong (C), Rafael J. Wysocki, Len Brown, lpieralisi,
catalin.marinas, will, Rafael J. Wysocki, linux-acpi,
linux-kernel, pjaroszynski, guohanjun, linux-arm-kernel, rmikey,
kernel-team
In-Reply-To: <20260414-cute-shapeless-dolphin-c5b2fc@sudeepholla>
Hello Sudeep,
On Tue, Apr 14, 2026 at 01:25:53PM +0100, Sudeep Holla wrote:
> So while I understand that the kernel did not report an error previously, that
> does not mean the _LPI table is merely moot on this platform when it contains
> only a WFI state.
Can you clarify whether datacenter ARM systems are expected to expose
deeper idle states beyond WFI in their _LPI tables?
Backing up, I'm observing 72 pr_err() messages during boot on these
hosts and trying to determine whether this indicates a firmware issue or
if the kernel needs adjustment.
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Alexis Lothoré @ 2026-04-14 13:12 UTC (permalink / raw)
To: Andrey Konovalov, Alexis Lothoré (eBPF Foundation)
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
David S. Miller, David Ahern, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Shuah Khan,
Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, linux-kernel, netdev, linux-kselftest,
linux-stm32, linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CA+fCnZfubV6LgRjO3NQvhrG2Q5o0ftkFFupLWVYS50XDnmCaog@mail.gmail.com>
Hi Andrey, thanks for the prompt review !
On Tue Apr 14, 2026 at 12:19 AM CEST, Andrey Konovalov wrote:
> On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation)
> <alexis.lothore@bootlin.com> wrote:
>>
[...]
>> +#ifdef CONFIG_KASAN_GENERIC
>> +void __asan_load1(void *p);
>> +void __asan_store1(void *p);
>> +void __asan_load2(void *p);
>> +void __asan_store2(void *p);
>> +void __asan_load4(void *p);
>> +void __asan_store4(void *p);
>> +void __asan_load8(void *p);
>> +void __asan_store8(void *p);
>> +void __asan_load16(void *p);
>> +void __asan_store16(void *p);
>> +#endif /* CONFIG_KASAN_GENERIC */
>
> This looks ugly, let's not do this unless it's really required.
>
> You can just use kasan_check_read/write() instead - these are public
> wrappers around the same shadow memory checking functions. And they
> also work with the SW_TAGS mode, in case the BPF would want to use
> that mode at some point. (For HW_TAGS, we only have kasan_check_byte()
> that checks a single byte, but it can be extended in the future if
> required to be used by BPF.)
ACK, I'll try to use those kasan_check_read and kasan_check_write rather
than __asan_{load,store}X.
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix max TX packet length configuration
From: Paolo Abeni @ 2026-04-14 13:04 UTC (permalink / raw)
To: Lorenzo Bianconi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260412-airoha-fix-max-mtu-v1-1-333030d0a564@kernel.org>
On 4/12/26 10:09 AM, Lorenzo Bianconi wrote:
> According to the Airoha documentation, REG_GDM_LEN_CFG() register does not
> include FCS length. Fix MTU configuration removing ETH_FCS_LEN from
> maximum TX packet length configuration.
>
> Fixes: 54d989d58d2ac ("net: airoha: Move min/max packet len configuration in airoha_dev_open()")
> Fixes: 03b1b69f0662c ("net: airoha: Introduce airoha_dev_change_mtu callback")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index c14cdce588a7..a81ffda72b39 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1629,9 +1629,9 @@ static void airoha_update_hw_stats(struct airoha_gdm_port *port)
>
> static int airoha_dev_open(struct net_device *dev)
> {
> - int err, len = ETH_HLEN + dev->mtu + ETH_FCS_LEN;
> struct airoha_gdm_port *port = netdev_priv(dev);
> struct airoha_qdma *qdma = port->qdma;
> + int err, len = ETH_HLEN + dev->mtu;
Sashiko noted that the above may cause regressions, dropping max MTU
vlan frames.
/P
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix max TX packet length configuration
From: Lorenzo Bianconi @ 2026-04-14 13:04 UTC (permalink / raw)
To: Simon Horman
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260414124011.751922-1-horms@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]
> From: 'Simon Horman' <horms@kernel.org>
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://sashiko.dev
> ---
> net: airoha: Fix max TX packet length configuration
>
> This commit fixes the MTU configuration for the Airoha driver by removing
> ETH_FCS_LEN from the maximum TX packet length, matching the hardware
> documentation which states the register does not include the FCS length.
>
> > diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> > index c14cdce588a7c..a81ffda72b39f 100644
> > --- a/drivers/net/ethernet/airoha/airoha_eth.c
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> > @@ -1629,9 +1629,9 @@ static void airoha_update_hw_stats(struct airoha_gdm_port *port)
> >
> > static int airoha_dev_open(struct net_device *dev)
> > {
> > - int err, len = ETH_HLEN + dev->mtu + ETH_FCS_LEN;
> > struct airoha_gdm_port *port = netdev_priv(dev);
> > struct airoha_qdma *qdma = port->qdma;
> > + int err, len = ETH_HLEN + dev->mtu;
>
> Does this regression cause MTU-sized VLAN-tagged frames to be dropped by the
> hardware?
>
> By limiting the frame size to ETH_HLEN + dev->mtu, the maximum allowed length
> becomes 1514 bytes for a standard 1500 MTU. An Ethernet frame containing a
> standard 802.1Q VLAN tag and a maximum-sized 1500-byte IP payload requires an
> 18-byte L2 header, making the total frame size 1518 bytes (excluding FCS).
>
> Previously, the inclusion of ETH_FCS_LEN inadvertently provided the 4-byte
> headroom needed to accommodate a single VLAN tag.
>
> Could the configuration explicitly account for VLAN headers using VLAN_ETH_HLEN
> instead?
ack, thx for pointing this out. I will fix it in v2.
Regards,
Lorenzo
>
> [ ... ]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: airoha: Add missing PPE configurations in airoha_ppe_hw_init()
From: Simon Horman @ 2026-04-14 12:48 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260412-airoha_ppe_hw_init-missing-bits-v1-1-06ac670819e3@kernel.org>
On Sun, Apr 12, 2026 at 10:43:26AM +0200, Lorenzo Bianconi wrote:
> Add the following PPE configuration in airoha_ppe_hw_init routine:
> - 6RD hw offloading is currently not supported by Netfilter flowtable.
> Disable explicitly PPE 6RD offloading in order to prevent PPE to learn
> 6RD flows and eventually interrupt the traffic.
> - Add missing PPE bind rate configuration for L3 and L2 traffic.
> PPE bind rate configuration specifies the pps threshold to move a PPE
> entry state from UNBIND to BIND. Without this configuration this value
> is random.
> - Set ageing thresholds to the values used in the vendor SDK in order to
> improve connection stability under load and avoid packet loss caused by
> fast aging.
>
> Fixes: 00a7678310fe3 ("net: airoha: Introduce flowtable offload support")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* [PATCH v4 6/6] perf arm_spe: Print remaining IMPDEF event numbers
From: James Clark @ 2026-04-14 12:48 UTC (permalink / raw)
To: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, James Clark,
Al Grant, Leo Yan
In-Reply-To: <20260414-james-spe-impdef-decode-v4-0-1dd30783a33b@linaro.org>
Any IMPDEF events not printed out from a known core's IMPDEF list or for
a completely unknown core will still not be shown to the user. Fix this
by printing the remaining bits as comma separated raw numbers, e.g.
"IMPDEF:1,2,3,4".
Suggested-by: Al Grant <al.grant@arm.com>
Reviewed-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: James Clark <james.clark@linaro.org>
---
tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
index b74f887a48f2a13b1be165947b4e3293f9987bd4..600677318f84c06970e4e618280c39cc83ac5b1e 100644
--- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
+++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
@@ -8,6 +8,7 @@
#include <string.h>
#include <endian.h>
#include <byteswap.h>
+#include <linux/bitmap.h>
#include <linux/bitops.h>
#include <stdarg.h>
#include <linux/kernel.h>
@@ -365,6 +366,23 @@ static int arm_spe_pkt_desc_event(const struct arm_spe_pkt *packet,
payload);
}
+ /*
+ * Print remaining IMPDEF bits that weren't printed above as raw
+ * "IMPDEF:1,2,3,4" etc.
+ */
+ if (payload) {
+ arm_spe_pkt_out_string(&err, &buf, &buf_len, " IMPDEF:");
+ for (int i = 0; i < 64; i++) {
+ const char *sep = payload & (payload - 1) ? "," : "";
+
+ if (payload & BIT_ULL(i)) {
+ arm_spe_pkt_out_string(&err, &buf, &buf_len, "%d%s", i,
+ sep);
+ payload &= ~BIT_ULL(i);
+ }
+ }
+ }
+
return err;
}
--
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