Re: Regression: arm64: dts: sdm845-db845c: make firmware filenames follow linux-firmware

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 4, 2021 at 11:37 PM John Stultz <john.stultz@xxxxxxxxxx> 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..

BR,
-R



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux