On Tue, Feb 24, 2026 at 11:48:00AM +0530, Sibi Sankar wrote: > > On 2/23/2026 10:44 PM, Dmitry Baryshkov wrote: > > On Mon, 23 Feb 2026 at 11:09, Sibi Sankar <[email protected]> > > wrote: > > > > > > On 2/3/2026 6:09 PM, Dmitry Baryshkov wrote: > > > > On Mon, Feb 02, 2026 at 11:16:19AM +0100, Konrad Dybcio wrote: > > > > > On 1/31/26 8:54 AM, Dmitry Baryshkov wrote: > > > > > > On Fri, Jan 30, 2026 at 10:55:24AM +0100, Konrad Dybcio wrote: > > > > > > > On 1/29/26 1:13 AM, Sibi Sankar wrote: > > > > > > > > Enable ADSP and CDSP on Glymur CRD board. > > > > > > > > > > > > > > > > Signed-off-by: Sibi Sankar <[email protected]> > > > > > > > > --- > > > > > > > > arch/arm64/boot/dts/qcom/glymur-crd.dts | 14 ++++++++++++++ > > > > > > > > 1 file changed, 14 insertions(+) > > > > > > > > > > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dts > > > > > > > > b/arch/arm64/boot/dts/qcom/glymur-crd.dts > > > > > > > > index 0899214465ac..0eed4faa8b07 100644 > > > > > > > > --- a/arch/arm64/boot/dts/qcom/glymur-crd.dts > > > > > > > > +++ b/arch/arm64/boot/dts/qcom/glymur-crd.dts > > > > > > > > @@ -487,6 +487,20 @@ &pon_resin { > > > > > > > > status = "okay"; > > > > > > > > }; > > > > > > > > > > > > > > > > +&remoteproc_adsp { > > > > > > > > + firmware-name = "qcom/glymur/adsp.mbn", > > > > > > > > + "qcom/glymur/adsp_dtb.mbn"; > > > > > > > > + > > > > > > > > + status = "okay"; > > > > > > > > +}; > > > > > > > > + > > > > > > > > +&remoteproc_cdsp { > > > > > > > > + firmware-name = "qcom/glymur/cdsp.mbn", > > > > > > > > + "qcom/glymur/cdsp_dtb.mbn"; > > > > > > > > + > > > > > > > > + status = "okay"; > > > > > > > > +}; > > > > > > > Please make sure it gets to L-F (only Kaanapali is there right > > > > > > > now) > > > > > > > > > > > > > > Reviewed-by: Konrad Dybcio <[email protected]> > > > > > > Hmm, looking at x1e80100-crd which references > > > > > > qcom/x1e80100/adsp.mbn, > > > > > > but the firmware in linux-firmware is (now) targeting IoT devices, > > > > > > should we use WoA-like names for firmware on Glymur CRD instead > > > > > > (qcadsp-something.mbn). It would match what was done for the > > > > > > SC8280XP > > > > > > CRD. > > > > > I think it's simply time to stop pretending the firmware is generic > > > > > (some fw simply isn't and some fw may come from different/incompatible > > > > > branchpoints) and include a board name in the path > > > > Well... CDSP is usually generic, except for WP vs non-WP. > > > Hey Dmitry/Konrad, > > > > > > Thanks for taking time to review the series :) > > > > > > The ADSP/CDSP firmware that got upstreamed to linux-firmware got their > > > functionality tested on Glymur WP CRD devices. Given that the firmware > > > has already landed, can I continue to use the same name as the patch and > > > have a different name for other boards if something specific has to be > > > pushed > > > for IOT? > > Thank you for a prompt reaction, it took just 20 days. During that > > time we could have fixed WP firmware filenames, but... linux-firmware > > Hey Dmitry, > > I'm really sorry that this happened this way :( but I was out > on vacation the past three weeks getting married. A quick > review comment on the firmware pull request for naming > change request would also sufficed in the interim. Also to address > some of your concerns there aren't any plans to push an iot > specific ADSP/CDSP firmware for Glymur reference devices.
There are no plans to push or there are no plans to have it? > Also, this series already warrants a re-post so I can still > accommodate your naming requests with corresponding > updates to linux-firmware. Yes, but the linux-firmware has been released with these file names, so you can't just change them. You will have to provide backwards-compatibility links, which defeats the purpose. > > -Sibi > > > got released just two days ago, so we can't fix that anymore. Now we > > don't have any other option than to use a non-standard name for IoT > > firmware when it comes later. > > > > > -Sibi > > > > > -- With best wishes Dmitry
