archive mirror
 help / color / mirror / Atom feed
From: Bjorn Andersson <>
To: John Stultz <>
Cc: Dmitry Baryshkov <>,
	Vinod Koul <>,
	Srini Kandagatla <>,
	Amit Pundir <>,
	YongQin Liu <>,
	linux-arm-msm <>
Subject: Re: Regression: arm64: dts: sdm845-db845c: make firmware filenames follow linux-firmware
Date: Wed, 5 May 2021 14:06:13 -0500	[thread overview]
Message-ID: <20210505190613.GG2484@yoga> (raw)
In-Reply-To: <>

On Wed 05 May 01:20 CDT 2021, John Stultz wrote:

> Hey Dmitry, Bjorn,
>   I wanted to raise a regression I caught in the merge window on db845c.
> I was seeing troubles with audio and while there are a few other
> pending fixes needed, they did not seem to work for me. So I spent
> some time bisecting things down and found the problematic commit was
> 7443ff06da45 ("arm64: dts: sdm845-db845c: make firmware filenames
> follow linux-firmware").
> It seems for systems using the old firmware filenames, this will break
> dependent devices on adsp_pas and cdsp_pas nodes.
> Now, obviously updating the firmware files in userland should resolve
> this, but it adds the complexity that we can't just replace the
> firmware files because older LTS kernels will look for the old names,
> while newer kernels will look for the new names. We can add both files
> to the system images, but then there is some confusion on which
> version of the firmware files are being used where.
> So yes, we should align with linux-firmware file names, but I think
> more care is needed for this sort of thing as it has the potential to
> break folks, and this isn't the first time around we've had similar
> firmware name changes break us.

Due to the workings of the userspace firmware loader fallback I
unfortunately don't see any reasonable way to deal with this.
Introducing a fallback mechanism would suffer from an unavoidable 60
second delay waiting for the first choice to timeout, or if we used the
non-userspace-assisted method we'd probably give up too early.

> So I'm working on fixing this by including both filenames in userland,

The kernel will detect in runtime if you pass it a squashed or split
firmware package, the suffix has no significance. So if you have the
need to go back and forth just make sure you have a symlink that points
the .mbn to the .mdt (or vice versa).

> so we probably don't need a revert here, but *please* maybe take more
> care on this sort of change.

Yes, I should have paid more attention when we merged the original
firmware-name to avoid this issue. Sorry for not getting this right from
the beginning.


      parent reply	other threads:[~2021-05-05 19:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-05  6:20 John Stultz
2021-05-05 15:08 ` Rob Clark
2021-05-05 19:35   ` John Stultz
2021-05-05 20:05     ` Rob Clark
2021-05-05 20:07       ` Dmitry Baryshkov
2021-05-05 21:14       ` John Stultz
2021-05-05 21:02     ` Bjorn Andersson
2021-05-05 18:43 ` Dmitry Baryshkov
2021-05-05 19:06 ` Bjorn Andersson [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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210505190613.GG2484@yoga \ \ \ \ \ \ \ \ \
    --subject='Re: Regression: arm64: dts: sdm845-db845c: make firmware filenames follow linux-firmware' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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 NNTP newsgroup(s).