* [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 wireless-next] wifi: mt76: fix of_get_mac_address error handling
From: Rosen Penev @ 2026-06-30 21:03 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Felix Fietkau, linux-wireless, Lorenzo Bianconi, Ryder Lee,
Shayne Chen, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, Tobias Klausmann,
Klara Modin, Linux kernel regressions list
In-Reply-To: <173df064-f373-4cce-b35f-e52f728be263@leemhuis.info>
On Tue, Jun 30, 2026 at 5:18 AM Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> On 6/19/26 03:50, Rosen Penev wrote:
> > On Thu Jun 18, 2026 at 4:51 PM PDT, Klara Modin wrote:
> >> On 2026-06-18 16:01:45 -0700, Rosen Penev wrote:
> >>> On Thu, Jun 18, 2026 at 2:47 PM Klara Modin <klarasmodin@gmail.com> wrote:
> >>>> On 2026-04-26 22:17:46 -0700, Rosen Penev wrote:
> >>>>> Check return value instead of is_valid_ether_addr. The latter is handled
> >>>>> by the former.
> >>>>>
> >>>>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> >>>>> [...]
> >>>>>>>> Recently I have started to see randomized MAC-addresses on my
> x86 laptop
> >>>> with a MT7922 and the above message printed in the kernel log. I have
> >>>> CONFIG_OF turned on, but since this is an ACPI system the device is not
> >>>> described by any device tree and the earlier of_get_mac_address() likely
> >>>> fails with -ENODEV. Looking at the !CONFIG_OF stub for
> >>>> of_get_mac_address it always returns -ENODEV, meaning this will always
> >>>> randomize the mac in that case too.
> >>
> >>> IIRC, the normal device_get_mac_address supports nvmem now. Does that
> >>> fix your use case?
> >>
> >> I tried this:
> >> [...]
> >> but I still get a random MAC.
> > Then the original patch should be reverted. Unfortunate that it doesn't
> > workq
>
> Happens, no worries, but seems nobody submitted such a revert yet since
> you posted that. Unless I'm missing something -- if so, please do not
> hesitate to tell me!
>
> But if no revert is in the works, could you please submit one, given
> that it was your change that cause the problem?
https://lore.kernel.org/linux-wireless/20260630210215.400379-1-rosenp@gmail.com/T/#u
>
> Side note: Tobias (now CCed) ran into the same problem, too:
> https://lore.kernel.org/all/30a90714-02d8-45f2-a7f1-4cfe0627d50b@skade.local/
>
> Makes me wonder if more people are affected by this and if we should try
> to mainline the revert rather sooner than later.
>
> Ciao, Thorsten
>
> >>>>
> >>>> Reverting this patch fixes the issue and the correct MAC address is
> >>>> used. I'm not sure if there is any case where of_get_mac_addres() could
> >>>> fail in a way that results in a valid MAC address but it seems unlikely
> >>>> to me.
> >>>>
> >>>> Regards,
> >>>> Klara Modin
> >
> >
>
^ permalink raw reply
* [PATCH wireless-next] wifi: mt76: fix MAC address for non OF pcie cards
From: Rosen Penev @ 2026-06-30 21:02 UTC (permalink / raw)
To: linux-wireless
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Rosen Penev, open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
If seems the check for err is wrong as the proper macaddr gets written
to from the EEPROM itself. Meaning checking err from of_get_mac_address is
wrong as the proper macaddr has been written by this point.
Fixes: 31ee1582717e ("wifi: mt76: fix of_get_mac_address error handling")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/net/wireless/mediatek/mt76/eeprom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
index b99d7452800f..afdb73661866 100644
--- a/drivers/net/wireless/mediatek/mt76/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
@@ -181,7 +181,7 @@ mt76_eeprom_override(struct mt76_phy *phy)
if (err == -EPROBE_DEFER)
return err;
- if (err) {
+ if (!is_valid_ether_addr(phy->macaddr)) {
eth_random_addr(phy->macaddr);
dev_info(dev->dev,
"Invalid MAC address, using random address %pM\n",
--
2.55.0
^ permalink raw reply related
* Re: [PATCH v3 1/5] dmaengine: sun6i-dma: Refactor to support A733 interrupt and register handling
From: Yuanshen Cao @ 2026-06-30 21:00 UTC (permalink / raw)
To: Andre Przywara
Cc: conor+dt, mripard, krzk+dt, robh, samuel, wens, jernej.skrabec,
Frank.Li, vkoul, dmaengine, linux-arm-kernel, linux-sunxi,
devicetree, linux-kernel, Frank Li
In-Reply-To: <20260629003505.18f0053d@ryzen.lan>
On Mon, Jun 29, 2026 at 12:35:05AM +0200, Andre Przywara wrote:
> On Mon, 22 Jun 2026 01:36:23 +0000
> Yuanshen Cao <alex.caoys@gmail.com> wrote:
>
> Hi,
>
> first, many thanks for sending this, also for structuring the changes
> nicely, so that they remain reviewable!
>
> > Refactor to support the Allwinner A733 DMA controller. Currently, the
> > `sun6i-dma` driver has several functions related to interrupt handling
> > (reading/writing interrupt enable and status registers) and register
> > dumping that are hardcoded.
> >
> > To support the A733, which has different register layouts and interrupt
> > handling logic, these functions are being moved into the
> > `sun6i_dma_config` structure as function pointers.
>
> So I see that this driver already makes use of per-device function
> pointer, though personally I don't like this approach very much, as it
> decreases the readability, and suggests significant differences between
> the SoC generations that are not really there: each function just reads
> or write an MMIO register, it's just the offset that differs.
Yes, I considered to do this but since the original mainline code and
BSP code all use function-pointer so I impelement this the same way.
>
> So I think it's better to express the differences through data
> entries in the config struct, for the IRQ enable/stat functions I think
> this should be something like this:
>
> struct sun6i_dma_config {
> ...
> u32 irq_stride;
> u32 irq_en_offset;
> u32 irq_stat_offset;
> ...
> };
>
> - irq_val = readl(sdev->base + DMA_IRQ_EN(irq_reg));
> + irq_val = readl(sdev->base + sdev->cfg->irq_en_offset + irq_reg * sdev->cfg->irq_stride);
>
> the existing configs set .stride to 0x04, and .en_offset to 0x0, the
> A733 later uses .stride = 0x40 and .en_offset = 0x134.
> Maybe we still move that now longish line into a helper function, but
> not a config specific one.
>
> I think that's more readable, and avoids unnecessary redirections and
> potential pipeline stalls.
>
> dump_com_regs is a different story, since the two instances of that
> function are significantly different.
>
> What do you think?
I am okay to change this one but should we do the same for the other
function pointers as well? Just to keep them aligned. Let me know what
do you think.
> > This allows the
> > driver to use a polymorphic approach where the specific implementation
> > is determined by the hardware configuration assigned during device
> > probing.
> >
> > Changes:
> > - Added function pointers to `struct sun6i_dma_config` for:
>
> By the way: the preferred style to list changes in commit messages in
> imperative mood [1], not in past tense. Think about you ask the
> code base what to change:
>
> Add function pointers to ...
> Implement generic functions ...
Thanks for the advice! I'll make sure to follow them in the future.
Best,
Alex
> Cheers,
> Andre
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n94
>
> > - `dump_com_regs`
> > - `read_irq_en`
> > - `write_irq_en`
> > - `read_irq_stat`
> > - `write_irq_stat`
> > - Implemented generic `sun6i_read/write_irq_*` functions for existing
> > hardware.
> > - Added a macro and updated existing `sun6i_dma_config` instances (A31,
> > A23, H3, A64, A100, H6, V3S) to use these new function pointers.
> >
> > Reviewed-by: Frank Li <Frank.Li@nxp.com>
> > Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
> > ---
> > drivers/dma/sun6i-dma.c | 50 ++++++++++++++++++++++++++++++++++++++++++++-----
> > 1 file changed, 45 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> > index a9a254dbf8cb..ef3052c4ab36 100644
> > --- a/drivers/dma/sun6i-dma.c
> > +++ b/drivers/dma/sun6i-dma.c
> > @@ -138,6 +138,11 @@ struct sun6i_dma_config {
> > void (*set_burst_length)(u32 *p_cfg, s8 src_burst, s8 dst_burst);
> > void (*set_drq)(u32 *p_cfg, s8 src_drq, s8 dst_drq);
> > void (*set_mode)(u32 *p_cfg, s8 src_mode, s8 dst_mode);
> > + void (*dump_com_regs)(struct sun6i_dma_dev *sdev);
> > + u32 (*read_irq_en)(struct sun6i_dma_dev *sdev, u32 irq_reg);
> > + void (*write_irq_en)(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 irq_val);
> > + u32 (*read_irq_stat)(struct sun6i_dma_dev *sdev, u32 irq_reg);
> > + void (*write_irq_stat)(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 status);
> > u32 src_burst_lengths;
> > u32 dst_burst_lengths;
> > u32 src_addr_widths;
> > @@ -347,6 +352,26 @@ static void sun6i_set_mode_h6(u32 *p_cfg, s8 src_mode, s8 dst_mode)
> > DMA_CHAN_CFG_DST_MODE_H6(dst_mode);
> > }
> >
> > +static u32 sun6i_read_irq_en(struct sun6i_dma_dev *sdev, u32 irq_reg)
> > +{
> > + return readl(sdev->base + DMA_IRQ_EN(irq_reg));
> > +}
> > +
> > +static void sun6i_write_irq_en(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 irq_val)
> > +{
> > + writel(irq_val, sdev->base + DMA_IRQ_EN(irq_reg));
> > +}
> > +
> > +static u32 sun6i_read_irq_stat(struct sun6i_dma_dev *sdev, u32 irq_reg)
> > +{
> > + return readl(sdev->base + DMA_IRQ_STAT(irq_reg));
> > +}
> > +
> > +static void sun6i_write_irq_stat(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 status)
> > +{
> > + writel(status, sdev->base + DMA_IRQ_STAT(irq_reg));
> > +}
> > +
> > static size_t sun6i_get_chan_size(struct sun6i_pchan *pchan)
> > {
> > struct sun6i_desc *txd = pchan->desc;
> > @@ -460,16 +485,16 @@ static int sun6i_dma_start_desc(struct sun6i_vchan *vchan)
> >
> > vchan->irq_type = vchan->cyclic ? DMA_IRQ_PKG : DMA_IRQ_QUEUE;
> >
> > - irq_val = readl(sdev->base + DMA_IRQ_EN(irq_reg));
> > + irq_val = sdev->cfg->read_irq_en(sdev, irq_reg);
> > irq_val &= ~((DMA_IRQ_HALF | DMA_IRQ_PKG | DMA_IRQ_QUEUE) <<
> > (irq_offset * DMA_IRQ_CHAN_WIDTH));
> > irq_val |= vchan->irq_type << (irq_offset * DMA_IRQ_CHAN_WIDTH);
> > - writel(irq_val, sdev->base + DMA_IRQ_EN(irq_reg));
> > + sdev->cfg->write_irq_en(sdev, irq_reg, irq_val);
> >
> > writel(pchan->desc->p_lli, pchan->base + DMA_CHAN_LLI_ADDR);
> > writel(DMA_CHAN_ENABLE_START, pchan->base + DMA_CHAN_ENABLE);
> >
> > - sun6i_dma_dump_com_regs(sdev);
> > + sdev->cfg->dump_com_regs(sdev);
> > sun6i_dma_dump_chan_regs(sdev, pchan);
> >
> > return 0;
> > @@ -549,14 +574,14 @@ static irqreturn_t sun6i_dma_interrupt(int irq, void *dev_id)
> > u32 status;
> >
> > for (i = 0; i < sdev->num_pchans / DMA_IRQ_CHAN_NR; i++) {
> > - status = readl(sdev->base + DMA_IRQ_STAT(i));
> > + status = sdev->cfg->read_irq_stat(sdev, i);
> > if (!status)
> > continue;
> >
> > dev_dbg(sdev->slave.dev, "DMA irq status %s: 0x%x\n",
> > str_high_low(i), status);
> >
> > - writel(status, sdev->base + DMA_IRQ_STAT(i));
> > + sdev->cfg->write_irq_stat(sdev, i, status);
> >
> > for (j = 0; (j < DMA_IRQ_CHAN_NR) && status; j++) {
> > pchan = sdev->pchans + j;
> > @@ -1101,6 +1126,13 @@ static inline void sun6i_dma_free(struct sun6i_dma_dev *sdev)
> > }
> > }
> >
> > +#define SUN6I_DMA_IRQ_A31_COMMON_OPS \
> > + .dump_com_regs = sun6i_dma_dump_com_regs, \
> > + .read_irq_en = sun6i_read_irq_en, \
> > + .write_irq_en = sun6i_write_irq_en, \
> > + .read_irq_stat = sun6i_read_irq_stat, \
> > + .write_irq_stat = sun6i_write_irq_stat,
> > +
> > /*
> > * For A31:
> > *
> > @@ -1132,6 +1164,7 @@ static struct sun6i_dma_config sun6i_a31_dma_cfg = {
> > .dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> > BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> > BIT(DMA_SLAVE_BUSWIDTH_4_BYTES),
> > + SUN6I_DMA_IRQ_A31_COMMON_OPS
> > };
> >
> > /*
> > @@ -1155,6 +1188,7 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
> > .dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> > BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> > BIT(DMA_SLAVE_BUSWIDTH_4_BYTES),
> > + SUN6I_DMA_IRQ_A31_COMMON_OPS
> > };
> >
> > static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
> > @@ -1173,6 +1207,7 @@ static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
> > .dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> > BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> > BIT(DMA_SLAVE_BUSWIDTH_4_BYTES),
> > + SUN6I_DMA_IRQ_A31_COMMON_OPS
> > };
> >
> > /*
> > @@ -1200,6 +1235,7 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
> > BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> > BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) |
> > BIT(DMA_SLAVE_BUSWIDTH_8_BYTES),
> > + SUN6I_DMA_IRQ_A31_COMMON_OPS
> > };
> >
> > /*
> > @@ -1221,6 +1257,7 @@ static struct sun6i_dma_config sun50i_a64_dma_cfg = {
> > BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> > BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) |
> > BIT(DMA_SLAVE_BUSWIDTH_8_BYTES),
> > + SUN6I_DMA_IRQ_A31_COMMON_OPS
> > };
> >
> > /*
> > @@ -1244,6 +1281,7 @@ static struct sun6i_dma_config sun50i_a100_dma_cfg = {
> > BIT(DMA_SLAVE_BUSWIDTH_8_BYTES),
> > .has_high_addr = true,
> > .has_mbus_clk = true,
> > + SUN6I_DMA_IRQ_A31_COMMON_OPS
> > };
> >
> > /*
> > @@ -1266,6 +1304,7 @@ static struct sun6i_dma_config sun50i_h6_dma_cfg = {
> > BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) |
> > BIT(DMA_SLAVE_BUSWIDTH_8_BYTES),
> > .has_mbus_clk = true,
> > + SUN6I_DMA_IRQ_A31_COMMON_OPS
> > };
> >
> > /*
> > @@ -1289,6 +1328,7 @@ static struct sun6i_dma_config sun8i_v3s_dma_cfg = {
> > .dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> > BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> > BIT(DMA_SLAVE_BUSWIDTH_4_BYTES),
> > + SUN6I_DMA_IRQ_A31_COMMON_OPS
> > };
> >
> > static const struct of_device_id sun6i_dma_match[] = {
> >
>
^ permalink raw reply
* [PATCH v2 3/4] firmware: raspberrypi: Add reboot mode support
From: Gregor Herburger @ 2026-06-30 20:59 UTC (permalink / raw)
To: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, Stefan Wahren
Cc: linux-rpi-kernel, linux-arm-kernel, linux-kernel, devicetree,
Gregor Herburger
In-Reply-To: <20260630-rpi-tryboot-v2-0-f68d2dc6aa27@linutronix.de>
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));
+
+ 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);
+
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,
--
2.47.3
^ permalink raw reply related
* [PATCH v2 1/4] firmware: raspberrypi: reorder rpi_firmware_property_tag enum
From: Gregor Herburger @ 2026-06-30 20:59 UTC (permalink / raw)
To: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, Stefan Wahren
Cc: linux-rpi-kernel, linux-arm-kernel, linux-kernel, devicetree,
Gregor Herburger
In-Reply-To: <20260630-rpi-tryboot-v2-0-f68d2dc6aa27@linutronix.de>
The enum was once ordered by tags. The later added tags where added in
a different order. Reorder the tags again.
No functional change intended.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
include/soc/bcm2835/raspberrypi-firmware.h | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index e1f87fbfe5542..66cc5a426c3c5 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -72,26 +72,26 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_GET_EDID_BLOCK = 0x00030020,
RPI_FIRMWARE_GET_CUSTOMER_OTP = 0x00030021,
RPI_FIRMWARE_GET_DOMAIN_STATE = 0x00030030,
+ RPI_FIRMWARE_GET_GPIO_STATE = 0x00030041,
+ RPI_FIRMWARE_GET_GPIO_CONFIG = 0x00030043,
+ RPI_FIRMWARE_GET_PERIPH_REG = 0x00030045,
RPI_FIRMWARE_GET_THROTTLED = 0x00030046,
RPI_FIRMWARE_GET_CLOCK_MEASURED = 0x00030047,
RPI_FIRMWARE_NOTIFY_REBOOT = 0x00030048,
+ RPI_FIRMWARE_GET_POE_HAT_VAL = 0x00030049,
+ RPI_FIRMWARE_SET_POE_HAT_VAL = 0x00030050,
+ RPI_FIRMWARE_NOTIFY_XHCI_RESET = 0x00030058,
+ RPI_FIRMWARE_NOTIFY_DISPLAY_DONE = 0x00030066,
RPI_FIRMWARE_SET_CLOCK_STATE = 0x00038001,
RPI_FIRMWARE_SET_CLOCK_RATE = 0x00038002,
RPI_FIRMWARE_SET_VOLTAGE = 0x00038003,
RPI_FIRMWARE_SET_TURBO = 0x00038009,
RPI_FIRMWARE_SET_CUSTOMER_OTP = 0x00038021,
RPI_FIRMWARE_SET_DOMAIN_STATE = 0x00038030,
- RPI_FIRMWARE_GET_GPIO_STATE = 0x00030041,
RPI_FIRMWARE_SET_GPIO_STATE = 0x00038041,
RPI_FIRMWARE_SET_SDHOST_CLOCK = 0x00038042,
- RPI_FIRMWARE_GET_GPIO_CONFIG = 0x00030043,
RPI_FIRMWARE_SET_GPIO_CONFIG = 0x00038043,
- RPI_FIRMWARE_GET_PERIPH_REG = 0x00030045,
RPI_FIRMWARE_SET_PERIPH_REG = 0x00038045,
- RPI_FIRMWARE_GET_POE_HAT_VAL = 0x00030049,
- RPI_FIRMWARE_SET_POE_HAT_VAL = 0x00030050,
- RPI_FIRMWARE_NOTIFY_XHCI_RESET = 0x00030058,
- RPI_FIRMWARE_NOTIFY_DISPLAY_DONE = 0x00030066,
/* Dispmanx TAGS */
RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE = 0x00040001,
@@ -107,7 +107,6 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_FRAMEBUFFER_GET_PALETTE = 0x0004000b,
RPI_FIRMWARE_FRAMEBUFFER_GET_TOUCHBUF = 0x0004000f,
RPI_FIRMWARE_FRAMEBUFFER_GET_GPIOVIRTBUF = 0x00040010,
- RPI_FIRMWARE_FRAMEBUFFER_RELEASE = 0x00048001,
RPI_FIRMWARE_FRAMEBUFFER_TEST_PHYSICAL_WIDTH_HEIGHT = 0x00044003,
RPI_FIRMWARE_FRAMEBUFFER_TEST_VIRTUAL_WIDTH_HEIGHT = 0x00044004,
RPI_FIRMWARE_FRAMEBUFFER_TEST_DEPTH = 0x00044005,
@@ -117,6 +116,7 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_FRAMEBUFFER_TEST_OVERSCAN = 0x0004400a,
RPI_FIRMWARE_FRAMEBUFFER_TEST_PALETTE = 0x0004400b,
RPI_FIRMWARE_FRAMEBUFFER_TEST_VSYNC = 0x0004400e,
+ RPI_FIRMWARE_FRAMEBUFFER_RELEASE = 0x00048001,
RPI_FIRMWARE_FRAMEBUFFER_SET_PHYSICAL_WIDTH_HEIGHT = 0x00048003,
RPI_FIRMWARE_FRAMEBUFFER_SET_VIRTUAL_WIDTH_HEIGHT = 0x00048004,
RPI_FIRMWARE_FRAMEBUFFER_SET_DEPTH = 0x00048005,
@@ -125,10 +125,10 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_FRAMEBUFFER_SET_VIRTUAL_OFFSET = 0x00048009,
RPI_FIRMWARE_FRAMEBUFFER_SET_OVERSCAN = 0x0004800a,
RPI_FIRMWARE_FRAMEBUFFER_SET_PALETTE = 0x0004800b,
- RPI_FIRMWARE_FRAMEBUFFER_SET_TOUCHBUF = 0x0004801f,
- RPI_FIRMWARE_FRAMEBUFFER_SET_GPIOVIRTBUF = 0x00048020,
RPI_FIRMWARE_FRAMEBUFFER_SET_VSYNC = 0x0004800e,
RPI_FIRMWARE_FRAMEBUFFER_SET_BACKLIGHT = 0x0004800f,
+ RPI_FIRMWARE_FRAMEBUFFER_SET_TOUCHBUF = 0x0004801f,
+ RPI_FIRMWARE_FRAMEBUFFER_SET_GPIOVIRTBUF = 0x00048020,
RPI_FIRMWARE_VCHIQ_INIT = 0x00048010,
--
2.47.3
^ permalink raw reply related
* [PATCH v2 4/4] arm64: dts: broadcom: bcm2712: Add reboot modes to firmware node
From: Gregor Herburger @ 2026-06-30 20:59 UTC (permalink / raw)
To: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, Stefan Wahren
Cc: linux-rpi-kernel, linux-arm-kernel, linux-kernel, devicetree,
Gregor Herburger
In-Reply-To: <20260630-rpi-tryboot-v2-0-f68d2dc6aa27@linutronix.de>
The raspberry pi firmware driver allows the tryboot reboot mode. Add
this mode and normal boot mode to the node.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
index b7a6bc34ae1ab..67095c7ff770d 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
@@ -49,6 +49,8 @@ firmware: rpi-firmware {
compatible = "raspberrypi,bcm2835-firmware", "simple-mfd";
mboxes = <&mailbox>;
+ mode-normal = <0>;
+ mode-tryboot = <1>;
firmware_clocks: clocks {
compatible = "raspberrypi,firmware-clocks";
--
2.47.3
^ permalink raw reply related
* [PATCH v2 0/4] firmware: raspberrypi: Add support for the tryboot mode
From: Gregor Herburger @ 2026-06-30 20:59 UTC (permalink / raw)
To: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, Stefan Wahren
Cc: linux-rpi-kernel, linux-arm-kernel, linux-kernel, devicetree,
Gregor Herburger
This adds support for the tryboot mode on Raspberry Pis. As there is no
documentation other than the downstream implementation [0] the
implementation is based on this.
I tested this on Raspberry Pi 5 and therefore I only added the
properties to this devicetree. But afaik this should work on all
Raspberry Pis. I will add it to the correspondings dts if I get some
hardware to test it.
[0] https://github.com/raspberrypi/linux/commit/eb56da0c1925c07e8929ce4c9fe8aeafa7cb8c7b
---
Changes in v2:
- Remove unnecessary reboot_mode_unregister().
- dt-binding: restrict to mode-{normal,tryboot} and only allow 32bit value.
- Link to v1: https://patch.msgid.link/20260626-rpi-tryboot-v1-0-490b1c4c4970@linutronix.de
---
Gregor Herburger (4):
firmware: raspberrypi: reorder rpi_firmware_property_tag enum
dt-bindings: raspberrypi,bcm2835-firmware: Include 'reboot-mode.yaml'
firmware: raspberrypi: Add reboot mode support
arm64: dts: broadcom: bcm2712: Add reboot modes to firmware node
.../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 9 +++++++++
.../boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi | 2 ++
drivers/firmware/Kconfig | 1 +
drivers/firmware/raspberrypi.c | 23 ++++++++++++++++++++++
include/soc/bcm2835/raspberrypi-firmware.h | 22 +++++++++++----------
5 files changed, 47 insertions(+), 10 deletions(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260623-rpi-tryboot-4292c92b0727
Best regards,
--
Gregor Herburger <gregor.herburger@linutronix.de>
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: raspberrypi,bcm2835-firmware: Include 'reboot-mode.yaml'
From: Gregor Herburger @ 2026-06-30 20:59 UTC (permalink / raw)
To: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, Stefan Wahren
Cc: linux-rpi-kernel, linux-arm-kernel, linux-kernel, devicetree,
Gregor Herburger
In-Reply-To: <20260630-rpi-tryboot-v2-0-f68d2dc6aa27@linutronix.de>
The Raspberry Pi firmware allows to set a reboot mode called tryboot
that allows to try booting from a different partition to allow updating
of the boot partition. Allow reboot mode properties by referencing the
reboot-mode schema. The firmware allows a 32bit value to be sent as
reboot flag so restrict the maxItems to 1.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
.../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index 983ea80eaec97..28c5713860468 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -133,6 +133,15 @@ properties:
required:
- compatible
+ mode-normal:
+ maxItems: 1
+
+ mode-tryboot:
+ maxItems: 1
+
+allOf:
+ - $ref: /schemas/power/reset/reboot-mode.yaml#
+
required:
- compatible
- mboxes
--
2.47.3
^ permalink raw reply related
* [PATCHv2] firmware: arm_scmi: simplify some allocations
From: Rosen Penev @ 2026-06-30 20:51 UTC (permalink / raw)
To: arm-scmi
Cc: Sudeep Holla, Cristian Marussi, Kees Cook, Gustavo A. R. Silva,
moderated list:SYSTEM CONTROL & POWER/MANAGEMENT INTERFACE (SC...),
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be|_ptr)?b
Use flexible array members to combine allocations and remove kcalloc
usage.
Add __counted_by where appropriate for extra runtime analysis. Move
counting variable assignment after allocation before any potential array
access.
Also make registered_protocols a static array. No need to use
struct_size when the value is a constant.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
v2: fix missing struct_size.
drivers/firmware/arm_scmi/notify.c | 42 ++++++++++++------------------
1 file changed, 16 insertions(+), 26 deletions(-)
diff --git a/drivers/firmware/arm_scmi/notify.c b/drivers/firmware/arm_scmi/notify.c
index 40ec184eedae..8f69f2f599b2 100644
--- a/drivers/firmware/arm_scmi/notify.c
+++ b/drivers/firmware/arm_scmi/notify.c
@@ -209,11 +209,11 @@ struct scmi_registered_events_desc;
* @init_work: A work item to perform final initializations of pending handlers
* @notify_wq: A reference to the allocated Kernel cmwq
* @pending_mtx: A mutex to protect @pending_events_handlers
+ * @pending_events_handlers: An hashtable containing all pending events'
+ * handlers descriptors
* @registered_protocols: A statically allocated array containing pointers to
* all the registered protocol-level specific information
* related to events' handling
- * @pending_events_handlers: An hashtable containing all pending events'
- * handlers descriptors
*
* Each platform instance, represented by a handle, has its own instance of
* the notification subsystem represented by this structure.
@@ -225,8 +225,8 @@ struct scmi_notify_instance {
struct workqueue_struct *notify_wq;
/* lock to protect pending_events_handlers */
struct mutex pending_mtx;
- struct scmi_registered_events_desc **registered_protocols;
DECLARE_HASHTABLE(pending_events_handlers, SCMI_PENDING_HASH_SZ);
+ struct scmi_registered_events_desc *registered_protocols[SCMI_MAX_PROTO];
};
/**
@@ -276,13 +276,13 @@ struct scmi_registered_event;
* @eh_sz: Size of the pre-allocated buffer @eh
* @in_flight: A reference to an in flight &struct scmi_registered_event
* @num_events: Number of events in @registered_events
- * @registered_events: A dynamically allocated array holding all the registered
- * events' descriptors, whose fixed-size is determined at
- * compile time.
* @registered_mtx: A mutex to protect @registered_events_handlers
* @ph: SCMI protocol handle reference
* @registered_events_handlers: An hashtable containing all events' handlers
* descriptors registered for this protocol
+ * @registered_events: A dynamically allocated array holding all the registered
+ * events' descriptors, whose fixed-size is determined at
+ * compile time.
*
* All protocols that register at least one event have their protocol-specific
* information stored here, together with the embedded allocated events_queue.
@@ -302,11 +302,11 @@ struct scmi_registered_events_desc {
size_t eh_sz;
void *in_flight;
int num_events;
- struct scmi_registered_event **registered_events;
/* mutex to protect registered_events_handlers */
struct mutex registered_mtx;
const struct scmi_protocol_handle *ph;
DECLARE_HASHTABLE(registered_events_handlers, SCMI_REGISTERED_HASH_SZ);
+ struct scmi_registered_event *registered_events[] __counted_by(num_events);
};
/**
@@ -338,9 +338,9 @@ struct scmi_registered_event {
void *report;
u32 num_sources;
bool not_supported_by_platform;
- refcount_t *sources;
/* locking to serialize the access to sources */
struct mutex sources_mtx;
+ refcount_t sources[] __counted_by(num_sources);
};
/**
@@ -706,9 +706,12 @@ scmi_allocate_registered_events_desc(struct scmi_notify_instance *ni,
if (WARN_ON(ni->registered_protocols[proto_id]))
return ERR_PTR(-EINVAL);
- pd = devm_kzalloc(ni->handle->dev, sizeof(*pd), GFP_KERNEL);
+ pd = devm_kzalloc(ni->handle->dev, struct_size(pd, registered_events, num_events),
+ GFP_KERNEL);
if (!pd)
return ERR_PTR(-ENOMEM);
+
+ pd->num_events = num_events;
pd->id = proto_id;
pd->ops = ops;
pd->ni = ni;
@@ -722,12 +725,6 @@ scmi_allocate_registered_events_desc(struct scmi_notify_instance *ni,
return ERR_PTR(-ENOMEM);
pd->eh_sz = eh_sz;
- pd->registered_events = devm_kcalloc(ni->handle->dev, num_events,
- sizeof(char *), GFP_KERNEL);
- if (!pd->registered_events)
- return ERR_PTR(-ENOMEM);
- pd->num_events = num_events;
-
/* Initialize per protocol handlers table */
mutex_init(&pd->registered_mtx);
hash_init(pd->registered_events_handlers);
@@ -796,18 +793,16 @@ int scmi_register_protocol_events(const struct scmi_handle *handle, u8 proto_id,
int id;
struct scmi_registered_event *r_evt;
- r_evt = devm_kzalloc(ni->handle->dev, sizeof(*r_evt),
+ r_evt = devm_kzalloc(ni->handle->dev,
+ struct_size(r_evt, sources, num_sources),
GFP_KERNEL);
if (!r_evt)
return -ENOMEM;
+
+ r_evt->num_sources = num_sources;
r_evt->proto = pd;
r_evt->evt = evt;
- r_evt->sources = devm_kcalloc(ni->handle->dev, num_sources,
- sizeof(refcount_t), GFP_KERNEL);
- if (!r_evt->sources)
- return -ENOMEM;
- r_evt->num_sources = num_sources;
mutex_init(&r_evt->sources_mtx);
r_evt->report = devm_kzalloc(ni->handle->dev,
@@ -1673,11 +1668,6 @@ int scmi_notification_init(struct scmi_handle *handle)
ni->gid = gid;
ni->handle = handle;
- ni->registered_protocols = devm_kcalloc(handle->dev, SCMI_MAX_PROTO,
- sizeof(char *), GFP_KERNEL);
- if (!ni->registered_protocols)
- goto err;
-
ni->notify_wq = alloc_workqueue(dev_name(handle->dev),
WQ_UNBOUND | WQ_FREEZABLE | WQ_SYSFS,
0);
--
2.55.0
^ permalink raw reply related
* Re: [PATCH 0/5] arm64: dts: describe the Lynx 10G and 28G SerDes blocks for Layerscape SoCs
From: Frank Li @ 2026-06-30 20:20 UTC (permalink / raw)
To: Ioana Ciornei
Cc: Frank.Li, robh, krzk+dt, conor+dt, devicetree, vladimir.oltean,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260630110459.516364-1-ioana.ciornei@nxp.com>
On Tue, Jun 30, 2026 at 02:04:54PM +0300, Ioana Ciornei wrote:
> This patch set adds the device tree nodes for the Lynx10G SerDes blocks
> found on the LS1028A, LS1046A, LS1088A and LS2088A SoCs.
>
> The first patch also transitions the LX2160A SoC dtsi to use the
> device-specific Lynx28G SerDes compatible.
>
Next time please cc imx@lists.linux.dev, otherwise, patchwork can't see
this patch.
I sent patch to update maintainers file
https://lore.kernel.org/imx/20260630201618.3497941-1-Frank.Li@oss.nxp.com/#R
Frank
> Ioana Ciornei (1):
> arm64: dts: ls1088a: describe the Lynx 10G SerDes blocks
>
> Vladimir Oltean (4):
> arm64: dts: lx2160a: transition to device-specific SerDes compatible
> strings
> arm64: dts: ls1028a: describe the Lynx 10G SerDes
> arm64: dts: ls1046a: describe the Lynx 10G SerDes blocks
> arm64: dts: ls208xa: describe the Lynx 10G SerDes blocks
>
> .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 29 ++++
> .../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 60 +++++++
> .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 58 +++++++
> .../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 98 ++++++++++++
> .../freescale/fsl-lx2160a-clearfog-itx.dtsi | 4 +
> .../boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 +
> .../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 150 +++++++++++++++++-
> .../dts/freescale/fsl-lx2162a-clearfog.dts | 2 +-
> .../boot/dts/freescale/fsl-lx2162a-qds.dts | 2 +-
> .../arm64/boot/dts/freescale/fsl-lx2162a.dtsi | 24 +++
> 10 files changed, 427 insertions(+), 4 deletions(-)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
>
> --
> 2.25.1
>
^ permalink raw reply
* [PATCH 1/1] MAINTAINERS: ARM/FREESCALE: merge Layerscape entry into i.MX entry
From: Frank.Li @ 2026-06-30 20:16 UTC (permalink / raw)
To: s.hauer, kernel, festevam, robh, krzk+dt, conor+dt, imx,
linux-arm-kernel, devicetree, linux-kernel
Cc: Frank Li
From: Frank Li <Frank.Li@nxp.com>
Both platforms are maintained by the same people, and the two entries
contain largely identical information. Maintaining separate entries adds
unnecessary duplication.
Additionally, the standalone Layerscape entry does not include the
imx@lists.linux.dev mailing list, causing Layerscape patches to miss
NXP's Patchwork instance. Consolidating the entries ensures patches for
both platforms are routed consistently and reduces future maintenance
overhead.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
MAINTAINERS | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 15011f5752a99..31188163a8592 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2881,7 +2881,7 @@ W: http://www.armlinux.org.uk/
F: arch/arm/include/asm/hardware/dec21285.h
F: arch/arm/mach-footbridge/
-ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
+ARM/FREESCALE IMX / MXC / LAYERSCAPE ARM ARCHITECTURE
M: Frank Li <Frank.Li@nxp.com>
M: Sascha Hauer <s.hauer@pengutronix.de>
R: Pengutronix Kernel Team <kernel@pengutronix.de>
@@ -2895,22 +2895,11 @@ F: Documentation/devicetree/bindings/firmware/nxp*
F: arch/arm/boot/dts/nxp/
F: arch/arm64/boot/dts/freescale/
X: Documentation/devicetree/bindings/media/i2c/
-X: arch/arm64/boot/dts/freescale/fsl-*
-X: arch/arm64/boot/dts/freescale/qoriq-*
X: drivers/media/i2c/
N: imx
N: mxs
N: \bmxc[^\d]
-ARM/FREESCALE LAYERSCAPE ARM ARCHITECTURE
-M: Frank Li <Frank.Li@nxp.com>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S: Maintained
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git
-F: arch/arm/boot/dts/nxp/ls/
-F: arch/arm64/boot/dts/freescale/fsl-*
-F: arch/arm64/boot/dts/freescale/qoriq-*
-
ARM/FREESCALE VYBRID ARM ARCHITECTURE
M: Frank Li <Frank.Li@nxp.com>
M: Sascha Hauer <s.hauer@pengutronix.de>
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v7 1/4] dt-bindings: pci: Strictly distinguish C0 from C1-C5
From: Bjorn Helgaas @ 2026-06-30 20:13 UTC (permalink / raw)
To: Thierry Reding
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár, Michal Simek,
Kevin Xie, Aksh Garg, linux-pci, devicetree, linux-tegra,
linux-kernel, linux-arm-kernel, Thierry Reding
In-Reply-To: <20260617-tegra264-pcie-v7-1-eae7ae964629@nvidia.com>
On Wed, Jun 17, 2026 at 06:01:28PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Instead of using the ECAM registers as the first entry, strictly make a
> distinction between C0 and C1-C5. This is needed because otherwise the
> unit address doesn't match the first "reg" entry. We also cannot change
> the ordering of these nodes to follow the ECAM addresses because that
> would put them outside of their "control bus" hierarchy since the ECAM
> address space is a global one outside of any of the control busses.
Can you make the subject line a little more specific? Something like:
dt-bindings: PCI: tegra264: Strictly ...
would match the history of
Documentation/devicetree/bindings/pci/nvidia*
We can do while merging if there's no v8.
^ permalink raw reply
* ✅ PASS: Test report for for-kernelci (7.2.0-rc1, upstream-arm-next, ff4c5a0d)
From: cki-project @ 2026-06-30 20:02 UTC (permalink / raw)
To: catalin.marinas, will, linux-arm-kernel
Hi, we tested your kernel and here are the results:
Overall result: PASSED
Merge: OK
Compile: OK
Test: OK
Tested-by: CKI Project <cki-project@redhat.com>
Kernel information:
Commit message: arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:2640930305
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
^ permalink raw reply
* Re: [for-next][PATCH 04/15] tracepoint: Add lockdep rcu_is_watching() check to trace_##name##_enabled()
From: Steven Rostedt @ 2026-06-30 19:53 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David Carlier, linux-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Vineeth Pillai (Google),
Peter Zijlstra, Linux ARM, Linux-Renesas
In-Reply-To: <CAMuHMdXud_RpWag_hFqa2ByBGRxg6KnxGL1ObCWZrpTsk3TfAw@mail.gmail.com>
On Tue, 30 Jun 2026 19:39:02 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Other Renesas ARM32 platforms I tried (R-Mobile A1, RZ/A1H, RZ/A2M)
> are unafffected, perhaps because they are not SMP?
> All Renesas ARM64 platforms I tried (R-Car Gen3/4) are also unaffected.
>
> Reverting the commit fixes the issue.
>
> Do you have a clue?
Yes, it means the code was buggy before the commit. The commit will trigger
warnings in places that have issues. Before the commit, the buggy code was
never caught.
It's like enabling KASAN and finding code that has use-after-free.
Disabling KASAN is not the fix.
Tracepoints are managed by using RCU. There's places that RCU is turned
off, meaning a tracepoint in one of those locations can be triggered when
RCU is not active which may have a use-after-free semantic when the
tracepoint is enabled.
Tracepoints hidden by trace_#tracepoint#_enabled() are not caught when RCU
is disabled and the tracepoint is not active. This commit makes these
locations trigger even when the tracepoint is not active.
One way to find out if this is an existing bug or not, could you enable the
preemptirq tracepoints and run the tests again with the commit reverted?
echo 1 > /sys/kernel/tracing/events/preemptirq/enable
This will enable the events that are hidden without the commit. If it
triggers when enabled, it shows the commit found a bug.
If you get the same errors, the bug isn't with the commit in question, it's
with the tracepoints being called during suspend/resume. We will need to
fix that if that's the case.
-- Steve
^ permalink raw reply
* [PATCH v1] PCI: xgene: Drop unnecessary OF node reference
From: Yuho Choi @ 2026-06-30 19:52 UTC (permalink / raw)
To: Toan Le, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Bjorn Helgaas
Cc: Rob Herring, linux-pci, linux-arm-kernel, linux-kernel, Yuho Choi
xgene_pcie_probe() stores dev->of_node in port->node with
of_node_get(), but the cached node is only used during probe by
xgene_pcie_parse_map_dma_ranges(). The driver never releases the extra
reference, so the node reference is leaked.
There is no need for private OF node ownership here. Use the device's
existing of_node directly in xgene_pcie_parse_map_dma_ranges() and remove
the cached port->node pointer.
Fixes: 5f6b6ccdbe1c ("PCI: xgene: Add APM X-Gene PCIe driver")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
drivers/pci/controller/pci-xgene.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/pci/controller/pci-xgene.c b/drivers/pci/controller/pci-xgene.c
index b95afa35201d..83c9a2930eec 100644
--- a/drivers/pci/controller/pci-xgene.c
+++ b/drivers/pci/controller/pci-xgene.c
@@ -58,7 +58,6 @@
#define XGENE_PCIE_IP_VER_2 2
struct xgene_pcie {
- struct device_node *node;
struct device *dev;
struct clk *clk;
void __iomem *csr_base;
@@ -526,7 +525,7 @@ static void xgene_pcie_setup_ib_reg(struct xgene_pcie *port,
static int xgene_pcie_parse_map_dma_ranges(struct xgene_pcie *port)
{
- struct device_node *np = port->node;
+ struct device_node *np = port->dev->of_node;
struct of_pci_range range;
struct of_pci_range_parser parser;
struct device *dev = port->dev;
@@ -612,7 +611,6 @@ static bool xgene_check_pcie_msi_ready(void)
static int xgene_pcie_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- struct device_node *dn = dev->of_node;
struct xgene_pcie *port;
struct pci_host_bridge *bridge;
int ret;
@@ -627,7 +625,6 @@ static int xgene_pcie_probe(struct platform_device *pdev)
port = pci_host_bridge_priv(bridge);
- port->node = of_node_get(dn);
port->dev = dev;
port->version = XGENE_PCIE_IP_VER_1;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH rc v7 0/7] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Nicolin Chen @ 2026-06-30 19:27 UTC (permalink / raw)
To: Mostafa Saleh
Cc: will, robin.murphy, jgg, joro, praan, kees, baolu.lu, kevin.tian,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, stable,
jamien
In-Reply-To: <akPB6l-fuJUcg4a2@google.com>
(I think Jason has answered most of the questions here.)
On Tue, Jun 30, 2026 at 01:17:30PM +0000, Mostafa Saleh wrote:
> For example, patch 4 disables the EVTQ to avoid events as there might
> be a lot, why are they not fatal also?
FWIW, the PATCH-4 doesn't disable the EVTQ: EVTQ is disabled in
kdump case prior to the series; PATCH-4 just makes sure it won't
get enabled transiently.
Nicolin
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
From: Rob Herring (Arm) @ 2026-06-30 19:25 UTC (permalink / raw)
To: Gerald Loacker
Cc: Conor Dooley, linux-kernel, Krzysztof Kozlowski, Neil Armstrong,
linux-arm-kernel, linux-rockchip, Vinod Koul, devicetree,
Heiko Stuebner, linux-phy
In-Reply-To: <20260630-feature-mipi-csi-dphy-4k60-v3-2-176792ab71fa@wolfvision.net>
On Tue, 30 Jun 2026 09:48:25 +0200, Gerald Loacker wrote:
> Add support for the optional rockchip,clk-lane-phase device tree property
> to allow board-specific tuning of the clock lane sampling phase for
> improved signal integrity across supported data rates.
>
> Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
> ---
> .../devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH rc v7 0/7] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Nicolin Chen @ 2026-06-30 19:24 UTC (permalink / raw)
To: Jason Gunthorpe
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: <20260630190819.GG7481@nvidia.com>
On Tue, Jun 30, 2026 at 04:08:19PM -0300, Jason Gunthorpe wrote:
> On Tue, Jun 30, 2026 at 06:30:41PM +0000, Pranjal Shrivastava wrote:
> > > As I mentioned above in the previous
> > > reply I am not sure I understand what situation leads into this, when
> > > does a device trigger SError to the system vs when not which is observed
> > > as an event in that case.
> >
> > Ack. I see what you mean now.. How does a DMA fault raise an SError?
>
> As I gave an example to Robin if the unhandled failure escalates into
> RAS emergency unplugging CXL memory then the system is going to
> explode when kdump touches that CXL memory as part of the dumping. It
> is not quite so simple that a DMA abort is triggering SError.
Here is link to that email:
https://lore.kernel.org/all/20260416172005.GB761338@nvidia.com/
> 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
Thanks
Nicolin
^ permalink raw reply
* [PATCH 3/3] rtc: s35390a: make use of interrupt signal 1
From: Markus Probst @ 2026-06-30 19:22 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth
Cc: linux-arm-kernel, linux-rtc, devicetree, linux-kernel,
Markus Probst
In-Reply-To: <20260630-rtc_s35390a_int1-v1-0-1b2239e16be2@posteo.de>
If configured, use output pin for interrupt signal 1 for the wake alarm.
Successfully Tested on a Synology DS923+.
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
drivers/rtc/rtc-s35390a.c | 61 +++++++++++++++++++++++++++++++++++++----------
1 file changed, 49 insertions(+), 12 deletions(-)
diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc/rtc-s35390a.c
index 4cfe7034c516..6875bf039cbf 100644
--- a/drivers/rtc/rtc-s35390a.c
+++ b/drivers/rtc/rtc-s35390a.c
@@ -12,11 +12,13 @@
#include <linux/bcd.h>
#include <linux/slab.h>
#include <linux/delay.h>
+#include <dt-bindings/rtc/s35390a.h>
#define S35390A_CMD_STATUS1 0
#define S35390A_CMD_STATUS2 1
#define S35390A_CMD_TIME1 2
#define S35390A_CMD_TIME2 3
+#define S35390A_CMD_INT1_REG1 4
#define S35390A_CMD_INT2_REG1 5
#define S35390A_CMD_FREE_REG 7
@@ -36,6 +38,7 @@
#define S35390A_FLAG_POC BIT(0)
#define S35390A_FLAG_BLD BIT(1)
#define S35390A_FLAG_INT2 BIT(2)
+#define S35390A_FLAG_INT1 BIT(3)
#define S35390A_FLAG_24H BIT(6)
#define S35390A_FLAG_RESET BIT(7)
@@ -50,6 +53,14 @@
#define S35390A_INT2_MODE_FREQ BIT(3) /* INT2FE */
#define S35390A_INT2_MODE_PMIN (BIT(3) | BIT(2)) /* INT2FE | INT2ME */
+/* INT1 pin output mode */
+#define S35390A_INT1_MODE_MASK 0xE0
+#define S35390A_INT1_MODE_NOINTR 0x00
+#define S35390A_INT1_MODE_ALARM BIT(5) /* INT1AE */
+#define S35390A_INT1_MODE_PMIN_EDG BIT(6) /* INT1ME */
+#define S35390A_INT1_MODE_FREQ BIT(7) /* INT1FE */
+#define S35390A_INT1_MODE_PMIN (BIT(7) | BIT(6)) /* INT1FE | INT1ME */
+
static const struct i2c_device_id s35390a_id[] = {
{ .name = "s35390a" },
{ }
@@ -65,6 +76,7 @@ MODULE_DEVICE_TABLE(of, s35390a_of_match);
struct s35390a {
struct i2c_client *client[8];
int twentyfourhour;
+ bool wakealarm_use_int1;
};
static int s35390a_set_reg(struct s35390a *s35390a, int reg, u8 *buf, int len)
@@ -275,7 +287,7 @@ static int s35390a_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
struct i2c_client *client = to_i2c_client(dev);
struct s35390a *s35390a = i2c_get_clientdata(client);
u8 buf[3], sts = 0;
- int err, i;
+ int err, i, reg;
dev_dbg(&client->dev, "%s: alm is secs=%d, mins=%d, hours=%d mday=%d, "\
"mon=%d, year=%d, wday=%d\n", __func__, alm->time.tm_sec,
@@ -293,9 +305,13 @@ static int s35390a_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
return err;
if (alm->enabled)
- sts = S35390A_INT2_MODE_ALARM;
+ sts = s35390a->wakealarm_use_int1
+ ? S35390A_INT1_MODE_ALARM
+ : S35390A_INT2_MODE_ALARM;
else
- sts = S35390A_INT2_MODE_NOINTR;
+ sts = s35390a->wakealarm_use_int1
+ ? S35390A_INT1_MODE_NOINTR
+ : S35390A_INT2_MODE_NOINTR;
/* set interrupt mode*/
err = s35390a_set_reg(s35390a, S35390A_CMD_STATUS2, &sts, sizeof(sts));
@@ -317,8 +333,11 @@ static int s35390a_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
for (i = 0; i < 3; ++i)
buf[i] = bitrev8(buf[i]);
- err = s35390a_set_reg(s35390a, S35390A_CMD_INT2_REG1, buf,
- sizeof(buf));
+ reg = s35390a->wakealarm_use_int1
+ ? S35390A_CMD_INT1_REG1
+ : S35390A_CMD_INT2_REG1;
+
+ err = s35390a_set_reg(s35390a, reg, buf, sizeof(buf));
return err;
}
@@ -328,13 +347,21 @@ static int s35390a_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
struct i2c_client *client = to_i2c_client(dev);
struct s35390a *s35390a = i2c_get_clientdata(client);
u8 buf[3], sts;
- int i, err;
+ int i, err, reg, mask, mode;
err = s35390a_get_reg(s35390a, S35390A_CMD_STATUS2, &sts, sizeof(sts));
if (err < 0)
return err;
- if ((sts & S35390A_INT2_MODE_MASK) != S35390A_INT2_MODE_ALARM) {
+ mask = s35390a->wakealarm_use_int1
+ ? S35390A_INT1_MODE_MASK
+ : S35390A_INT2_MODE_MASK;
+
+ mode = s35390a->wakealarm_use_int1
+ ? S35390A_INT1_MODE_ALARM
+ : S35390A_INT2_MODE_ALARM;
+
+ if ((sts & mask) != mode) {
/*
* When the alarm isn't enabled, the register to configure
* the alarm time isn't accessible.
@@ -345,7 +372,11 @@ static int s35390a_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
alm->enabled = 1;
}
- err = s35390a_get_reg(s35390a, S35390A_CMD_INT2_REG1, buf, sizeof(buf));
+ reg = s35390a->wakealarm_use_int1
+ ? S35390A_CMD_INT1_REG1
+ : S35390A_CMD_INT2_REG1;
+
+ err = s35390a_get_reg(s35390a, reg, buf, sizeof(buf));
if (err < 0)
return err;
@@ -437,10 +468,10 @@ static int s35390a_nvmem_write(void *priv, unsigned int offset, void *val,
static int s35390a_probe(struct i2c_client *client)
{
int err, err_read;
- unsigned int i;
+ unsigned int i, wakealarm_output_pin = 0;
struct s35390a *s35390a;
struct rtc_device *rtc;
- u8 buf, status1;
+ u8 buf, status1, flag;
struct device *dev = &client->dev;
struct nvmem_config nvmem_cfg = {
.name = "s35390a_nvram",
@@ -452,6 +483,9 @@ static int s35390a_probe(struct i2c_client *client)
.reg_write = s35390a_nvmem_write,
};
+ fwnode_property_read_u32(dev->fwnode, "sii,wakealarm-output-pin",
+ &wakealarm_output_pin);
+
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
return -ENODEV;
@@ -460,6 +494,7 @@ static int s35390a_probe(struct i2c_client *client)
return -ENOMEM;
s35390a->client[0] = client;
+ s35390a->wakealarm_use_int1 = wakealarm_output_pin == S35390A_OUTPUT_PIN_INT1;
i2c_set_clientdata(client, s35390a);
/* This chip uses multiple addresses, use dummy devices for them */
@@ -489,7 +524,9 @@ static int s35390a_probe(struct i2c_client *client)
else
s35390a->twentyfourhour = 0;
- if (status1 & S35390A_FLAG_INT2) {
+ flag = s35390a->wakealarm_use_int1 ? S35390A_FLAG_INT1 : S35390A_FLAG_INT2;
+
+ if (status1 & flag) {
/* disable alarm (and maybe test mode) */
buf = 0;
err = s35390a_set_reg(s35390a, S35390A_CMD_STATUS2, &buf, 1);
@@ -514,7 +551,7 @@ static int s35390a_probe(struct i2c_client *client)
set_bit(RTC_FEATURE_ALARM_RES_MINUTE, rtc->features);
clear_bit(RTC_FEATURE_UPDATE_INTERRUPT, rtc->features);
- if (status1 & S35390A_FLAG_INT2)
+ if (status1 & flag)
rtc_update_irq(rtc, 1, RTC_AF);
nvmem_cfg.priv = s35390a;
--
2.54.0
^ permalink raw reply related
* [PATCH 2/3] rtc: s35390a: Add missing newline to dev_err
From: Markus Probst @ 2026-06-30 19:22 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth
Cc: linux-arm-kernel, linux-rtc, devicetree, linux-kernel,
Markus Probst
In-Reply-To: <20260630-rtc_s35390a_int1-v1-0-1b2239e16be2@posteo.de>
Fixes: 3bd32722c827d ("rtc: s35390a: improve irq handling")
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
drivers/rtc/rtc-s35390a.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc/rtc-s35390a.c
index b72eef4fb099..4cfe7034c516 100644
--- a/drivers/rtc/rtc-s35390a.c
+++ b/drivers/rtc/rtc-s35390a.c
@@ -494,7 +494,7 @@ static int s35390a_probe(struct i2c_client *client)
buf = 0;
err = s35390a_set_reg(s35390a, S35390A_CMD_STATUS2, &buf, 1);
if (err < 0) {
- dev_err(dev, "error disabling alarm");
+ dev_err(dev, "error disabling alarm\n");
return err;
}
} else {
--
2.54.0
^ permalink raw reply related
* [PATCH 0/3] rtc: s35390a: Allow use of output pin for interrupt signal 1 for wakealarm
From: Markus Probst @ 2026-06-30 19:22 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth
Cc: linux-arm-kernel, linux-rtc, devicetree, linux-kernel,
Markus Probst
Add a dt property to allow the use of output pin for interrupt signal 1
for wakealarm. This is needed for wakealarms to work on Synology NAS
devices.
It appears there is currently no entry in the MAINTAINERS file for the
S35390A driver. I assume the driver is currently maintained by
Alexandre Belloni.
I hope its fine I added him as maintainer for the newly added devicetree
binding, in order to keep it maintained by the same person.
Also If I am not mistaken, wake alarms on these systems are currently broken:
(not tested, judged by looking at the devicetrees).
- arch/arm/boot/dts/marvell/armada-370-synology-ds213j.dts
- arch/arm/boot/dts/marvell/armada-xp-synology-ds414.dts
- arch/arm/boot/dts/marvell/kirkwood-synology.dtsi
- arch/arm/boot/dts/marvell/kirkwood-ds110jv10.dts
- arch/arm/boot/dts/marvell/kirkwood-ds111.dts
- arch/arm/boot/dts/marvell/kirkwood-ds112.dts
- arch/arm/boot/dts/marvell/kirkwood-ds210.dts
- arch/arm/boot/dts/marvell/kirkwood-ds212.dts
- arch/arm/boot/dts/marvell/kirkwood-ds212j.dts
- arch/arm/boot/dts/marvell/kirkwood-ds411.dts
- arch/arm/boot/dts/marvell/kirkwood-ds411j.dts
- arch/arm/boot/dts/marvell/kirkwood-ds411slim.dts
- arch/arm/boot/dts/marvell/kirkwood-rs212.dts
- arch/arm/boot/dts/marvell/kirkwood-rs411.dts
If thats the case it can be fixed by using this patch series and adding
`sii,wakealarm-output-pin = <S35390A_OUTPUT_PIN_INT1>;` to the
s35390a devicetree.
If somebody still runs one of these systems, please test.
Thanks
- Markus Probst
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
Markus Probst (3):
dt-bindings: rtc: Add sii,wakealarm-output-pin property for S35390A
rtc: s35390a: Add missing newline to dev_err
rtc: s35390a: make use of interrupt signal 1
.../devicetree/bindings/rtc/sii,s35390a.yaml | 54 +++++++++++++++++++
.../devicetree/bindings/rtc/trivial-rtc.yaml | 3 --
MAINTAINERS | 1 +
drivers/rtc/rtc-s35390a.c | 63 +++++++++++++++++-----
include/dt-bindings/rtc/s35390a.h | 9 ++++
5 files changed, 114 insertions(+), 16 deletions(-)
---
base-commit: 728e68a889bcf257b1e67298b12c360e5c3a13e0
change-id: 20260630-rtc_s35390a_int1-556ccb308d3f
^ permalink raw reply
* [PATCH 1/3] dt-bindings: rtc: Add sii,wakealarm-output-pin property for S35390A
From: Markus Probst @ 2026-06-30 19:22 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth
Cc: linux-arm-kernel, linux-rtc, devicetree, linux-kernel,
Markus Probst
In-Reply-To: <20260630-rtc_s35390a_int1-v1-0-1b2239e16be2@posteo.de>
Synology NAS devices use the output pin for interrupt signal 1 to wake up
the system.
Move devicetree bindings for sii,s35390a into its own file.
Add sii,wakealarm-output-pin property to enable the use of the output
pin for interrupt signal 1 for the wake alarm, which makes it possible to
set an wake alarm on Synology NAS devices.
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
.../devicetree/bindings/rtc/sii,s35390a.yaml | 54 ++++++++++++++++++++++
.../devicetree/bindings/rtc/trivial-rtc.yaml | 3 --
MAINTAINERS | 1 +
include/dt-bindings/rtc/s35390a.h | 9 ++++
4 files changed, 64 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml b/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml
new file mode 100644
index 000000000000..31a578673870
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/sii,s35390a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: S-35390A 2-WIRE REAL-TIME CLOCK
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+description:
+ The S-35390A is a CMOS 2-wire real-time clock IC which operates with the
+ very low current consumption in the wide range of operation voltage.
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ const: sii,s35390a
+
+ reg:
+ maxItems: 1
+
+ sii,wakealarm-output-pin:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2]
+ description: |
+ The output pin to wake up the system.
+ Default will use the output pin for interrupt signal 2.
+ <S35390A_OUTPUT_PIN_INT1> : Output pin for interrupt signal 1
+ <S35390A_OUTPUT_PIN_INT2> : Output pin for interrupt signal 2
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/rtc/s35390a.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc: rtc@30 {
+ compatible = "sii,s35390a";
+ reg = <0x30>;
+ sii,wakealarm-output-pin = <S35390A_OUTPUT_PIN_INT2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
index f4d0eed98a08..7b3f682ef4d5 100644
--- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
@@ -81,8 +81,6 @@ properties:
- ricoh,rv5c386
# I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
- ricoh,rv5c387a
- # 2-wire CMOS real-time clock
- - sii,s35390a
# ST SPEAr Real-time Clock
- st,spear600-rtc
# VIA/Wondermedia VT8500 Real-time Clock
@@ -105,5 +103,4 @@ required:
- reg
additionalProperties: false
-
...
diff --git a/MAINTAINERS b/MAINTAINERS
index 15011f5752a9..46a19a0873e0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22690,6 +22690,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git
F: Documentation/admin-guide/rtc.rst
F: Documentation/devicetree/bindings/rtc/
F: drivers/rtc/
+F: include/dt-bindings/rtc/
F: include/linux/rtc.h
F: include/linux/rtc/
F: include/uapi/linux/rtc.h
diff --git a/include/dt-bindings/rtc/s35390a.h b/include/dt-bindings/rtc/s35390a.h
new file mode 100644
index 000000000000..bd99db118d31
--- /dev/null
+++ b/include/dt-bindings/rtc/s35390a.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) */
+
+#ifndef __DT_BINDINGS_RTC_S35390A_H
+#define __DT_BINDINGS_RTC_S35390A_H
+
+#define S35390A_OUTPUT_PIN_INT1 1
+#define S35390A_OUTPUT_PIN_INT2 2
+
+#endif /* __DT_BINDINGS_RTC_S35390A_H */
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Properly disable remote wakeup for MT7922/MT7925 on Ryzen platform
From: Rong Zhang @ 2026-06-30 19:15 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Matthias Brugger, AngeloGioacchino Del Regno,
Luiz Augusto von Dentz, Chris Lu (陸稚泓),
Will-CY Lee (李政穎),
SS Wu (巫憲欣), linux-bluetooth, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <CABBYNZLhqQF-V8sJORwMW2C_4FxFY+pkAK=cSDg4aeWJYfiJrA@mail.gmail.com>
Hi Luiz,
于 2026年7月1日 GMT+08:00 02:13:39，Luiz Augusto von Dentz <luiz.dentz@gmail.com> 写道：
>Hi Rong,
>
>On Mon, Jun 29, 2026 at 11:28 AM Rong Zhang <i@rong.moe> wrote:
>>
>> It is reported that a remote wakeup could cause MT7922/MT7925's btusb
>> interface completely unresponsive. Resetting the xHCI root hub doesn't
>> help at all, and recovering from such a state needs a power cycle.
>>
>> All reports seen to be relevant to Ryzen-based laptops. These NICs are
>> usually used as OEM components thanks to some sort of reference designs.
>>
>> Their popularity on other platforms is unclear. While there is still a
>> chance that the quirk may exist on other platforms, be cautious and only
>> apply the quirk on AMD platforms for the time being.
>>
>> Meanwhile, though device_set_wakeup_capable(false) is the correct fix
>> for other NICs with fake remote wakeup capabilities, doing so for
>> MT7922/MT7925 effectively prevents it from being used as wakeup
>> sources as per userspace requests. Hence, return -EBUSY on runtime
>> suspend to prevent the interface from being autosuspended while it's
>> still opened, which has the same effect as
>> device_set_wakeup_capable(false), since disabling remote wakeup simply
>> causes the USB core to gate runtime autosuspend as well due to
>> needs_remote_wakeup == 1. The interface can be safely autosuspended as
>> long as remote wakeup is disabled, i.e., after closing the HCI device.
>>
>> Specifically, the interface may still take the advantage of remote
>> wakeup in order to wake up the system from sleep if userspace has
>> enabled it as a wakeup source.
>>
>> Fixes: e31d761628ad ("Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925")
>> Signed-off-by: Rong Zhang <i@rong.moe>
>> ---
>> drivers/bluetooth/btmtk.c | 10 ---------
>> drivers/bluetooth/btusb.c | 57 +++++++++++++++++++++++++++++++++++++++++++----
>> 2 files changed, 53 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
>> index 02a96342e964..4614434dd57b 100644
>> --- a/drivers/bluetooth/btmtk.c
>> +++ b/drivers/bluetooth/btmtk.c
>> @@ -1381,16 +1381,6 @@ int btmtk_usb_setup(struct hci_dev *hdev)
>> break;
>> case 0x7922:
>> case 0x7925:
>> - /*
>> - * A remote wakeup could cause the device completely unresponsive, and
>> - * recovering from such a state needs a power cycle.
>> - *
>> - * Since the remote wakeup capability is super broken, just disable it
>> - * to get rid of the troubles. The device can still be autosuspended
>> - * when the bluetooth interface is closed.
>> - */
>> - device_set_wakeup_capable(&btmtk_data->udev->dev, false);
>> - fallthrough;
>> case 0x7961:
>> case 0x7902:
>> case 0x6639:
>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
>> index 08c0a99a62c5..023ae782f41a 100644
>> --- a/drivers/bluetooth/btusb.c
>> +++ b/drivers/bluetooth/btusb.c
>> @@ -6,6 +6,7 @@
>> * Copyright (C) 2005-2008 Marcel Holtmann <marcel@holtmann.org>
>> */
>>
>> +#include <linux/cpufeature.h>
>> #include <linux/dmi.h>
>> #include <linux/module.h>
>> #include <linux/usb.h>
>> @@ -957,6 +958,7 @@ struct qca_dump_info {
>> #define BTUSB_USE_ALT3_FOR_WBS 15
>> #define BTUSB_ALT6_CONTINUOUS_TX 16
>> #define BTUSB_HW_SSR_ACTIVE 17
>> +#define BTUSB_WAKEUP_BROKEN 18
>>
>> struct btusb_data {
>> struct hci_dev *hdev;
>> @@ -2936,10 +2938,20 @@ static int btusb_send_frame_mtk(struct hci_dev *hdev, struct sk_buff *skb)
>> }
>> }
>>
>> +static inline bool platform_is_ryzen(void)
>> +{
>> +#ifdef CONFIG_X86
>> + return boot_cpu_has(X86_FEATURE_ZEN);
>> +#else
>> + return false;
>> +#endif
>> +}
>> +
>> static int btusb_mtk_setup(struct hci_dev *hdev)
>> {
>> struct btusb_data *data = hci_get_drvdata(hdev);
>> struct btmtk_data *btmtk_data = hci_get_priv(hdev);
>> + int err;
>>
>> /* MediaTek WMT vendor cmd requiring below USB resources to
>> * complete the handshake.
>> @@ -2956,7 +2968,29 @@ static int btusb_mtk_setup(struct hci_dev *hdev)
>> btusb_mtk_claim_iso_intf(data);
>> }
>>
>> - return btmtk_usb_setup(hdev);
>> + err = btmtk_usb_setup(hdev);
>> + if (err)
>> + return err;
>> +
>> + switch (btmtk_data->dev_id) {
>> + case 0x7922:
>> + case 0x7925:
>> + /*
>> + * All reports seen to be relevant to Ryzen-based laptops. These
>> + * NICs are usually used as OEM components thanks to some sort
>> + * of reference designs.
>> + *
>> + * Their popularity on other platforms is unclear. While there
>> + * is still a chance that the quirk may exist on other
>> + * platforms, be cautious and only apply the quirk on AMD
>> + * platforms for the time being.
>> + */
>
>Is this going to be a reliable way to detect if wakeup is broken or
>not? Since USB is a bus capable of hotplug, this check would block not
>only internal/built-in controllers with the above IDs but also those
>plugged via external ports if the CPU happens to be of the ZEN
>familly.
Hmm, it seems that we can detect the device's position by comparing its parent and its bus. We can additionally make it further by checking against the root hub's VID. In this manner we should be able to drop the boot_cpu_has() check too.
I will try and send a v2.
Thanks,
Rong
>
>> + if (platform_is_ryzen())
>> + set_bit(BTUSB_WAKEUP_BROKEN, &data->flags);
>> + break;
>> + }
>> +
>> + return 0;
>> }
>>
>> static int btusb_mtk_shutdown(struct hci_dev *hdev)
>> @@ -4532,11 +4566,26 @@ static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
>>
>> BT_DBG("intf %p", intf);
>>
>> - /* Don't auto-suspend if there are connections or discovery in
>> - * progress; external suspend calls shall never fail.
>> + /*
>> + * It is reported that remote wakeup events could sometimes cause some
>> + * adapters completely unresponsive. Resetting the xHCI root hub doesn't
>> + * help at all, and recovering from such a state needs a power cycle.
>> + * Since disabling remote wakeup simply causes the USB core to gate
>> + * runtime autosuspend as well due to needs_remote_wakeup == 1, let's do
>> + * this ourselves to make our life easier. The interface can be safely
>> + * autosuspended as long as remote wakeup is disabled, i.e., after
>> + * closing the HCI device.
>> + *
>> + * Don't auto-suspend if there are connections or discovery in progress.
>> + *
>> + * External suspend calls shall never fail. Specifically, a device with
>> + * broken remote wakeup may still take the advantage of remote wakeup in
>> + * order to wake up the system from sleep if userspace has enabled it as
>> + * a wakeup source.
>> */
>> if (PMSG_IS_AUTO(message) &&
>> - (hci_conn_count(data->hdev) || hci_discovery_active(data->hdev)))
>> + ((test_bit(BTUSB_WAKEUP_BROKEN, &data->flags) && data->intf->needs_remote_wakeup) ||
>> + hci_conn_count(data->hdev) || hci_discovery_active(data->hdev)))
>> return -EBUSY;
>>
>> if (data->suspend_count++)
>>
>> ---
>> base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
>> change-id: 230ba8c9-btmtk-ryzen-remote-wakeup-055a407682ef
>>
>> Thanks,
>> Rong
>>
>
>
^ permalink raw reply
* Re: [PATCH v5 5/5] phy: fsl-imx8mq-usb: keep PHY power domain runtime always-on for i.MX8MP
From: Frank Li @ 2026-06-30 19:13 UTC (permalink / raw)
To: Xu Yang
Cc: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Jun Li, linux-phy, imx,
linux-arm-kernel, linux-kernel, Xu Yang
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-5-25d616403844@nxp.com>
On Tue, Jun 30, 2026 at 06:11:32PM +0800, Xu Yang wrote:
> From: Xu Yang <xu.yang_2@nxp.com>
>
> On i.MX8MP, the USB PHY has a dedicated power domain that was previously
> never powered off at runtime. With the introduction of runtime PM support,
> the power domain will be powered off if the device is runtime suspended,
> which breaks USB wakeup functionality.
>
> To preserve wakeup functionality, mark the PHY power domain as runtime
> always-on for i.MX8MP platform. To limit the behavior to i.MX8MP, add a
> new imx95_usb_phy_ops for i.MX95 and introduce usb_phy_is_imx8mp() helper
> to identify i.MX8MP PHY instance.
>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
>
> ---
> Changes in v5:
> - no changes
> Changes in v4:
> - no changes
> Changes in v3:
> - new patch
> ---
> drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index 4949ec78d304..c9741b532663 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> @@ -9,6 +9,7 @@
> #include <linux/of.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> #include <linux/pm_runtime.h>
> #include <linux/regulator/consumer.h>
> #include <linux/regmap.h>
> @@ -660,13 +661,20 @@ static const struct phy_ops imx8mp_usb_phy_ops = {
> .owner = THIS_MODULE,
> };
>
> +static const struct phy_ops imx95_usb_phy_ops = {
> + .init = imx8mp_usb_phy_init,
> + .power_on = imx8mq_phy_power_on,
> + .power_off = imx8mq_phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> static const struct of_device_id imx8mq_usb_phy_of_match[] = {
> {.compatible = "fsl,imx8mq-usb-phy",
> .data = &imx8mq_usb_phy_ops,},
> {.compatible = "fsl,imx8mp-usb-phy",
> .data = &imx8mp_usb_phy_ops,},
> {.compatible = "fsl,imx95-usb-phy",
> - .data = &imx8mp_usb_phy_ops,},
> + .data = &imx95_usb_phy_ops,},
> { }
> };
> MODULE_DEVICE_TABLE(of, imx8mq_usb_phy_of_match);
> @@ -679,6 +687,11 @@ static const struct regmap_config imx_cr_regmap_config = {
> .max_register = 0x7,
> };
>
> +static bool usb_phy_is_imx8mp(const void *data)
> +{
> + return data == &imx8mp_usb_phy_ops;
> +}
> +
It is not good direct use drvdata as it.
Can you add new drvdata
drvdata
{
phy_ops ops;
bool always_on;
}
in follow probe check
if (always_on)
...
it is more extendable in future.
Frank
> static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> {
> struct phy_provider *phy_provider;
> @@ -721,6 +734,9 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> if (!phy_ops)
> return -EINVAL;
>
> + if (usb_phy_is_imx8mp(phy_ops))
> + dev_pm_genpd_rpm_always_on(dev, true);
> +
> imx_phy->phy = devm_phy_create(dev, NULL, phy_ops);
> if (IS_ERR(imx_phy->phy))
> return PTR_ERR(imx_phy->phy);
>
> --
> 2.34.1
>
>
^ 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