Re: [PATCH 0/2] Fix for MediaTek reset affecting Focusrite audio interfaces

["gregkh@xxxxxxxxxxxxxxxxxxx" <gregkh@xxxxxxxxxxxxxxxxxxx>]

On Thu, Mar 13, 2025 at 09:05:16AM +0000, Chris Lu (陸稚泓) wrote:
> Hi Luiz,
> 
> Sorry for the late response.
> 
> On Thu, 2025-03-13 at 09:08 +0100, Paul Menzel wrote:
> > 
> > External email : Please do not click links or open attachments until
> > you have verified the sender or the content.
> > 
> > 
> > [Cc: +regressions, commit ccfc8948d7e4 was added in v6.11-rc1]
> > 
> > Am 13.03.25 um 02:43 schrieb Benedikt Ziemons:
> > > On Tue, 2025-03-11 at 21:53 -0400, Luiz Augusto von Dentz wrote:
> > 
> > > > On Mon, Mar 10, 2025 at 5:24 PM Geraldo Nascimento wrote:
> > > > > 
> > > > > On Sun, Mar 09, 2025 at 06:02:11AM +1030, Geoffrey D. Bennett
> > > > > wrote:
> > > > > > This series (choose 1 of the 2 patches) addresses an issue
> > > > > > where the
> > > > > > MT7922 Bluetooth controller reset added in commit
> > > > > > ccfc8948d7e4
> > > > > > ("Bluetooth: btusb: mediatek: reset the controller before
> > > > > > downloading
> > > > > > the fw") is causing Focusrite USB audio devices to fail to
> > > > > > initialise
> > > > > > when connected during boot on kernels 6.11 and newer.
> > > > > > 
> > > > > > Reported by three users here:
> > > > > > https://urldefense.com/v3/__https://github.com/geoffreybennett/linux-fcp/issues/24__;!!CTRNKA9wMg0ARbw!hovfaKcQBzFKUu7X62SNU_berXiuXtSb2ndXGjAyf9WCptdz3D8jnprUqYc6b2fQE_3zrt88nGpKtJcYUCCcdA$
> > > > > > 
> > > > > > Two users confirmed they have an MT7922.
> > > > > > 
> > > > > > I'm providing two possible solutions as I note there was a
> > > > > > similar
> > > > > > change made in commit a7208610761a ("Bluetooth: btmtk: Remove
> > > > > > resetting mt7921 before downloading the fw"), so I'm not sure
> > > > > > if the
> > > > > > reset should be reverted for the MT7925 as well as the
> > > > > > MT7922.
> > > > > > 
> > > > > > Option 1: Revert the problematic reset behaviour entirely
> > > > > > (MT7922 +
> > > > > > MT7925)
> > > > > > 
> > > > > > Option 2: Remove the reset only for the MT7922
> > > > > > 
> > > > > > Geoffrey D. Bennett (2):
> > > > > > 
> > > > > >    [PATCH 1/2] Revert "Bluetooth: btusb: mediatek: reset the
> > > > > > controller
> > > > > >      before downloading the fw"
> > > > > > 
> > > > > >    [PATCH 2/2] Bluetooth: btmtk: Remove resetting mt7922
> > > > > > before
> > > > > >      downloading the fw
> > > > > > 
> > > > > > --
> > > > > > 2.45.0
> > > > > > 
> > > > > > 
> > > > > 
> > > > > Hi Geoffrey,
> > > > > 
> > > > > I understand there's no apparent nexus of causality here.
> > > > > 
> > > > > However if three different users suddenly reported the same
> > > > > problem
> > > > > and the fix fixes it, we should take the report seriously and
> > > > > back
> > > > > down on the problematic commit until we figure for sure what
> > > > > the heck
> > > > > is going on.
> > > > > 
> > > > > My bet is this is bona fide bug in the USB subsystem, but
> > > > > either I'm
> > > > > not looking hard enough or I'm looking into the wrong places,
> > > > > because
> > > > > there's no way I can see in which way USB bluetooth driver from
> > > > > MediaTek could cause clock detection to fail.
> > > > > 
> > > > > No point in pressing this harder, but yeah, take the reports
> > > > > more than
> > > > > seriously, because if we don't understand in which way our own
> > > > > (Linux)
> > > > > code could be causing this, at least we should take cautionary
> > > > > measures.
> > > > > 
> > > > > In that sense, putting Takashi Iwai and Greg KH to Cc: in a
> > > > > modest but
> > > > > sincere belief that this issue is more than real, even though
> > > > > it looks
> > > > > like anticipated April 1st. Takashi can help with his expertise
> > > > > in
> > > > > clock detection and Greg could help pinpoint if this is indeed
> > > > > madness
> > > > > in the USB subsystem.
> > > > > 
> > > > > Hope you and them don't mind the escalation :)
> > > > 
> > > > Do you guys have any idea what could be possibly going on here?
> > > > There
> > > > really seems something is not right if one driver affects the
> > > > other,
> > > > especially if the devices are not actually related in any way.
> > 
> 
> I've discussed internally with Sean and Hao from MediaTek who submit
> the changes to Kernel. The original intention was to ensure
> controller's status is clean before Bluetooth driver doing firmware
> binary download when booting. However, it seems that the changes cause
> unexpected USB device enumeration problem at this timing with specific
> USB devices.
> 
> To avoid such problem, we also agree that reverting those changes would
> be a better choice. Thanks a lot.

Great, can someone please submit the reverts?

thanks,

greg k-h