Hi Thorsten,
On Wed, 2024-10-30 at 12:29 +0100, Thorsten Leemhuis wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> On 30.10.24 12:03, Chris Lu (陸稚泓) wrote:
> >
> > Let me recap and update the status of this problem.
>
> Many thx!
>
> > Marc feedback that he has some problem with MT7921AUN usb module.
> > Originally, we thought it was caused by the change "Fixes:
> > ccfc8948d7e4d9 ("Bluetooth: btusb: mediatek: reset the controller
> > before downloading the fw")". The change is mainly for MT7922, we
> > found some problem with MT7921 on specific platform internally. As
> > a result, Hao sent another patch to remove MT7921 from that
> > rule(Bluetooth: btmtk: Remove resetting mt7921 before downloading
> > the fw).
> >
> > However, Marc also mentioned that BT is able to work if changing
> > back
> > to an old firmware bin. Based on the clue, we found it was caused
> > by a
> > firmware change that specific MT7921 model will not able to setup
> > successfully. (In fact, we didn't expect that MT7921AUN can be get
> > by
> > normal user.)
> >
> > Since we can't predict which model user use and Luiz also suggests
> > MediaTek to fix it if that model can work before, we have prepared
> > a
> > solution. I've verified the solution locally that MT7921AUN model
> > can
> > work normally on Ubuntu PC. It will be a firmware modification. We
> > plan
> > to submit new firmware with this modification in 2024 Nov.
>
> Great, but due to the kernel's "no regressions" rule this is mostly
> irrelevant, as the regression must be fixed in a way that does not
> require users to change their firmware.
>
Marc's module(MT7921AUN) is not working is due to a change in specific
firmware uploaded last year and we plan to revert that in the next
firmware release. Since it's related to controller's behavior, it's
quite hard to cover in software side.
Additionally, MT7921AUN is an external usb dongle. MediaTek official PC
project doesn't use this type of MT7921 model. We uses another type for
PC projects that it can be guaranteed bluetooth works normally with any
firmware we upload to Kernel. As a result, we believe the impact is
minimal to general user.
> So is any such solution in sight? Or should we just revert
> ccfc8948d7e4d9 and any related follow up patches for now? Or would
> that
> just cause regressions for other users?
>
Actually, it's not related to ccfc8948d7e4d9 which make bluetooth can't
setup normally if using MT7921AUN model + mismatched firmware. We
thought it was the same issue in the beginning, but it's not eventually
after getting more and more clue/logs.
I think we can keep the change because it's necessary to the change
submitter-Hao's project.
Chris Lu
> Ciao, Thorsten
>
> > On Wed, 2024-10-30 at 10:21 +0100, Thorsten Leemhuis wrote:
> > > External email : Please do not click links or open attachments
> > > until
> > > you have verified the sender or the content.
> > >
> > >
> > > Hi, Thorsten here, the Linux kernel's regression tracker. Top-
> > > posting
> > > for once, to make this easily accessible to everyone.
> > >
> > > I'm a bit lost here, but maybe I'm missing something.
> > >
> > > Luiz, can you help out here? Is there a reason why this patch is
> > > not
> > > making any process?
> > >
> > > Chris Lu and/or Hao Qin: Can you maybe help out as well as well
> > > and
> > > help
> > > with resolving some open questions that might or might not be
> > > relevant
> > > (see below).
> > >
> > > From Takashi reply, the bugzilla ticket he linked to, and the
> > > mail
> > > from
> > > the MediaTek folks
> > > (
> > >
https://lore.kernel.org/lkml/12a344e25b31ec00fe8b57814d43fcb166e71be5.camel@xxxxxxxxxxxx/
> > > ) it from the outside looks like this patch should really be
> > > merged
> > > rather sooner that later as it fixes regressions for some people.
> > > Afaics it should get a "Fixes: ccfc8948d7e4d9 ("Bluetooth: btusb:
> > > mediatek: reset the controller before downloading the fw")" tag,
> > > as
> > > it's
> > > afaics that commit that causes the regression that is known since
> > > more
> > > than three months now
> > > (https://lore.kernel.org/all/ZsTh7Jyug7MbZsLE@xxxxxxxxxxxx/ ).
> > >
> > > But note, it seems it does not fix the regression completely
> > > according
> > > to Marc's testing.
> > > https://lore.kernel.org/all/ZuCB98DSdtKCgxaL@xxxxxxxxxxxx/
> > >
> > > Marc: Is that still how things are with current mainline?
> > >
> > > Ciao, Thorsten
> > >
> > >
> > > On 22.10.24 12:56, Takashi Iwai wrote:
> > > > On Mon, 14 Oct 2024 11:29:40 +0200,
> > > > Linux regression tracking (Thorsten Leemhuis) wrote:
> > > > >
> > > > > On 20.09.24 08:27, Chris Lu (陸稚泓) wrote:
> > > > > > On Thu, 2024-09-19 at 23:25 +0100, marc.payne@xxxxxxxxxxxx
> > > > > > wrote:
> > > > > > >
> > > > > > > External email : Please do not click links or open
> > > > > > > attachments until
> > > > > > > you have verified the sender or the content.
> > > > > > > Hi Chris and Luiz,
> > > > > > >
> > > > > > > What were your thoughts on the findings in my email dated
> > > > > > > 18th
> > > > > > > September?
> > > > > >
> > > > > > Thanks for your suggestion.
> > > > > >
> > > > > > I've prepared the same environment (Kernel v6.11 +
> > > > > > MT7921AUN
> > > > > > dongle) to
> > > > > > reproduce the issue, collected necessary logs locally and
> > > > > > also
> > > > > > initiated an internal discussion to clarify the root cause
> > > > > > of
> > > > > > this
> > > > > > symptom. We'll review the changes between two firmware
> > > > > > (20230526/20231109) if it's a bug or not.
> > > > > >
> > > > > > It may take some time to investigate. I'll let you know if
> > > > > > there is any
> > > > > > progress.
> > > > >
> > > > > Just wondering: Chris Lu, and Marc, what's the status here?
> > > > > From
> > > > > here it
> > > > > looks like there was no progress to fix this regression for a
> > > > > while, but
> > > > > it's easy to miss something, that's why I ask.
> > > > >
> > > > > Ciao, Thorsten
> > > >
> > > > FWIW, the similar bug was reported for the recent 6.11.x kernel
> > > > on
> > > > openSUSE Tumbleweed, and this patch was confirmed to work
> > > > around
> > > > the
> > > > crash at boot:
> > > >
> > > >
https://urldefense.com/v3/__https://bugzilla.suse.com/show_bug.cgi?id=1231599__;!!CTRNKA9wMg0ARbw!jYyH2oubBEtIKXmKl9cI2rrmK-7kSdaiIJQ8xH4NZa5i5YCTQDHaoOxCBhMgdAAY6ROIPAoPwbOV-LNeMRJBlR6u-As$
> > > >
> > > > It'd be great if you can go ahead and merge the proper fix to
> > > > the
> > > > upstream.
> > > >
> > > > Let me know if you have another patch to test. Then I can
> > > > create a
> > > > test kernel package and ask the bug reporter for testing.
> > > >
> > > >
> > > > thanks,
> > > >
> > > > Takashi
> > > >
> > >
> > >
> >
> > ************* MEDIATEK Confidentiality Notice ********************
> > The information contained in this e-mail message (including any
> > attachments) may be confidential, proprietary, privileged, or
> > otherwise
> > exempt from disclosure under applicable laws. It is intended to be
> > conveyed only to the designated recipient(s). Any use,
> > dissemination,
> > distribution, printing, retaining or copying of this e-mail
> > (including its
> > attachments) by unintended recipient(s) is strictly prohibited and
> > may
> > be unlawful. If you are not an intended recipient of this e-mail,
> > or believe
> > that you have received this e-mail in error, please notify the
> > sender
> > immediately (by replying to this e-mail), delete any and all copies
> > of
> > this e-mail (including any attachments) from your system, and do
> > not
> > disclose the content of this e-mail to any other person. Thank you!
> >
>
>
