[PATCH v2] Bluetooth: btmtk: don't generate bogus ISO packets from zero padding

[Pauli Virtanen]

Hi,

ke, 2026-09-16 kello 10:34 +0000, dt kirjoitti:
> Following up on your v2 proposal:
> https://www.spinics.net/lists/linux-bluetooth/msg129361.html
> 
> Additional evidence for the MT7925 padding issue, from an MT7925 using
> LE Audio on kernel 7.2.4-3-cachyos:
> 
> Before filtering, a capture contained 206,325 spurious handle-zero ISO
> packets. The count matches interpreting the zero remainder of 264-byte
> transfers as four-byte headers: 3,633 genuine 60-byte SDUs and 507 empty
> SDUs give 3633 * 48 + 507 * 63 = 206325. USB URB boundaries were not
> captured, so this is byte-accounting evidence for the padding explanation.
> 
> A local adaptation of this proposal eliminates the phantom packets in
> two subsequent capture summaries, which contain only the real ISO handles
> and no short or truncated ISO headers.
> 
> The tested variant differs from this v2: it uses the existing dev_id to
> restrict filtering to MT7925, leaves btmtk.h unchanged, and omits the
> once-per-device warning. It retains the original 264-byte transfer check
> and discards an all-zero remainder only after consuming some data and
> reaching a new packet boundary. The original v2 itself was not tested.
> 
> The complete local setup has also passed reboot, reconnect and duplex
> profile-switch testing. Separate PipeWire, WirePlumber and BlueZ fixes
> were involved, so the specific result attributable to this filter is the
> removal of the bogus padding packets.
> 
> As of 2026-09-16, the receive loops in bluetooth-next at 2e63b55654e0
> and Linux at 9b87fdc9af2f still lack a trailing-padding check. Would a
> refresh of this proposal be useful? Has MediaTek confirmed whether the
> fixed-size zero padding is intentional, which would inform retaining or
> removing the warning?

It's probably intentional since IIRC the host -> controller direction
has same padding.

There was no comment / fix from Mediatek, so it probably should be
resent since it seems like driver bug.

BTW, did you test the latest 20260813113236 firmware version too?
https://gitlab.com/kernel-firmware/linux-firmware/-/tree/main/mediatek/mt7925

-- 
Pauli Virtanen