From: Pauli Virtanen <pav@iki.fi>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: linux-bluetooth@vger.kernel.org,
linux-mediatek <linux-mediatek@lists.infradead.org>
Subject: Re: [PATCH] Bluetooth: btusb: deal with MT7925 invalid ISO RX packets
Date: Sat, 25 Apr 2026 00:11:55 +0300 [thread overview]
Message-ID: <9aa316a561086294bdb4932241d96e1cd1d913cc.camel@iki.fi> (raw)
In-Reply-To: <CABBYNZ+DhKq9_1kW0Xt6NgDPjMnAVjNXs+DPk-zbVFkhfDR9Uw@mail.gmail.com>
Hi Luiz,
pe, 2026-04-24 kello 15:47 -0400, Luiz Augusto von Dentz kirjoitti:
> On Fri, Apr 24, 2026 at 3:38 PM Pauli Virtanen <pav@iki.fi> wrote:
> >
> > MT7925 produces empty ISO packets for Handle 0 when RX is active:
> >
> > > ISO Data RX: Handle 0 SN 36734 flags 0x00 dlen 0 slen 58 #851 [hci0]
> > > ISO Data RX: Handle 0 SN 36734 flags 0x00 dlen 0 slen 58 #852 [hci0]
> >
> > The driver should filter these out before passing to hci_core, otherwise
> > it will printk "Bluetooth: hci0: ISO packet for unknown connection
> > handle 0" errors.
>
> Aren't these rate limited though?
They are rate limited, yes, but it's still 10 messages every 5 seconds
while RX is active.
These are generated at a fairly high rate, something like ~60 such
packets per each valid ISO packet, so I agree this looks like some
firmware or driver bug.
btmtk has some custom USB code for ISO RX, btmtk_recv_isopkt(), that's
maybe one suspicious place to check.
> > Filter out by adding hdev->classify_pkt_type
> >
> > Signed-off-by: Pauli Virtanen <pav@iki.fi>
> > ---
> > drivers/bluetooth/btmtk.c | 13 +++++++++++++
> > drivers/bluetooth/btmtk.h | 8 ++++++++
> > drivers/bluetooth/btusb.c | 1 +
> > 3 files changed, 22 insertions(+)
> >
> > diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
> > index ab34f1dd42bc..9ba58cc9720a 100644
> > --- a/drivers/bluetooth/btmtk.c
> > +++ b/drivers/bluetooth/btmtk.c
> > @@ -1568,6 +1568,19 @@ int btmtk_recv_event(struct hci_dev *hdev, struct sk_buff *skb)
> > return hci_recv_frame(hdev, skb);
> > }
> > EXPORT_SYMBOL_GPL(btmtk_recv_event);
> > +
> > +u8 btmtk_classify_pkt_type(struct hci_dev *hdev, struct sk_buff *skb)
> > +{
> > + /* MT7925 spams invalid ISO packets during ISO RX */
> > + if (hci_skb_pkt_type(skb) == HCI_ISODATA_PKT &&
> > + skb->len == sizeof(struct hci_iso_hdr) &&
> > + hci_iso_hdr(skb)->handle == 0 &&
> > + hci_iso_hdr(skb)->dlen == 0)
> > + return HCI_DIAG_PKT;
>
> Not really following you here, why would marking it as a diagnostic
> packet make it any better? In fact I do think this needs to print
> something to the output if the firmware generates spurious packets and
> have it fixed in the firmware asap, silently discarding the packets
> just makes the issue undetectable, which I don't think really helps
> users.
The motivation is to not spam user logs with error messages they can do
nothing about. I guess we could eg. emit an error only on the first
such packet.
Maybe it's better to first make sure the issue is not in the driver,
though.
> > +
> > + return hci_skb_pkt_type(skb);
> > +}
> > +EXPORT_SYMBOL_GPL(btmtk_classify_pkt_type);
> > #endif
> >
> > MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
> > diff --git a/drivers/bluetooth/btmtk.h b/drivers/bluetooth/btmtk.h
> > index c83c24897c95..e573b21cecf7 100644
> > --- a/drivers/bluetooth/btmtk.h
> > +++ b/drivers/bluetooth/btmtk.h
> > @@ -222,6 +222,8 @@ int btmtk_usb_setup(struct hci_dev *hdev);
> > int btmtk_usb_shutdown(struct hci_dev *hdev);
> >
> > int btmtk_recv_event(struct hci_dev *hdev, struct sk_buff *skb);
> > +
> > +u8 btmtk_classify_pkt_type(struct hci_dev *hdev, struct sk_buff *skb);
> > #else
> >
> > static inline int btmtk_set_bdaddr(struct hci_dev *hdev,
> > @@ -306,4 +308,10 @@ static inline int btmtk_recv_event(struct hci_dev *hdev, struct sk_buff *skb)
> > {
> > return hci_recv_frame(hdev, skb);
> > }
> > +
> > +static inline u8 btmtk_classify_pkt_type(struct hci_dev *hdev,
> > + struct sk_buff *skb)
> > +{
> > + return hci_skb_pkt_type(skb);
> > +}
> > #endif
> > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > index a0a7da498466..7479928eec4b 100644
> > --- a/drivers/bluetooth/btusb.c
> > +++ b/drivers/bluetooth/btusb.c
> > @@ -4245,6 +4245,7 @@ static int btusb_probe(struct usb_interface *intf,
> > hdev->reset = btmtk_reset_sync;
> > hdev->set_bdaddr = btmtk_set_bdaddr;
> > hdev->send = btusb_send_frame_mtk;
> > + hdev->classify_pkt_type = btmtk_classify_pkt_type;
> > hci_set_quirk(hdev, HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN);
> > hci_set_quirk(hdev, HCI_QUIRK_NON_PERSISTENT_SETUP);
> > data->recv_acl = btmtk_usb_recv_acl;
> > --
> > 2.53.0
> >
> >
>
--
Pauli Virtanen
prev parent reply other threads:[~2026-04-24 21:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-24 19:35 [PATCH] Bluetooth: btusb: deal with MT7925 invalid ISO RX packets Pauli Virtanen
2026-04-24 19:47 ` Luiz Augusto von Dentz
2026-04-24 21:11 ` Pauli Virtanen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9aa316a561086294bdb4932241d96e1cd1d913cc.camel@iki.fi \
--to=pav@iki.fi \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=luiz.dentz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).