* 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
* ✅ 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: [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
* [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 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
* [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
* [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
* [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 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 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 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
* 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 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 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 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
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