Quick regression status pre 7.3-rc3

Quick regression status pre 7.3-rc3

[Thorsten Leemhuis]

Hi Linus! Here is a quick report about a few unresolved regressions from
the current or the previous cycle that I found worth mentioning for one
reason or another; fixes are available for all of them:


* c6b1b34b509032 ("media: pci: intel: Add CVS support for IPU bridge
driver") [v7.2-rc1] broke the internal camera on laptops where the
sensor sits behind an IVSC. There are various reports, among them:
  https://lore.kernel.org/lkml/20260901194526.6369-1-gvozdoder@gmail.com/

https://lore.kernel.org/linux-media/2f8b67fc-ec2a-46f6-9ee0-06279e612bde@badakan.com/

  Sergey Zagursky provided a fix that sits in -next as ce92674d8d8b29
("media: ipu-bridge: do not use the CVS device lookup for IVSC")
[next-20260903] and can also be found here:
  https://lore.kernel.org/all/20260902211524.5572-1-gvozdoder@gmail.com/

  I asked Mauro about the plans to mainline this up (this was before
this weeks media PR was sent), but that didn't lead to any reaction afaics:

https://lore.kernel.org/linux-media/27c82eb4-4f8e-41b5-b983-dff7a0a27951@leemhuis.info/


* f3b1357673ddb3 ("remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ
APIs") [v7.3-rc1] broke GPU and modem on on Qcom devices that have a
TrustZone firmware without PAS. This was already known before the merge
window and is still unfixed -- which is why I'm mentioning it, as it is
a good example how long some fixes take to reach mainline (see my
maintainers summit proposal). The two fixes for that regression at least
finally both made it to -next now:

 - b853857293584d ("remoteproc: qcom_q6v5_mss: Don't require PAS for
memory protection") [next-20260901]
 - b7c0f8436f077e ("drm/msm/adreno: Only check for PAS when a zap shader
is present") [next-20260911 (pending-fixes)]


The two regressions from last week's report (also known since the merge
window) are still around and didn't make any progress afaics:

> * 9417c5818a0146 ("wifi: mt76: mt7921: validate CLC firmware records")
> [v7.3-rc1] causes probe failures for some widely used mediatek wifi chips:
> 
>   - Mikhail Gavrilov reported this on 2026-08-16 (e.g. right before the
> merge window opened):
> https://lore.kernel.org/lkml/20260816132325.23007-1-mikhail.v.gavrilov@gmail.com/
>   - Junjie Cao reported this on 2026-09-01 with another fix (withdrawn
> meanwhile):
> https://lore.kernel.org/stable/20260901011840.416787-1-junjie.cao@intel.com/
> 
> 
>   The culprit's author within hours of the first report provided a fix
> that got "Tested-by" from the two aforementioned reporters:
> https://lore.kernel.org/linux-wireless/20260816174841.1918-1-acharyalaxman8848@
> 7.2 final/-rc8gmail.com/
> 
>   The maintainers afaics never reacted to the fix and it three weeks
> later still marked as "new" in patchwork:
> https://patchwork.kernel.org/project/linux-wireless/patch/20260816174841.1918-1-acharyalaxman8848@gmail.com/

The culprit made it to a few of the current stable-rc releases, but was
dropped today.

> * 9b80bd9cab40c4 ("wifi: mt76: mt7921: add regulatory wiphy self manager
> support") [v7.3-rc1] and e9f3f1cc133fc2 ("wifi: mt76: mt7925: add
> regulatory wiphy self manager support") [v7.3-rc1] also causes probe
> failures for some widely used mediatek wifi chips; the problem is in a
> similar area and affects similar chips, but from my limited
> understanding seems to be different.
> 
>  - Klara Modin reported the regression on 2026-08-24:
> https://lore.kernel.org/linux-wireless/aoyxqHYvSuaBeubf@soda.int.kasm.eu/
>  - Devin Wittmayer within a day reproduced the problem and provided a
> fix that got a Tested-by from Klara:
> https://lore.kernel.org/lkml/20260825181712.28548-1-lucid_duck@justthetip.ca/
>  - David Gow recently ran into the same problem and provided a Tested-by
> for the fix, too:
> https://lore.kernel.org/lkml/bcf1ee9b-97e5-43f9-81eb-67ac6a0a98dc@davidgow.net/
> 
>   The maintainers never reacted to that afaics and that patch is still
> marked as "new" in patchwork:
> https://patchwork.kernel.org/project/linux-wireless/patch/20260825181712.28548-1-lucid_duck@justthetip.ca/

No progress for this one afaics.

HTH, Ciao, Thorsten

Re: Quick regression status pre 7.3-rc3

[Linus Torvalds]

On Sun, 13 Sept 2026 at 07:32, Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> Hi Linus! Here is a quick report about a few unresolved regressions from
> the current or the previous cycle that I found worth mentioning for one
> reason or another; fixes are available for all of them:

I applied three patches for these issues and merged them. That
hopefully takes care of at least the IPU bridge and the mt76 issues.

The rest appear to at least be in linux-next, and I left those alone.

Please do double-check that what I did matches what you expected...

             Linus

Re: Quick regression status pre 7.3-rc3

[Thorsten Leemhuis]

On 9/13/26 19:40, Linus Torvalds wrote:
> On Sun, 13 Sept 2026 at 07:32, Thorsten Leemhuis
> <regressions@leemhuis.info> wrote:
>>
>> Hi Linus! Here is a quick report about a few unresolved regressions from
>> the current or the previous cycle that I found worth mentioning for one
>> reason or another; fixes are available for all of them:
> 
> I applied three patches for these issues and merged them. That
> hopefully takes care of at least the IPU bridge and the mt76 issues.

Thx!
> The rest appear to at least be in linux-next, and I left those alone.

Yeah, that's fine, so far it looks like that is a regression that is rare.
> Please do double-check that what I did matches what you expected...
Looks good from what I can see.

Side note: Some people suggested I should submit regression fixes like
the three you just applied directly to you as patches or through a git
tree you can pull.

Occasionally I think that might be a good idea, for example, in cases
where a maintainer is known to be on a vacation or something. That
approach also might make your Sunday evenings easier, too. If I'd sent
everything out on Thursday evenings (European time), it would also give
people a chance to speak up when needed before something stupid happens,
which is likely better than what we did here.

At the same time, I think that's a terrible idea, as bypassing the
maintainers' knowledge and setups (like subsystem-specific CIs)
obviously has many downsides and risks. Might also be a stupid idea for
the same reasons why the trivial tree failed and maybe was not a good
thing anyway.

Then again, I the risk of such bypassing might be a wake-up call
motivating some subsystems to mainline regression fixes faster.

In case you have any thoughts on that, I'd be interested to hear them.

Ciao, Thorsten

Re: Quick regression status pre 7.3-rc3

[Linus Torvalds]

On Sun, 13 Sept 2026 at 12:32, Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> Side note: Some people suggested I should submit regression fixes like
> the three you just applied directly to you as patches or through a git
> tree you can pull.

I would certainly not mind. It would make it easier than my "apply
patches by hand and then do that explanatory merge just to make the
reasoning obvious".

But hopefully this would also not be common enough to really be an
issue. So whatever works best for you,

                  Linus