* Re: [PATCH v2] dt-bindings: arm: marvell: Convert armada-380-mpcore-soc-ctrl to DT Schema
From: Rob Herring @ 2026-04-07 18:44 UTC (permalink / raw)
To: Padmashree S S
Cc: andrew, gregory.clement, sebastian.hesselbarth, krzk+dt, conor+dt,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260327114653.593582-1-padmashreess2006@gmail.com>
On Fri, Mar 27, 2026 at 05:16:53PM +0530, Padmashree S S wrote:
> Convert armada-380-mpcore-soc-ctrl to DT schema
>
> Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
> ---
> .../marvell/armada-380-mpcore-soc-ctrl.txt | 14 --------
> .../marvell/armada-380-mpcore-soc-ctrl.yaml | 32 +++++++++++++++++++
> 2 files changed, 32 insertions(+), 14 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
> create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml
Please move this to
bindings/soc/marvell/marvell,armada-380-mpcore-soc-ctrl.yaml
Don't forget to update the '$id' value.
Rob
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: pinctrl: sun55i-a523: increase IRQ banks number
From: Rob Herring (Arm) @ 2026-04-07 18:40 UTC (permalink / raw)
To: Andre Przywara
Cc: Jernej Skrabec, Samuel Holland, linux-gpio, linux-sunxi,
devicetree, linux-arm-kernel, Krzysztof Kozlowski, linux-kernel,
Conor Dooley, Chen-Yu Tsai
In-Reply-To: <20260327113006.3135663-3-andre.przywara@arm.com>
On Fri, 27 Mar 2026 11:30:05 +0000, Andre Przywara wrote:
> The Allwinner A523 SoC implements 10 GPIO banks in the first pinctrl
> instance, but it skips the first bank (PortA), so their index goes from
> 1 to 10. The same is actually true for the IRQ banks: there are registers
> for 11 banks, though the first bank is not implemented (RAZ/WI).
> In contrast to previous SoCs, the count of the IRQ banks starts with this
> first unimplemented bank, so we need to provide an interrupt for it.
> And indeed the A523 user manual lists an interrupt number for PortA, so we
> need to increase the maximum number of interrupts per pin controller to 11,
> to be able to assign the correct interrupt number for each bank.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> .../bindings/pinctrl/allwinner,sun55i-a523-pinctrl.yaml | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/4] perf arm_spe: Decode Arm N1 IMPDEF events
From: Ian Rogers @ 2026-04-07 18:26 UTC (permalink / raw)
To: James Clark
Cc: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Adrian Hunter, Al Grant,
linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <ee012f48-5d08-4004-b9d0-bcac825cb50c@linaro.org>
On Tue, Apr 7, 2026 at 5:35 AM James Clark <james.clark@linaro.org> wrote:
>
>
>
> On 02/04/2026 4:26 pm, Ian Rogers wrote:
> > On Wed, Apr 1, 2026 at 7:26 AM James Clark <james.clark@linaro.org> wrote:
> >>
> >> From the TRM [1], N1 has one IMPDEF event which isn't covered by the
> >> common list. Add a framework so that more cores can be added in the
> >> future and that the N1 IMPDEF event can be decoded. Also increase the
> >> size of the buffer because we're adding more strings and if it gets
> >> truncated it falls back to a hex dump only.
> >>
> >> [1]: https://developer.arm.com/documentation/100616/0401/Statistical-Profiling-Extension/implementation-defined-features-of-SPE
> >> Suggested-by: Al Grant <al.grant@arm.com>
> >> Signed-off-by: James Clark <james.clark@linaro.org>
> >> ---
> >> tools/perf/util/arm-spe-decoder/Build | 2 +
> >> .../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 45 ++++++++++++++++++++--
> >> .../util/arm-spe-decoder/arm-spe-pkt-decoder.h | 5 ++-
> >> tools/perf/util/arm-spe.c | 13 ++++---
> >> 4 files changed, 54 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/tools/perf/util/arm-spe-decoder/Build b/tools/perf/util/arm-spe-decoder/Build
> >> index ab500e0efe24..97a298d1e279 100644
> >> --- a/tools/perf/util/arm-spe-decoder/Build
> >> +++ b/tools/perf/util/arm-spe-decoder/Build
> >> @@ -1 +1,3 @@
> >> perf-util-y += arm-spe-pkt-decoder.o arm-spe-decoder.o
> >> +
> >> +CFLAGS_arm-spe-pkt-decoder.o += -I$(srctree)/tools/arch/arm64/include/ -I$(OUTPUT)arch/arm64/include/generated/
> >> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> >> index c880b0dec3a1..42a7501d4dfe 100644
> >> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> >> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> >> @@ -15,6 +15,8 @@
> >>
> >> #include "arm-spe-pkt-decoder.h"
> >>
> >> +#include "../../arm64/include/asm/cputype.h"
> >
> > Sashiko spotted:
> > https://sashiko.dev/#/patchset/20260401-james-spe-impdef-decode-v1-0-ad0d372c220c%40linaro.org
> > """
> > This isn't a bug, but does this include directive rely on accidental
> > path normalization?
> >
> > The relative path ../../arm64/include/asm/cputype.h does not exist relative
> > to arm-spe-pkt-decoder.c. It only compiles because the Build file adds
> > -I$(srctree)/tools/arch/arm64/include/ to CFLAGS.
> >
> > Would it be cleaner to use #include <asm/cputype.h> to explicitly rely on
> > the include path?
> > [ ... ]
> > """
> > I wouldn't use <asm/cputype.h> due to cross-compilation and the like,
> > instead just add the extra "../" into the include path.
> >
>
> Do you mean change the #include to this?
>
> #include "../../../arm64/include/asm/cputype.h"
>
> I still need to add:
>
> CFLAGS_arm-spe-pkt-decoder.o += -I$(srctree)/tools/arch/arm64/include/
>
> To make the this include in cputype.h work:
>
> #include <asm/sysreg.h>
>
> Which probably only works because there isn't a sysreg.h on other
> architectures. But I'm not sure what the significance of ../../ vs
> ../../../ is if either compile? arm-spe.c already does it with ../../
> which is what I copied.
Hmm.. maybe the path should be
"../../../arch/arm64/include/asm/cputype.h". The include preference is
for a path relative to the source file and
../../arm64/include/asm/cputype.h doesn't exist. It is kind of horrid
to add an include path and then use a relative path to escape into a
higher-level directory. arm-spe.c is a little different as it is one
directory higher in the directory layout.
Thanks,
Ian
> >> +
> >> static const char * const arm_spe_packet_name[] = {
> >> [ARM_SPE_PAD] = "PAD",
> >> [ARM_SPE_END] = "END",
> >> @@ -307,6 +309,11 @@ static const struct ev_string common_ev_strings[] = {
> >> { .event = 0, .desc = NULL },
> >> };
> >>
> >> +static const struct ev_string n1_event_strings[] = {
> >> + { .event = 12, .desc = "LATE-PREFETCH" },
> >> + { .event = 0, .desc = NULL },
> >> +};
> >> +
> >> static u64 print_event_list(int *err, char **buf, size_t *buf_len,
> >> const struct ev_string *ev_strings, u64 payload)
> >> {
> >> @@ -318,14 +325,44 @@ static u64 print_event_list(int *err, char **buf, size_t *buf_len,
> >> return payload;
> >> }
> >>
> >> +struct event_print_handle {
> >> + const struct midr_range *midr_ranges;
> >> + const struct ev_string *ev_strings;
> >> +};
> >> +
> >> +#define EV_PRINT(range, strings) \
> >> + { \
> >> + .midr_ranges = range, \
> >> + .ev_strings = strings, \
> >> + }
> >> +
> >> +static const struct midr_range n1_event_encoding_cpus[] = {
> >> + MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1),
> >> + {},
> >> +};
> >> +
> >> +static const struct event_print_handle event_print_handles[] = {
> >> + EV_PRINT(n1_event_encoding_cpus, n1_event_strings),
> >> +};
> >> +
> >> static int arm_spe_pkt_desc_event(const struct arm_spe_pkt *packet,
> >> - char *buf, size_t buf_len)
> >> + char *buf, size_t buf_len, u64 midr)
> >> {
> >> u64 payload = packet->payload;
> >> int err = 0;
> >>
> >> arm_spe_pkt_out_string(&err, &buf, &buf_len, "EV");
> >> - print_event_list(&err, &buf, &buf_len, common_ev_strings, payload);
> >> + payload = print_event_list(&err, &buf, &buf_len, common_ev_strings,
> >> + payload);
> >> +
> >> + /* Try to decode IMPDEF bits for known CPUs */
> >> + for (unsigned int i = 0; i < ARRAY_SIZE(event_print_handles); i++) {
> >> + if (is_midr_in_range_list(midr,
> >> + event_print_handles[i].midr_ranges))
> >> + payload = print_event_list(&err, &buf, &buf_len,
> >> + event_print_handles[i].ev_strings,
> >> + payload);
> >> + }
> >>
> >> return err;
> >> }
> >> @@ -506,7 +543,7 @@ static int arm_spe_pkt_desc_counter(const struct arm_spe_pkt *packet,
> >> }
> >>
> >> int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf,
> >> - size_t buf_len)
> >> + size_t buf_len, u64 midr)
> >> {
> >> int idx = packet->index;
> >> unsigned long long payload = packet->payload;
> >> @@ -522,7 +559,7 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf,
> >> arm_spe_pkt_out_string(&err, &buf, &blen, "%s", name);
> >> break;
> >> case ARM_SPE_EVENTS:
> >> - err = arm_spe_pkt_desc_event(packet, buf, buf_len);
> >> + err = arm_spe_pkt_desc_event(packet, buf, buf_len, midr);
> >> break;
> >> case ARM_SPE_OP_TYPE:
> >> err = arm_spe_pkt_desc_op_type(packet, buf, buf_len);
> >> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> >> index adf4cde320aa..17b067fe3c87 100644
> >> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> >> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> >> @@ -11,7 +11,7 @@
> >> #include <stddef.h>
> >> #include <stdint.h>
> >>
> >> -#define ARM_SPE_PKT_DESC_MAX 256
> >> +#define ARM_SPE_PKT_DESC_MAX 512
> >>
> >> #define ARM_SPE_NEED_MORE_BYTES -1
> >> #define ARM_SPE_BAD_PACKET -2
> >> @@ -186,5 +186,6 @@ const char *arm_spe_pkt_name(enum arm_spe_pkt_type);
> >> int arm_spe_get_packet(const unsigned char *buf, size_t len,
> >> struct arm_spe_pkt *packet);
> >>
> >> -int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf, size_t len);
> >> +int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf, size_t len,
> >> + u64 midr);
> >> #endif
> >> diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
> >> index 7447b000f9cd..46f0309c092b 100644
> >> --- a/tools/perf/util/arm-spe.c
> >> +++ b/tools/perf/util/arm-spe.c
> >> @@ -135,7 +135,7 @@ struct data_source_handle {
> >> }
> >>
> >> static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
> >> - unsigned char *buf, size_t len)
> >> + unsigned char *buf, size_t len, u64 midr)
> >> {
> >> struct arm_spe_pkt packet;
> >> size_t pos = 0;
> >> @@ -161,7 +161,7 @@ static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
> >> color_fprintf(stdout, color, " ");
> >> if (ret > 0) {
> >> ret = arm_spe_pkt_desc(&packet, desc,
> >> - ARM_SPE_PKT_DESC_MAX);
> >> + ARM_SPE_PKT_DESC_MAX, midr);
> >> if (!ret)
> >> color_fprintf(stdout, color, " %s\n", desc);
> >> } else {
> >> @@ -174,10 +174,10 @@ static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
> >> }
> >>
> >> static void arm_spe_dump_event(struct arm_spe *spe, unsigned char *buf,
> >> - size_t len)
> >> + size_t len, u64 midr)
> >> {
> >> printf(".\n");
> >> - arm_spe_dump(spe, buf, len);
> >> + arm_spe_dump(spe, buf, len, midr);
> >> }
> >>
> >> static int arm_spe_get_trace(struct arm_spe_buffer *b, void *data)
> >> @@ -1469,8 +1469,11 @@ static int arm_spe_process_auxtrace_event(struct perf_session *session,
> >> /* Dump here now we have copied a piped trace out of the pipe */
> >> if (dump_trace) {
> >> if (auxtrace_buffer__get_data(buffer, fd)) {
> >> + u64 midr = 0;
> >> +
> >> + arm_spe__get_midr(spe, buffer->cpu.cpu, &midr);
> >
> > Sashiko claims to have spotted an issue here:
> > """
> > Is it possible for arm_spe__get_midr() to cause a segmentation fault here?
> >
> > If the trace is from an older recording (metadata version 1) and the
> > environment lacks a CPUID string (such as during cross-architecture
> > analysis), perf_env__cpuid() returns NULL.
> >
> > It appears arm_spe__get_midr() then passes this NULL pointer to
> > strtol(cpuid, NULL, 16), which leads to undefined behavior.
> > """
> >
> > But this feels like, if this happens you're already having a bad time
> > and these changes aren't necessarily making things worse.
> >
> > Thanks,
> > Ian
> >
>
> Yeah I think it might be possible so I can add an error instead of a
> segfault. I'll check the rest of the Sashiko comments too.
>
> >> arm_spe_dump_event(spe, buffer->data,
> >> - buffer->size);
> >> + buffer->size, midr);
> >> auxtrace_buffer__put_data(buffer);
> >> }
> >> }
> >>
> >> --
> >> 2.34.1
> >>
>
^ permalink raw reply
* Re: [PATCH v4 01/27] media: dt-bindings: media: rockchip-rga: add rockchip,rk3588-rga3
From: Rob Herring (Arm) @ 2026-04-07 18:10 UTC (permalink / raw)
To: Sven Püschel
Cc: Jacob Chen, devicetree, sebastian.reichel, Ezequiel Garcia,
Krzysztof Kozlowski, Mauro Carvalho Chehab, Heiko Stuebner,
linux-rockchip, linux-kernel, Conor Dooley, linux-arm-kernel,
kernel, nicolas, linux-media
In-Reply-To: <20260325-spu-rga3-v4-1-e90ec1c61354@pengutronix.de>
On Wed, 25 Mar 2026 15:50:32 +0100, Sven Püschel wrote:
> Add a new compatible for the RGA3 (Raster Graphic Acceleration 3)
> peripheral found on the RK3588 SoC. Also specify an iommu property,
> as the RGA3 contains the generic rockchip iommu. While other versions
> also have an iommu, it's usually specific to them.
>
> The RK3588 contains one RGA2-Enhance core (also contained on the RK3399)
> and two RGA3 cores. Both feature a similar functionality of scaling,
> cropping and rotating of up to two input images into one output image.
> Key differences of the RGA3 are:
>
> - supports 10bit YUV output formats
> - supports 8x8 tiles and FBCD as inputs and outputs
> - supports BT2020 color space conversion
> - max output resolution of (8192-64)x(8192-64)
> - MMU can map up to 32G DDR RAM
> - fully planar formats (3 planes) are not supported
> - max scale up/down factor of 8 (RGA2 allows up to 16)
>
> Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
>
> ---
>
> Changed in v3/v4:
> - Dropped Acked-by: Krzysztof Kozlowski due to the added iommus property
> and description adjustments.
> ---
> Documentation/devicetree/bindings/media/rockchip-rga.yaml | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 6/6] mm: change to return bool for the MMU notifier's young flag check
From: Sean Christopherson @ 2026-04-07 17:52 UTC (permalink / raw)
To: Baolin Wang
Cc: Lorenzo Stoakes (Oracle), akpm, david, Liam.Howlett, vbabka, rppt,
surenb, mhocko, linux-arm-kernel, x86, linux-parisc, linuxppc-dev,
linux-riscv, linux-s390, kvm, open, linux-kernel
In-Reply-To: <2a216ee2-aebb-42ba-b2aa-826488448bbe@linux.alibaba.com>
On Tue, Apr 07, 2026, Baolin Wang wrote:
> On 4/4/26 7:12 AM, Sean Christopherson wrote:
> > On Fri, Mar 20, 2026, Baolin Wang wrote:
> > > > > -static __always_inline int kvm_age_hva_range(struct mmu_notifier *mn,
> > > > > - unsigned long start,
> > > > > - unsigned long end,
> > > > > - gfn_handler_t handler,
> > > > > - bool flush_on_ret)
> > > > > +static __always_inline bool kvm_age_hva_range(struct mmu_notifier *mn,
> > > > > + unsigned long start,
> > > > > + unsigned long end,
> > > > > + gfn_handler_t handler,
> > > > > + bool flush_on_ret)
> > > >
> > > > Can we please fix this terrrible indentation while we're here :)?
> > > >
> > > > static __always_inline bool kvm_age_hva_range(struct mmu_notifier *mn,
> > > > unsigned long start, unsigned long end, gfn_handler_t handler,
> > > > bool flush_on_ret)
> > > >
> > > > Would be nicer, thanks!
> >
> > No, please keep this as-is. KVM's preferred style is exactly this (and I personally
> > find mm's style much harder to parse).
>
> Um, Andrew has already queued v2[1] into the mm-stable branch. Do you want
> me to send a follow-up patch to restore the original KVM coding style?
Nah, not worth the churn. Thanks though!
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: sram: Document Allwinner H616 VE SRAM
From: Rob Herring (Arm) @ 2026-04-07 17:51 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: linux-kernel, linux-arm-kernel, Jernej Skrabec, devicetree,
linux-sunxi, Conor Dooley, Krzysztof Kozlowski, Samuel Holland
In-Reply-To: <20260324164357.1607247-2-wens@kernel.org>
On Wed, 25 Mar 2026 00:43:49 +0800, Chen-Yu Tsai wrote:
> The Allwinner H616 has two switchable peripheral SRAM regions:
>
> - The VE SRAM is a 2 MB dedicated SRAM for the Video Engine. CPU access
> to this region is enabled by default. CPU access can be disabled,
> after which reads will show the same stale value for all addresses,
> while writes are ignored.
>
> The mux value for this region is different from previous generations,
> and thus needs a completely new compatible.
>
> - The SRAM C region is an alias of the first 128 KB of VE SRAM, plus 64
> KB of DE SRAM. The latter is otherwise unaccessible from the CPU. When
> CPU access is disabled, the whole region reads as zero, while writes
> are ignored.
>
> The mux value for this region is the same as on the A64 and H6. The
> existing compatible for the A64 already covers this.
>
> Add the compatible for the VE SRAM to the list of covered compatibles in
> the generic SRAM region binding.
>
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
> ---
> Documentation/devicetree/bindings/sram/sram.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/7] dt-bindings: sram: sunxi-sram: Add H616 SRAM regions
From: Rob Herring (Arm) @ 2026-04-07 17:49 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: linux-kernel, Conor Dooley, Jernej Skrabec, devicetree,
Krzysztof Kozlowski, linux-arm-kernel, Samuel Holland,
linux-sunxi
In-Reply-To: <20260324164357.1607247-3-wens@kernel.org>
On Wed, 25 Mar 2026 00:43:50 +0800, Chen-Yu Tsai wrote:
> The Allwinner H616 has two switchable peripheral SRAM regions:
>
> - The VE SRAM is a 2 MB dedicated SRAM for the Video Engine. CPU access
> to this region is enabled by default. CPU access can be disabled,
> after which reads will show the same stale value for all addresses,
> while writes are ignored.
>
> The mux value for this region is different from previous generations.
>
> - The SRAM C region is an alias of the first 128 KB of VE SRAM, plus 64
> KB of DE SRAM. The latter is otherwise unaccessible from the CPU. When
> CPU access is disabled, the whole region reads as zero, while writes
> are ignored.
>
> The mux value for this region is the same as on the A64 and H6.
>
> Add compatible strings for both of them.
>
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
> ---
> .../bindings/sram/allwinner,sun4i-a10-system-control.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH v2] Bluetooth: Add Broadcom channel priority commands
From: Sasha Finkelstein via B4 Relay @ 2026-04-07 17:46 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, Marcel Holtmann,
Luiz Augusto von Dentz, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: linux-kernel, asahi, linux-arm-kernel, linux-bluetooth, netdev,
Sasha Finkelstein
From: Sasha Finkelstein <fnkl.kernel@gmail.com>
Certain Broadcom bluetooth chips (bcm4377/bcm4378/bcm438) need ACL
streams carrying audio to be set as "high priority" using a vendor
specific command to prevent 10-ish second-long dropouts whenever
something does a device scan. This patch sends the command when the
socket priority is set to TC_PRIO_INTERACTIVE, as BlueZ does for audio.
Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>
---
Changes in v2:
- new ioctl got nack-ed, so let's use sk_priority as the trigger
- Link to v1: https://lore.kernel.org/r/20260407-brcm-prio-v1-1-f38b17376640@gmail.com
---
MAINTAINERS | 2 ++
drivers/bluetooth/hci_bcm4377.c | 2 ++
include/net/bluetooth/bluetooth.h | 4 ++++
include/net/bluetooth/hci_core.h | 11 +++++++++++
net/bluetooth/Kconfig | 7 +++++++
net/bluetooth/Makefile | 1 +
net/bluetooth/brcm.c | 29 +++++++++++++++++++++++++++++
net/bluetooth/brcm.h | 17 +++++++++++++++++
net/bluetooth/hci_conn.c | 28 ++++++++++++++++++++++++++++
net/bluetooth/l2cap_sock.c | 13 +++++++++++++
10 files changed, 114 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c3fe46d7c4bc..81be021367ec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2562,6 +2562,8 @@ F: include/dt-bindings/pinctrl/apple.h
F: include/linux/mfd/macsmc.h
F: include/linux/soc/apple/*
F: include/uapi/drm/asahi_drm.h
+F: net/bluetooth/brcm.c
+F: net/bluetooth/brcm.h
ARM/ARTPEC MACHINE SUPPORT
M: Jesper Nilsson <jesper.nilsson@axis.com>
diff --git a/drivers/bluetooth/hci_bcm4377.c b/drivers/bluetooth/hci_bcm4377.c
index 925d0a635945..5f79920c0306 100644
--- a/drivers/bluetooth/hci_bcm4377.c
+++ b/drivers/bluetooth/hci_bcm4377.c
@@ -2397,6 +2397,8 @@ static int bcm4377_probe(struct pci_dev *pdev, const struct pci_device_id *id)
if (bcm4377->hw->broken_le_ext_adv_report_phy)
hci_set_quirk(hdev, HCI_QUIRK_FIXUP_LE_EXT_ADV_REPORT_PHY);
+ hci_set_brcm_capable(hdev);
+
pci_set_drvdata(pdev, bcm4377);
hci_set_drvdata(hdev, bcm4377);
SET_HCIDEV_DEV(hdev, &pdev->dev);
diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index 69eed69f7f26..07a250673950 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -457,6 +457,7 @@ struct l2cap_ctrl {
};
struct hci_dev;
+struct hci_conn;
typedef void (*hci_req_complete_t)(struct hci_dev *hdev, u8 status, u16 opcode);
typedef void (*hci_req_complete_skb_t)(struct hci_dev *hdev, u8 status,
@@ -469,6 +470,9 @@ void hci_req_cmd_complete(struct hci_dev *hdev, u16 opcode, u8 status,
int hci_ethtool_ts_info(unsigned int index, int sk_proto,
struct kernel_ethtool_ts_info *ts_info);
+int hci_conn_setsockopt(struct hci_conn *conn, struct sock *sk, int level,
+ int optname, sockptr_t optval, unsigned int optlen);
+
#define HCI_REQ_START BIT(0)
#define HCI_REQ_SKB BIT(1)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index a7bffb908c1e..947e7c2b08dd 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -642,6 +642,10 @@ struct hci_dev {
bool aosp_quality_report;
#endif
+#if IS_ENABLED(CONFIG_BT_BRCMEXT)
+ bool brcm_capable;
+#endif
+
int (*open)(struct hci_dev *hdev);
int (*close)(struct hci_dev *hdev);
int (*flush)(struct hci_dev *hdev);
@@ -1791,6 +1795,13 @@ static inline void hci_set_aosp_capable(struct hci_dev *hdev)
#endif
}
+static inline void hci_set_brcm_capable(struct hci_dev *hdev)
+{
+#if IS_ENABLED(CONFIG_BT_BRCMEXT)
+ hdev->brcm_capable = true;
+#endif
+}
+
static inline void hci_devcd_setup(struct hci_dev *hdev)
{
#ifdef CONFIG_DEV_COREDUMP
diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig
index 6b2b65a66700..0f2a5fbcafc5 100644
--- a/net/bluetooth/Kconfig
+++ b/net/bluetooth/Kconfig
@@ -110,6 +110,13 @@ config BT_AOSPEXT
This options enables support for the Android Open Source
Project defined HCI vendor extensions.
+config BT_BRCMEXT
+ bool "Enable Broadcom extensions"
+ depends on BT
+ help
+ This option enables support for the Broadcom defined HCI
+ vendor extensions.
+
config BT_DEBUGFS
bool "Export Bluetooth internals in debugfs"
depends on BT && DEBUG_FS
diff --git a/net/bluetooth/Makefile b/net/bluetooth/Makefile
index a7eede7616d8..b4c9013a46ce 100644
--- a/net/bluetooth/Makefile
+++ b/net/bluetooth/Makefile
@@ -24,5 +24,6 @@ bluetooth-$(CONFIG_BT_LE) += iso.o
bluetooth-$(CONFIG_BT_LEDS) += leds.o
bluetooth-$(CONFIG_BT_MSFTEXT) += msft.o
bluetooth-$(CONFIG_BT_AOSPEXT) += aosp.o
+bluetooth-$(CONFIG_BT_BRCMEXT) += brcm.o
bluetooth-$(CONFIG_BT_DEBUGFS) += hci_debugfs.o
bluetooth-$(CONFIG_BT_SELFTEST) += selftest.o
diff --git a/net/bluetooth/brcm.c b/net/bluetooth/brcm.c
new file mode 100644
index 000000000000..9aa0a265ab3d
--- /dev/null
+++ b/net/bluetooth/brcm.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026 The Asahi Linux Contributors
+ */
+
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+
+#include "brcm.h"
+
+int brcm_set_high_priority(struct hci_dev *hdev, u16 handle, bool enable)
+{
+ struct sk_buff *skb;
+ u8 cmd[3];
+
+ if (!hdev->brcm_capable)
+ return 0;
+
+ cmd[0] = handle;
+ cmd[1] = handle >> 8;
+ cmd[2] = !!enable;
+
+ skb = hci_cmd_sync(hdev, 0xfc57, sizeof(cmd), cmd, HCI_CMD_TIMEOUT);
+ if (IS_ERR(skb))
+ return PTR_ERR(skb);
+
+ kfree_skb(skb);
+ return 0;
+}
diff --git a/net/bluetooth/brcm.h b/net/bluetooth/brcm.h
new file mode 100644
index 000000000000..fdaee63bd1d2
--- /dev/null
+++ b/net/bluetooth/brcm.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2026 The Asahi Linux Contributors
+ */
+
+#if IS_ENABLED(CONFIG_BT_BRCMEXT)
+
+int brcm_set_high_priority(struct hci_dev *hdev, u16 handle, bool enable);
+
+#else
+
+static inline int brcm_set_high_priority(struct hci_dev *hdev, u16 handle, bool enable)
+{
+ return 0;
+}
+
+#endif
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 11d3ad8d2551..096163840f62 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -35,6 +35,7 @@
#include <net/bluetooth/iso.h>
#include <net/bluetooth/mgmt.h>
+#include "brcm.h"
#include "smp.h"
#include "eir.h"
@@ -3070,6 +3071,33 @@ int hci_conn_set_phy(struct hci_conn *conn, u32 phys)
}
}
+int hci_conn_setsockopt(struct hci_conn *conn, struct sock *sk, int level,
+ int optname, sockptr_t optval, unsigned int optlen)
+{
+ int val;
+ bool old_high, new_high, changed;
+
+ if (level != SOL_SOCKET)
+ return 0;
+
+ if (optname != SO_PRIORITY)
+ return 0;
+
+ if (optlen < sizeof(int))
+ return -EINVAL;
+
+ if (copy_from_sockptr(&val, optval, sizeof(val)))
+ return -EFAULT;
+
+ old_high = sk->sk_priority >= TC_PRIO_INTERACTIVE;
+ new_high = val >= TC_PRIO_INTERACTIVE;
+ changed = old_high != new_high;
+ if (!changed)
+ return 0;
+
+ return brcm_set_high_priority(conn->hdev, conn->handle, new_high);
+}
+
static int abort_conn_sync(struct hci_dev *hdev, void *data)
{
struct hci_conn *conn = data;
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 71e8c1b45bce..d5eef87accc4 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -891,6 +891,16 @@ static int l2cap_sock_setsockopt(struct socket *sock, int level, int optname,
BT_DBG("sk %p", sk);
+ if (level == SOL_SOCKET) {
+ conn = chan->conn;
+ if (conn)
+ err = hci_conn_setsockopt(conn->hcon, sock->sk, level,
+ optname, optval, optlen);
+ if (err)
+ return err;
+ return sock_setsockopt(sock, level, optname, optval, optlen);
+ }
+
if (level == SOL_L2CAP)
return l2cap_sock_setsockopt_old(sock, optname, optval, optlen);
@@ -1931,6 +1941,9 @@ static struct sock *l2cap_sock_alloc(struct net *net, struct socket *sock,
INIT_LIST_HEAD(&l2cap_pi(sk)->rx_busy);
+ if (sock)
+ set_bit(SOCK_CUSTOM_SOCKOPT, &sock->flags);
+
chan = l2cap_chan_create();
if (!chan) {
sk_free(sk);
---
base-commit: bfe62a454542cfad3379f6ef5680b125f41e20f4
change-id: 20260407-brcm-prio-b630e6cc3834
Best regards,
--
Sasha Finkelstein <fnkl.kernel@gmail.com>
^ permalink raw reply related
* Re: [PATCH v0 06/15] mshv: Implement mshv bridge device for VFIO
From: Mukesh R @ 2026-04-07 17:41 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: linux-kernel, linux-hyperv, linux-arm-kernel, iommu, linux-pci,
linux-arch, kys, haiyangz, wei.liu, decui, longli,
catalin.marinas, will, tglx, mingo, bp, dave.hansen, hpa, joro,
lpieralisi, kwilczynski, mani, robh, bhelgaas, arnd, nunodasneves,
mhklinux, romank
In-Reply-To: <aW-oniY3VpagQMPb@skinsburskii.localdomain>
On 1/20/26 08:09, Stanislav Kinsburskii wrote:
> On Mon, Jan 19, 2026 at 10:42:21PM -0800, Mukesh R wrote:
>> From: Mukesh Rathor <mrathor@linux.microsoft.com>
>>
>> Add a new file to implement VFIO-MSHV bridge pseudo device. These
>> functions are called in the VFIO framework, and credits to kvm/vfio.c
>> as this file was adapted from it.
>>
>> Original author: Wei Liu <wei.liu@kernel.org>
>> (Slightly modified from the original version).
>>
>
> There is a Linux standard for giving credits when code is adapted from.
> This doesn't follow that standard. Please fix.
>
>> Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
>> ---
>> drivers/hv/Makefile | 3 +-
>> drivers/hv/mshv_vfio.c | 210 +++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 212 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/hv/mshv_vfio.c
>>
>> diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
>> index a49f93c2d245..eae003c4cb8f 100644
>> --- a/drivers/hv/Makefile
>> +++ b/drivers/hv/Makefile
>> @@ -14,7 +14,8 @@ hv_vmbus-y := vmbus_drv.o \
>> hv_vmbus-$(CONFIG_HYPERV_TESTING) += hv_debugfs.o
>> hv_utils-y := hv_util.o hv_kvp.o hv_snapshot.o hv_utils_transport.o
>> mshv_root-y := mshv_root_main.o mshv_synic.o mshv_eventfd.o mshv_irq.o \
>> - mshv_root_hv_call.o mshv_portid_table.o mshv_regions.o
>> + mshv_root_hv_call.o mshv_portid_table.o mshv_regions.o \
>> + mshv_vfio.o
>> mshv_vtl-y := mshv_vtl_main.o
>>
>> # Code that must be built-in
>> diff --git a/drivers/hv/mshv_vfio.c b/drivers/hv/mshv_vfio.c
>> new file mode 100644
>> index 000000000000..6ea4d99a3bd2
>> --- /dev/null
>> +++ b/drivers/hv/mshv_vfio.c
>> @@ -0,0 +1,210 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * VFIO-MSHV bridge pseudo device
>> + *
>> + * Heavily inspired by the VFIO-KVM bridge pseudo device.
>> + */
>> +#include <linux/errno.h>
>> +#include <linux/file.h>
>> +#include <linux/list.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/slab.h>
>> +#include <linux/vfio.h>
>> +
>> +#include "mshv.h"
>> +#include "mshv_root.h"
>> +
>> +struct mshv_vfio_file {
>> + struct list_head node;
>> + struct file *file; /* list of struct mshv_vfio_file */
>> +};
>> +
>> +struct mshv_vfio {
>> + struct list_head file_list;
>> + struct mutex lock;
>> +};
>> +
>> +static bool mshv_vfio_file_is_valid(struct file *file)
>> +{
>> + bool (*fn)(struct file *file);
>> + bool ret;
>> +
>> + fn = symbol_get(vfio_file_is_valid);
>> + if (!fn)
>> + return false;
>> +
>> + ret = fn(file);
>> +
>> + symbol_put(vfio_file_is_valid);
>> +
>> + return ret;
>> +}
>> +
>> +static long mshv_vfio_file_add(struct mshv_device *mshvdev, unsigned int fd)
>> +{
>> + struct mshv_vfio *mshv_vfio = mshvdev->device_private;
>> + struct mshv_vfio_file *mvf;
>> + struct file *filp;
>> + long ret = 0;
>> +
>> + filp = fget(fd);
>> + if (!filp)
>> + return -EBADF;
>> +
>> + /* Ensure the FD is a vfio FD. */
>> + if (!mshv_vfio_file_is_valid(filp)) {
>> + ret = -EINVAL;
>> + goto out_fput;
>> + }
>> +
>> + mutex_lock(&mshv_vfio->lock);
>> +
>> + list_for_each_entry(mvf, &mshv_vfio->file_list, node) {
>> + if (mvf->file == filp) {
>> + ret = -EEXIST;
>> + goto out_unlock;
>> + }
>> + }
>> +
>> + mvf = kzalloc(sizeof(*mvf), GFP_KERNEL_ACCOUNT);
>> + if (!mvf) {
>> + ret = -ENOMEM;
>> + goto out_unlock;
>> + }
>> +
>> + mvf->file = get_file(filp);
>> + list_add_tail(&mvf->node, &mshv_vfio->file_list);
>> +
>> +out_unlock:
>> + mutex_unlock(&mshv_vfio->lock);
>> +out_fput:
>> + fput(filp);
>> + return ret;
>> +}
>> +
>> +static long mshv_vfio_file_del(struct mshv_device *mshvdev, unsigned int fd)
>> +{
>> + struct mshv_vfio *mshv_vfio = mshvdev->device_private;
>> + struct mshv_vfio_file *mvf;
>> + long ret;
>> +
>> + CLASS(fd, f)(fd);
>> +
>> + if (fd_empty(f))
>> + return -EBADF;
>> +
>> + ret = -ENOENT;
>> + mutex_lock(&mshv_vfio->lock);
>> +
>> + list_for_each_entry(mvf, &mshv_vfio->file_list, node) {
>> + if (mvf->file != fd_file(f))
>> + continue;
>> +
>> + list_del(&mvf->node);
>> + fput(mvf->file);
>> + kfree(mvf);
>> + ret = 0;
>> + break;
>> + }
>> +
>> + mutex_unlock(&mshv_vfio->lock);
>> + return ret;
>> +}
>> +
>> +static long mshv_vfio_set_file(struct mshv_device *mshvdev, long attr,
>> + void __user *arg)
>> +{
>> + int32_t __user *argp = arg;
>> + int32_t fd;
>> +
>> + switch (attr) {
>> + case MSHV_DEV_VFIO_FILE_ADD:
>> + if (get_user(fd, argp))
>> + return -EFAULT;
>> + return mshv_vfio_file_add(mshvdev, fd);
>> +
>> + case MSHV_DEV_VFIO_FILE_DEL:
>> + if (get_user(fd, argp))
>> + return -EFAULT;
>> + return mshv_vfio_file_del(mshvdev, fd);
>> + }
>> +
>> + return -ENXIO;
>> +}
>> +
>> +static long mshv_vfio_set_attr(struct mshv_device *mshvdev,
>> + struct mshv_device_attr *attr)
>> +{
>> + switch (attr->group) {
>> + case MSHV_DEV_VFIO_FILE:
>> + return mshv_vfio_set_file(mshvdev, attr->attr,
>> + u64_to_user_ptr(attr->addr));
>> + }
>> +
>> + return -ENXIO;
>> +}
>> +
>> +static long mshv_vfio_has_attr(struct mshv_device *mshvdev,
>> + struct mshv_device_attr *attr)
>> +{
>> + switch (attr->group) {
>> + case MSHV_DEV_VFIO_FILE:
>> + switch (attr->attr) {
>> + case MSHV_DEV_VFIO_FILE_ADD:
>> + case MSHV_DEV_VFIO_FILE_DEL:
>> + return 0;
>> + }
>> +
>> + break;
>> + }
>> +
>> + return -ENXIO;
>> +}
>> +
>> +static long mshv_vfio_create_device(struct mshv_device *mshvdev, u32 type)
>> +{
>> + struct mshv_device *tmp;
>> + struct mshv_vfio *mshv_vfio;
>> +
>> + /* Only one VFIO "device" per VM */
>> + hlist_for_each_entry(tmp, &mshvdev->device_pt->pt_devices,
>> + device_ptnode)
>> + if (tmp->device_ops == &mshv_vfio_device_ops)
>> + return -EBUSY;
>> +
>> + mshv_vfio = kzalloc(sizeof(*mshv_vfio), GFP_KERNEL_ACCOUNT);
>> + if (mshv_vfio == NULL)
>> + return -ENOMEM;
>> +
>> + INIT_LIST_HEAD(&mshv_vfio->file_list);
>> + mutex_init(&mshv_vfio->lock);
>> +
>> + mshvdev->device_private = mshv_vfio;
>> +
>> + return 0;
>> +}
>> +
>> +/* This is called from mshv_device_fop_release() */
>> +static void mshv_vfio_release_device(struct mshv_device *mshvdev)
>> +{
>> + struct mshv_vfio *mv = mshvdev->device_private;
>> + struct mshv_vfio_file *mvf, *tmp;
>> +
>> + list_for_each_entry_safe(mvf, tmp, &mv->file_list, node) {
>> + fput(mvf->file);
>
> This put must be sync as device must be detached from domain before
> attempting partition destruction.
Like I said in 6.6 PR, this does not attach or detach devices.
> This was explicitly mentioned in the patch originated this code.
> Please fix, add a comment and credits to the commit message.
That was ".detstroy" hook which is gone.
Thanks,
-Mukesh
> Thanks,
> Stanislav
>
>
>> + list_del(&mvf->node);
>> + kfree(mvf);
>> + }
>> +
>> + kfree(mv);
>> + kfree(mshvdev);
>> +}
>> +
>> +struct mshv_device_ops mshv_vfio_device_ops = {
>> + .device_name = "mshv-vfio",
>> + .device_create = mshv_vfio_create_device,
>> + .device_release = mshv_vfio_release_device,
>> + .device_set_attr = mshv_vfio_set_attr,
>> + .device_has_attr = mshv_vfio_has_attr,
>> +};
>> --
>> 2.51.2.vfs.0.1
>>
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Catalin Marinas @ 2026-04-07 17:37 UTC (permalink / raw)
To: Ryan Roberts
Cc: Will Deacon, David Hildenbrand (Arm), Dev Jain, Yang Shi,
Suzuki K Poulose, Jinjiang Tu, Kevin Brodsky, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <b545e650-f84f-4911-9902-b914870f0e1d@arm.com>
On Tue, Apr 07, 2026 at 02:06:10PM +0100, Ryan Roberts wrote:
> On 07/04/2026 11:52, Catalin Marinas wrote:
> > As the name implies, linear_map_requires_bbml2 tracks only this -
> > BBML2_NOABORT is required because the linear map uses large blocks.
> > Prior to your patches, that's only used as far as
> > linear_map_maybe_split_to_ptes() and if splitting took place, this
> > variable is no longer relevant (should be turned to false but since it's
> > not used, it doesn't matter).
> >
> > With your patches, its use was extended to runtime and I think it
> > remains true even if linear_map_maybe_split_to_ptes() changed the block
> > mappings. Do we need this:
>
> I'll admit it is ugly but it's not a bug; the system capabilitites are finalized
> by the time we call linear_map_maybe_split_to_ptes().
>
> The "if (!linear_map_requires_bbml2 || is_kfence_address((void *)start))" check
> in split_kernel_leaf_mapping() would ideally be "if (!force_pte_mapping() ||
> is_kfence_address((void *)start))", but it is not safe to call
> force_pte_mapping() from a secondary cpu prior to finalizing the system caps.
> I'm reusing the flag that I already had available to work around that.
The confusing part is that the flag may be false incorrectly due to the
is_realm_world() evaluation. Nothing to do with this patch though and
the subject even mentions the rodata=full case. We should fix it
separately.
We could have set the flag to zero in linear_map_maybe_split_to_ptes(),
though split_kernel_leaf_mapping() already exits early due to the
!system_supports_bbml2_noabort() && system_capabilities_finalized(), so
not a correctness issue.
> But regardless, I think we are talking about the pre-existing
> is_real_world() bug, so I'm not personally planning to do anything further here
> unless you shout.
Not for this series. Steven or Suzuki should address the other problem
with is_realm_world().
--
Catalin
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Catalin Marinas @ 2026-04-07 17:21 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Ryan Roberts, Will Deacon, David Hildenbrand (Arm), Dev Jain,
Yang Shi, Jinjiang Tu, Kevin Brodsky, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <1db93bd3-cb47-445b-b8ca-6de6f04b41cc@arm.com>
On Tue, Apr 07, 2026 at 10:57:35AM +0100, Suzuki K Poulose wrote:
> On 02/04/2026 21:43, Catalin Marinas wrote:
> > On Mon, Mar 30, 2026 at 05:17:02PM +0100, Ryan Roberts wrote:
> > > int split_kernel_leaf_mapping(unsigned long start, unsigned long end)
> > > {
> > > int ret;
> > > - /*
> > > - * !BBML2_NOABORT systems should not be trying to change permissions on
> > > - * anything that is not pte-mapped in the first place. Just return early
> > > - * and let the permission change code raise a warning if not already
> > > - * pte-mapped.
> > > - */
> > > - if (!system_supports_bbml2_noabort())
> > > - return 0;
> > > -
> > > /*
> > > * If the region is within a pte-mapped area, there is no need to try to
> > > * split. Additionally, CONFIG_DEBUG_PAGEALLOC and CONFIG_KFENCE may
> > > * change permissions from atomic context so for those cases (which are
> > > * always pte-mapped), we must not go any further because taking the
> > > - * mutex below may sleep.
> > > + * mutex below may sleep. Do not call force_pte_mapping() here because
> > > + * it could return a confusing result if called from a secondary cpu
> > > + * prior to finalizing caps. Instead, linear_map_requires_bbml2 gives us
> > > + * what we need.
> > > */
> > > - if (force_pte_mapping() || is_kfence_address((void *)start))
> > > + if (!linear_map_requires_bbml2 || is_kfence_address((void *)start))
> > > return 0;
> > > + if (!system_supports_bbml2_noabort()) {
> > > + /*
> > > + * !BBML2_NOABORT systems should not be trying to change
> > > + * permissions on anything that is not pte-mapped in the first
> > > + * place. Just return early and let the permission change code
> > > + * raise a warning if not already pte-mapped.
> > > + */
> > > + if (system_capabilities_finalized())
> > > + return 0;
> > > +
> > > + /*
> > > + * Boot-time: split_kernel_leaf_mapping_locked() allocates from
> > > + * page allocator. Can't split until it's available.
> > > + */
> > > + if (WARN_ON(!page_alloc_available))
> > > + return -EBUSY;
> > > +
> > > + /*
> > > + * Boot-time: Started secondary cpus but don't know if they
> > > + * support BBML2_NOABORT yet. Can't allow splitting in this
> > > + * window in case they don't.
> > > + */
> > > + if (WARN_ON(num_online_cpus() > 1))
> > > + return -EBUSY;
> > > + }
> >
> > I think sashiko is over cautions here
> > (https://sashiko.dev/#/patchset/20260330161705.3349825-1-ryan.roberts@arm.com)
> > but it has a somewhat valid point from the perspective of
> > num_online_cpus() semantics. We have have num_online_cpus() == 1 while
> > having a secondary CPU just booted and with its MMU enabled. I don't
> > think we can have any asynchronous tasks running at that point to
> > trigger a spit though. Even async_init() is called after smp_init().
> >
> > An option may be to attempt cpus_read_trylock() as this lock is taken by
> > _cpu_up(). If it fails, return -EBUSY, otherwise check num_online_cpus()
> > and unlock (and return -EBUSY if secondaries already started).
> >
> > Another thing I couldn't get my head around - IIUC is_realm_world()
> > won't return true for map_mem() yet (if in a realm).
>
> That is correct. map_mem() comes from paginig_init(), which gets called
> before arm64_rsi_init(). Realm check was delayed until psci_xx_init().
> We had a version which parsed the DT for PSCI conduit early enough
> to be able to make the SMC calls to detect the Realm. But there
> were concerns around it.
Ah, yes, I remember.
Does it mean that commit 42be24a4178f ("arm64: Enable memory encrypt for
Realms") was broken without rodata=full w.r.t. the linear map? Commit
a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full")
introduced force_pte_mapping() but it just copied the logic in the
existing can_set_direct_map(). Looking at the linear_map_requires_bbml2
assignment, we get (!is_realm_world() && is_realm_world()) and it
cancels out, no effect on it but we don't get pte mappings either (even
if we don't have BBML2).
I think we need at least some safety checks:
1. BBML2_NOABORT support on the boot CPU - continue with the existing
logic (as per Ryan's series)
2. !system_supports_bbml2_noabort() - split in
linear_map_maybe_split_to_ptes(). This does not currently happen
because linear_map_requires_bbml2 may be false in the absence of
rodata=full. Not sure how to fix this without some variable telling
us how the linear map was mapped. The requires_bbml2 flag doesn't
3. Panic in arm64_rsi_init() if !BBML2_NOABORT on the boot CPU _and_ we
have block mappings already. People can avoid it with rodata=full
4. If (3) is a common case, a better alternative is to rewrite the
linear map sometime after arm64_rsi_init() but before we call
split_kernel_leaf_mapping().
--
Catalin
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: dma: arm-dma350: document combined and per-channel IRQ topologies
From: Rob Herring @ 2026-04-07 17:20 UTC (permalink / raw)
To: Jun Guo
Cc: peter.chen, fugang.duan, krzk+dt, conor+dt, vkoul, ychuang3,
schung, robin.murphy, Frank.Li, dmaengine, devicetree,
linux-kernel, cix-kernel-upstream, linux-arm-kernel
In-Reply-To: <20260324120113.3681830-2-jun.guo@cixtech.com>
On Tue, Mar 24, 2026 at 08:01:11PM +0800, Jun Guo wrote:
> Document the interrupt topologies supported by DMA-350 integration:
> - one combined interrupt for all channels, or
> - one interrupt per channel (up to 8 channels).
>
> Assisted-by: Cursor:GPT-5.3-Codex
> Signed-off-by: Jun Guo <jun.guo@cixtech.com>
> ---
> .../devicetree/bindings/dma/arm,dma-350.yaml | 25 ++++++++++++-------
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
> index 429f682f15d8..bec9dc32541b 100644
> --- a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
> +++ b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
> @@ -22,15 +22,22 @@ properties:
>
> interrupts:
> minItems: 1
> - items:
> - - description: Channel 0 interrupt
> - - description: Channel 1 interrupt
> - - description: Channel 2 interrupt
> - - description: Channel 3 interrupt
> - - description: Channel 4 interrupt
> - - description: Channel 5 interrupt
> - - description: Channel 6 interrupt
> - - description: Channel 7 interrupt
> + maxItems: 8
Don't need maxItems
> + description:
> + Either one interrupt per channel (8 interrupts), or one
> + combined interrupt for all channels.
> + oneOf:
> + - items:
> + - description: Channel 0 interrupt
> + - description: Channel 1 interrupt
> + - description: Channel 2 interrupt
> + - description: Channel 3 interrupt
> + - description: Channel 4 interrupt
> + - description: Channel 5 interrupt
> + - description: Channel 6 interrupt
> + - description: Channel 7 interrupt
> + - items:
> + - description: Combined interrupt shared by all channels
>
> "#dma-cells":
> const: 1
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm-smmu: qcom: Add compatible for Hawi SoC
From: Will Deacon @ 2026-04-07 17:03 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Robin Murphy, Mukesh Ojha
Cc: catalin.marinas, kernel-team, Will Deacon, Robin Murphy,
linux-arm-kernel, iommu, devicetree, linux-kernel
In-Reply-To: <20260403080956.2714415-1-mukesh.ojha@oss.qualcomm.com>
On Fri, 03 Apr 2026 13:39:56 +0530, Mukesh Ojha wrote:
> Qualcomm Hawi SoC include apps smmu that implements arm,mmu-500, which
> is used to translate device-visible virtual addresses to physical
> addresses. Add compatible for these items.
>
>
Applied to iommu (arm/smmu/bindings), thanks!
[1/1] dt-bindings: arm-smmu: qcom: Add compatible for Hawi SoC
https://git.kernel.org/iommu/c/5e8323c3d528
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH V2] spi: zynq-qspi: Simplify clock handling with devm_clk_get_enabled()
From: Mark Brown @ 2026-04-07 11:53 UTC (permalink / raw)
To: michal.simek, linux-spi, linux-kernel, linux-arm-kernel, Pei Xiao
In-Reply-To: <24043625f89376da36feca2408f990a85be7ab36.1775555500.git.xiaopei01@kylinos.cn>
On Tue, 07 Apr 2026 17:55:08 +0800, Pei Xiao wrote:
> spi: zynq-qspi: Simplify clock handling with devm_clk_get_enabled()
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.0
Thanks!
[1/1] spi: zynq-qspi: Simplify clock handling with devm_clk_get_enabled()
https://git.kernel.org/broonie/spi/c/1f8fd9490e31
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH] spi: uniphier: Simplify clock handling with devm_clk_get_enabled()
From: Mark Brown @ 2026-04-07 12:12 UTC (permalink / raw)
To: hayashi.kunihiko, mhiramat, linux-spi, linux-arm-kernel,
linux-kernel, Pei Xiao
In-Reply-To: <b2deeefd4ef1a4bce71116aabfcb7e81400f6d37.1775546948.git.xiaopei01@kylinos.cn>
On Tue, 07 Apr 2026 15:30:28 +0800, Pei Xiao wrote:
> spi: uniphier: Simplify clock handling with devm_clk_get_enabled()
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.1
Thanks!
[1/1] spi: uniphier: Simplify clock handling with devm_clk_get_enabled()
https://git.kernel.org/broonie/sound/c/fdca270f8f87
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v6 2/3] dt-bindings: hwmon: emc2305: Add fan-shutdown-percent property
From: Conor Dooley @ 2026-04-07 16:20 UTC (permalink / raw)
To: florin.leotescu
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Michael Shych, linux-hwmon, devicetree, linux-kernel,
daniel.baluta, viorel.suman, linux-arm-kernel, imx, festevam,
Florin Leotescu
In-Reply-To: <20260402122514.1811737-3-florin.leotescu@oss.nxp.com>
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
On Thu, Apr 02, 2026 at 03:25:13PM +0300, florin.leotescu@oss.nxp.com wrote:
> From: Florin Leotescu <florin.leotescu@nxp.com>
>
> The EMC2305 fan controller supports multiple independent PWM fan
> outputs. Some systems require fans to enter a defined safe state
> during system shutdown or reboot handoff, until firmware or the next
> boot stage reconfigures the controller.
>
> Add an optional "fan-shutdown-percent" property to fan child nodes
> allowing the PWM duty cycle applied during shutdown to be configured
> per fan output.
>
> Signed-off-by: Florin Leotescu <florin.leotescu@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] dt-bindings: pinctrl: sun55i-a523: increase IRQ bank number
From: Rob Herring (Arm) @ 2026-04-07 16:14 UTC (permalink / raw)
To: Andre Przywara
Cc: linux-sunxi, Chen-Yu Tsai, linux-arm-kernel, Linus Walleij,
Krzysztof Kozlowski, Michal Piekos, linux-gpio, linux-kernel,
Samuel Holland, Conor Dooley, devicetree, Jernej Skrabec
In-Reply-To: <20260323110151.2352832-4-andre.przywara@arm.com>
On Mon, 23 Mar 2026 12:01:49 +0100, Andre Przywara wrote:
> The Allwinner A523 SoC implements 10 GPIO banks in the first pinctrl
> instance, but it skips the first bank (PortA), so their index goes from
> 1 to 10. The same is actually true for the IRQ banks: there are registers
> for 11 banks, though the first bank is not implemented (RAZ/WI).
> In contrast to previous SoCs, the count of the IRQ banks starts with this
> first unimplemented bank, so we need to provide an interrupt for it.
> And indeed the A523 user manual lists an interrupt number for PortA, so we
> need to increase the maximum number of interrupts per pin controller to 11,
> to be able to assign the correct interrupt number for each bank.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> .../bindings/pinctrl/allwinner,sun55i-a523-pinctrl.yaml | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 8/9] dt-bindings: arm: apple: Add M3 based devices
From: Rob Herring (Arm) @ 2026-04-07 16:10 UTC (permalink / raw)
To: Janne Grunau
Cc: devicetree, Lorenzo Pieralisi, Wim Van Sebroeck, linux-watchdog,
linux-arm-kernel, linux-kernel, asahi, Guenter Roeck, Neal Gompa,
Andi Shyti, linux-gpio, Conor Dooley, Mark Kettenis,
Sasha Finkelstein, Uwe Kleine-König, Sven Peter,
Linus Walleij, Krzysztof Kozlowski, linux-i2c, linux-pwm
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-8-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:26 +0100, Janne Grunau wrote:
> The Apple devices with the t8122 SoC (M3) are very similar to their M1
> and M2 predecessors.
> Only the 13-inch Macbook Pro is replaced by a 14-inch version based on
> the design of the 14-inch Macbook Pro with (M1/M2 Pro/Max). The Mac mini
> was not offered with M3.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/arm/apple.yaml | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 7/9] dt-bindings: pwm: apple,s5l-fpwm: Add t8122 compatible
From: Rob Herring (Arm) @ 2026-04-07 16:09 UTC (permalink / raw)
To: Janne Grunau
Cc: Neal Gompa, linux-arm-kernel, linux-gpio, linux-i2c,
Uwe Kleine-König, Wim Van Sebroeck, linux-watchdog,
devicetree, Guenter Roeck, Krzysztof Kozlowski, Sven Peter,
Sasha Finkelstein, Lorenzo Pieralisi, Andi Shyti, Mark Kettenis,
Linus Walleij, linux-pwm, linux-kernel, asahi, Conor Dooley
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-7-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:25 +0100, Janne Grunau wrote:
> The PWM controller on the Apple silicon t8122 (M3) SoC is compatible
> with the existing driver. Add "apple,t8122-fpwm" as SoC specific
> compatible under "apple,s5l-fpwm" used by the driver.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 5/9] dt-bindings: pinctrl: apple,pinctrl: Add t8122 compatible
From: Rob Herring (Arm) @ 2026-04-07 16:08 UTC (permalink / raw)
To: Janne Grunau
Cc: Uwe Kleine-König, Lorenzo Pieralisi, Sven Peter, devicetree,
Andi Shyti, asahi, Guenter Roeck, Krzysztof Kozlowski,
Wim Van Sebroeck, linux-i2c, linux-pwm, Mark Kettenis,
linux-kernel, Linus Walleij, linux-watchdog, Sasha Finkelstein,
Conor Dooley, linux-gpio, Neal Gompa, linux-arm-kernel
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-5-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:23 +0100, Janne Grunau wrote:
> The pin controller on the Apple silicon t8122 (M3) SoC is compatible
> with the existing driver. Add "apple,t8122-pinctrl" as SoC specific
> compatible under "apple,t8103-pinctrl" used by the driver.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 6/9] dt-bindings: i2c: apple,i2c: Add t8122 compatible
From: Rob Herring (Arm) @ 2026-04-07 16:08 UTC (permalink / raw)
To: Janne Grunau
Cc: Andi Shyti, Wim Van Sebroeck, Sven Peter, linux-watchdog,
linux-kernel, Sasha Finkelstein, devicetree, Neal Gompa, asahi,
Mark Kettenis, linux-pwm, Guenter Roeck, Krzysztof Kozlowski,
linux-arm-kernel, linux-i2c, linux-gpio, Uwe Kleine-König,
Conor Dooley, Lorenzo Pieralisi, Linus Walleij
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-6-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:24 +0100, Janne Grunau wrote:
> The i2c block on the Apple silicon t8122 (M3) SoC is compatible with the
> existing driver. Add "apple,t8122-i2c" as SoC specific compatible under
> "apple,t8103-i2c" used by the deriver.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/i2c/apple,i2c.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/9] dt-bindings: power: apple,pmgr-pwrstate: Add t8122 compatible
From: Rob Herring (Arm) @ 2026-04-07 16:08 UTC (permalink / raw)
To: Janne Grunau
Cc: devicetree, linux-arm-kernel, linux-i2c, Conor Dooley, Sven Peter,
Wim Van Sebroeck, Uwe Kleine-König, Mark Kettenis,
Andi Shyti, linux-kernel, Krzysztof Kozlowski, Neal Gompa,
Sasha Finkelstein, linux-gpio, linux-pwm, Guenter Roeck,
Linus Walleij, asahi, linux-watchdog, Lorenzo Pieralisi
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-3-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:21 +0100, Janne Grunau wrote:
> The device power state management of the PMGR blocks on Apple's t8122
> SoC (M3) is compatible with the existing driver.
> Add "apple,t8122-pmgr-pwrstate" as SoC specific compatible under the
> existing "apple,t8103-pmgr-pwrstate" used by the driver.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 4/9] dt-bindings: watchdog: apple,wdt: Add t8122 compatible
From: Rob Herring (Arm) @ 2026-04-07 16:07 UTC (permalink / raw)
To: Janne Grunau
Cc: Neal Gompa, linux-i2c, Linus Walleij, Uwe Kleine-König,
Mark Kettenis, Krzysztof Kozlowski, linux-kernel, Guenter Roeck,
devicetree, Sasha Finkelstein, Wim Van Sebroeck, linux-pwm,
linux-arm-kernel, Sven Peter, asahi, Conor Dooley, linux-gpio,
linux-watchdog, Andi Shyti, Lorenzo Pieralisi
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-4-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:22 +0100, Janne Grunau wrote:
> The watchdog on the Apple silicon t8122 (M3) SoC is compatible with the
> existing driver. Add "apple,t8122-wdt" as SoC specific compatible under
> "apple,t8103-wdt" used by the driver.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/watchdog/apple,wdt.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: imx8mm: imx8mp: Add DTOs for Data Modul i.MX8M Mini and Plus eDM SBC
From: Marek Vasut @ 2026-04-07 16:07 UTC (permalink / raw)
To: Frank Li
Cc: linux-arm-kernel, Conor Dooley, Fabio Estevam,
Krzysztof Kozlowski, Pengutronix Kernel Team, Rob Herring,
Sascha Hauer, devicetree, imx, linux-kernel
In-Reply-To: <adRhN_DDthCDHymn@lizhi-Precision-Tower-5810>
On 4/7/26 3:58 AM, Frank Li wrote:
> On Mon, Apr 06, 2026 at 11:58:45PM +0200, Marek Vasut wrote:
>> Add DT overlay for feature connector expansion module eDM-MOD-iMX8Mm-FIO1
>> providing additional UARTs, CAN, PWM Beeper, I2C, SPI and GPIO breakout.
>> This adapter can be optionally populated onto the eDM SBC.
>>
>> Add DT overlay for the DSI-to-HDMI adapter eDM-MOD-iMX8Mm-HDMI populated
>> with Lontium LT9611 bridge. This adapter can be optionally populated onto
>> the eDM SBC.
>>
>> Add DT overlay for the DSI-to-LVDS adapter eDM-MOD-iMX8Mm-LVDS populated
>> with Lontium LT9211 bridge. This adapter can be optionally populated onto
>> the eDM SBC. This adapter can be extended with multiple panels, currently
>> supported are the following:
>
> At least you can split to 3 patches to add these.
I did now, will send V3 patchset as 6 patches, but it won't help much
because most of the stuff is DSI-to-LVDS .
>> +#include "imx8mm-pinfunc.h"
>> +#include "imx8mm-data-modul-edm-sbc-overlay-edm-mod-imx8mm-fio1-audio.dtsi"
>> +
>> +&can_fio {
>> + interrupts-extended = <&gpio4 25 IRQ_TYPE_LEVEL_LOW>;
>
> Now, I have not good ways to unify this information for difference boards
> yet. It is quite common user case, let me think more.
It is a different interrupt line on these two boards.
>> +};
>> +
>> +&iomuxc {
>> + pinctrl_codec_mclk: codec-mclk_feature-grp {
>> + fsl,pins = <
>> + /* GPIO4_IO27 */
>> + MX8MM_IOMUXC_SAI2_MCLK_SAI5_MCLK 0x2
>> + >;
>> + };
>> +
>> + pinctrl_sai2: sai2_feature-grp {
>> + fsl,pins = <
>> + MX8MM_IOMUXC_SAI2_RXC_SAI2_RX_BCLK 0x90
>> + MX8MM_IOMUXC_SAI2_TXD0_SAI2_TX_DATA0 0x96
>> + MX8MM_IOMUXC_SAI2_RXD0_SAI2_RX_DATA0 0x90
>> + MX8MM_IOMUXC_SAI2_TXFS_SAI2_TX_SYNC 0x96
>> + >;
>> + };
>
> I think this part should be in main boards's dts file, there should have
> hardware plug header, which include these signals.
>
> If there are other added on boards, add-on dtso can resuse the label,
> pinctrl_sai2 and pinctrl_codec_mclk.
No, not really, the audio-board is a bit of an outlier so I would prefer
to keep the audio-board specific changes in the audio-board DTO instead
of polluting the base DT with its specifics.
>> +};
>> +
>> +&pinctrl_hog_feature {
>> + fsl,pins = <
>> + /* GPIO5_IO03 */
>> + MX8MM_IOMUXC_SPDIF_TX_GPIO5_IO3 0x40000006
>> + /* GPIO5_IO04 */
>> + MX8MM_IOMUXC_SPDIF_RX_GPIO5_IO4 0x40000006
>> +
>> + /* CAN_INT# */
>> + MX8MM_IOMUXC_SAI2_TXC_GPIO4_IO25 0x40000090
>> + >;
>> +};
>> +
>> +&sai2 {
>> + assigned-clocks = <&clk IMX8MM_CLK_SAI2>;
>> + assigned-clock-parents = <&clk IMX8MM_AUDIO_PLL1_OUT>;
>> + fsl,sai-bit-clock-swap;
>> +};
>> +
>> +&sgtl5000_fio {
>> + VDDA-supply = <&buck4_reg>;
>> + VDDD-supply = <&buck5_reg>;
>> + VDDIO-supply = <&buck4_reg>;
>
> buck4_reg can provide addtional label, such as porta_vdd ..., so needn't
> this sections.
I simply renamed the base DT regulator names to buckN_reg and ldoN_reg
for both MX8MM and MX8MP eDM SBC , no need for additional labels .
>> +};
>> +
>> +&spba2 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + sai5clk: clock-controller@30050000 { /* SAI5 */
>> + compatible = "fsl,imx8mm-sai-clock", "fsl,imx8mq-sai-clock";
>> + reg = <0x30050000 0x10000>;
>> + #clock-cells = <1>;
>
> Not sure why need overwrite these informaiton here, suppose it should be
> the same for Soc.
I don't quite understand this comment, I am adding a node separate from
the sai5 node, so I won't end up pulling in unrelated properties for the
"fsl,imx8mm-sai-clock" (which is not "fsl,imx8mm-sai").
^ permalink raw reply
* Re: [PATCH 2/9] dt-bindings: arm: apple: apple,pmgr: Add t8122 compatible
From: Rob Herring (Arm) @ 2026-04-07 16:07 UTC (permalink / raw)
To: Janne Grunau
Cc: Linus Walleij, linux-arm-kernel, devicetree, asahi,
Wim Van Sebroeck, linux-pwm, Lorenzo Pieralisi, Guenter Roeck,
linux-kernel, linux-i2c, linux-gpio, Andi Shyti, Mark Kettenis,
Sasha Finkelstein, Uwe Kleine-König, Sven Peter, Neal Gompa,
Krzysztof Kozlowski, linux-watchdog, Conor Dooley
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-2-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:20 +0100, Janne Grunau wrote:
> The PMGR blocks on Apple silicon M3 SoCs (t8122) are compatible with the
> M1 and M2 predecessors. Add "apple,t8122-pmgr" as M3 specific
> compatible.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ 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