On Wed 05 May 14:35 CDT 2021, John Stultz wrote:
> On Wed, May 5, 2021 at 8:04 AM Rob Clark <robdclark@xxxxxxxxx> wrote:
> > 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..
>
> 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.
Regards,
Bjorn
