archive mirror
 help / color / mirror / Atom feed
From: Bjorn Andersson <>
To: John Stultz <>
Cc: Rob Clark <>,
	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 16:02:40 -0500	[thread overview]
Message-ID: <20210505210240.GH2484@yoga> (raw)
In-Reply-To: <>

On Wed 05 May 14:35 CDT 2021, John Stultz wrote:

> On Wed, May 5, 2021 at 8:04 AM Rob Clark <> wrote:
> > On Tue, May 4, 2021 at 11:37 PM 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.
> > >
> > > So I'm working on fixing this by including both filenames in userland,
> > > so we probably don't need a revert here, but *please* maybe take more
> > > care on this sort of change.
> > >
> >
> > It is rather more difficult than you think, because if you try the
> > wrong path you could end up waiting with a timeout.. we have
> > shenanigans to work around that for gpu fw in drm/msm to avoid this
> > sort of regression with people using downstream firmware trees.  I'd
> > like to rip that out at some point, but I suppose doing so would be
> > problematic for folks doing upstream kernel on android devices.
> >
> > Maybe there is some way to add support to simultaneously
> > request_firmware for two different paths at the same time.. not sure
> > how that would work from the PoV of the usermode helper path.
> >
> > It really is a lot of pain to deal with downstream firmware layout..
> Yeah, but on other platforms, the kernel has to meet and deal with the
> hardware, firmware and userland as it exists in the world.

The whole problem is that the kernel _didn't_ work with the firmware
that was published to the world, we used the wrong firmware name and
because you and apparently the LT releases doesn't follow linux-firmware
this was not noticed until now.

> It would be quite a thing if an upstream kernel change required a new
> BIOS update which then made the system incompatible with the most
> recent LTS.

Certainly so, but even if we didn't have to deal with OEM-signed,
per-board firmware files we'd have to hard code the file names in the
drivers - and would have run into this problem anyways.

> And yes, I'm very sympathetic that it's a pain (In the timekeeping
> code, there's a ton of messy duplicative code required to keep
> timespec alongside of ktime_t representations of time so we can be
> fast no matter which interface is used). :)
> And again, I can work around this one.  It's just that this isn't the
> first time, so I want to nudge folks to have a broader view and
> consider these issues a little more when making changes (not just in
> the kernel, but in why the names in linux-firmware are different then
> what's on devices in the field, etc).

Right, you certainly have suffered from this in the past, because we
didn't have a strategy for handling more than a single Qualcomm device
with any given instance of /lib/firmware.

Now we have a plan, and I believe db845c was the first board to
implement this plan and I got it wrong.  Going forward I hope to avoid
making this mistake again.


  parent reply	other threads:[~2021-05-05 21:02 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 [this message]
2021-05-05 18:43 ` Dmitry Baryshkov
2021-05-05 19:06 ` Bjorn Andersson

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=20210505210240.GH2484@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).