* [PATCH v1] serial: ma35d1: Fix OF node reference leaks in console init
From: Yuho Choi @ 2026-06-30 21:40 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, linux-serial, Jacky Huang,
Shan-Chun Hung
Cc: linux-arm-kernel, linux-kernel, Yuho Choi
ma35d1serial_console_init_port() stores matching UART device nodes in
ma35d1serial_uart_nodes[] with an extra of_node_get() so that console
setup can later read the "reg" property. However, the stored references
are never released after console setup has finished using them.
Drop the stored node reference after ma35d1serial_console_setup() reads
the "reg" property, and clear the array slot to avoid leaving a stale
pointer behind. Also release the iterator reference before breaking out
of for_each_matching_node(), since the normal iterator advance will not
run in that path.
Fixes: 930cbf92db01 ("tty: serial: Add Nuvoton ma35d1 serial driver support")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
drivers/tty/serial/ma35d1_serial.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/ma35d1_serial.c b/drivers/tty/serial/ma35d1_serial.c
index 285b0fe41a86..920fe7ff5083 100644
--- a/drivers/tty/serial/ma35d1_serial.c
+++ b/drivers/tty/serial/ma35d1_serial.c
@@ -608,8 +608,14 @@ static int __init ma35d1serial_console_setup(struct console *co, char *options)
if (!np || !p)
return -ENODEV;
- if (of_property_read_u32_array(np, "reg", val32, ARRAY_SIZE(val32)) != 0)
+ if (of_property_read_u32_array(np, "reg", val32, ARRAY_SIZE(val32)) != 0) {
+ of_node_put(np);
+ ma35d1serial_uart_nodes[co->index] = NULL;
return -EINVAL;
+ }
+
+ of_node_put(np);
+ ma35d1serial_uart_nodes[co->index] = NULL;
p->port.iobase = val32[1];
p->port.membase = ioremap(p->port.iobase, MA35_UART_REG_SIZE);
@@ -648,8 +654,10 @@ static void ma35d1serial_console_init_port(void)
of_node_get(np);
ma35d1serial_uart_nodes[i] = np;
i++;
- if (i == MA35_UART_NR)
+ if (i == MA35_UART_NR) {
+ of_node_put(np);
break;
+ }
}
}
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 1/1] dt-bindings: mfd: st,stmpe: fix typo st,stmpe601 (should be st,stmpe610)
From: Linus Walleij @ 2026-06-30 21:47 UTC (permalink / raw)
To: Frank.Li
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Coquelin, Alexandre Torgue,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/STM32 ARCHITECTURE,
moderated list:ARM/STM32 ARCHITECTURE, open list, imx, Frank Li
In-Reply-To: <20260629223735.2559722-1-Frank.Li@oss.nxp.com>
On Tue, Jun 30, 2026 at 12:37 AM <Frank.Li@oss.nxp.com> wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> The compatible string "st,stmpe601" is a typo and does not correspond to
> any existing STMPE device in either the driver or DTS files. The correct
> compatible string is "st,stmpe610".
>
> Fix the typo to ensure proper schema matching and eliminate the
> following CHECK_DTBS warning:
> imx53-m53evk.dtb: /soc/bus@60000000/i2c@63fc4000/touchscreen@41: failed to match any schema with compatible: ['st,stmpe610']
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Fixes: e10038ce1ba9 ("dt-bindings: mfd: Convert STMPE to YAML schema")
With that added:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 3/4] firmware: raspberrypi: Add reboot mode support
From: Stefan Wahren @ 2026-06-30 21:57 UTC (permalink / raw)
To: Gregor Herburger, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Eric Anholt
Cc: linux-rpi-kernel, linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <20260630-rpi-tryboot-v2-3-f68d2dc6aa27@linutronix.de>
Hi Gregor,
Am 30.06.26 um 22:59 schrieb Gregor Herburger:
> The Raspberry Pi firmware has a tryboot mode where it tries to boot from
> another partition. This can be used to create a A/B update schema.
>
> To enable this on the next boot the RPI_FIRMWARE_SET_REBOOT_FLAGS
> message must be send to the firmware.
>
> Add support for this by registering a reboot mode driver.
>
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
> drivers/firmware/Kconfig | 1 +
> drivers/firmware/raspberrypi.c | 23 +++++++++++++++++++++++
> include/soc/bcm2835/raspberrypi-firmware.h | 2 ++
> 3 files changed, 26 insertions(+)
>
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index bbd2155d84838..04bc8263e0017 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -115,6 +115,7 @@ config ISCSI_IBFT
> config RASPBERRYPI_FIRMWARE
> tristate "Raspberry Pi Firmware Driver"
> depends on BCM2835_MBOX
> + select REBOOT_MODE
> help
> This option enables support for communicating with the firmware on the
> Raspberry Pi.
> diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> index 0aa322e9a2e73..bba8d14604002 100644
> --- a/drivers/firmware/raspberrypi.c
> +++ b/drivers/firmware/raspberrypi.c
> @@ -14,6 +14,7 @@
> #include <linux/of.h>
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
> +#include <linux/reboot-mode.h>
> #include <linux/slab.h>
> #include <soc/bcm2835/raspberrypi-firmware.h>
>
> @@ -29,6 +30,7 @@ struct rpi_firmware {
> struct mbox_client cl;
> struct mbox_chan *chan; /* The property channel. */
> struct completion c;
> + struct reboot_mode_driver reboot_mode;
> u32 enabled;
>
> struct kref consumers;
> @@ -273,10 +275,25 @@ static void devm_rpi_firmware_put(void *data)
> rpi_firmware_put(fw);
> }
>
> +static int rpi_firmware_reboot_mode_write(struct reboot_mode_driver *reboot,
> + unsigned int magic)
> +{
> + struct rpi_firmware *fw = container_of(reboot, struct rpi_firmware,
> + reboot_mode);
> + int ret = 0;
> +
> + if (magic)
> + ret = rpi_firmware_property(fw, RPI_FIRMWARE_SET_REBOOT_FLAGS,
> + &magic, sizeof(magic));
I think it's more elegant to check for !magic and return 0 directly. So
we can drop "ret".
> +
> + return ret;
> +}
> +
> static int rpi_firmware_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> struct rpi_firmware *fw;
> + int ret;
>
> /*
> * Memory will be freed by rpi_firmware_delete() once all users have
> @@ -306,6 +323,12 @@ static int rpi_firmware_probe(struct platform_device *pdev)
> rpi_register_hwmon_driver(dev, fw);
> rpi_register_clk_driver(dev);
>
> + fw->reboot_mode.dev = dev;
> + fw->reboot_mode.write = rpi_firmware_reboot_mode_write;
> + ret = devm_reboot_mode_register(dev, &fw->reboot_mode);
> + if (ret)
> + dev_err(dev, "Failed to register reboot mode: %d\n", ret);
I suggest to move all of this code into a function called
rpi_register_reboot_mode() ?
Best regards
> +
> return 0;
> }
>
> diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
> index 66cc5a426c3c5..f905bff0fb3ea 100644
> --- a/include/soc/bcm2835/raspberrypi-firmware.h
> +++ b/include/soc/bcm2835/raspberrypi-firmware.h
> @@ -81,6 +81,7 @@ enum rpi_firmware_property_tag {
> RPI_FIRMWARE_GET_POE_HAT_VAL = 0x00030049,
> RPI_FIRMWARE_SET_POE_HAT_VAL = 0x00030050,
> RPI_FIRMWARE_NOTIFY_XHCI_RESET = 0x00030058,
> + RPI_FIRMWARE_GET_REBOOT_FLAGS = 0x00030064,
> RPI_FIRMWARE_NOTIFY_DISPLAY_DONE = 0x00030066,
> RPI_FIRMWARE_SET_CLOCK_STATE = 0x00038001,
> RPI_FIRMWARE_SET_CLOCK_RATE = 0x00038002,
> @@ -92,6 +93,7 @@ enum rpi_firmware_property_tag {
> RPI_FIRMWARE_SET_SDHOST_CLOCK = 0x00038042,
> RPI_FIRMWARE_SET_GPIO_CONFIG = 0x00038043,
> RPI_FIRMWARE_SET_PERIPH_REG = 0x00038045,
> + RPI_FIRMWARE_SET_REBOOT_FLAGS = 0x00038064,
>
> /* Dispmanx TAGS */
> RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE = 0x00040001,
>
^ permalink raw reply
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: Linus Walleij @ 2026-06-30 21:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Dmitry Torokhov, Jakub Kicinski,
Paolo Abeni, Dominik Brodowski, linux-kernel, linux-arm-kernel,
linux-samsung-soc, patches, linux-m68k, linux-mips, linux-sh,
linux-input, linux-media, netdev, linux-sunxi, linux-phy,
linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-1-arnd@kernel.org>
On Mon, Jun 29, 2026 at 3:26 PM Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The linux/gpio.h header used to be the global definition for the gpio
> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
> 130 of those remain, so this series cleans out the rest.
>
> In each subsystem, we can replace the header either with
> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
> or linux/gpio/legacy.h for the few remaining users of the old number
> based interface.
>
> All patches in this series can get applied independently, so my
> preference would be for each subsystem maintainer to apply these
> directly, with the rest going into the gpio tree at some point.
>
> The final patch here obviously needs to wait for all the others
> to get merged first.
This is helpful.
The series:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 03/13] mips: replace linux/gpio.h inclusions
From: Philippe Mathieu-Daudé @ 2026-06-30 22:08 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-4-arnd@kernel.org>
On 29/6/26 15:26, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h should no longer be used, convert these instead to
> either linux/gpio/consumer.h or linux/gpio/legacy.h as needed.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/mips/alchemy/board-xxs1500.c | 2 +-
> arch/mips/alchemy/devboards/db1000.c | 2 +-
> arch/mips/alchemy/devboards/db1200.c | 2 +-
> arch/mips/alchemy/devboards/db1550.c | 2 +-
> arch/mips/bcm47xx/workarounds.c | 2 +-
> arch/mips/bcm63xx/boards/board_bcm963xx.c | 1 +
> arch/mips/include/asm/mach-bcm63xx/board_bcm963xx.h | 2 +-
> arch/mips/txx9/rbtx4927/setup.c | 2 +-
> 8 files changed, 8 insertions(+), 7 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 04/13] sh: replace linux/gpio.h inclusions
From: Philippe Mathieu-Daudé @ 2026-06-30 22:08 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-5-arnd@kernel.org>
On 29/6/26 15:26, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h should no longer be used, convert these instead to
> linux/gpio/legacy.h for the sh boards using the legacy interfaces,
> or remove it where it is not needed at all.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/sh/boards/board-magicpanelr2.c | 2 +-
> arch/sh/boards/board-sh7757lcr.c | 2 +-
> arch/sh/boards/board-urquell.c | 2 +-
> arch/sh/boards/mach-ap325rxa/setup.c | 2 +-
> arch/sh/boards/mach-ecovec24/setup.c | 2 +-
> arch/sh/boards/mach-highlander/pinmux-r7785rp.c | 2 +-
> arch/sh/boards/mach-kfr2r09/lcd_wqvga.c | 2 +-
> arch/sh/boards/mach-kfr2r09/setup.c | 2 +-
> arch/sh/boards/mach-migor/lcd_qvga.c | 2 +-
> arch/sh/boards/mach-migor/setup.c | 2 +-
> arch/sh/boards/mach-rsk/devices-rsk7203.c | 2 +-
> arch/sh/boards/mach-rsk/devices-rsk7269.c | 1 -
> arch/sh/boards/mach-se/7724/setup.c | 2 +-
> arch/sh/include/mach-common/mach/magicpanelr2.h | 2 --
> arch/sh/kernel/cpu/sh4a/setup-shx3.c | 2 +-
> 15 files changed, 13 insertions(+), 16 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 13/13] gpiolib: remove linux/gpio.h
From: Philippe Mathieu-Daudé @ 2026-06-30 22:09 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-14-arnd@kernel.org>
On 29/6/26 15:26, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> After all other drivers have converted to linux/gpio/consumer.h
> or linux/gpio/legacy.h, remove the final leftover bits here.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> MAINTAINERS | 1 -
> drivers/gpio/TODO | 4 +---
> drivers/gpio/gpiolib-cdev.c | 2 +-
> drivers/gpio/gpiolib-legacy.c | 3 +--
> drivers/gpio/gpiolib.c | 2 +-
> include/linux/gpio.h | 22 ----------------------
> 6 files changed, 4 insertions(+), 30 deletions(-)
> delete mode 100644 include/linux/gpio.h
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v4 1/7] dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via NVMEM
From: Linus Walleij @ 2026-06-30 22:12 UTC (permalink / raw)
To: Manikandan Muralidharan
Cc: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, arnd,
michael, linux-mtd, devicetree, linux-kernel, linux-arm-kernel,
netdev
In-Reply-To: <20260630092406.150587-2-manikandan.m@microchip.com>
Hi Manikandan,
thanks for your patch!
On Tue, Jun 30, 2026 at 11:24 AM Manikandan Muralidharan
<manikandan.m@microchip.com> wrote:
> Add an optional "sfdp" child node (compatible "jedec,sfdp") that
> describes the SFDP as a read-only NVMEM provider via nvmem.yaml, so its
> contents (e.g. a vendor EUI-48/EUI-64) can be read through NVMEM cells.
>
> Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
I would expect it to follow nvmem conventions like this, notice
compatibles specific-to-general with sfdp first:
sfdp {
/* NVMEM provided by SFDP */
compatible = "jedec,sfdp", "nvmem-cells";
label = "SFDP";
read-only;
#address-cells = <1>;
#size-cells = <1>;
mac0: macaddr@0x00 {
reg = <0x00 0x06>;
};
mac1: macaddr@0x06 {
reg = <0x06 0x06>;
};
};
Your example should definitely be more elaborate like this,
just an opaque sfdp node will not suffice. Maybe a separate
example?
Yours,
Linus Walleij
^ permalink raw reply
* Re: (subset) [PATCH v5 0/2] media: nxp: imx8-isi: Add virtual channel and frame descriptor support
From: Bryan O'Donoghue @ 2026-06-30 22:20 UTC (permalink / raw)
To: Frank Li, Laurent Pinchart
Cc: Mauro Carvalho Chehab, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Guoniu Zhou, Frank Li, Aisheng Dong, linux-media,
imx, linux-arm-kernel, linux-kernel, Guoniu Zhou
In-Reply-To: <akPsxPgLNgu3YsEV@SMW015318>
On 30/06/2026 17:20, Frank Li wrote:
> On Mon, Jun 29, 2026 at 11:23:02PM +0300, Laurent Pinchart wrote:
>> On Mon, Jun 29, 2026 at 03:42:31PM -0400, Frank.Li@oss.nxp.com wrote:
>>> From: Frank Li <Frank.Li@nxp.com>
>>>
>>>
>>> On Thu, 21 May 2026 17:10:03 +0800, Guoniu Zhou wrote:
>>>> This patch series enhances the i.MX ISI driver's with virtual channel
>>>> support and adds frame descriptor capabilities to the crossbar subdevice.
>>>
>>> Applied, thanks!
>>>
>>> [1/2] media: imx8-isi: crossbar: Add get_frame_desc operation
>>> commit: 3e15a3510908c990ee352aa206d5f9c23d4b216e
>>
>> Is this a mistake ? Patch 1/2 has no R-b tag, and you're not listed as
>> maintainer for this driver.
>
> Sorry, I missed checking Maintainer files, in media summit, agree on I pick
> imx's media drivers, but forget finalize the file\dir list. Can you help
> summery which files\dir I should take care?
>
> If you have concern about this patch, I can drop it.
>
> Frank
You should set yourself up here:
https://patchwork.linuxtv.org/project/linux-media/list/
That way you can coordinate with other maintainers on which files get
reviewed by whom, see what the RB and ci status is.
Its pretty essential.
---
bod
^ permalink raw reply
* [PATCH] arm64/sysreg: Fix BWE field encoding in ID_AA64DFR2_EL1
From: Jia He @ 2026-06-30 22:23 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier, linux-arm-kernel
Cc: Lorenzo Pieralisi, Mark Brown, Sascha Bischoff, Fuad Tabba,
Anshuman Khandual, Oliver Upton, linux-kernel, Bin Guo, Jia He
Commit 93d7356e4b30 ("arm64: sysreg: Describe ID_AA64DFR2_EL1 fields")
encodes the FEAT_BWE2 value of the BWE field as '0b0002'. Binary
literals only accept the digits 0 and 1, so the intended value is 2,
i.e. 0b0010.
The macro generated by gen-sysreg.awk currently expands to
#define ID_AA64DFR2_EL1_BWE_FEAT_BWE2 UL(0b0002)
is not legal C and would fail to compile if any in-tree code referenced
it. At present no caller uses this enum value, so the kernel still
builds cleanly, but the bug is latent.
Fix the typo by using the correct binary literal 0b0010.
Cc: Bin Guo <guobin@linux.alibaba.com>
Fixes: 93d7356e4b30 ("arm64: sysreg: Describe ID_AA64DFR2_EL1 fields")
Signed-off-by: Jia He <justin.he@arm.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/tools/sysreg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index bc1788b1662b..7cb61aca3797 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1806,7 +1806,7 @@ Res0 15:8
UnsignedEnum 7:4 BWE
0b0000 NI
0b0001 FEAT_BWE
- 0b0002 FEAT_BWE2
+ 0b0010 FEAT_BWE2
EndEnum
UnsignedEnum 3:0 STEP
0b0000 NI
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 3/7] mtd: spi-nor: sfdp: expose the SFDP as a read-only NVMEM device
From: Linus Walleij @ 2026-06-30 22:25 UTC (permalink / raw)
To: Manikandan Muralidharan
Cc: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, arnd,
michael, linux-mtd, devicetree, linux-kernel, linux-arm-kernel,
netdev
In-Reply-To: <20260630092406.150587-4-manikandan.m@microchip.com>
Hi Manikandan,
thanks for your patch!
On Tue, Jun 30, 2026 at 11:25 AM Manikandan Muralidharan
<manikandan.m@microchip.com> wrote:
> Register the cached SFDP as a read-only NVMEM device rooted at the
> flash's "sfdp" child node, exposing it in on-flash byte order. This lets
> NVMEM cells reference any SFDP data: a fixed-layout for parameters at a
> known offset, or an nvmem-layout parser for vendor data whose location
> must be discovered at runtime. The device is only registered when an
> "sfdp" node is present in the device tree.
It seems the existing serial NOR driver core already reads out the SFDP
and stores it in nor->sfdp->dwords, right?
This should be mentioned in the commit so we know when the stuff
is actually read in from the flash memory.
>
> Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
(...)
> @@ -3204,6 +3204,11 @@ static int spi_nor_init_params(struct spi_nor *nor)
> spi_nor_init_params_deprecated(nor);
> }
>
> + /* Expose the SFDP as an NVMEM device. */
Add "if and only if the flash has an SFDP"
> +static int spi_nor_sfdp_nvmem_read(void *priv, unsigned int offset,
> + void *val, size_t bytes)
Name it _reg_read() to mirror the nvmem prototype.
> +/**
> + * spi_nor_register_sfdp_nvmem() - expose the SFDP as a read-only NVMEM device
> + * @nor: pointer to a 'struct spi_nor'
> + *
> + * Expose the whole SFDP, in on-flash byte order, as a read-only NVMEM device
> + * rooted at the flash's "sfdp" child node. This lets generic (fixed-layout) or
> + * vendor (nvmem-layout) cells reference any SFDP data. The device is only
> + * registered when an "sfdp" node is described in the device tree.
> + *
> + * Return: 0 on success or if there is nothing to do, -errno otherwise.
> + */
> +int spi_nor_register_sfdp_nvmem(struct spi_nor *nor)
> +{
> + struct device *dev = nor->dev;
> + struct nvmem_config config = { };
> + struct nvmem_device *nvmem;
> + struct device_node *np;
> + int ret;
> +
> + if (!nor->sfdp)
> + return 0;
> +
> + np = of_get_child_by_name(dev_of_node(dev), "sfdp");
> + if (!np)
> + return 0;
If this node name is required to be named like that it has to be
enforced in the schema.
I would instead check all the nodes (for_each_available_child)
for the right compatible "jedec,sfdp".
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 5/7] ARM: dts: microchip: sama5d27_wlsom1: use fixed-partitions for QSPI flash
From: Linus Walleij @ 2026-06-30 22:27 UTC (permalink / raw)
To: Manikandan Muralidharan
Cc: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, arnd,
michael, linux-mtd, devicetree, linux-kernel, linux-arm-kernel,
netdev
In-Reply-To: <20260630092406.150587-6-manikandan.m@microchip.com>
On Tue, Jun 30, 2026 at 11:26 AM Manikandan Muralidharan
<manikandan.m@microchip.com> wrote:
> Move the QSPI flash partitions under a "partitions" node with the
> "fixed-partitions" compatible, as required by the current MTD partition
> binding, instead of declaring them as direct children of the flash node.
> No functional change.
>
> Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 1/2] gpio: shared-proxy: always serialize with a sleeping mutex
From: Linus Walleij @ 2026-06-30 22:31 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Viacheslav Bocharov, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Marek Szyprowski, Robin Murphy,
Diederik de Haas, linux-gpio, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <CAMRc=MfpXEFreGynUtAJfvW+27OgKiTOEZvkddt5U0+QG4cYeQ@mail.gmail.com>
On Fri, Jun 26, 2026 at 5:02 PM Bartosz Golaszewski <brgl@kernel.org> wrote:
> This looks good to me. Linus: do you want me to take patch 2/2 as well? I'll
> send it for v7.2-rc2.
Yep that's the best, I'll add my tag.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 2/2] pinctrl: meson: restore non-sleeping GPIO access
From: Linus Walleij @ 2026-06-30 22:31 UTC (permalink / raw)
To: Viacheslav Bocharov
Cc: Bartosz Golaszewski, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Marek Szyprowski, Robin Murphy,
Diederik de Haas, linux-gpio, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260625115718.1678991-3-v@baodeep.com>
On Thu, Jun 25, 2026 at 1:58 PM Viacheslav Bocharov <v@baodeep.com> wrote:
> Commit 28f240683871 ("pinctrl: meson: mark the GPIO controller as
> sleeping") set gpio_chip.can_sleep = true to work around
> gpio-shared-proxy holding a spinlock across a sleeping pinctrl config
> path. That locking bug is now fixed in the shared-proxy itself ("gpio:
> shared-proxy: always serialize with a sleeping mutex"), so the
> controller-wide workaround is no longer needed; the meson GPIO
> controller does not sleep.
>
> meson_gpio_get/set/direction_* access MMIO through regmap. The
> regmap_mmio bus uses fast I/O (spinlock) locking, so these value
> callbacks do not contain sleeping operations. Since gpio_chip.can_sleep
> describes the get/set value path, restore can_sleep = false.
>
> Marking the controller sleeping also broke atomic value consumers such
> as w1-gpio (1-Wire bitbang): w1_io.c runs its read time slot under
> local_irq_save() and uses the non-cansleep gpiod_set_value() /
> gpiod_get_value(), which with can_sleep=true trigger WARN_ON(can_sleep)
> in gpiolib on every transferred bit (from w1_gpio_write_bit() /
> w1_gpio_read_bit() via w1_reset_bus() and w1_search()). The printk and
> stack dump inside the IRQs-off, microsecond-scale time slot destroy the
> bit timing, so reset/presence detection and ROM search fail: the bus
> master registers but w1_master_slave_count stays at 0 and no devices
> are found. Verified on an Amlogic A113X board (DS18B20 on GPIOA_14):
> with can_sleep restored to false the warnings are gone and the sensor
> is detected and read again.
>
> This must not be applied or backported without the shared-proxy locking
> fix above; otherwise the original Khadas VIM3 splat returns on boards
> that genuinely share a meson GPIO.
>
> Fixes: 28f240683871 ("pinctrl: meson: mark the GPIO controller as sleeping")
> Link: https://lore.kernel.org/all/20260105150509.56537-1-bartosz.golaszewski@oss.qualcomm.com/
> Signed-off-by: Viacheslav Bocharov <v@baodeep.com>
Acked-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2] ARM: enable interrupts when unhandled user faults are triggered
From: Linus Walleij @ 2026-06-30 22:49 UTC (permalink / raw)
To: Xie Yuanbin
Cc: linux, bigeasy, clrkwllms, rostedt, rmk+kernel, arnd,
linux-arm-kernel, linux-kernel, linux-rt-devel, liaohua4,
lilinjie8
In-Reply-To: <20260629123349.134224-1-xieyuanbin1@huawei.com>
On Mon, Jun 29, 2026 at 2:34 PM Xie Yuanbin <xieyuanbin1@huawei.com> wrote:
> PREEMPT_RT requires interrupts to be enabled when sending signals.
>
> When do_DataAbort()/do_PrefetchAbort() triggers unhandled user faults,
> that is `inf->fn()` return a non-zero value, and the interrupts are not
> enabled within the hook function, force_sig_fault() will be called
> with interrupts disabled.
>
> This can be triggered by user programs executing the bkpt instruction,
> with kernel config CONFIG_PERF_EVENTS=n.
>
> Enable interrupts in do_DataAbort()/do_PrefetchAbort() when unhandled
> user faults are triggered to fix the issue.
>
> Fixes: c6e61c06d606 ("ARM: 9463/1: Allow to enable RT")
>
Skip blank line.
> Suggested-by: Russell King <linux@armlinux.org.uk>
> Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com>
I had something like this in my (currently put on ice) generic entry
patch series:
https://lore.kernel.org/linux-arm-kernel/20250225-arm-generic-entry-v5-30-2f02313653e5@linaro.org/
This goes in that direction so:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v1 0/6] perf vendor events intel: update
From: Namhyung Kim @ 2026-06-30 23:35 UTC (permalink / raw)
To: peterz, mingo, acme, Chun-Tse Shao
Cc: alexander.shishkin, jolsa, irogers, adrian.hunter, james.clark,
afaerber, mani, dapeng1.mi, linux-perf-users, linux-kernel,
linux-arm-kernel, linux-actions
In-Reply-To: <20260609215046.2391903-1-ctshao@google.com>
On Tue, 09 Jun 2026 14:50:39 -0700, Chun-Tse Shao wrote:
> Sync with the latest perfmon events from:
> https://github.com/intel/perfmon
> by running the script:
> https://github.com/intel/perfmon/blob/main/scripts/create_perf_json.py
> and copying the resulting json and mapfile.csv changes into the perf
> tree.
>
> [...]
Applied to perf-tools-next, thanks!
Best regards,
Namhyung
^ permalink raw reply
* Re: [PATCH v3 02/13] iio: adc: at91-sama5d2_adc: use cleanup.h for NVMEM buffer
From: Jonathan Cameron @ 2026-06-30 23:36 UTC (permalink / raw)
To: Varshini Rajendran
Cc: ehristev, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
marcelo.schmitt, jorge.marques, mazziesaccount, Jonathan.Santos,
jishnu.prakash, antoniu.miclaus, duje, linux-iio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260630093603.38663-3-varshini.rajendran@microchip.com>
On Tue, 30 Jun 2026 15:05:52 +0530
Varshini Rajendran <varshini.rajendran@microchip.com> wrote:
> Use __free(kfree) cleanup helper for the NVMEM data buffer in
> at91_adc_temp_sensor_init() to simplify error handling paths.
>
> Since __free(kfree) requires a valid kfree-able pointer (not an
Does it require a a kfree-able pointer?
Definition is:
DEFINE_FREE(kfree, void *, if (!IS_ERR_OR_NULL(_T)) kfree(_T))
Some of these DEFINE_FREE() uses did change to be more resilient
to errors so maybe you have an old kernel?
> ERR_PTR), store nvmem_cell_read() result in a temporary void pointer
> first, check for errors, then assign to the managed buffer.
>
> Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
> ---
> drivers/iio/adc/at91-sama5d2_adc.c | 21 +++++++++++----------
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iio/adc/at91-sama5d2_adc.c b/drivers/iio/adc/at91-sama5d2_adc.c
> index 255970b2e747..5015c234289e 100644
> --- a/drivers/iio/adc/at91-sama5d2_adc.c
> +++ b/drivers/iio/adc/at91-sama5d2_adc.c
> @@ -2251,9 +2251,10 @@ static int at91_adc_temp_sensor_init(struct at91_adc_state *st,
> {
> struct at91_adc_temp_sensor_clb *clb = &st->soc_info.temp_sensor_clb;
> struct nvmem_cell *temp_calib;
> - u32 *buf;
> + u32 *buf __free(kfree) = NULL;
This breaks the 'rule' about having the destructor defined right next to the
destructor (IIRC there is guidance on this in cleanup.h comments). Linus is
very keen on this always being done and doesn't like the = NULL pattern at all
(I agree but easier to blame the chief Penguin ;)
Given the argument for this seems to be wrong anyway, just define and assign
in one line below.
> + void *cell_data;
> size_t len;
> - int ret = 0;
> + int ret;
>
> if (!st->soc_info.platform->temp_sensor)
> return 0;
> @@ -2267,16 +2268,18 @@ static int at91_adc_temp_sensor_init(struct at91_adc_state *st,
> return ret;
> }
>
> - buf = nvmem_cell_read(temp_calib, &len);
> + cell_data = nvmem_cell_read(temp_calib, &len);
> nvmem_cell_put(temp_calib);
This dance with nvmem_cell_put being called before the error check
seems like another place a cleanup.h trick is useful.
Can we have a DEFINE_FREE() for nvmem_cell_put() I don't think
ti will matter if we hold that reference for the scope of the rest
of this function - but do check that!
With that in place, you can just do
u32 *buf __free(kfree) = nvmem_cell_read(temp_calib, &len);
if (IS_ERR(buf))
return dev_err_probe(dev, PTR_ERR(buf),
"Failed to read calibration data");
}
> - if (IS_ERR(buf)) {
> + if (IS_ERR(cell_data)) {
> dev_err(dev, "Failed to read calibration data!\n");
> - return PTR_ERR(buf);
> + return PTR_ERR(cell_data);
> }
> +
> + buf = cell_data;
> +
> if (len < AT91_ADC_TS_CLB_IDX_MAX * 4) {
> dev_err(dev, "Invalid calibration data!\n");
> - ret = -EINVAL;
> - goto free_buf;
> + return -EINVAL;
> }
>
> /* Store calibration data for later use. */
> @@ -2289,9 +2292,7 @@ static int at91_adc_temp_sensor_init(struct at91_adc_state *st,
> */
> clb->p1 = clb->p1 * 1000;
>
> -free_buf:
> - kfree(buf);
> - return ret;
> + return 0;
> }
>
> static int at91_adc_probe(struct platform_device *pdev)
^ permalink raw reply
* Re: [PATCH v3 03/13] iio: adc: at91-sama5d2_adc: rework temp calibration layout handling
From: Jonathan Cameron @ 2026-06-30 23:38 UTC (permalink / raw)
To: Varshini Rajendran
Cc: ehristev, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
marcelo.schmitt, jorge.marques, mazziesaccount, Jonathan.Santos,
jishnu.prakash, antoniu.miclaus, duje, linux-iio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260630093603.38663-4-varshini.rajendran@microchip.com>
On Tue, 30 Jun 2026 15:05:53 +0530
Varshini Rajendran <varshini.rajendran@microchip.com> wrote:
> Extend support to handle different temperature calibration layouts.
>
> Add a temperature calibration data layout structure to describe indexes
> of the factors P1, P4, P6, tag, minimum length of the packet and the
> scaling factors for P1 (mul, div) which are SoC-specific instead of the
> older non scalable id structure. This helps handle the differences in the
> same function flow and prepare the calibration data to be applied. Add
> additional condition to validate the calibration data read from the
> NVMEM cell using the TAG of the packet.
Last bit smells like an AND in a commit message.
I.e. should be in as separate patch as it is making a functional change,
whereas the rest is refactoring only.
^ permalink raw reply
* Re: [PATCH v3 04/13] iio: adc: at91-sama5d2_adc: adapt the driver for sama7d65
From: Jonathan Cameron @ 2026-06-30 23:43 UTC (permalink / raw)
To: Varshini Rajendran
Cc: ehristev, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
marcelo.schmitt, jorge.marques, mazziesaccount, Jonathan.Santos,
jishnu.prakash, antoniu.miclaus, duje, linux-iio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260630093603.38663-5-varshini.rajendran@microchip.com>
On Tue, 30 Jun 2026 15:05:54 +0530
Varshini Rajendran <varshini.rajendran@microchip.com> wrote:
> Add support for sama7d65 ADC. The differences are highlighted with the
> compatible. The calibration data layout is the main difference.
>
> Update Kconfig help text to mention SAMA7 SoC family support.
>
> Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
> @@ -2639,6 +2667,9 @@ static const struct of_device_id at91_adc_dt_match[] = {
> }, {
> .compatible = "microchip,sama7g5-adc",
> .data = (const void *)&sama7g5_platform,
> + }, {
> + .compatible = "microchip,sama7d65-adc",
> + .data = (const void *)&sama7d65_platform,
Silly question for you that is more about the original code than what you
are adding, but why the casts? It is already a const pointer so I think
we are fine under the C spec to just do this cast implicitly to a const
void *
If you agree, ideally please add a precursor patch to drop these casts
before this patch.
Thanks,
Jonathan
> }, {
> /* sentinel */
> }
^ permalink raw reply
* Re: [PATCH v3 06/13] nvmem: microchip-otpc: add tag-based packet lookup
From: Jonathan Cameron @ 2026-06-30 23:49 UTC (permalink / raw)
To: Varshini Rajendran
Cc: ehristev, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
marcelo.schmitt, jorge.marques, mazziesaccount, Jonathan.Santos,
jishnu.prakash, antoniu.miclaus, duje, linux-iio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260630093603.38663-7-varshini.rajendran@microchip.com>
On Tue, 30 Jun 2026 15:05:56 +0530
Varshini Rajendran <varshini.rajendran@microchip.com> wrote:
> Add support for accessing OTP packets by their 4-byte ASCII tag while
> preserving backward compatibility with the existing ID-based lookup.
>
> The OTP memory layout can vary across devices and may change over time,
> making the packet ID approach unreliable when the memory map is not
> known in advance. The packet tag provides a reliable way to identify
> and access packets without prior knowledge of the OTP memory layout.
>
> Two offset encoding are now supported:
> 1. Legacy ID-based: offset = OTP_PKT(id) = id * 4
> Used in DT as: reg = <OTP_PKT(1) 76>;
> 2. TAG-based: offset = 4-byte ASCII packet tag
> Used in DT as: reg = <0x41435354 0x4c>; (tag "ACST")
>
> The driver resolves offsets matching valid legacy selectors (multiples
> of 4 within the packet count) through ID lookup, falling back to tag
> lookup for other values. This ensures existing device trees continue
> to work while enabling new tag-based access.
>
> During probe, packet meta data including the tag is read and cached.
> The driver also validates OTP memory accessibility and emulation mode
> status. When the boot packet is not configured, emulation mode allows
> access to the other packets. When both are not available an
> informational message is logged.
>
> The stride of the nvmem memory is set to 1 in order to support tag based
> offsets, comment in the header file is updated accordingly.
>
> Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
A couple of trivial things inline
Thanks,
Jonathan
> static int mchp_otpc_prepare_read(struct mchp_otpc *otpc,
> unsigned int offset)
> {
> @@ -140,8 +198,29 @@ static int mchp_otpc_prepare_read(struct mchp_otpc *otpc,
> * offset returned by hardware.
> *
> * For this, the read function will return the first requested bytes in the
> - * packet. The user will have to be aware of the memory footprint before doing
> - * the read request.
> + * packet.
> + *
> + * Two offset encoding are supported:
"encodings" as there are two of them.
> + *
> + * 1. Legacy ID-based: offset = OTP_PKT(id) = id * 4
> + * Used in DT as: reg = <OTP_PKT(1) 76>;
> + * 2. TAG-based: offset = 4-byte ASCII packet tag
> + * Used in DT as: reg = <0x41435354 0x4c>; (tag "ACST")
> + *
> + * To use the legacy ID based packet lookup the user will have to be aware of
> + * the memory footprint before doing the read request.
> + *
> + * But by using the TAG based packet lookup, the user won't have to be aware
> + * of the memory footprint before doing the read request since this driver has
> + * it abstracted and taken care of.
> + *
> + * Practically, there is no way of knowing the mapping of the OTP memory table
> + * in advance for every device. But by using the packet tag - the identifier
> + * ASCII value, the packets can be recognized without being aware of the
> + * flashed OTP memory map table and the payload can be acquired reliably.
> + *
> + * While the legacy ID based lookup is still supported, TAG based approach is
> + * recommended.
> */
> @@ -244,7 +356,8 @@ static int mchp_otpc_probe(struct platform_device *pdev)
> {
> struct nvmem_device *nvmem;
> struct mchp_otpc *otpc;
> - u32 size;
> + bool emul_enable;
> + u32 size, tmp;
If possible give tmp a more meaningful name. reg_val or better yet
something about which register.
> int ret;
>
> otpc = devm_kzalloc(&pdev->dev, sizeof(*otpc), GFP_KERNEL);
> @@ -256,10 +369,22 @@ static int mchp_otpc_probe(struct platform_device *pdev)
> return PTR_ERR(otpc->base);
>
> otpc->dev = &pdev->dev;
> +
> + tmp = readl_relaxed(otpc->base + MCHP_OTPC_MR);
> + emul_enable = tmp & MCHP_OTPC_MR_EMUL;
> + if (emul_enable)
> + dev_info(otpc->dev, "Emulation mode enabled\n");
> +
> ret = mchp_otpc_init_packets_list(otpc, &size);
> if (ret)
> return ret;
>
> + if (!size) {
> + dev_warn(otpc->dev, "Cannot access OTP memory\n");
> + if (!emul_enable)
> + dev_info(otpc->dev, "Boot packet not programmed and emulation mode disabled\n");
> + }
> +
^ permalink raw reply
* Re: [PATCH v10 0/9] perf cs-etm: Support thread stack and callchain
From: Namhyung Kim @ 2026-06-30 23:53 UTC (permalink / raw)
To: Leo Yan
Cc: Arnaldo Carvalho de Melo, John Garry, Will Deacon, James Clark,
Mike Leach, Suzuki K Poulose, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Ian Rogers, Adrian Hunter, Al Grant, Paschalis Mpeis,
Amir Ayupov, linux-arm-kernel, coresight, linux-perf-users,
Leo Yan
In-Reply-To: <20260630082310.GE1812158@e132581.arm.com>
On Tue, Jun 30, 2026 at 09:23:10AM +0100, Leo Yan wrote:
> Hi Namhyung,
>
> On Mon, Jun 29, 2026 at 05:36:48PM -0700, Namhyung Kim wrote:
>
> [...]
>
> > Will you send a new version or want to merge this? It seems there are
> > some remaining comments from Sashiko.
>
> I prefer to merge this series.
>
> Sashiko reported several critical issues in the common code, they are on
> my to-do list.
I see, I'll merge this and looking forward to seeing more fixes.
Thanks,
Namhyung
^ permalink raw reply
* Re: [PATCH v10 0/9] perf cs-etm: Support thread stack and callchain
From: Namhyung Kim @ 2026-06-30 23:57 UTC (permalink / raw)
To: Leo Yan
Cc: Arnaldo Carvalho de Melo, John Garry, Will Deacon, James Clark,
Mike Leach, Suzuki K Poulose, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Ian Rogers, Adrian Hunter, Al Grant, Paschalis Mpeis,
Amir Ayupov, linux-arm-kernel, coresight, linux-perf-users,
Leo Yan
In-Reply-To: <20260630082310.GE1812158@e132581.arm.com>
On Tue, Jun 30, 2026 at 09:23:10AM +0100, Leo Yan wrote:
> Hi Namhyung,
>
> On Mon, Jun 29, 2026 at 05:36:48PM -0700, Namhyung Kim wrote:
>
> [...]
>
> > Will you send a new version or want to merge this? It seems there are
> > some remaining comments from Sashiko.
>
> I prefer to merge this series.
Hmm.. it's not applying anymore.. Please rebase.
Thanks,
Namhyung
^ permalink raw reply
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: patchwork-bot+netdevbpf @ 2026-07-01 0:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, arnd, brgl, andrew, sebastian.hesselbarth,
gregory.clement, Frank.Li, robert.jarzmik, krzk, gerg, tsbogend,
hauke, zajec5, ysato, glaubitz, linusw, dmitry.torokhov, kuba,
pabeni, linux, linux-kernel, linux-arm-kernel, linux-samsung-soc,
patches, linux-m68k, linux-mips, linux-sh, linux-input,
linux-media, netdev, linux-sunxi, linux-phy, linux-rockchip,
linux-sound
In-Reply-To: <20260629132633.1300009-1-arnd@kernel.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 29 Jun 2026 15:26:20 +0200 you wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The linux/gpio.h header used to be the global definition for the gpio
> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
> 130 of those remain, so this series cleans out the rest.
>
> In each subsystem, we can replace the header either with
> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
> or linux/gpio/legacy.h for the few remaining users of the old number
> based interface.
>
> [...]
Here is the summary with links:
- [01/13] ARM: replace linux/gpio.h inclusions
(no matching commit)
- [02/13] m68k/coldfire: replace linux/gpio.h inclusions
(no matching commit)
- [03/13] mips: replace linux/gpio.h inclusions
(no matching commit)
- [04/13] sh: replace linux/gpio.h inclusions
(no matching commit)
- [05/13] mfd: replace linux/gpio.h inclusions
(no matching commit)
- [06/13,net-next] net: replace linux/gpio.h inclusions
https://git.kernel.org/netdev/net-next/c/a53d1872f2be
- [07/13] ASoC: replace linux/gpio.h inclusions
(no matching commit)
- [08/13] pcmcia: replace linux/gpio.h inclusions
(no matching commit)
- [09/13] phy: replace linux/gpio.h inclusions
(no matching commit)
- [10/13] media: replace linux/gpio.h inclusions
(no matching commit)
- [11/13] Input: matrix_keyboard - replace linux/gpio.h inclusion
(no matching commit)
- [12/13] gpib: gpio: replace linux/gpio.h inclusion
(no matching commit)
- [13/13] gpiolib: remove linux/gpio.h
(no matching commit)
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 rc v7 0/7] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Jason Gunthorpe @ 2026-07-01 0:25 UTC (permalink / raw)
To: Nicolin Chen
Cc: Pranjal Shrivastava, Mostafa Saleh, will, robin.murphy, joro,
kees, baolu.lu, kevin.tian, miko.lenczewski, linux-arm-kernel,
iommu, linux-kernel, stable, jamien
In-Reply-To: <akQYCgLWv4fs7GAg@nvidia.com>
On Tue, Jun 30, 2026 at 12:24:58PM -0700, Nicolin Chen wrote:
> > I don't know exactly the sequence of events that lead up to the kdump
> > kernel crashing (I imagine it is hard to debug that one), but it is
> > something related to the new kernel not participating in the RAS and
> > the RAS flow escalating to something fatal.
>
> Here is the original bug report:
> - kernel boots into a crash kernel
> - crash kernel hits OOM do to insufficient reserved memory and
> panics
> - PCIe errors are observed during this failure flow
Maybe the RAS events hits some bugs and OOMs the kdump kernel?
Regardless more general cases like CXL are still things where you
don't want to cause unexpected ATS failures..
Jason
^ permalink raw reply
* Re: [PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support
From: Nazle Asmade, Muhammad Nazim Amirul @ 2026-07-01 1:32 UTC (permalink / raw)
To: Maxime Chevallier, Andrew Lunn
Cc: dinguyen@kernel.org, rmk+kernel@armlinux.org.uk,
krzk+dt@kernel.org, conor+dt@kernel.org, robh@kernel.org,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, andrew+netdev@lunn.ch,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <e691298f-b3e5-4c1a-8270-a821c1f46a2b@bootlin.com>
On 30/6/2026 11:42 pm, Maxime Chevallier wrote:
>
>
> On 6/30/26 17:13, Nazle Asmade, Muhammad Nazim Amirul wrote:
>
>> Yes, Agilex5 has the same concept. The GMII-to-RGMII converter is a
>> Quartus soft IP instantiated in the FPGA fabric — equivalent to the
>> CycloneV EMAC splitter. The XGMAC outputs GMII signals to the FPGA
>> fabric, the soft IP converts them to RGMII, and the RGMII signals then
>> go through the FPGA HVIO pins to the external Marvell 88E1512 PHY.
>
> Does this converter need any special config, and does it expose any
> control registers ? or is it fully autonomous ?
>
> If it's fully autonomous, can you detect its presence through some
> capability registers or something like that ?
>
>
> Maxime
>
Hi Maxime,
Per my knowledge, the converter is fully autonomous with no control
registers and no software configuration required.
Speed switching is handled entirely in hardware — the XGMAC's mac_speed
output signals are wired directly in the FPGA fabric to the converter's
speed input. No driver intervention is needed on speed changes.
There are no capability registers and no way to detect its presence in
hardware. It is a property of the FPGA design, not the HPS silicon.
BR,
Nazim Amirul
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox