* Re: [PATCH net V2 1/2] net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec
From: Sean Anderson @ 2026-03-30 19:09 UTC (permalink / raw)
To: Suraj Gupta, Radhey Shyam Pandey, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Michal Simek, Daniel Borkmann, Ariane Keller, netdev,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260327073238.134948-2-suraj.gupta2@amd.com>
On 3/27/26 03:32, Suraj Gupta wrote:
> The XAXIDMA_BD_CTRL_LENGTH_MASK and XAXIDMA_BD_STS_ACTUAL_LEN_MASK
> macros were defined as 0x007FFFFF (23 bits), but the AXI DMA IP
> product guide (PG021) specifies the buffer length field as bits 25:0
> (26 bits). Update both masks to match the IP documentation.
>
> In practice this had no functional impact, since Ethernet frames are
> far smaller than 2^23 bytes and the extra bits were always zero, but
> the masks should still reflect the hardware specification.
>
> Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> ---
> drivers/net/ethernet/xilinx/xilinx_axienet.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet.h b/drivers/net/ethernet/xilinx/xilinx_axienet.h
> index 5ff742103beb..fcd3aaef27fc 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet.h
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet.h
> @@ -105,7 +105,7 @@
> #define XAXIDMA_BD_HAS_DRE_MASK 0xF00 /* Whether has DRE mask */
> #define XAXIDMA_BD_WORDLEN_MASK 0xFF /* Whether has DRE mask */
>
> -#define XAXIDMA_BD_CTRL_LENGTH_MASK 0x007FFFFF /* Requested len */
> +#define XAXIDMA_BD_CTRL_LENGTH_MASK GENMASK(25, 0) /* Requested len */
> #define XAXIDMA_BD_CTRL_TXSOF_MASK 0x08000000 /* First tx packet */
> #define XAXIDMA_BD_CTRL_TXEOF_MASK 0x04000000 /* Last tx packet */
> #define XAXIDMA_BD_CTRL_ALL_MASK 0x0C000000 /* All control bits */
> @@ -130,7 +130,7 @@
> #define XAXIDMA_BD_CTRL_TXEOF_MASK 0x04000000 /* Last tx packet */
> #define XAXIDMA_BD_CTRL_ALL_MASK 0x0C000000 /* All control bits */
>
> -#define XAXIDMA_BD_STS_ACTUAL_LEN_MASK 0x007FFFFF /* Actual len */
> +#define XAXIDMA_BD_STS_ACTUAL_LEN_MASK GENMASK(25, 0) /* Actual len */
> #define XAXIDMA_BD_STS_COMPLETE_MASK 0x80000000 /* Completed */
> #define XAXIDMA_BD_STS_DEC_ERR_MASK 0x40000000 /* Decode error */
> #define XAXIDMA_BD_STS_SLV_ERR_MASK 0x20000000 /* Slave error */
Reviewed-by: Sean Anderson <sean.anderson@linux.dev>
^ permalink raw reply
* Re: [PATCH v4 2/3] driver core: make software nodes available earlier
From: Andy Shevchenko @ 2026-03-30 20:24 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Aaro Koskinen,
Janusz Krzysztofik, Tony Lindgren, Russell King, Dmitry Torokhov,
Kevin Hilman, Arnd Bergmann, brgl, driver-core, linux-kernel,
linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <20260330-nokia770-gpio-swnodes-v4-2-b68592e977d0@oss.qualcomm.com>
On Mon, Mar 30, 2026 at 02:40:47PM +0200, Bartosz Golaszewski wrote:
> Software nodes are currently initialized in a function registered as
> a postcore_initcall(). However, some devices may want to register
> software nodes earlier than that (or also in a postcore_initcall() where
> they're at the merci of the link order). Move the initialization to
> driver_init() making swnode available much earlier as well as making
> their initialization time deterministic.
...
> -static void __exit software_node_exit(void)
> -{
> - ida_destroy(&swnode_root_ids);
> - kset_unregister(swnode_kset);
> }
> -__exitcall(software_node_exit);
Why? What's wrong with the __exitcall?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 07/12] kbuild: Only run objtool if there is at least one command
From: Nicolas Schier @ 2026-03-30 18:49 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: x86, linux-kernel, live-patching, Peter Zijlstra, Joe Lawrence,
Song Liu, Catalin Marinas, Will Deacon, linux-arm-kernel,
Mark Rutland, Nathan Chancellor, Herbert Xu
In-Reply-To: <zdipyf26t2gos5dw2gjyzmeg2zm5a67xwr5ozubnhmhllrwgnm@ezdt54coe2bk>
On Wed, Mar 18, 2026 at 05:49:27PM -0700, Josh Poimboeuf wrote:
> On Wed, Mar 18, 2026 at 08:54:31PM +0100, Nicolas Schier wrote:
> > On Tue, Mar 17, 2026 at 03:51:07PM -0700, Josh Poimboeuf wrote:
> > > Split the objtool args into commands and options, such that if no
> > > commands have been enabled, objtool doesn't run.
> > >
> > > This is in preparation in enabling objtool and klp-build for arm64.
> > >
> > > Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> > > Tested-by: Nathan Chancellor <nathan@kernel.org>
> > > Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> > > ---
> > > arch/x86/boot/startup/Makefile | 2 +-
> > > scripts/Makefile.build | 4 +--
> > > scripts/Makefile.lib | 46 ++++++++++++++++++----------------
> > > scripts/Makefile.vmlinux_o | 15 ++++-------
> > > 4 files changed, 33 insertions(+), 34 deletions(-)
> > >
> > [...]
> > > diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> > > index 3652b85be545..8a1bdfdb2fdb 100644
> > > --- a/scripts/Makefile.build
> > > +++ b/scripts/Makefile.build
> > > @@ -277,7 +277,7 @@ endif # CONFIG_FTRACE_MCOUNT_USE_RECORDMCOUNT
> > > is-standard-object = $(if $(filter-out y%, $(OBJECT_FILES_NON_STANDARD_$(target-stem).o)$(OBJECT_FILES_NON_STANDARD)n),$(is-kernel-object))
> > >
> > > ifdef CONFIG_OBJTOOL
> > > -$(obj)/%.o: private objtool-enabled = $(if $(is-standard-object),$(if $(delay-objtool),$(is-single-obj-m),y))
> > > +$(obj)/%.o: private objtool-enabled = $(if $(is-standard-object),$(if $(objtool-cmds-y),$(if $(delay-objtool),$(is-single-obj-m),y)))
> >
> > Please use $(and a,b,c) instead of multiple nested $(if $(a),$(if
> > $(b),$(c)); as the last variable (is-single-obj-m) is 'y' or empty, the final 'y' can be
> > left-out:
> >
> > $(obj)/%.o: private objtool-enabled = $(and $(is-standard-object),$(objtool-cmds-y),$(delay-objtool),$(is-single-obj-m))
>
> I believe that would break the !delay-objtool case. The logic needs to
> be something like:
>
> if (is-standard-object && objtool-cmds-y) {
> if (delay-objtool) {
> // for delay-objtool, only enable objtool for single-object modules
> $(is-single-obj-m)
> } else {
> // for !delay-objtool, always enable objtool
> y
> }
> }
>
> so maybe something like this?
>
> $(obj)/%.o: private objtool-enabled = $(and $(is-standard-object),$(objtool-cmds-y),$(if $(delay-objtool),$(is-single-obj-m),y))
sorry for the delay! Yes, I overlooked the !delay-objtool. That line
looks good to me, thanks!
--
Nicolas
^ permalink raw reply
* Re: [PATCH] firmware: psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
From: Jon Hunter @ 2026-03-30 20:15 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Manivannan Sadhasivam, mark.rutland, bjorn.andersson,
konrad.dybcio, mani, linux-arm-kernel, linux-kernel,
Konrad Dybcio, Konrad Dybcio, Sudeep Holla,
linux-tegra@vger.kernel.org
In-Reply-To: <acJPHGIW1fb7whsu@lpieralisi>
Hi Lorenzo,
On 24/03/2026 08:45, Lorenzo Pieralisi wrote:
...
>>> I wanted to ask what the status of this patch is?
>>>
>>> It turns out that since commit f3ac2ff14834 ("PCI/ASPM: Enable all
>>> ClockPM and ASPM states for devicetree platforms"), this fix is also
>>> need for Tegra platforms that have NVMe devices to ensure that they are
>>> suspended as needed. There is some more background in this thread [0].
>>
>>
>> Any feedback on this? I am not sure if this patch is purposely being
>> ignored, but if so, I would like to understand why.
>
> It fell through the cracks, apologies.
No worries. Do you plan to pick this up?
Thanks
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v4 0/8] Bluetooth: Add MediaTek MT7927 (MT6639) support
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert, Jose Tiburcio Ribeiro Netto, Llewellyn Curran,
Chapuis Dario, Evgeny Kapusta, Nitin Gurram, Thibaut FRANCOIS,
Ivan Lubnin
combo WiFi 7 + BT 5.4 module. The BT subsystem uses hardware variant
0x6639 and connects via USB.
The MT7927 is shipping in motherboards and PCIe add-in cards from ASUS,
Gigabyte, Lenovo, MSI, and TP-Link since mid-2024. Without these patches,
users see "Unsupported hardware variant (00006639)" or the BT subsystem
hangs during firmware download.
The series consists of eight patches:
[1/8] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support
[2/8] Bluetooth: btmtk: fix ISO interface setup for single alt setting
[3/8] Bluetooth: btusb: Add MT7927 ID for ASUS ROG Crosshair X870E Hero
[4/8] Bluetooth: btusb: Add MT7927 ID for Lenovo Legion Pro 7 16ARX9
[5/8] Bluetooth: btusb: Add MT7927 ID for Gigabyte Z790 AORUS MASTER X
[6/8] Bluetooth: btusb: Add MT7927 ID for MSI X870E Ace Max
[7/8] Bluetooth: btusb: Add MT7927 ID for TP-Link Archer TBE550E
[8/8] Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-Creator
Three driver changes are needed for MT6639 (patch 1):
1. CHIPID workaround: On some boards the BT USB MMIO register reads
0x0000 for dev_id. Force dev_id to 0x6639 only when the USB VID/PID
matches a known MT6639 device, avoiding misdetection if a future
chip also reads zero. This follows the WiFi-side pattern.
2. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of
"1_1" used by MT7925 and other variants. The firmware path is
mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin, using the mt7927
directory to match the WiFi firmware convention. The filename will
likely change to use MT7927 once MediaTek submits a dedicated
Linux firmware binary.
3. Section filtering: The firmware binary contains 9 sections, but only
sections with (dlmodecrctype & 0xff) == 0x01 are Bluetooth-related.
Sending WiFi/other sections causes an irreversible BT subsystem hang.
Patch 2 fixes the ISO interface setup for devices that expose only a
single alternate setting (alt 0) on the ISO endpoint. Without this fix,
btmtk_usb_claim_iso_intf() fails with EINVAL, causing ~20 second
initialization delays on 13d3:3588 devices.
WBS (Wideband Speech) was verified on MT7927 hardware. The controller
reports LMP_TRANSPARENT, LMP_ERR_DATA_REPORTING, and mSBC codec support.
A btmon capture confirms eSCO links establish with Transparent air mode
(mSBC) and 60-byte frames. BTUSB_WIDEBAND_SPEECH is correct for this
controller family.
Tested on:
- ASUS ROG Crosshair X870E Hero (USB 0489:e13a)
- ASUS ROG STRIX X870E-E (USB 13d3:3588)
- ASUS ROG STRIX B850-E GAMING WIFI (USB 0489:e13a)
- Gigabyte Z790 AORUS MASTER X (USB 0489:e10f)
- Lenovo Legion Pro 7 16ARX9 (USB 0489:e0fa)
Changes in v4:
- Pass dev_id as parameter to btmtk_setup_firmware_79xx instead of
using hci_get_priv, which is not available in btmtksdio
(suggested by Luiz Augusto von Dentz)
- Skip post-reset CHIPID validation for 0x6639 in
btmtk_usb_subsys_reset since the register always returns 0x0000
on affected boards
Link to v3: https://lore.kernel.org/linux-bluetooth/20260326-mt7927-bt-support-v3-0-fa7ebd424323@jetm.me/
Signed-off-by: Javier Tia <floss@jetm.me>
---
Javier Tia (8):
Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support
Bluetooth: btmtk: fix ISO interface setup for single alt setting
Bluetooth: btusb: Add MT7927 ID for ASUS ROG Crosshair X870E Hero
Bluetooth: btusb: Add MT7927 ID for Lenovo Legion Pro 7 16ARX9
Bluetooth: btusb: Add MT7927 ID for Gigabyte Z790 AORUS MASTER X
Bluetooth: btusb: Add MT7927 ID for MSI X870E Ace Max
Bluetooth: btusb: Add MT7927 ID for TP-Link Archer TBE550E
Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-Creator
drivers/bluetooth/btmtk.c | 63 ++++++++++++++++++++++++++++++++++++++-----
drivers/bluetooth/btmtk.h | 7 +++--
drivers/bluetooth/btmtksdio.c | 2 +-
drivers/bluetooth/btusb.c | 12 +++++++++
4 files changed, 75 insertions(+), 9 deletions(-)
---
base-commit: 7f9446b23ac77f46d356b354ea8da49113e8000d
change-id: 20260305-mt7927-bt-support-6589a50c961f
Best regards,
--
Javier Tia <floss@jetm.me>
^ permalink raw reply
* [PATCH v4 1/8] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert
In-Reply-To: <20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me>
The MediaTek MT7927 (Filogic 380) combo WiFi 7 + BT 5.4 module uses
hardware variant 0x6639 for its Bluetooth subsystem. Without this patch,
the chip fails with "Unsupported hardware variant (00006639)" or hangs
during firmware download.
Three changes are needed to support MT6639:
1. CHIPID workaround: On some boards the BT USB MMIO register reads
0x0000 for dev_id, causing the driver to skip the 0x6639 init path.
Force dev_id to 0x6639 only when the USB VID/PID matches a known
MT6639 device, avoiding misdetection if a future chip also reads
zero. This follows the WiFi-side pattern that uses PCI device IDs
to scope the same workaround.
2. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of
"1_1" used by MT7925 and other variants. The firmware path is
mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin, using the mt7927
directory to match the WiFi firmware convention. The filename will
likely change to use MT7927 once MediaTek submits a dedicated
Linux firmware binary.
3. Section filtering: The MT6639 firmware binary contains 9 sections, but
only sections with (dlmodecrctype & 0xff) == 0x01 are Bluetooth-related.
Sending the remaining WiFi/other sections causes an irreversible BT
subsystem hang requiring a full power cycle. This matches the Windows
driver behavior observed via USB captures.
Also add 0x6639 to the reset register (CONNV3) and firmware setup switch
cases alongside the existing 0x7925 handling.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Reported-by: Ryan Gilbert <xelnaga@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/bluetooth/btmtk.c | 60 +++++++++++++++++++++++++++++++++++++++----
drivers/bluetooth/btmtk.h | 7 +++--
drivers/bluetooth/btmtksdio.c | 2 +-
3 files changed, 61 insertions(+), 8 deletions(-)
diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index 2507d587f28a..4af19b86c551 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -25,6 +25,22 @@
/* It is for mt79xx iso data transmission setting */
#define MTK_ISO_THRESHOLD 264
+/* Known MT6639 (MT7927) Bluetooth USB devices.
+ * Used to scope the zero-CHIPID workaround to real MT6639 hardware,
+ * since some boards return 0x0000 from the MMIO chip ID register.
+ */
+static const struct {
+ u16 vendor;
+ u16 product;
+} btmtk_mt6639_devs[] = {
+ { 0x0489, 0xe13a }, /* ASUS ROG Crosshair X870E Hero */
+ { 0x0489, 0xe0fa }, /* Lenovo Legion Pro 7 16ARX9 */
+ { 0x0489, 0xe10f }, /* Gigabyte Z790 AORUS MASTER X */
+ { 0x0489, 0xe110 }, /* MSI X870E Ace Max */
+ { 0x0489, 0xe116 }, /* TP-Link Archer TBE550E */
+ { 0x13d3, 0x3588 }, /* ASUS ROG STRIX X870E-E */
+};
+
struct btmtk_patch_header {
u8 datetime[16];
u8 platform[4];
@@ -112,7 +128,11 @@ static void btmtk_coredump_notify(struct hci_dev *hdev, int state)
void btmtk_fw_get_filename(char *buf, size_t size, u32 dev_id, u32 fw_ver,
u32 fw_flavor)
{
- if (dev_id == 0x7925)
+ if (dev_id == 0x6639)
+ snprintf(buf, size,
+ "mediatek/mt7927/BT_RAM_CODE_MT%04x_2_%x_hdr.bin",
+ dev_id & 0xffff, (fw_ver & 0xff) + 1);
+ else if (dev_id == 0x7925)
snprintf(buf, size,
"mediatek/mt%04x/BT_RAM_CODE_MT%04x_1_%x_hdr.bin",
dev_id & 0xffff, dev_id & 0xffff, (fw_ver & 0xff) + 1);
@@ -128,7 +148,8 @@ void btmtk_fw_get_filename(char *buf, size_t size, u32 dev_id, u32 fw_ver,
EXPORT_SYMBOL_GPL(btmtk_fw_get_filename);
int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
- wmt_cmd_sync_func_t wmt_cmd_sync)
+ wmt_cmd_sync_func_t wmt_cmd_sync,
+ u32 dev_id)
{
struct btmtk_hci_wmt_params wmt_params;
struct btmtk_patch_header *hdr;
@@ -166,6 +187,14 @@ int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
section_offset = le32_to_cpu(sectionmap->secoffset);
dl_size = le32_to_cpu(sectionmap->bin_info_spec.dlsize);
+ /* MT6639: only download sections where dlmode byte0 == 0x01,
+ * matching the Windows driver behavior which skips WiFi/other
+ * sections that would cause the chip to hang.
+ */
+ if (dev_id == 0x6639 && dl_size > 0 &&
+ (le32_to_cpu(sectionmap->bin_info_spec.dlmodecrctype) & 0xff) != 0x01)
+ continue;
+
if (dl_size > 0) {
retry = 20;
while (retry > 0) {
@@ -852,7 +881,7 @@ int btmtk_usb_subsys_reset(struct hci_dev *hdev, u32 dev_id)
if (err < 0)
return err;
msleep(100);
- } else if (dev_id == 0x7925) {
+ } else if (dev_id == 0x7925 || dev_id == 0x6639) {
err = btmtk_usb_uhw_reg_read(hdev, MTK_BT_RESET_REG_CONNV3, &val);
if (err < 0)
return err;
@@ -938,7 +967,7 @@ int btmtk_usb_subsys_reset(struct hci_dev *hdev, u32 dev_id)
}
err = btmtk_usb_id_get(hdev, 0x70010200, &val);
- if (err < 0 || !val)
+ if (err < 0 || (!val && dev_id != 0x6639))
bt_dev_err(hdev, "Can't get device id, subsys reset fail.");
return err;
@@ -1322,6 +1351,24 @@ int btmtk_usb_setup(struct hci_dev *hdev)
fw_flavor = (fw_flavor & 0x00000080) >> 7;
}
+ if (!dev_id) {
+ u16 vid = le16_to_cpu(btmtk_data->udev->descriptor.idVendor);
+ u16 pid = le16_to_cpu(btmtk_data->udev->descriptor.idProduct);
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(btmtk_mt6639_devs); i++) {
+ if (vid == btmtk_mt6639_devs[i].vendor &&
+ pid == btmtk_mt6639_devs[i].product) {
+ dev_id = 0x6639;
+ break;
+ }
+ }
+
+ if (dev_id)
+ bt_dev_info(hdev, "MT6639: CHIPID=0x0000 with VID=%04x PID=%04x, using 0x6639",
+ vid, pid);
+ }
+
btmtk_data->dev_id = dev_id;
err = btmtk_register_coredump(hdev, btmtk_data->drv_name, fw_version);
@@ -1339,11 +1386,13 @@ int btmtk_usb_setup(struct hci_dev *hdev)
case 0x7925:
case 0x7961:
case 0x7902:
+ case 0x6639:
btmtk_fw_get_filename(fw_bin_name, sizeof(fw_bin_name), dev_id,
fw_version, fw_flavor);
err = btmtk_setup_firmware_79xx(hdev, fw_bin_name,
- btmtk_usb_hci_wmt_sync);
+ btmtk_usb_hci_wmt_sync,
+ dev_id);
if (err < 0) {
/* retry once if setup firmware error */
if (!test_and_set_bit(BTMTK_FIRMWARE_DL_RETRY, &btmtk_data->flags))
@@ -1516,3 +1565,4 @@ MODULE_FIRMWARE(FIRMWARE_MT7668);
MODULE_FIRMWARE(FIRMWARE_MT7922);
MODULE_FIRMWARE(FIRMWARE_MT7961);
MODULE_FIRMWARE(FIRMWARE_MT7925);
+MODULE_FIRMWARE(FIRMWARE_MT7927);
diff --git a/drivers/bluetooth/btmtk.h b/drivers/bluetooth/btmtk.h
index adaf385626ee..c564aedc0ce0 100644
--- a/drivers/bluetooth/btmtk.h
+++ b/drivers/bluetooth/btmtk.h
@@ -8,6 +8,7 @@
#define FIRMWARE_MT7902 "mediatek/BT_RAM_CODE_MT7902_1_1_hdr.bin"
#define FIRMWARE_MT7961 "mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin"
#define FIRMWARE_MT7925 "mediatek/mt7925/BT_RAM_CODE_MT7925_1_1_hdr.bin"
+#define FIRMWARE_MT7927 "mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin"
#define HCI_EV_WMT 0xe4
#define HCI_WMT_MAX_EVENT_SIZE 64
@@ -189,7 +190,8 @@ typedef int (*wmt_cmd_sync_func_t)(struct hci_dev *,
int btmtk_set_bdaddr(struct hci_dev *hdev, const bdaddr_t *bdaddr);
int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
- wmt_cmd_sync_func_t wmt_cmd_sync);
+ wmt_cmd_sync_func_t wmt_cmd_sync,
+ u32 dev_id);
int btmtk_setup_firmware(struct hci_dev *hdev, const char *fwname,
wmt_cmd_sync_func_t wmt_cmd_sync);
@@ -228,7 +230,8 @@ static inline int btmtk_set_bdaddr(struct hci_dev *hdev,
static inline int btmtk_setup_firmware_79xx(struct hci_dev *hdev,
const char *fwname,
- wmt_cmd_sync_func_t wmt_cmd_sync)
+ wmt_cmd_sync_func_t wmt_cmd_sync,
+ u32 dev_id)
{
return -EOPNOTSUPP;
}
diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
index 042064464d34..5b0fab7b89b5 100644
--- a/drivers/bluetooth/btmtksdio.c
+++ b/drivers/bluetooth/btmtksdio.c
@@ -883,7 +883,7 @@ static int mt79xx_setup(struct hci_dev *hdev, const char *fwname)
u8 param = 0x1;
int err;
- err = btmtk_setup_firmware_79xx(hdev, fwname, mtk_hci_wmt_sync);
+ err = btmtk_setup_firmware_79xx(hdev, fwname, mtk_hci_wmt_sync, 0);
if (err < 0) {
bt_dev_err(hdev, "Failed to setup 79xx firmware (%d)", err);
return err;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/8] Bluetooth: btmtk: fix ISO interface setup for single alt setting
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert
In-Reply-To: <20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me>
Some MT6639 Bluetooth USB interfaces (e.g. IMC Networks 13d3:3588 on
ASUS ROG STRIX X870E-E and ProArt X870E-Creator boards) expose only a
single alternate setting (alt 0) on the ISO interface. The driver
unconditionally requests alt setting 1, which fails with EINVAL on
these devices, causing a ~20 second initialization delay and no LE
audio support.
Check the number of available alternate settings before selecting one.
If only alt 0 exists, use it; otherwise request alt 1 as before.
Closes: https://github.com/jetm/mediatek-mt7927-dkms/pull/39
Signed-off-by: Javier Tia <floss@jetm.me>
Reported-by: Ryan Gilbert <xelnaga@gmail.com>
Tested-by: Ryan Gilbert <xelnaga@gmail.com>
---
drivers/bluetooth/btmtk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index 4af19b86c551..f8cff895f14c 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -1029,7 +1029,8 @@ static int __set_mtk_intr_interface(struct hci_dev *hdev)
if (!btmtk_data->isopkt_intf)
return -ENODEV;
- err = usb_set_interface(btmtk_data->udev, MTK_ISO_IFNUM, 1);
+ err = usb_set_interface(btmtk_data->udev, MTK_ISO_IFNUM,
+ (intf->num_altsetting > 1) ? 1 : 0);
if (err < 0) {
bt_dev_err(hdev, "setting interface failed (%d)", -err);
return err;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 3/8] Bluetooth: btusb: Add MT7927 ID for ASUS ROG Crosshair X870E Hero
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Jose Tiburcio Ribeiro Netto
In-Reply-To: <20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me>
Add USB device ID 0489:e13a (Foxconn/Hon Hai) for the MediaTek MT7927
(Filogic 380) Bluetooth interface found on the ASUS ROG Crosshair X870E
Hero WiFi motherboard.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e13a Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
...
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Jose Tiburcio Ribeiro Netto <jnetto@mineiro.io>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index a5e44887a5b5..58309af0f7a2 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -751,6 +751,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe139), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x0489, 0xe13a), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* [PATCH v4 4/8] Bluetooth: btusb: Add MT7927 ID for Lenovo Legion Pro 7 16ARX9
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Llewellyn Curran
In-Reply-To: <20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me>
Add USB device ID 0489:e0fa (Foxconn/Hon Hai) for the MediaTek MT7927
(Filogic 380) Bluetooth interface found on the Lenovo Legion Pro 7
16ARX9 laptop.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e0fa Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
...
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Llewellyn Curran <melinko2003@gmail.com>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 58309af0f7a2..2c9ca3d6016b 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -753,6 +753,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe13a), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x0489, 0xe0fa), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* [PATCH v4 5/8] Bluetooth: btusb: Add MT7927 ID for Gigabyte Z790 AORUS MASTER X
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Chapuis Dario, Evgeny Kapusta
In-Reply-To: <20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me>
Add USB device ID 0489:e10f (Foxconn/Hon Hai) for the MediaTek MT7927
(Filogic 380) Bluetooth interface found on the Gigabyte Z790 AORUS
MASTER X motherboard.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e10f Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
...
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 2c9ca3d6016b..d60798331bb3 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -755,6 +755,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe0fa), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x0489, 0xe10f), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* [PATCH v4 6/8] Bluetooth: btusb: Add MT7927 ID for MSI X870E Ace Max
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Nitin Gurram
In-Reply-To: <20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me>
Add USB device ID 0489:e110 (Foxconn/Hon Hai) for the MediaTek MT7927
(Filogic 380) Bluetooth interface found on the MSI X870E Ace Max
motherboard.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e110 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
...
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Nitin Gurram <nitin.reddy88@gmail.com>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index d60798331bb3..96882e9b831c 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -757,6 +757,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe10f), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x0489, 0xe110), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* [PATCH v4 7/8] Bluetooth: btusb: Add MT7927 ID for TP-Link Archer TBE550E
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Thibaut FRANCOIS
In-Reply-To: <20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me>
Add USB device ID 0489:e116 (Foxconn/Hon Hai) for the MediaTek MT7927
(Filogic 380) Bluetooth interface found on the TP-Link Archer TBE550E
PCIe adapter.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e116 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
...
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Thibaut FRANCOIS <tibo@humeurlibre.fr>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 96882e9b831c..55a000540439 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -759,6 +759,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe110), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x0489, 0xe116), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* [PATCH v4 8/8] Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-Creator
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Jose Tiburcio Ribeiro Netto, Ivan Lubnin
In-Reply-To: <20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me>
Add USB device ID 13d3:3588 (IMC Networks/Azurewave) for the MediaTek
MT7927 (Filogic 380) Bluetooth interface found on the ASUS ROG STRIX
X870E-E GAMING WIFI and ASUS ProArt X870E-Creator WiFi motherboards.
Note: boards with this USB ID report only one ISO alternate setting
(alt 0), causing a non-fatal "setting interface failed (22)" during
setup. Bluetooth still functions but initialization takes ~19 seconds
instead of ~2.6 seconds.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3588 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Jose Tiburcio Ribeiro Netto <jnetto@mineiro.io>
Tested-by: Ivan Lubnin <lubnin.ivan@gmail.com>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 55a000540439..45ef0d008bce 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -761,6 +761,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe116), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x13d3, 0x3588), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 0/8] Bluetooth: Add MediaTek MT7927 (MT6639) support
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Matthias Brugger, AngeloGioacchino Del Regno,
linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert, Jose Tiburcio Ribeiro Netto, Llewellyn Curran,
Chapuis Dario, Evgeny Kapusta, Nitin Gurram, Thibaut FRANCOIS,
Ivan Lubnin
Hi Luiz,
Thank you for the review.
On Thu, Mar 27, 2026 Luiz Augusto von Dentz wrote:
> https://sashiko.dev/#/patchset/20260326-mt7927-bt-support-v3-0-fa7ebd424323%40jetm.me
>
> First one is more concerning since it may mean it can lead to crashes
> with SDIO driver, the other comment may actually need to be addressed
> separately, perhaps WBS handling needs to be fixed on this family of
> controllers.
Both issues are addressed in v4.
For the SDIO concern: btmtk_setup_firmware_79xx now takes dev_id
as a parameter instead of reading it from hci_get_priv. The SDIO
caller passes its own dev_id, so there is no out-of-bounds read
from a mismatched private struct layout.
For the subsys reset: btmtk_usb_subsys_reset now skips the
post-reset CHIPID validation for 0x6639. On affected boards the
register always reads back 0x0000, so the validation would always
fail. This is scoped to 0x6639 only.
Regarding WBS, I verified it on MT7927 hardware (ASUS ROG
Crosshair X870E Hero). The controller reports LMP_TRANSPARENT
and LMP_ERR_DATA_REPORTING in its LMP features, and
HCI_Read_Local_Supported_Codecs returns CVSD, Transparent, and
mSBC. A btmon capture confirms eSCO links establish with
Transparent air mode (0x03) and 60-byte mSBC frames. WBS works
correctly on this controller family, no fix needed.
Link to v4: https://lore.kernel.org/linux-bluetooth/20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me/
Best,
Javier
^ permalink raw reply
* Re: [PATCH] firmware: psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
From: Bjorn Andersson @ 2026-03-30 20:48 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: mark.rutland, lpieralisi, bjorn.andersson, konrad.dybcio, mani,
linux-arm-kernel, linux-kernel, Konrad Dybcio, Konrad Dybcio,
Sudeep Holla
In-Reply-To: <20251231162126.7728-1-manivannan.sadhasivam@oss.qualcomm.com>
On Wed, Dec 31, 2025 at 09:51:26PM +0530, Manivannan Sadhasivam wrote:
> From: Konrad Dybcio <konradybcio@kernel.org>
>
> PSCI specification defines the SYSTEM_SUSPEND feature which enables the
> firmware to implement the suspend to RAM (S2RAM) functionality by
> transitioning the system to a deeper low power state. When the system
> enters such state, the power to the peripheral devices might be removed.
What is the actual extent of "peripheral devices" in this definition?
> So
> the respective device drivers must prepare for the possible removal of the
> power by performing actions such as shutting down or resetting the device
> in their system suspend callbacks.
>
Our typical interpretation of this state is that IP-blocks might be
non-functional during this time, but typically some state is retained.
Will the acceptance of this patch result in that we in the Qualcomm case
should start accepting/writing patches that implement save/restore of
state that is generally retained throughout the drivers - in the name of
"power might be removed"?
> The Linux PM framework allows the platform drivers to convey this info to
> device drivers by calling the pm_set_suspend_via_firmware() and
> pm_set_resume_via_firmware() APIs.
>
> Hence, if the PSCI firmware supports SYSTEM_SUSPEND feature, call the above
> mentioned APIs in the psci_system_suspend_begin() and
> psci_system_suspend_enter() callbacks.
>
With the right interpretation of what this means for us, I think this
patch looks good - but as we've discussed, I'm a bit worried about how
to deal with the alternative interpretations.
Specifically, if we fully adopt "power might be removed", we should to
take actions which will prevent a typical Qualcomm system from waking up
from sleep again.
Regards,
Bjorn
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> [mani: reworded the description to be more elaborative]
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
>
> This patch was part of an old series that didn't make it to mainline due to
> objections in the binding and exposing CPU_SUSPEND as S2RAM patches:
> https://lore.kernel.org/all/20241028-topic-cpu_suspend_s2ram-v1-0-9fdd9a04b75c@oss.qualcomm.com/
>
> But this patch on its own is useful for platforms implementing the S2RAM
> feature in PSCI firmware. So I picked it up, tested on Qcom X1E T14s and
> resending it.
>
> drivers/firmware/psci/psci.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 38ca190d4a22..e73bae6cb23a 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -539,12 +539,22 @@ static int psci_system_suspend(unsigned long unused)
>
> static int psci_system_suspend_enter(suspend_state_t state)
> {
> + pm_set_resume_via_firmware();
> +
> return cpu_suspend(0, psci_system_suspend);
> }
>
> +static int psci_system_suspend_begin(suspend_state_t state)
> +{
> + pm_set_suspend_via_firmware();
> +
> + return 0;
> +}
> +
> static const struct platform_suspend_ops psci_suspend_ops = {
> .valid = suspend_valid_only_mem,
> .enter = psci_system_suspend_enter,
> + .begin = psci_system_suspend_begin,
> };
>
> static void __init psci_init_system_reset2(void)
> --
> 2.48.1
>
^ permalink raw reply
* ✅ PASS: Test report for for-kernelci (7.0.0-rc5, upstream-arm-next, f97a8538)
From: cki-project @ 2026-03-30 20:53 UTC (permalink / raw)
To: will, catalin.marinas, linux-arm-kernel
Hi, we tested your kernel and here are the results:
Overall result: PASSED
Merge: OK
Compile: OK
Test: OK
Tested-by: CKI Project <cki-project@redhat.com>
Kernel information:
Commit message: Merge branch 'devel/linus-uaccess' into for-kernelci
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:2418826285
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
^ permalink raw reply
* [PATCHv2] clk: kirkwood: use kzalloc_flex
From: Rosen Penev @ 2026-03-30 20:55 UTC (permalink / raw)
To: linux-clk
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Michael Turquette, Stephen Boyd, Kees Cook, Gustavo A. R. Silva,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
Simplify allocation by using a flexible array member and kzalloc_flex to
combine allocations.
Add __counted_by for extra runtime analysis. Move counting variable
assignment to right after allocation as required by __counted_by.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
v2: remove unused goto.
drivers/clk/mvebu/kirkwood.c | 21 ++++++++-------------
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/mvebu/kirkwood.c b/drivers/clk/mvebu/kirkwood.c
index ed061d82fb65..f4f62b241193 100644
--- a/drivers/clk/mvebu/kirkwood.c
+++ b/drivers/clk/mvebu/kirkwood.c
@@ -253,8 +253,8 @@ struct clk_muxing_soc_desc {
struct clk_muxing_ctrl {
spinlock_t *lock;
- struct clk **muxes;
int num_muxes;
+ struct clk *muxes[] __counted_by(num_muxes);
};
static const char *powersave_parents[] = {
@@ -297,21 +297,18 @@ static void __init kirkwood_clk_muxing_setup(struct device_node *np,
if (WARN_ON(!base))
return;
- ctrl = kzalloc_obj(*ctrl);
- if (WARN_ON(!ctrl))
- goto ctrl_out;
-
- /* lock must already be initialized */
- ctrl->lock = &ctrl_gating_lock;
-
/* Count, allocate, and register clock muxes */
for (n = 0; desc[n].name;)
n++;
+ ctrl = kzalloc_flex(*ctrl, muxes, n);
+ if (WARN_ON(!ctrl))
+ goto ctrl_out;
+
ctrl->num_muxes = n;
- ctrl->muxes = kzalloc_objs(struct clk *, ctrl->num_muxes);
- if (WARN_ON(!ctrl->muxes))
- goto muxes_out;
+
+ /* lock must already be initialized */
+ ctrl->lock = &ctrl_gating_lock;
for (n = 0; n < ctrl->num_muxes; n++) {
ctrl->muxes[n] = clk_register_mux(NULL, desc[n].name,
@@ -324,8 +321,6 @@ static void __init kirkwood_clk_muxing_setup(struct device_node *np,
of_clk_add_provider(np, clk_muxing_get_src, ctrl);
return;
-muxes_out:
- kfree(ctrl);
ctrl_out:
iounmap(base);
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v13 10/48] arm64: RMI: Ensure that the RMM has GPT entries for memory
From: Mathieu Poirier @ 2026-03-30 20:58 UTC (permalink / raw)
To: Steven Price
Cc: kvm, kvmarm, Catalin Marinas, Marc Zyngier, Will Deacon,
James Morse, Oliver Upton, Suzuki K Poulose, Zenghui Yu,
linux-arm-kernel, linux-kernel, Joey Gouly, Alexandru Elisei,
Christoffer Dall, Fuad Tabba, linux-coco, Ganapatrao Kulkarni,
Gavin Shan, Shanker Donthineni, Alper Gun, Aneesh Kumar K . V,
Emi Kisanuki, Vishal Annapurve
In-Reply-To: <20260318155413.793430-11-steven.price@arm.com>
Hi,
On Wed, Mar 18, 2026 at 03:53:34PM +0000, Steven Price wrote:
> The RMM may not be tracking all the memory of the system at boot. Create
> the necessary tracking state and GPTs within the RMM so that all boot
> memory can be delegated to the RMM as needed during runtime.
>
> Note: support is currently missing for SROs which means that if the RMM
> needs memory donating this will fail (and render CCA unusable in Linux).
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> New patch for v13
> ---
> arch/arm64/kvm/rmi.c | 89 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 89 insertions(+)
>
> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
> index 9590dff9a2c1..80aedc85e94a 100644
> --- a/arch/arm64/kvm/rmi.c
> +++ b/arch/arm64/kvm/rmi.c
> @@ -4,6 +4,7 @@
> */
>
> #include <linux/kvm_host.h>
> +#include <linux/memblock.h>
>
> #include <asm/kvm_pgtable.h>
> #include <asm/rmi_cmds.h>
> @@ -56,6 +57,18 @@ static int rmi_check_version(void)
> return 0;
> }
>
> +/*
> + * These are the 'default' sizes when passing 0 as the tracking_region_size.
> + * TODO: Support other granule sizes
> + */
> +#ifdef CONFIG_PAGE_SIZE_4KB
> +#define RMM_GRANULE_TRACKING_SIZE SZ_1G
> +#elif defined(CONFIG_PAGE_SIZE_16KB)
> +#define RMM_GRANULE_TRACKING_SIZE SZ_32M
> +#elif defined(CONFIG_PAGE_SIZE_64KB)
> +#define RMM_GRANULE_TRACKING_SIZE SZ_512M
> +#endif
> +
> static int rmi_configure(void)
> {
> struct rmm_config *config __free(free_page) = NULL;
> @@ -95,6 +108,80 @@ static int rmi_configure(void)
> return 0;
> }
>
> +static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t end)
> +{
> + start = ALIGN_DOWN(start, RMM_GRANULE_TRACKING_SIZE);
This will produce an error on systems where the start of system memory is not
aligned to RMM_GRANULE_TRACKING_SIZE. For instance, on QEMU-SBSA the system
memory starts at 0x100_4300_0000. With the above and RMM_GRANULE_TRACKING_SIZE
set to SZ_1G, @start becomes 0x100_4000_0000, which falls outside the memory map
known to the TF-A. I fixed it with these modifications:
LINUX:
diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
index 10ff1c3bddaf..21bfbbe2f047 100644
--- a/arch/arm64/kvm/rmi.c
+++ b/arch/arm64/kvm/rmi.c
@@ -424,7 +424,9 @@ static int rmi_configure(void)
static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t end)
{
- start = ALIGN_DOWN(start, RMM_GRANULE_TRACKING_SIZE);
+ phys_addr_t offset;
+
+ offset = start - ALIGN_DOWN(start, RMM_GRANULE_TRACKING_SIZE);
end = ALIGN(end, RMM_GRANULE_TRACKING_SIZE);
while (start < end) {
@@ -439,7 +441,13 @@ static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t end)
start);
return -ENODEV;
}
- start += RMM_GRANULE_TRACKING_SIZE;
+
+ if (offset) {
+ start += (RMM_GRANULE_TRACKING_SIZE - offset);
+ offset = 0;
+ } else {
+ start += RMM_GRANULE_TRACKING_SIZE;
+ }
}
return 0;
RMM:
diff --git a/runtime/rmi/granule.c b/runtime/rmi/granule.c
index cef521fc0869..60358d9ee81e 100644
--- a/runtime/rmi/granule.c
+++ b/runtime/rmi/granule.c
@@ -209,9 +209,11 @@ void smc_granule_tracking_get(unsigned long addr,
return;
}
+#if 0
if (!ALIGNED(addr, RMM_INTERNAL_TRACKING_REGION_SIZE)) {
return;
}
+#endif
g = find_granule(addr);
if (g != NULL) {
This is likely not the right fix but hopefully provides some guidance. Send me
your patches when you have an idea and I'll test them.
Thanks,
Mathieu
> + end = ALIGN(end, RMM_GRANULE_TRACKING_SIZE);
> +
> + while (start < end) {
> + unsigned long ret, category, state;
> +
> + ret = rmi_granule_tracking_get(start, &category, &state);
> + if (ret != RMI_SUCCESS ||
> + state != RMI_TRACKING_FINE ||
> + category != RMI_MEM_CATEGORY_CONVENTIONAL) {
> + /* TODO: Set granule tracking in this case */
> + kvm_err("Granule tracking for region isn't fine/conventional: %llx",
> + start);
> + return -ENODEV;
> + }
> + start += RMM_GRANULE_TRACKING_SIZE;
> + }
> +
> + return 0;
> +}
> +
> +static unsigned long rmi_l0gpt_size(void)
> +{
> + return 1UL << (30 + FIELD_GET(RMI_FEATURE_REGISTER_1_L0GPTSZ,
> + rmm_feat_reg1));
> +}
> +
> +static int rmi_create_gpts(phys_addr_t start, phys_addr_t end)
> +{
> + unsigned long l0gpt_sz = rmi_l0gpt_size();
> +
> + start = ALIGN_DOWN(start, l0gpt_sz);
> + end = ALIGN(end, l0gpt_sz);
> +
> + while (start < end) {
> + int ret = rmi_gpt_l1_create(start);
> +
> + if (ret && ret != RMI_ERROR_GPT) {
> + /*
> + * FIXME: Handle SRO so that memory can be donated for
> + * the tables.
> + */
> + kvm_err("GPT Level1 table missing for %llx\n", start);
> + return -ENOMEM;
> + }
> + start += l0gpt_sz;
> + }
> +
> + return 0;
> +}
> +
> +static int rmi_init_metadata(void)
> +{
> + phys_addr_t start, end;
> + const struct memblock_region *r;
> +
> + for_each_mem_region(r) {
> + int ret;
> +
> + start = memblock_region_memory_base_pfn(r) << PAGE_SHIFT;
> + end = memblock_region_memory_end_pfn(r) << PAGE_SHIFT;
> + ret = rmi_verify_memory_tracking(start, end);
> + if (ret)
> + return ret;
> + ret = rmi_create_gpts(start, end);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> static int rmm_check_features(void)
> {
> if (kvm_lpa2_is_enabled() && !rmi_has_feature(RMI_FEATURE_REGISTER_0_LPA2)) {
> @@ -120,6 +207,8 @@ void kvm_init_rmi(void)
> return;
> if (rmi_configure())
> return;
> + if (rmi_init_metadata())
> + return;
>
> /* Future patch will enable static branch kvm_rmi_is_available */
> }
> --
> 2.43.0
>
>
^ permalink raw reply related
* Re: [PATCH v2 2/8] perf build loongarch: Remove reference to missing file
From: Arnaldo Carvalho de Melo @ 2026-03-30 21:05 UTC (permalink / raw)
To: Ian Rogers
Cc: 9erthalion6, adrian.hunter, alex, alexander.shishkin,
andrew.jones, aou, atrajeev, blakejones, ctshao, dapeng1.mi,
howardchu95, james.clark, john.g.garry, jolsa, leo.yan,
libunwind-devel, linux-arm-kernel, linux-kernel, linux-perf-users,
linux-riscv, mingo, namhyung, palmer, peterz, pjw, shimin.guo,
tglozar, tmricht, will, yuzhuo
In-Reply-To: <20260305221927.3237145-3-irogers@google.com>
On Thu, Mar 05, 2026 at 02:19:21PM -0800, Ian Rogers wrote:
> The file was removed in commit e62fae9d9e85 ("perf unwind-libdw: Fix a
> cross-arch unwinding bug") but the Build file not updated.
>
> Fixes: commit e62fae9d9e85 ("perf unwind-libdw: Fix a cross-arch unwinding bug")
Removing the 'commit' part.
- Arnaldo
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> tools/perf/arch/loongarch/util/Build | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/tools/perf/arch/loongarch/util/Build b/tools/perf/arch/loongarch/util/Build
> index 3ad73d0289f3..8d91e78d31c9 100644
> --- a/tools/perf/arch/loongarch/util/Build
> +++ b/tools/perf/arch/loongarch/util/Build
> @@ -1,4 +1,3 @@
> perf-util-y += header.o
>
> perf-util-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o
> -perf-util-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o
> --
> 2.53.0.473.g4a7958ca14-goog
^ permalink raw reply
* Re: [PATCH v2 3/8] tools build: Deduplicate test-libunwind for different architectures
From: Arnaldo Carvalho de Melo @ 2026-03-30 21:08 UTC (permalink / raw)
To: Ian Rogers
Cc: 9erthalion6, adrian.hunter, alex, alexander.shishkin,
andrew.jones, aou, atrajeev, blakejones, ctshao, dapeng1.mi,
howardchu95, james.clark, john.g.garry, jolsa, leo.yan,
libunwind-devel, linux-arm-kernel, linux-kernel, linux-perf-users,
linux-riscv, mingo, namhyung, palmer, peterz, pjw, shimin.guo,
tglozar, tmricht, will, yuzhuo
In-Reply-To: <20260305221927.3237145-4-irogers@google.com>
On Thu, Mar 05, 2026 at 02:19:22PM -0800, Ian Rogers wrote:
> The separate test files only exist to pass a different #include,
> instead have a single source file and pass -include to $(CC) to
> include the relevant header file for the architecture being
> tested. Generate the rules using a foreach loop. Include tests for all
> current libunwind architectures.
Clever :-)
- Arnaldo
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> tools/build/feature/Makefile | 38 +++++++++----------
> tools/build/feature/test-libunwind-aarch64.c | 27 -------------
> tools/build/feature/test-libunwind-arm.c | 28 --------------
> .../test-libunwind-debug-frame-aarch64.c | 17 ---------
> .../feature/test-libunwind-debug-frame-arm.c | 17 ---------
> .../feature/test-libunwind-debug-frame.c | 1 -
> tools/build/feature/test-libunwind-x86.c | 28 --------------
> tools/build/feature/test-libunwind-x86_64.c | 28 --------------
> tools/build/feature/test-libunwind.c | 1 -
> 9 files changed, 19 insertions(+), 166 deletions(-)
> delete mode 100644 tools/build/feature/test-libunwind-aarch64.c
> delete mode 100644 tools/build/feature/test-libunwind-arm.c
> delete mode 100644 tools/build/feature/test-libunwind-debug-frame-aarch64.c
> delete mode 100644 tools/build/feature/test-libunwind-debug-frame-arm.c
> delete mode 100644 tools/build/feature/test-libunwind-x86.c
> delete mode 100644 tools/build/feature/test-libunwind-x86_64.c
>
> diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
> index 1fbcb3ce74d2..a0b40e826688 100644
> --- a/tools/build/feature/Makefile
> +++ b/tools/build/feature/Makefile
> @@ -204,27 +204,27 @@ $(OUTPUT)test-numa_num_possible_cpus.bin:
> $(BUILD) -lnuma
>
> $(OUTPUT)test-libunwind.bin:
> - $(BUILD) -lelf -llzma
> + $(BUILD) -include libunwind.h -lelf -llzma -lunwind
>
> $(OUTPUT)test-libunwind-debug-frame.bin:
> - $(BUILD) -lelf -llzma
> -$(OUTPUT)test-libunwind-x86.bin:
> - $(BUILD) -lelf -llzma -lunwind-x86
> -
> -$(OUTPUT)test-libunwind-x86_64.bin:
> - $(BUILD) -lelf -llzma -lunwind-x86_64
> -
> -$(OUTPUT)test-libunwind-arm.bin:
> - $(BUILD) -lelf -llzma -lunwind-arm
> -
> -$(OUTPUT)test-libunwind-aarch64.bin:
> - $(BUILD) -lelf -llzma -lunwind-aarch64
> -
> -$(OUTPUT)test-libunwind-debug-frame-arm.bin:
> - $(BUILD) -lelf -llzma -lunwind-arm
> -
> -$(OUTPUT)test-libunwind-debug-frame-aarch64.bin:
> - $(BUILD) -lelf -llzma -lunwind-aarch64
> + $(BUILD) -include libunwind.h -lelf -llzma -lunwind
> +
> +LIBUNWIND_ARCHS:=aarch64 arm loongarch64 mips ppc32 ppc64 riscv s390x x86 x86_64
> +define LIBUNWIND_RULE
> +$$(OUTPUT)test-libunwind-$(1).bin:
> + $$(CC) $$(CFLAGS) -MD -Wall -Werror -include libunwind-$(1).h -o $$@ \
> + test-libunwind.c $$(LDFLAGS) -lelf -llzma -lunwind-$(1) \
> + > $$(@:.bin=.make.output) 2>&1
> +
> +$$(OUTPUT)test-libunwind-debug-frame-$(1).bin:
> + $$(CC) $$(CFLAGS) -MD -Wall -Werror -include libunwind-$(1).h -o $$@ \
> + test-libunwind-debug-frame.c $$(LDFLAGS) -lelf -llzma -lunwind-$(1) \
> + > $$(@:.bin=.make.output) 2>&1
> +
> +endef
> +$(foreach arch,$(LIBUNWIND_ARCHS), \
> + $(eval $(call LIBUNWIND_RULE,$(arch))) \
> +)
>
> $(OUTPUT)test-libslang.bin:
> $(BUILD) -lslang
> diff --git a/tools/build/feature/test-libunwind-aarch64.c b/tools/build/feature/test-libunwind-aarch64.c
> deleted file mode 100644
> index 323803f49212..000000000000
> --- a/tools/build/feature/test-libunwind-aarch64.c
> +++ /dev/null
> @@ -1,27 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <libunwind-aarch64.h>
> -#include <stdlib.h>
> -
> -extern int UNW_OBJ(dwarf_search_unwind_table) (unw_addr_space_t as,
> - unw_word_t ip,
> - unw_dyn_info_t *di,
> - unw_proc_info_t *pi,
> - int need_unwind_info, void *arg);
> -
> -#define dwarf_search_unwind_table UNW_OBJ(dwarf_search_unwind_table)
> -
> -static unw_accessors_t accessors;
> -
> -int main(void)
> -{
> - unw_addr_space_t addr_space;
> -
> - addr_space = unw_create_addr_space(&accessors, 0);
> - if (addr_space)
> - return 0;
> -
> - unw_init_remote(NULL, addr_space, NULL);
> - dwarf_search_unwind_table(addr_space, 0, NULL, NULL, 0, NULL);
> -
> - return 0;
> -}
> diff --git a/tools/build/feature/test-libunwind-arm.c b/tools/build/feature/test-libunwind-arm.c
> deleted file mode 100644
> index cb378b7d6866..000000000000
> --- a/tools/build/feature/test-libunwind-arm.c
> +++ /dev/null
> @@ -1,28 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <libunwind-arm.h>
> -#include <stdlib.h>
> -
> -extern int UNW_OBJ(dwarf_search_unwind_table) (unw_addr_space_t as,
> - unw_word_t ip,
> - unw_dyn_info_t *di,
> - unw_proc_info_t *pi,
> - int need_unwind_info, void *arg);
> -
> -
> -#define dwarf_search_unwind_table UNW_OBJ(dwarf_search_unwind_table)
> -
> -static unw_accessors_t accessors;
> -
> -int main(void)
> -{
> - unw_addr_space_t addr_space;
> -
> - addr_space = unw_create_addr_space(&accessors, 0);
> - if (addr_space)
> - return 0;
> -
> - unw_init_remote(NULL, addr_space, NULL);
> - dwarf_search_unwind_table(addr_space, 0, NULL, NULL, 0, NULL);
> -
> - return 0;
> -}
> diff --git a/tools/build/feature/test-libunwind-debug-frame-aarch64.c b/tools/build/feature/test-libunwind-debug-frame-aarch64.c
> deleted file mode 100644
> index 36d6646c185e..000000000000
> --- a/tools/build/feature/test-libunwind-debug-frame-aarch64.c
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <libunwind-aarch64.h>
> -#include <stdlib.h>
> -
> -extern int
> -UNW_OBJ(dwarf_find_debug_frame) (int found, unw_dyn_info_t *di_debug,
> - unw_word_t ip, unw_word_t segbase,
> - const char *obj_name, unw_word_t start,
> - unw_word_t end);
> -
> -#define dwarf_find_debug_frame UNW_OBJ(dwarf_find_debug_frame)
> -
> -int main(void)
> -{
> - dwarf_find_debug_frame(0, NULL, 0, 0, NULL, 0, 0);
> - return 0;
> -}
> diff --git a/tools/build/feature/test-libunwind-debug-frame-arm.c b/tools/build/feature/test-libunwind-debug-frame-arm.c
> deleted file mode 100644
> index 8696e48e1268..000000000000
> --- a/tools/build/feature/test-libunwind-debug-frame-arm.c
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <libunwind-arm.h>
> -#include <stdlib.h>
> -
> -extern int
> -UNW_OBJ(dwarf_find_debug_frame) (int found, unw_dyn_info_t *di_debug,
> - unw_word_t ip, unw_word_t segbase,
> - const char *obj_name, unw_word_t start,
> - unw_word_t end);
> -
> -#define dwarf_find_debug_frame UNW_OBJ(dwarf_find_debug_frame)
> -
> -int main(void)
> -{
> - dwarf_find_debug_frame(0, NULL, 0, 0, NULL, 0, 0);
> - return 0;
> -}
> diff --git a/tools/build/feature/test-libunwind-debug-frame.c b/tools/build/feature/test-libunwind-debug-frame.c
> index efb55cdd8d01..4c57e37004b3 100644
> --- a/tools/build/feature/test-libunwind-debug-frame.c
> +++ b/tools/build/feature/test-libunwind-debug-frame.c
> @@ -1,5 +1,4 @@
> // SPDX-License-Identifier: GPL-2.0
> -#include <libunwind.h>
> #include <stdlib.h>
>
> extern int
> diff --git a/tools/build/feature/test-libunwind-x86.c b/tools/build/feature/test-libunwind-x86.c
> deleted file mode 100644
> index e5e0f6c89637..000000000000
> --- a/tools/build/feature/test-libunwind-x86.c
> +++ /dev/null
> @@ -1,28 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <libunwind-x86.h>
> -#include <stdlib.h>
> -
> -extern int UNW_OBJ(dwarf_search_unwind_table) (unw_addr_space_t as,
> - unw_word_t ip,
> - unw_dyn_info_t *di,
> - unw_proc_info_t *pi,
> - int need_unwind_info, void *arg);
> -
> -
> -#define dwarf_search_unwind_table UNW_OBJ(dwarf_search_unwind_table)
> -
> -static unw_accessors_t accessors;
> -
> -int main(void)
> -{
> - unw_addr_space_t addr_space;
> -
> - addr_space = unw_create_addr_space(&accessors, 0);
> - if (addr_space)
> - return 0;
> -
> - unw_init_remote(NULL, addr_space, NULL);
> - dwarf_search_unwind_table(addr_space, 0, NULL, NULL, 0, NULL);
> -
> - return 0;
> -}
> diff --git a/tools/build/feature/test-libunwind-x86_64.c b/tools/build/feature/test-libunwind-x86_64.c
> deleted file mode 100644
> index 62ae4db597dc..000000000000
> --- a/tools/build/feature/test-libunwind-x86_64.c
> +++ /dev/null
> @@ -1,28 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <libunwind-x86_64.h>
> -#include <stdlib.h>
> -
> -extern int UNW_OBJ(dwarf_search_unwind_table) (unw_addr_space_t as,
> - unw_word_t ip,
> - unw_dyn_info_t *di,
> - unw_proc_info_t *pi,
> - int need_unwind_info, void *arg);
> -
> -
> -#define dwarf_search_unwind_table UNW_OBJ(dwarf_search_unwind_table)
> -
> -static unw_accessors_t accessors;
> -
> -int main(void)
> -{
> - unw_addr_space_t addr_space;
> -
> - addr_space = unw_create_addr_space(&accessors, 0);
> - if (addr_space)
> - return 0;
> -
> - unw_init_remote(NULL, addr_space, NULL);
> - dwarf_search_unwind_table(addr_space, 0, NULL, NULL, 0, NULL);
> -
> - return 0;
> -}
> diff --git a/tools/build/feature/test-libunwind.c b/tools/build/feature/test-libunwind.c
> index 53fd26614ff0..5af5dc3a73d4 100644
> --- a/tools/build/feature/test-libunwind.c
> +++ b/tools/build/feature/test-libunwind.c
> @@ -1,5 +1,4 @@
> // SPDX-License-Identifier: GPL-2.0
> -#include <libunwind.h>
> #include <stdlib.h>
>
> extern int UNW_OBJ(dwarf_search_unwind_table) (unw_addr_space_t as,
> --
> 2.53.0.473.g4a7958ca14-goog
>
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Christian Schrefl @ 2026-03-30 21:09 UTC (permalink / raw)
To: Miguel Ojeda, Russell King (Oracle), Alice Ryhl
Cc: Ard Biesheuvel, Jamie Cunliffe, Will Deacon, Catalin Marinas,
Miguel Ojeda, a.hindborg, acourbot, akpm, anton.ivanov, bjorn3_gh,
boqun.feng, dakr, david, gary, johannes, justinstitt,
linux-arm-kernel, linux-kbuild, linux-kernel, linux-mm, linux-um,
llvm, lossin, mark.rutland, mmaurer, morbo, nathan,
nick.desaulniers+lkml, nicolas.schier, nsc, peterz, richard,
rust-for-linux, tmgross, urezki
In-Reply-To: <CANiq72=b+cr7Stxph_hXQTmD5crCvwWTqdaGKOJ7W1-66v4i_w@mail.gmail.com>
On 3/26/26 6:30 PM, Miguel Ojeda wrote:
> On Thu, Mar 26, 2026 at 4:18 PM Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
>>
>> I'm not sure if this is still true, but I believe it used to be the case
>> that the -linux-gnueabi target has one behaviour for enums (fixed size)
>> whereas -none-eabi, the size of the type depends on the range of values
>> included in the enum.
>>
>> Certianly, when Arm Ltd were proposing EABI, EABI had the latter
>> behaviour, and I think there were cases where Linux used "enum" in
>> its UAPI.
>
> Short enums? I see `c-enum-min-bits` in the armv7a-none-eabi built-in
> `rustc` target, and indeed:
>
> #![no_std]
>
> #[repr(C)]
> enum T {
> A,
> B,
> }
>
> pub static S: usize = core::mem::size_of::<T>();
>
> is 1 for that one, and 4 for the other.
I guess we could use a custom target spec, but I'm not
sure if that is worth the hassle of adding another one.
Cheers,
Christian
^ permalink raw reply
* Re: [PATCH v2 1/3] ARM: dts: ti: Enable overlays for am335x BeagleBoard devicetrees
From: Kevin Hilman @ 2026-03-30 21:14 UTC (permalink / raw)
To: Kory Maincent
Cc: Aaro Koskinen, Andreas Kemnade, Roger Quadros, Tony Lindgren,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Russell King,
Thomas Petazzoni, linux-omap, devicetree, linux-kernel,
linux-arm-kernel, dri-devel, Luca Ceresoli, Bajjuri Praneeth,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Louis Chauvet
In-Reply-To: <20260324103934.7d259008@kmaincent-XPS-13-7390>
Kory Maincent <kory.maincent@bootlin.com> writes:
> Hello Kevin,
>
> On Thu, 05 Mar 2026 17:07:23 -0800
> Kevin Hilman <khilman@baylibre.com> wrote:
>
>> On Mon, 16 Feb 2026 17:55:52 +0100, Kory Maincent (TI) wrote:
>> > Allow overlays to be applied to am335x BeagleBoard boards. This adds
>> > around ~40% to the total size of the DTB files on average.
>> >
>> >
>>
>> Applied, thanks!
>>
>> [1/3] ARM: dts: ti: Enable overlays for am335x BeagleBoard devicetrees
>> commit: 18161bb01ede109fed41c66efa2624a4c27377f7
>>
>> Best regards,
>
> Thanks for merging it.
> I see that you have merged patch 1 and 2 in your for-next branch.
> Is there a reason to not merge the patch 3? Are you waiting for a dts
> maintainer ack?
>
> Maybe I can resend only the 3rd patch to ping the dts maintainers.
Not necessary. I'm not sure how/why I missed patch 3. It's now queued
in my tree.
Thanks for letting me know,
Kevin
^ permalink raw reply
* [PATCH] dmaengine: st_fdma: simplify allocation
From: Rosen Penev @ 2026-03-30 21:15 UTC (permalink / raw)
To: dmaengine
Cc: Patrice Chotard, Vinod Koul, Frank Li, Kees Cook,
Gustavo A. R. Silva, moderated list:ARM/STI ARCHITECTURE,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
Use a flexible array member to combine kzalloc and kcalloc to a single
allocation.
Add __counted_by for extra runtime analysis. Assign counting variable
after allocation as required by __counted_by.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/dma/st_fdma.c | 27 ++++++++-------------------
drivers/dma/st_fdma.h | 4 ++--
2 files changed, 10 insertions(+), 21 deletions(-)
diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
index d9547017f3bd..3ec0d6731b8d 100644
--- a/drivers/dma/st_fdma.c
+++ b/drivers/dma/st_fdma.c
@@ -710,16 +710,6 @@ static const struct of_device_id st_fdma_match[] = {
};
MODULE_DEVICE_TABLE(of, st_fdma_match);
-static int st_fdma_parse_dt(struct platform_device *pdev,
- const struct st_fdma_driverdata *drvdata,
- struct st_fdma_dev *fdev)
-{
- snprintf(fdev->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf",
- drvdata->name, drvdata->id);
-
- return of_property_read_u32(pdev->dev.of_node, "dma-channels",
- &fdev->nr_channels);
-}
#define FDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
@@ -742,27 +732,26 @@ static int st_fdma_probe(struct platform_device *pdev)
struct st_fdma_dev *fdev;
struct device_node *np = pdev->dev.of_node;
const struct st_fdma_driverdata *drvdata;
+ u32 nr_channels;
int ret, i;
drvdata = device_get_match_data(&pdev->dev);
- fdev = devm_kzalloc(&pdev->dev, sizeof(*fdev), GFP_KERNEL);
- if (!fdev)
- return -ENOMEM;
-
- ret = st_fdma_parse_dt(pdev, drvdata, fdev);
+ ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", &nr_channels);
if (ret) {
dev_err(&pdev->dev, "unable to find platform data\n");
- goto err;
+ return ret;
}
- fdev->chans = devm_kcalloc(&pdev->dev, fdev->nr_channels,
- sizeof(struct st_fdma_chan), GFP_KERNEL);
- if (!fdev->chans)
+ fdev = devm_kzalloc(&pdev->dev, struct_size(fdev, chans, nr_channels), GFP_KERNEL);
+ if (!fdev)
return -ENOMEM;
+ fdev->nr_channels = nr_channels;
fdev->dev = &pdev->dev;
fdev->drvdata = drvdata;
+ snprintf(fdev->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf", drvdata->name, drvdata->id);
+
platform_set_drvdata(pdev, fdev);
fdev->irq = platform_get_irq(pdev, 0);
diff --git a/drivers/dma/st_fdma.h b/drivers/dma/st_fdma.h
index f1e746f7bc7d..27ded555879f 100644
--- a/drivers/dma/st_fdma.h
+++ b/drivers/dma/st_fdma.h
@@ -136,13 +136,13 @@ struct st_fdma_dev {
int irq;
- struct st_fdma_chan *chans;
-
spinlock_t dreq_lock;
unsigned long dreq_mask;
u32 nr_channels;
char fw_name[FW_NAME_SIZE];
+
+ struct st_fdma_chan chans[] __counted_by(nr_channels);
};
/* Peripheral Registers*/
--
2.53.0
^ permalink raw reply related
* Re: i.MX8MP: Fix HDMI LCDIF FIFO underruns
From: Paul Kocialkowski @ 2026-03-30 21:16 UTC (permalink / raw)
To: Lucas Stach
Cc: Krzysztof Hałasa, Liu Ying, Maxime Ripard, Marco Felsch,
Marek Vasut, Stefan Agner, Simona Vetter, imx, Fabio Estevam,
Pengutronix Kernel Team, Maarten Lankhorst, Sascha Hauer,
Frank Li, linux-kernel, dri-devel, Thomas Zimmermann,
David Airlie, linux-arm-kernel
In-Reply-To: <0e8863b39cc9cab3ef16aedde480c70a158c4cbe.camel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 5322 bytes --]
Hi Lucas,
On Mon 30 Mar 26, 18:44, Lucas Stach wrote:
> Am Montag, dem 30.03.2026 um 18:09 +0200 schrieb Paul Kocialkowski:
> > After weeks of investigation I finally narrowed it down to a part of the nxp
> > original code that is missing in the upstream driver:
> > https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy/drivers/gpu/imx/lcdifv3/lcdifv3-common.c#L492
> >
> Thanks for tracking this down! It was also on my list of things to look
> at.
Glad that it helps :)
> > A big old sleep that waits for the DMA engine to finish handling the current
> > frame before it is disabled. When this delay is not respected, there seems to
> > be "unlucky" times when disabling the DMA engine too early will confuse the
> > unit and make it unable to resume proper operation later.
> >
> I think we can be a bit more clever than a indiscriminate sleep. If we
> set the shadow load enable bit in the disable sequence, we should be
> able to wait for this bit to be cleared by the hardware. All the DMA
> parameters (presumably including the enable state) should be applied by
> the hardware when this bit is cleared.
I just tried it out and it works fine, thanks! It polls for a variable delay
from < 1 ms to < 16 ms, which makes perfect sense for a 60 Hz mode.
This is much better than the hardcoded 25 ms. I'll add your Co-developed-by tag
to the final commit.
> I guess the read_poll_timeout in lcdif_disable_controller() was
> supposed to do exactly that wait, but as it was actually copied from
> the mxsfb driver, it's not working as intended. It's my understanding
> that the old lcdif HW only cleared the enable bit once it is actually
> done, but on the lcdifv3 on i.MX8MP those states are double buffered,
> so the bit in the register would be cleared instantaneously, rendering
> the wait in the current code a no-op. The only reliable indicator to
> see if the HW has updated it's internal state is to set the shadow load
> enable bit and wait for it to be cleared.
Sounds right to me. Thanks for the details! Are there resources about the
different generations/families used by nxp/freescale? They seem to be in-house
designs but with lots of different variations.
> > It is a bit surprising that the issue is not actually related to configuring
> > the display engine but to disabling it. This is why the first mode set always
> > works but subsequentil ones might fail. The crtc is essentially disabled and
> > re-enabled each time a new mode is applied.
> >
> > Adding the sleep solves the issue on my side and all mode sets now work
> > reliably. It does add a delay before returning to userspace when configuring
> > a new mode, but it seems legitimate to me if the underlying hardware is still
> > in-flight. I'm also unsure if it would apply to an async atomic commit.
> >
> This hardware doesn't support async commits. All DMA state changes are
> applied during vblank when the shadow load enable bit is set.
Ah sorry I meant non-blocking atomic commit, not async. Since this is in the
CRTC disable path, it probably makes the userspace process sleep even in the
case of a non-blocking commit (unless this happens in a kernel thread, I'm not
sure exactly). But I guess it is legitimate to block until the previous frame
is finished if it is mandatory.
All the best,
Paul
>
> Regards,
> Lucas
>
> > I will send a patch adding the delay and the undocumented fifo clear
> > bit that was discovered in this thread too.
> >
> > All the best,
> >
> > Paul
> >
> > Perhaps there is a more elegant way to handle this
> >
> >
> > > Interestingly, Weston usually starts fine in subsequent launches.
> > >
> > > How is this first (actually second - after the first VSYNC) frame
> > > different from all the others? Maybe we're programming UPDATE_SHADOW
> > > after the actual start of blanking period, but before DE, so it has no
> > > chance to reload registers, yet the DMA is somehow not ready?
> > >
> > > The manual (LCDIF display control Register (CTRL)) suggests that the DMA
> > > (with present settings) starts to fetch FB data at the end of the
> > > previous active video pixel time (DE and pixel data going inactive):
> > > fetch_start_option (bits 9-8): Indicates when to start fetching for new
> > > frame. This signals also decide the shadow load, fifo clear time
> > > 00b - fetch start as soon as FPV begins(as the end of the data_enable).
> > >
> > > This should leave a lot of time to fill the FIFO (before the next DE),
> > > shouldn't it?
> > >
> > > 297 MHz pixclk, 3840x2160, 30 Hz, H back porch 296 pixclks, Vfp 176,
> > > V back porch 72 lines, Hfp 8 lines, VSYNC 10 lines, HSYNC 88 pixclks.
> > > HTotal = 4400 pixels which makes Vactive time = 4400 * 2160/297e6 =
> > > 32 ms, with the remaining 1.3333 ms for all the V sync stuff.
> > > --
> > > Krzysztof "Chris" Hałasa
> > >
> > > Sieć Badawcza Łukasiewicz
> > > Przemysłowy Instytut Automatyki i Pomiarów PIAP
> > > Al. Jerozolimskie 202, 02-486 Warszawa
> >
>
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCHv2] ARM: omap2: simplify allocation for omap_device
From: Kevin Hilman @ 2026-03-30 21:20 UTC (permalink / raw)
To: Rosen Penev, linux-omap
Cc: Aaro Koskinen, Andreas Kemnade, Roger Quadros, Tony Lindgren,
Russell King, Kees Cook, Gustavo A. R. Silva,
moderated list:ARM SUB-ARCHITECTURES, open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260327191104.206512-1-rosenp@gmail.com>
Rosen Penev <rosenp@gmail.com> writes:
> Use a flexible array member to combine allocations.
>
> Add __counted_by for extra runtime analysis.
>
> Remove goto paths as they are not really needed anymore.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Could you please add a bit more explanation about the *why* behind this
patch. Your description tells us *what* you are doing, but is a bit
light on the *why*.
Thanks,
Kevin
^ 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