From: Rob Clark <firstname.lastname@example.org> To: John Stultz <email@example.com> Cc: Bjorn Andersson <firstname.lastname@example.org>, Dmitry Baryshkov <email@example.com>, Vinod Koul <firstname.lastname@example.org>, Srini Kandagatla <email@example.com>, Amit Pundir <firstname.lastname@example.org>, YongQin Liu <email@example.com>, linux-arm-msm <firstname.lastname@example.org> Subject: Re: Regression: arm64: dts: sdm845-db845c: make firmware filenames follow linux-firmware Date: Wed, 5 May 2021 08:08:17 -0700 [thread overview] Message-ID: <CAF6AEGt5AZ4jPO5=qUy-JhDCj1D5oD9nboNDDiJFnFDmWWvOaA@mail.gmail.com> (raw) In-Reply-To: <CALAqxLXsLcA=r1x6hXxLx3aVA-8=RG5qd+yj+sKEFiaWPUzkSA@mail.gmail.com> On Tue, May 4, 2021 at 11:37 PM John Stultz <email@example.com> 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
next prev parent reply other threads:[~2021-05-05 15:04 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 [this message] 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
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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAF6AEGt5AZ4jPO5=qUy-JhDCj1D5oD9nboNDDiJFnFDmWWvOaA@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Regression: arm64: dts: sdm845-db845c: make firmware filenames follow linux-firmware' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * 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).