From: John Stultz <email@example.com> To: Rob Clark <firstname.lastname@example.org> Cc: Bjorn Andersson <email@example.com>, Dmitry Baryshkov <firstname.lastname@example.org>, Vinod Koul <email@example.com>, Srini Kandagatla <firstname.lastname@example.org>, Amit Pundir <email@example.com>, YongQin Liu <firstname.lastname@example.org>, linux-arm-msm <email@example.com> Subject: Re: Regression: arm64: dts: sdm845-db845c: make firmware filenames follow linux-firmware Date: Wed, 5 May 2021 12:35:32 -0700 [thread overview] Message-ID: <CALAqxLVxURmmJ227n8ozzsV96qqAxB+BdVV_kHbgFS7680=dbA@mail.gmail.com> (raw) In-Reply-To: <CAF6AEGt5AZ4jPO5=qUy-JhDCj1D5oD9nboNDDiJFnFDmWWvOaA@mail.gmail.com> On Wed, May 5, 2021 at 8:04 AM Rob Clark <firstname.lastname@example.org> wrote: > 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.. Yeah, but on other platforms, the kernel has to meet and deal with the hardware, firmware and userland as it exists in the world. 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. 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). thanks -john
next prev parent reply other threads:[~2021-05-05 19:35 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 [this message] 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='CALAqxLVxURmmJ227n8ozzsV96qqAxB+BdVV_kHbgFS7680=dbA@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).