* [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
* Re: [PATCH 1/9] dt-bindings: arm: cpus: Add Apple M3 CPU core compatibles
From: Rob Herring @ 2026-04-07 16:06 UTC (permalink / raw)
To: Janne Grunau
Cc: Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi, Sven Peter,
Neal Gompa, Wim Van Sebroeck, Guenter Roeck, Linus Walleij,
Mark Kettenis, Andi Shyti, Uwe Kleine-König,
Sasha Finkelstein, devicetree, linux-kernel, asahi,
linux-arm-kernel, linux-watchdog, linux-gpio, linux-i2c,
linux-pwm
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-1-5842e1e393a8@jannau.net>
On Fri, Mar 20, 2026 at 01:23:19PM +0100, Janne Grunau wrote:
> Add "apple,everest" compatible for the M3 performance core and
> "apple,sawtooth" for the M3 efficiency CPU core. These CPU cores are
> found on Apple Silicon SoCs M3 and M3 Pro, Max and Ultra.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/arm/cpus.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Applied, thanks.
Rob
^ permalink raw reply
* Re: [PATCH v2 6/6] perf arm_spe: Print remaining IMPDEF event numbers
From: Leo Yan @ 2026-04-07 15:46 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, Ian Rogers, Adrian Hunter,
Al Grant, linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <20260407-james-spe-impdef-decode-v2-6-55d3ef997c48@linaro.org>
On Tue, Apr 07, 2026 at 03:05:20PM +0100, James Clark wrote:
> Any IMPDEF events not printed out from a known core's IMPDEF list or for
> a completely unknown core will still not be shown to the user. Fix this
> by printing the remaining bits as comma separated raw numbers, e.g.
> "IMPDEF:1,2,3,4".
>
> Suggested-by: Al Grant <al.grant@arm.com>
> Signed-off-by: James Clark <james.clark@linaro.org>
Reviewed-by: Leo Yan <leo.yan@arm.com>
^ permalink raw reply
* [PATCH mt76] wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3S
From: Zenm Chen @ 2026-04-07 15:44 UTC (permalink / raw)
To: nbd, lorenzo, ryder.lee, shayne.chen, sean.wang, matthias.bgg,
angelogioacchino.delregno, linux-wireless, linux-kernel,
linux-arm-kernel, linux-mediatek
Cc: zenmchen, stable
Add the ID 056e:400a to the table to support an additional MT7612U
adapter: ELECOM WDC-867SU3S.
Compile tested only.
Cc: stable@vger.kernel.org # 5.10.x
Signed-off-by: Zenm Chen <zenmchen@gmail.com>
---
This ID was found from [1] and adding it to the device table should be
enough to make it work. Hardware probes at [2] can prove its existence.
[1] https://bushowhige.blogspot.com/2019/08/ubuntu-1804-mediatek-usb-wi-fi.html
[2] https://linux-hardware.org/?id=usb:056e-400a
---
drivers/net/wireless/mediatek/mt76/mt76x2/usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c b/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
index 01cb3b283..459c4044f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
@@ -16,6 +16,7 @@ static const struct usb_device_id mt76x2u_device_table[] = {
{ USB_DEVICE(0x0e8d, 0x7612) }, /* Aukey USBAC1200 - Alfa AWUS036ACM */
{ USB_DEVICE(0x057c, 0x8503) }, /* Avm FRITZ!WLAN AC860 */
{ USB_DEVICE(0x7392, 0xb711) }, /* Edimax EW 7722 UAC */
+ { USB_DEVICE(0x056e, 0x400a) }, /* ELECOM WDC-867SU3S */
{ USB_DEVICE(0x0e8d, 0x7632) }, /* HC-M7662BU1 */
{ USB_DEVICE(0x0471, 0x2126) }, /* LiteOn WN4516R module, nonstandard USB connector */
{ USB_DEVICE(0x0471, 0x7600) }, /* LiteOn WN4519R module, nonstandard USB connector */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 5/6] perf arm_spe: Decode Arm N1 IMPDEF events
From: Leo Yan @ 2026-04-07 15:44 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, Ian Rogers, Adrian Hunter,
Al Grant, linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <20260407-james-spe-impdef-decode-v2-5-55d3ef997c48@linaro.org>
On Tue, Apr 07, 2026 at 03:05:19PM +0100, James Clark 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>
Reviewed-by: Leo Yan <leo.yan@arm.com>
^ permalink raw reply
* Re: [PATCH net-next v9 1/4] net: stmmac: Add DW25GMAC support in stmmac core driver
From: Russell King (Oracle) @ 2026-04-07 15:42 UTC (permalink / raw)
To: Jitendra Vegiraju
Cc: netdev, alexandre.torgue, davem, edumazet, kuba, pabeni,
mcoquelin.stm32, bcm-kernel-feedback-list, richardcochran, ast,
daniel, hawk, john.fastabend, rohan.g.thomas, linux-kernel,
linux-stm32, linux-arm-kernel, bpf, andrew+netdev, horms, sdf, me,
siyanteng, prabhakar.mahadev-lad.rj, weishangjuan, wens,
vladimir.oltean, lizhi2, boon.khai.ng, maxime.chevallier,
chenchuangyu, yangtiezhu, ovidiu.panait.rb, chenhuacai,
florian.fainelli, quic_abchauha
In-Reply-To: <adUQHHBD0d3p1OSI@shell.armlinux.org.uk>
On Tue, Apr 07, 2026 at 03:09:32PM +0100, Russell King (Oracle) wrote:
> Not withstanding my comment about the other Synopsys xlgmac driver that
> we have in the kernel...
>
> On Thu, Apr 02, 2026 at 02:36:26PM -0700, Jitendra Vegiraju wrote:
> > From: Jitendra Vegiraju <jitendra.vegiraju@broadcom.com>
> >
> > The DW25GMAC introduced a new DMA architecture called Hyper-DMA (HDMA) for
> > virtualization scalability. This is realized by decoupling physical DMA
> > channels(PDMA) from potentially large number of virtual DMA channels(VDMA).
> > The VDMAs provide software abstraction to driver that map to PDMAs for
> > frame transmission and reception.
> > Since 25GMAC is a derivative of XGMAC, majority of IP is common to both.
> >
> > To add support for the HDMA in 25GMAC, a new instance of dma_ops,
> > dw25gmac400_dma_ops is introduced.
> > To support the current needs, a simple one-to-one mapping of dw25gmac's
> > logical VDMA (channel) to TC to PDMAs is used. Most of the other dma
> > operation functions in existing dwxgamc2_dma.c file are reused whereever
>
> Typo: dwxgmac2_dma.c
>
> > applicable.
> > Added setup function for DW25GMAC's stmmac_hwif_entry in stmmac core.
>
> In a previous review, I questioned the use of DWMAC_CORE_25GMAC and
> asked about its version numberspace. I believe you indicated that the
> version numberspace is the same as the existing XGMAC core.
>
> I'm going to question the value of adding DWMAC_CORE_25GMAC.
>
> 1. What is the value of splitting DWMAC_CORE_25GMAC from
> DWMAC_CORE_XGMAC given that it's in the same versioning numberspace
> as XGMAC, and most tests (via dwmac_is_xgmac()) test for XGMAC or
> 25GMAC?
>
> 2. Have you reviewed all the places that explicitly test for
> DWMAC_CORE_XGMAC, looking at their "false" paths (for non-XGMAC
> cores) to determine whether they are suitable? For example:
>
> if (priv->plat->core_type == DWMAC_CORE_XGMAC)
> ndev->max_mtu = XGMAC_JUMBO_LEN;
> else if (priv->plat->enh_desc || priv->synopsys_id >= DWMAC_CORE_4_00)
> ndev->max_mtu = JUMBO_LEN;
> else
> ndev->max_mtu = SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN);
>
> XGMAC can handle a max MTU of 16368, but with your code using
> DWMAC_CORE_25GMAC, we fall back to the next test, which tests the
> IP version against 0x40, and uses a max MTU of 9000. Given that
> DWMAC_CORE_4_00 is a different "version number space" this seems
> wrong.
This is actually wrong - for DWMAC_CORE_25GMAC with a synopsys_id
less than 0x40, this will fall back to SKB_MAX_HEAD(NET_SKB_PAD +
NET_IP_ALIGN) which is as good as "pluck a number out of the air
and watch the driver fall over if you increase the MTU to maximum".
max_mtu ends up being dependent on the system page size, not on any
hardware limitation, which is garbage.
> 3. Looking at the MDIO code, this looks very wrong if you're
> introducing DWMAC_CORE_25GMAC. Have you tested MDIO accesses?
>
> dwxgmac2_setup() is called for DWMAC_CORE_XGMAC core-type. In
> stmmac_mdio_register(), DWMAC_CORE_XGMAC uses different functions
> for MDIO bus access for C22 and C45 from other cores - it uses the
> stmmac_xgmac2_mdio_* functions.
>
> These use stmmac_xgmac2_c45_format() and stmmac_xgmac2_c22_format()
> to format the register values which do not depend on mii.*_mask, but
> do use mii.address and mii.data for the register offsets. Thus, is
> there any point to setting mii.addr_mask and mii.reg_mask ?
>
> For non-DWMAC_CORE_XGMAC cores, we fall back to the stmmac_mdio_*()
> functions, which for non-DWMAC_CORE_GMAC4 will only support Clause
> 22 access, not Clause 45 - which would be very strange for a 25G
> core.
>
> 4. What about the feature printing in
> stmmac_main.c::stmmac_dma_cap_show() ?
>
> 5. What about similar tests in stmmac_est.c and stmmac_ethtool.c ?
Another issue that needs to be looked into is all the tests that
check priv->synopsys_id without checking the core_type. I'm already
concerned that many of these are wrong.
I have some patches now that rename synopsys_id to snpsver (it's really
the Synopsys IP version field which is BCD of the major version and
first digit of the minor version, not some random ID that identifies
the core.)
From what I've ascertained so far:
GMAC100 cores do not have a readable snpsver number, thus this
will be zero.
GMAC cores generally have a snpsver number less than 0x40.
GMAC4 cores may have a version number that overlaps GMAC cores
(see first entry for DWMAC_CORE_GMAC4).
XGMAC and XLGMAC cores each have an entirely separate IP version
number space from GMAC and GMAC4, which are distinguished by their
respective userver.
For example:
/* Only DWMAC core version 5.20 onwards supports HW descriptor prefetch.
*/
if (priv->snpsver < DWMAC_CORE_5_20)
priv->plat->dma_cfg->dche = false;
This will match your 25GMAC cores and the XGMAC cores because they have
a Synopsys IP version number less than 0x52. What saves us there is
that dche is only read by dwmac4_dma_init(), used by dwmac4_dma_ops and
dwmac410_dma_ops. These are all used by hwif entries that require
priv->plat->core_type to be DWMAC_CORE_GMAC4. Thus, I'm changing this
one to:
/* Only DWMAC4 core version 5.20 onwards support HW descriptor prefetch.
*/
if (priv->plat->core_type != DWMAC_CORE_GMAC4 ||
priv->snpsver < DWMAC_CORE_5_20)
priv->plat->dma_cfg->dche = false;
although I'm wondering if that should really be == && to avoid writing
to it for non-GMAC4 cores (it really doesn't matter.)
Then there this:
case HWTSTAMP_FILTER_PTP_V2_EVENT:
/* PTP v2/802.AS1 any layer, any kind of event packet */
config->rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
if (priv->snpsver < DWMAC_CORE_4_10)
ts_event_en = PTP_TCR_TSEVNTENA;
Is PTP_TCR_TSEVNTENA needed for this PTP filter type for XGMAC and
25GMAC cores - because they'll get it because they have snpsver
smaller than 0x41.
Similar here:
if (priv->plat->rx_coe) {
priv->hw->rx_csum = priv->plat->rx_coe;
dev_info(priv->device, "RX Checksum Offload Engine supported\n")+;
if (priv->snpsver < DWMAC_CORE_4_00)
dev_info(priv->device, "COE Type %d\n", priv->hw->rx_csu+m);
}
In stmmac_ethtool.c, stmmac_mac_debug() won't be called for XGMAC or
25GMAC cores, because:
if (priv->snpsver >= DWMAC_CORE_3_50)
stmmac_mac_debug(priv, priv->ioaddr,
(void *)&priv->xstats,
rx_queues_count, tx_queues_count);
snpsver (synopsys_id) will be smaller than 0x35. Is this correct?
The good news is that stmmac_mdio.c at gates all its checks on the
Synopsys IP version against the core type.
I'll post my RFC patches tidying up some of the version mess in the
next day or so.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v2 3/6] perf arm_spe: Store MIDR in arm_spe_pkt
From: Leo Yan @ 2026-04-07 15:41 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, Ian Rogers, Adrian Hunter,
Al Grant, linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <20260407-james-spe-impdef-decode-v2-3-55d3ef997c48@linaro.org>
On Tue, Apr 07, 2026 at 03:05:17PM +0100, James Clark wrote:
> The MIDR will affect printing of arm_spe_pkts, so store a copy of it
> there. Technically it's constant for each decoder, but there is no
> decoder when doing a raw dump, so it has to be stored in every packet.
> It will only be used in raw dump mode and not in normal decoding for
> now, but to avoid any surprises, set MIDR properly on the decoder too.
>
> Having both the MIDR and the arm_spe_pkt (which has a copy of it) in the
> decoder seemed a bit weird, so remove arm_spe_pkt from the decoder. The
> packet is only short lived anyway so probably shouldn't have been there
> in the first place.
>
> Signed-off-by: James Clark <james.clark@linaro.org>
Reviewed-by: Leo Yan <leo.yan@arm.com>
^ permalink raw reply
* [PATCH v4 0/2] perf: marvell: Add CN20K DDR PMU support
From: Geetha sowjanya @ 2026-04-07 15:35 UTC (permalink / raw)
To: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree
Cc: mark.rutland, will, krzk+dt
This series adds support for the DDR Performance Monitoring Unit (PMU)
present in Marvell CN20K SoCs.
The DDR PMU is part of the DRAM Subsystem (DSS) and provides hardware
counters to monitor DDR traffic and performance events. The block
implements eight programmable counters and two fixed-function counters
tracking DDR read and write activity, and is accessed via a dedicated
MMIO region.
CN20K is the successor to CN10K, and the DDR PMU hardware is functionally
equivalent to the CN10K implementation, with only minor differences in
register offsets and event mappings. To allow software to distinguish
between the two silicon variants, this series introduces a specific
"marvell,cn20k-ddr-pmu" compatible and extends the existing
marvell_cn10k_ddr_pmu driver to handle CN20K via variant-specific data.
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
Chnages in v3:
- Expanded cover letter and commit message to better describe the DDR PMU
hardware and its relationship to CN10K
- Fixed the file name.
Changes in v2:
- Fixed YAML syntax error triggered by a tab character in the examples
section, which caused dt_binding_check to fail.
Changes in v1:
- Added a description field to the binding.
- Simplified the compatible property using 'const' instead of 'items/enum'.
- Updated the example node name to include a unit-address matching the reg base.
Geetha sowjanya (2):
dt-bindings: perf: marvell: Document CN20K DDR PMU
perf: marvell: Add CN20K DDR PMU support
.../bindings/perf/marvell-cn20k-ddr-pmu.yaml | 39 ++++
drivers/perf/marvell_cn10k_ddr_pmu.c | 187 ++++++++++++++++--
2 files changed, 210 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr-pmu.yaml
--
2.25.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox