mbox series

[00/12] arm64: qcom: autodetect firmware paths

Message ID 20240521-qcom-firmware-name-v1-0-99a6d32b1e5e@linaro.org
Headers show
Series arm64: qcom: autodetect firmware paths | expand

Message

Dmitry Baryshkov May 21, 2024, 9:45 a.m. UTC
This is a followup to the discussion during the Linaro Connect. Remove
most of the firmware-name properties from the board DT by using
root node compatible to detect firmware path.

The most obvious change is that the drivers now have to look for the
MBN firmware files by default, so this might break the case of the user
simply mounting vendor's firmware partition to /lib/firmware and
expecting it to work.

Also things are slightly more complex for the platforms like DB845c and
Qualcomm RB5. These platforms have generic SoC firmware in qcom/sdm845
and qcom/sm8250 and also the board-specific firmware at
qcom/sdm845/Thundercomm/DB845C and qcom/sm8250/Thundercomm/RB5
respectively. Making these boards follow up the scheme would require
additional symlinks in the firmware dir.

+Link: qcom/sdm845/Thundercomm/db845c/a630_zap.mbn -> ../../a630_zap.mbn
+Link: qcom/sm8250/Thundercomm/RB5/a650_zap.mbn -> ../../a650_zap.mbn
+Link: qcom/sdm845/Thundercomm/db845c/adsp.mbn -> ../../adsp.mbn
+Link: qcom/sdm845/Thundercomm/db845c/adspr.jsn -> ../../adspr.jsn
+Link: qcom/sdm845/Thundercomm/db845c/adspua.jsn -> ../../adspua.jsn
+Link: qcom/sdm845/Thundercomm/db845c/cdsp.mbn -> ../../cdsp.mbn
+Link: qcom/sdm845/Thundercomm/db845c/cdspr.jsn -> ../../cdspr.jsn
+Link: qcom/sm8250/Thundercomm/RB5/adsp.mbn -> ../../adsp.mbn
+Link: qcom/sm8250/Thundercomm/RB5/adspr.jsn -> ../../adspr.jsn
+Link: qcom/sm8250/Thundercomm/RB5/adspua.jsn -> ../../adspua.jsn
+Link: qcom/sm8250/Thundercomm/RB5/cdsp.mbn -> ../../cdsp.mbn
+Link: qcom/sm8250/Thundercomm/RB5/cdspr.jsn -> ../../cdspr.jsn

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
Dmitry Baryshkov (12):
      soc: qcom: add firmware name helper
      wifi: wcn36xx: make use of QCOM_FW_HELPER
      soc: qcom: wcnss_ctrl: make use of QCOM_FW_HELPER
      remoteproc: qcom_q6v5_mss: switch to mbn files by default
      remoteproc: qcom_q6v5_mss: make use of QCOM_FW_HELPER
      remoteproc: qcom_q6v5_pas: switch to mbn files by default
      remoteproc: qcom_q6v5_pas: make use of QCOM_FW_HELPER
      remoteproc: qcom_wcnss: switch to mbn files by default
      remoteproc: qcom_wcnss: make use of QCOM_FW_HELPER
      remoteproc: qcom_wcnss: make use of QCOM_FW_HELPER
      arm64: dts: qcom: apq8016-sbc: drop firmware-name properties
      arm64: dts: qcom: apq8096-db820c: drop firmware-name properties

 arch/arm64/boot/dts/qcom/apq8016-sbc.dts    |  5 +-
 arch/arm64/boot/dts/qcom/apq8096-db820c.dts |  2 -
 drivers/net/wireless/ath/wcn36xx/Kconfig    |  1 +
 drivers/net/wireless/ath/wcn36xx/main.c     |  5 ++
 drivers/remoteproc/Kconfig                  |  3 +
 drivers/remoteproc/qcom_q6v5_mss.c          | 12 +++-
 drivers/remoteproc/qcom_q6v5_pas.c          | 85 +++++++++++++++-------------
 drivers/remoteproc/qcom_wcnss.c             |  8 ++-
 drivers/soc/qcom/Kconfig                    |  6 ++
 drivers/soc/qcom/Makefile                   |  1 +
 drivers/soc/qcom/qcom_fw_helper.c           | 86 +++++++++++++++++++++++++++++
 drivers/soc/qcom/wcnss_ctrl.c               |  9 +++
 include/linux/soc/qcom/fw_helper.h          | 10 ++++
 13 files changed, 187 insertions(+), 46 deletions(-)
---
base-commit: 632483ea8004edfadd035de36e1ab2c7c4f53158
change-id: 20240520-qcom-firmware-name-aeef265a753a

Best regards,

Comments

Neil Armstrong May 21, 2024, 9:52 a.m. UTC | #1
On 21/05/2024 11:45, Dmitry Baryshkov wrote:
> Qualcomm platforms have different sets of the firmware files, which
> differ from platform to platform (and from board to board, due to the
> embedded signatures). Rather than listing all the firmware files,
> including full paths, in the DT, provide a way to determine firmware
> path based on the root DT node compatible.

Ok this looks quite over-engineered but necessary to handle the legacy,
but I really think we should add a way to look for a board-specific path
first and fallback to those SoC specific paths.

Neil

> 
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
>   drivers/soc/qcom/Kconfig           |  5 +++
>   drivers/soc/qcom/Makefile          |  1 +
>   drivers/soc/qcom/qcom_fw_helper.c  | 86 ++++++++++++++++++++++++++++++++++++++
>   include/linux/soc/qcom/fw_helper.h | 10 +++++
>   4 files changed, 102 insertions(+)
> 
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 5af33b0e3470..b663774d65f8 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -62,6 +62,11 @@ config QCOM_MDT_LOADER
>   	tristate
>   	select QCOM_SCM
>   
> +config QCOM_FW_HELPER
> +	tristate "NONE FW HELPER"
> +	help
> +	  Helpers to return platform-specific location for the firmware files.
> +
>   config QCOM_OCMEM
>   	tristate "Qualcomm On Chip Memory (OCMEM) driver"
>   	depends on ARCH_QCOM
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> index ca0bece0dfff..e612bee5b955 100644
> --- a/drivers/soc/qcom/Makefile
> +++ b/drivers/soc/qcom/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_QCOM_GENI_SE) +=	qcom-geni-se.o
>   obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
>   obj-$(CONFIG_QCOM_GSBI)	+=	qcom_gsbi.o
>   obj-$(CONFIG_QCOM_MDT_LOADER)	+= mdt_loader.o
> +obj-$(CONFIG_QCOM_FW_HELPER)	+= qcom_fw_helper.o
>   obj-$(CONFIG_QCOM_OCMEM)	+= ocmem.o
>   obj-$(CONFIG_QCOM_PDR_HELPERS)	+= pdr_interface.o
>   obj-$(CONFIG_QCOM_PMIC_GLINK)	+= pmic_glink.o
> diff --git a/drivers/soc/qcom/qcom_fw_helper.c b/drivers/soc/qcom/qcom_fw_helper.c
> new file mode 100644
> index 000000000000..13123c2514b8
> --- /dev/null
> +++ b/drivers/soc/qcom/qcom_fw_helper.c
> @@ -0,0 +1,86 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Qualcomm Firmware loading data
> + *
> + * Copyright (C) 2024 Linaro Ltd
> + */
> +
> +#include <linux/cleanup.h>
> +#include <linux/device.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/soc/qcom/fw_helper.h>
> +
> +static DEFINE_MUTEX(qcom_fw_mutex);
> +static const char *fw_path;
> +
> +static const struct of_device_id qcom_fw_paths[] = {
> +	/* device-specific entries */
> +	{ .compatible = "thundercomm,db845c", .data = "qcom/sdm845/Thundercomm/db845c", },
> +	{ .compatible = "qcom,qrb5165-rb5", .data = "qcom/sm8250/Thundercomm/RB5", },
> +	/* SoC default entries */
> +	{ .compatible = "qcom,apq8016", .data = "qcom/apq8016", },
> +	{ .compatible = "qcom,apq8096", .data = "qcom/apq8096", },
> +	{ .compatible = "qcom,sdm845", .data = "qcom/sdm845", },
> +	{ .compatible = "qcom,sm8250", .data = "qcom/sm8250", },
> +	{ .compatible = "qcom,sm8350", .data = "qcom/sm8350", },
> +	{ .compatible = "qcom,sm8450", .data = "qcom/sm8450", },
> +	{ .compatible = "qcom,sm8550", .data = "qcom/sm8550", },
> +	{ .compatible = "qcom,sm8650", .data = "qcom/sm8650", },
> +	{},
> +};
> +
> +static int qcom_fw_ensure_init(void)
> +{
> +	const struct of_device_id *match;
> +	struct device_node *root;
> +
> +	if (fw_path)
> +		return 0;
> +
> +	root = of_find_node_by_path("/");
> +	if (!root)
> +		return -ENODEV;
> +
> +	match = of_match_node(qcom_fw_paths, root);
> +	of_node_put(root);
> +	if (!match || !match->data) {
> +		pr_notice("Platform not supported by qcom_fw_helper\n");
> +		return -ENODEV;
> +	}
> +
> +	fw_path = match->data;
> +
> +	return 0;
> +}
> +
> +const char *qcom_get_board_fw(const char *firmware)
> +{
> +	if (strchr(firmware, '/'))
> +		return kstrdup(firmware, GFP_KERNEL);
> +
> +	scoped_guard(mutex, &qcom_fw_mutex) {
> +		if (!qcom_fw_ensure_init())
> +			return kasprintf(GFP_KERNEL, "%s/%s", fw_path, firmware);
> +	}
> +
> +	return kstrdup(firmware, GFP_KERNEL);
> +}
> +EXPORT_SYMBOL_GPL(qcom_get_board_fw);
> +
> +const char *devm_qcom_get_board_fw(struct device *dev, const char *firmware)
> +{
> +	if (strchr(firmware, '/'))
> +		return devm_kstrdup(dev, firmware, GFP_KERNEL);
> +
> +	scoped_guard(mutex, &qcom_fw_mutex) {
> +		if (!qcom_fw_ensure_init())
> +			return devm_kasprintf(dev, GFP_KERNEL, "%s/%s", fw_path, firmware);
> +	}
> +
> +	return devm_kstrdup(dev, firmware, GFP_KERNEL);
> +}
> +EXPORT_SYMBOL_GPL(devm_qcom_get_board_fw);
> +
> +MODULE_DESCRIPTION("Firmware helpers for Qualcomm devices");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/soc/qcom/fw_helper.h b/include/linux/soc/qcom/fw_helper.h
> new file mode 100644
> index 000000000000..755645386bba
> --- /dev/null
> +++ b/include/linux/soc/qcom/fw_helper.h
> @@ -0,0 +1,10 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __QCOM_FW_HELPER_H__
> +#define __QCOM_FW_HELPER_H__
> +
> +struct device;
> +
> +const char *qcom_get_board_fw(const char *firmware);
> +const char *devm_qcom_get_board_fw(struct device *dev, const char *firmware);
> +
> +#endif
>
Dmitry Baryshkov May 21, 2024, 10:01 a.m. UTC | #2
On Tue, 21 May 2024 at 12:52, <neil.armstrong@linaro.org> wrote:
>
> On 21/05/2024 11:45, Dmitry Baryshkov wrote:
> > Qualcomm platforms have different sets of the firmware files, which
> > differ from platform to platform (and from board to board, due to the
> > embedded signatures). Rather than listing all the firmware files,
> > including full paths, in the DT, provide a way to determine firmware
> > path based on the root DT node compatible.
>
> Ok this looks quite over-engineered but necessary to handle the legacy,
> but I really think we should add a way to look for a board-specific path
> first and fallback to those SoC specific paths.

Again, CONFIG_FW_LOADER_USER_HELPER => delays.

>
> Neil
>
> >
> > Suggested-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > ---
> >   drivers/soc/qcom/Kconfig           |  5 +++
> >   drivers/soc/qcom/Makefile          |  1 +
> >   drivers/soc/qcom/qcom_fw_helper.c  | 86 ++++++++++++++++++++++++++++++++++++++
> >   include/linux/soc/qcom/fw_helper.h | 10 +++++
> >   4 files changed, 102 insertions(+)
> >
> > diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> > index 5af33b0e3470..b663774d65f8 100644
> > --- a/drivers/soc/qcom/Kconfig
> > +++ b/drivers/soc/qcom/Kconfig
> > @@ -62,6 +62,11 @@ config QCOM_MDT_LOADER
> >       tristate
> >       select QCOM_SCM
> >
> > +config QCOM_FW_HELPER
> > +     tristate "NONE FW HELPER"
> > +     help
> > +       Helpers to return platform-specific location for the firmware files.
> > +
> >   config QCOM_OCMEM
> >       tristate "Qualcomm On Chip Memory (OCMEM) driver"
> >       depends on ARCH_QCOM
> > diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> > index ca0bece0dfff..e612bee5b955 100644
> > --- a/drivers/soc/qcom/Makefile
> > +++ b/drivers/soc/qcom/Makefile
> > @@ -6,6 +6,7 @@ obj-$(CONFIG_QCOM_GENI_SE) += qcom-geni-se.o
> >   obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
> >   obj-$(CONFIG_QCOM_GSBI)     +=      qcom_gsbi.o
> >   obj-$(CONFIG_QCOM_MDT_LOADER)       += mdt_loader.o
> > +obj-$(CONFIG_QCOM_FW_HELPER) += qcom_fw_helper.o
> >   obj-$(CONFIG_QCOM_OCMEM)    += ocmem.o
> >   obj-$(CONFIG_QCOM_PDR_HELPERS)      += pdr_interface.o
> >   obj-$(CONFIG_QCOM_PMIC_GLINK)       += pmic_glink.o
> > diff --git a/drivers/soc/qcom/qcom_fw_helper.c b/drivers/soc/qcom/qcom_fw_helper.c
> > new file mode 100644
> > index 000000000000..13123c2514b8
> > --- /dev/null
> > +++ b/drivers/soc/qcom/qcom_fw_helper.c
> > @@ -0,0 +1,86 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Qualcomm Firmware loading data
> > + *
> > + * Copyright (C) 2024 Linaro Ltd
> > + */
> > +
> > +#include <linux/cleanup.h>
> > +#include <linux/device.h>
> > +#include <linux/mutex.h>
> > +#include <linux/of.h>
> > +#include <linux/soc/qcom/fw_helper.h>
> > +
> > +static DEFINE_MUTEX(qcom_fw_mutex);
> > +static const char *fw_path;
> > +
> > +static const struct of_device_id qcom_fw_paths[] = {
> > +     /* device-specific entries */
> > +     { .compatible = "thundercomm,db845c", .data = "qcom/sdm845/Thundercomm/db845c", },
> > +     { .compatible = "qcom,qrb5165-rb5", .data = "qcom/sm8250/Thundercomm/RB5", },
> > +     /* SoC default entries */
> > +     { .compatible = "qcom,apq8016", .data = "qcom/apq8016", },
> > +     { .compatible = "qcom,apq8096", .data = "qcom/apq8096", },
> > +     { .compatible = "qcom,sdm845", .data = "qcom/sdm845", },
> > +     { .compatible = "qcom,sm8250", .data = "qcom/sm8250", },
> > +     { .compatible = "qcom,sm8350", .data = "qcom/sm8350", },
> > +     { .compatible = "qcom,sm8450", .data = "qcom/sm8450", },
> > +     { .compatible = "qcom,sm8550", .data = "qcom/sm8550", },
> > +     { .compatible = "qcom,sm8650", .data = "qcom/sm8650", },
> > +     {},
> > +};
> > +
> > +static int qcom_fw_ensure_init(void)
> > +{
> > +     const struct of_device_id *match;
> > +     struct device_node *root;
> > +
> > +     if (fw_path)
> > +             return 0;
> > +
> > +     root = of_find_node_by_path("/");
> > +     if (!root)
> > +             return -ENODEV;
> > +
> > +     match = of_match_node(qcom_fw_paths, root);
> > +     of_node_put(root);
> > +     if (!match || !match->data) {
> > +             pr_notice("Platform not supported by qcom_fw_helper\n");
> > +             return -ENODEV;
> > +     }
> > +
> > +     fw_path = match->data;
> > +
> > +     return 0;
> > +}
> > +
> > +const char *qcom_get_board_fw(const char *firmware)
> > +{
> > +     if (strchr(firmware, '/'))
> > +             return kstrdup(firmware, GFP_KERNEL);
> > +
> > +     scoped_guard(mutex, &qcom_fw_mutex) {
> > +             if (!qcom_fw_ensure_init())
> > +                     return kasprintf(GFP_KERNEL, "%s/%s", fw_path, firmware);
> > +     }
> > +
> > +     return kstrdup(firmware, GFP_KERNEL);
> > +}
> > +EXPORT_SYMBOL_GPL(qcom_get_board_fw);
> > +
> > +const char *devm_qcom_get_board_fw(struct device *dev, const char *firmware)
> > +{
> > +     if (strchr(firmware, '/'))
> > +             return devm_kstrdup(dev, firmware, GFP_KERNEL);
> > +
> > +     scoped_guard(mutex, &qcom_fw_mutex) {
> > +             if (!qcom_fw_ensure_init())
> > +                     return devm_kasprintf(dev, GFP_KERNEL, "%s/%s", fw_path, firmware);
> > +     }
> > +
> > +     return devm_kstrdup(dev, firmware, GFP_KERNEL);
> > +}
> > +EXPORT_SYMBOL_GPL(devm_qcom_get_board_fw);
> > +
> > +MODULE_DESCRIPTION("Firmware helpers for Qualcomm devices");
> > +MODULE_LICENSE("GPL");
> > diff --git a/include/linux/soc/qcom/fw_helper.h b/include/linux/soc/qcom/fw_helper.h
> > new file mode 100644
> > index 000000000000..755645386bba
> > --- /dev/null
> > +++ b/include/linux/soc/qcom/fw_helper.h
> > @@ -0,0 +1,10 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef __QCOM_FW_HELPER_H__
> > +#define __QCOM_FW_HELPER_H__
> > +
> > +struct device;
> > +
> > +const char *qcom_get_board_fw(const char *firmware);
> > +const char *devm_qcom_get_board_fw(struct device *dev, const char *firmware);
> > +
> > +#endif
> >
>
Dmitry Baryshkov May 21, 2024, 1:08 p.m. UTC | #3
On Tue, 21 May 2024 at 13:20, Kalle Valo <kvalo@kernel.org> wrote:
>
> Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes:
>
> > On Tue, 21 May 2024 at 12:52, <neil.armstrong@linaro.org> wrote:
> >>
> >> On 21/05/2024 11:45, Dmitry Baryshkov wrote:
> >> > Qualcomm platforms have different sets of the firmware files, which
> >> > differ from platform to platform (and from board to board, due to the
> >> > embedded signatures). Rather than listing all the firmware files,
> >> > including full paths, in the DT, provide a way to determine firmware
> >> > path based on the root DT node compatible.
> >>
> >> Ok this looks quite over-engineered but necessary to handle the legacy,
> >> but I really think we should add a way to look for a board-specific path
> >> first and fallback to those SoC specific paths.
> >
> > Again, CONFIG_FW_LOADER_USER_HELPER => delays.
>
> To me this also looks like very over-engineered, can you elaborate more
> why this is needed? Concrete examples would help to understand better.

Sure. During the meeting last week Arnd suggested evaluating if we can
drop firmware-name from the board DT files. Several reasons for that:
- DT should describe the hardware, not the Linux-firmware locations
- having firmware name in DT complicates updating the tree to use
different firmware API (think of mbn vs mdt vs any other format)
- If the DT gets supplied by the vendor (e.g. for
SystemReady-certified devices), there should be a sync between the
vendor's DT, linux kernel and the rootfs. Dropping firmware names from
DT solves that by removing one piece of the equation

Now for the complexity of the solution. Each SoC family has their own
firmware set. This includes firmware for the DSPs, for modem, WiFi
bits, GPU shader, etc.
For the development boards these devices are signed by the testing key
and the actual signature is not validated against the root of trust
certificate.
For the end-user devices the signature is actually validated against
the bits fused to the SoC during manufacturing process. CA certificate
(and thus the fuses) differ from vendor to vendor (and from the device
to device)

Not all of the firmware files are a part of the public linux-firmware
tree. However we need to support the rootfs bundled with the firmware
for different platforms (both public and vendor). The non-signed files
come from the Adreno GPU and can be shared between platforms. All
other files are SoC-specific and in some cases device-specific.

So for example the SDM845 db845c (open device) loads following firmware files:
Not signed:
- qcom/a630_sqe.fw
- qcom/a630_gmu.bin

Signed, will work for any non-secured sdm845 device:
- qcom/sdm845/a630_zap.mbn
- qcom/sdm845/adsp.mbn
- qcom/sdm845/cdsp.mbn
- qcom/sdm485/mba.mbn
- qcom/sdm845/modem.mbn
- qcom/sdm845/wlanmdsp.mbn (loaded via TQFTP)
- qcom/venus-5.2/venus.mbn

Signed, works only for DB845c.
- qcom/sdm845/Thundercomm/db845c/slpi.mbn

In comparison, the SDM845 Pixel-3 phone (aka blueline) should load the
following firmware files:
- qcom/a630_sqe.fw (the same, non-signed file)
- qcom/a630_gmu.bin (the same, non-signed file)
- qcom/sdm845/Google/blueline/a630_zap.mbn
- qcom/sdm845/Google/blueline/adsp.mbn
- qcom/sdm845/Google/blueline/cdsp.mbn
- qcom/sdm845/Google/blueline/ipa_fws.mbn
- qcom/sdm845/Google/blueline/mba.mbn
- qcom/sdm845/Google/blueline/modem.mbn
- qcom/sdm845/Google/blueline/venus.mbn
- qcom/sdm845/Google/blueline/wlanmdsp.mbn
- qcom/sdm845/Google/blueline/slpi.mbn

The Lenovo Yoga C630 WoS laptop (SDM850 is a variant of SDM845) uses
another set of files:
- qcom/a630_sqe.fw (the same, non-signed file)
- qcom/a630_gmu.bin (the same, non-signed file)
- qcom/sdm850/LENOVO/81JL/qcdxkmsuc850.mbn
- qcom/sdm850/LENOVO/81JL/qcadsp850.mbn
- qcom/sdm850/LENOVO/81JL/qccdsp850.mbn
- qcom/sdm850/LENOVO/81JL/ipa_fws.elf
- qcom/sdm850/LENOVO/81JL/qcdsp1v2850.mbn
- qcom/sdm850/LENOVO/81JL/qcdsp2850.mbn
- qcom/sdm850/LENOVO/81JL/qcvss850.mbn
- qcom/sdm850/LENOVO/81JL/wlanmdsp.mbn
- qcom/sdm850/LENOVO/81JL/qcslpi850.mbn

If we look at one of the recent platforms, e.g. SM8650-QRD, this list
also grows up:
- qcom/gen70900_sqe.fw (generic, non-signed)
- qcom/gmu_gen70900.bin (generic, non-signed)
- qcom/sm8650/gen70900_zap.mbn
- qcom/sm8650/adsp.mbn
- qcom/sm8650/adsp_dtb.mbn
- qcom/sm8650/cdsp.mbn
- qcom/sm8650/cdsp_dtb.mbn
- qcom/sm8650/ipa_fws.mbn
- qcom/sm8650/modem.mbn
- qcom/sm8650/modem_dtb.mbn
- qcom/sm8650/vpu33_4v.mbn (or maybe qcom/vpu-33/vpu_4v.mbn)
Jeff Johnson May 22, 2024, 7:21 p.m. UTC | #4
On 5/21/2024 2:45 AM, Dmitry Baryshkov wrote:
> Make the driver use qcom_fw_helper to autodetect the path to the
> calibration data file.
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
>  drivers/remoteproc/qcom_wcnss.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
> index 421a3943a90d..45fc578ae30b 100644
> --- a/drivers/remoteproc/qcom_wcnss.c
> +++ b/drivers/remoteproc/qcom_wcnss.c
> @@ -23,6 +23,7 @@
>  #include <linux/regulator/consumer.h>
>  #include <linux/remoteproc.h>
>  #include <linux/soc/qcom/mdt_loader.h>
> +#include <linux/soc/qcom/fw_helper.h>
>  #include <linux/soc/qcom/smem.h>
>  #include <linux/soc/qcom/smem_state.h>
>  
> @@ -555,8 +556,13 @@ static int wcnss_probe(struct platform_device *pdev)
>  	if (ret < 0 && ret != -EINVAL)
>  		return ret;
>  
> +	fw_name = qcom_get_board_fw(fw_name);
> +	if (!fw_name)
> +		return -ENOMEM;
> +
>  	rproc = devm_rproc_alloc(&pdev->dev, pdev->name, &wcnss_ops,
>  				 fw_name, sizeof(*wcnss));
> +	kfree(fw_name);
>  	if (!rproc) {
>  		dev_err(&pdev->dev, "unable to allocate remoteproc\n");
>  		return -ENOMEM;
> 

can you cleanly bisect to this patch? seems it depends upon patch 10.
should 09 & 10 be swapped, or perhaps squashed?
Dmitry Baryshkov May 22, 2024, 8:42 p.m. UTC | #5
On Wed, 22 May 2024 at 22:22, Jeff Johnson <quic_jjohnson@quicinc.com> wrote:
>
> On 5/21/2024 2:45 AM, Dmitry Baryshkov wrote:
> > Make the driver use qcom_fw_helper to autodetect the path to the
> > calibration data file.
> >
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > ---
> >  drivers/remoteproc/qcom_wcnss.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
> > index 421a3943a90d..45fc578ae30b 100644
> > --- a/drivers/remoteproc/qcom_wcnss.c
> > +++ b/drivers/remoteproc/qcom_wcnss.c
> > @@ -23,6 +23,7 @@
> >  #include <linux/regulator/consumer.h>
> >  #include <linux/remoteproc.h>
> >  #include <linux/soc/qcom/mdt_loader.h>
> > +#include <linux/soc/qcom/fw_helper.h>
> >  #include <linux/soc/qcom/smem.h>
> >  #include <linux/soc/qcom/smem_state.h>
> >
> > @@ -555,8 +556,13 @@ static int wcnss_probe(struct platform_device *pdev)
> >       if (ret < 0 && ret != -EINVAL)
> >               return ret;
> >
> > +     fw_name = qcom_get_board_fw(fw_name);
> > +     if (!fw_name)
> > +             return -ENOMEM;
> > +
> >       rproc = devm_rproc_alloc(&pdev->dev, pdev->name, &wcnss_ops,
> >                                fw_name, sizeof(*wcnss));
> > +     kfree(fw_name);
> >       if (!rproc) {
> >               dev_err(&pdev->dev, "unable to allocate remoteproc\n");
> >               return -ENOMEM;
> >
>
> can you cleanly bisect to this patch? seems it depends upon patch 10.
> should 09 & 10 be swapped, or perhaps squashed?

Yes. I think I got this mixed during rebasing and squashing of the
changes. For v2, if the approach is found to be generally acceptable,
I'll squash them.
Bjorn Andersson May 22, 2024, 10:48 p.m. UTC | #6
On Tue, May 21, 2024 at 03:08:31PM +0200, Dmitry Baryshkov wrote:
> On Tue, 21 May 2024 at 13:20, Kalle Valo <kvalo@kernel.org> wrote:
> >
> > Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes:
> >
> > > On Tue, 21 May 2024 at 12:52, <neil.armstrong@linaro.org> wrote:
> > >>
> > >> On 21/05/2024 11:45, Dmitry Baryshkov wrote:
> > >> > Qualcomm platforms have different sets of the firmware files, which
> > >> > differ from platform to platform (and from board to board, due to the
> > >> > embedded signatures). Rather than listing all the firmware files,
> > >> > including full paths, in the DT, provide a way to determine firmware
> > >> > path based on the root DT node compatible.
> > >>
> > >> Ok this looks quite over-engineered but necessary to handle the legacy,
> > >> but I really think we should add a way to look for a board-specific path
> > >> first and fallback to those SoC specific paths.
> > >
> > > Again, CONFIG_FW_LOADER_USER_HELPER => delays.
> >
> > To me this also looks like very over-engineered, can you elaborate more
> > why this is needed? Concrete examples would help to understand better.
> 
> Sure. During the meeting last week Arnd suggested evaluating if we can
> drop firmware-name from the board DT files. Several reasons for that:
> - DT should describe the hardware, not the Linux-firmware locations
> - having firmware name in DT complicates updating the tree to use
> different firmware API (think of mbn vs mdt vs any other format)
> - If the DT gets supplied by the vendor (e.g. for
> SystemReady-certified devices), there should be a sync between the
> vendor's DT, linux kernel and the rootfs. Dropping firmware names from
> DT solves that by removing one piece of the equation
> 
> Now for the complexity of the solution. Each SoC family has their own
> firmware set. This includes firmware for the DSPs, for modem, WiFi
> bits, GPU shader, etc.
> For the development boards these devices are signed by the testing key
> and the actual signature is not validated against the root of trust
> certificate.
> For the end-user devices the signature is actually validated against
> the bits fused to the SoC during manufacturing process. CA certificate
> (and thus the fuses) differ from vendor to vendor (and from the device
> to device)
> 
> Not all of the firmware files are a part of the public linux-firmware
> tree. However we need to support the rootfs bundled with the firmware
> for different platforms (both public and vendor). The non-signed files
> come from the Adreno GPU and can be shared between platforms. All
> other files are SoC-specific and in some cases device-specific.
> 
> So for example the SDM845 db845c (open device) loads following firmware files:
> Not signed:
> - qcom/a630_sqe.fw
> - qcom/a630_gmu.bin
> 
> Signed, will work for any non-secured sdm845 device:
> - qcom/sdm845/a630_zap.mbn
> - qcom/sdm845/adsp.mbn
> - qcom/sdm845/cdsp.mbn
> - qcom/sdm485/mba.mbn
> - qcom/sdm845/modem.mbn
> - qcom/sdm845/wlanmdsp.mbn (loaded via TQFTP)
> - qcom/venus-5.2/venus.mbn
> 
> Signed, works only for DB845c.
> - qcom/sdm845/Thundercomm/db845c/slpi.mbn
> 
> In comparison, the SDM845 Pixel-3 phone (aka blueline) should load the
> following firmware files:
> - qcom/a630_sqe.fw (the same, non-signed file)
> - qcom/a630_gmu.bin (the same, non-signed file)
> - qcom/sdm845/Google/blueline/a630_zap.mbn

How do you get from "a630_zap.mbn" to this? By extending the lookup
table for every target, or what am I missing?

Regards,
Bjorn

> - qcom/sdm845/Google/blueline/adsp.mbn
> - qcom/sdm845/Google/blueline/cdsp.mbn
> - qcom/sdm845/Google/blueline/ipa_fws.mbn
> - qcom/sdm845/Google/blueline/mba.mbn
> - qcom/sdm845/Google/blueline/modem.mbn
> - qcom/sdm845/Google/blueline/venus.mbn
> - qcom/sdm845/Google/blueline/wlanmdsp.mbn
> - qcom/sdm845/Google/blueline/slpi.mbn
> 
> The Lenovo Yoga C630 WoS laptop (SDM850 is a variant of SDM845) uses
> another set of files:
> - qcom/a630_sqe.fw (the same, non-signed file)
> - qcom/a630_gmu.bin (the same, non-signed file)
> - qcom/sdm850/LENOVO/81JL/qcdxkmsuc850.mbn
> - qcom/sdm850/LENOVO/81JL/qcadsp850.mbn
> - qcom/sdm850/LENOVO/81JL/qccdsp850.mbn
> - qcom/sdm850/LENOVO/81JL/ipa_fws.elf
> - qcom/sdm850/LENOVO/81JL/qcdsp1v2850.mbn
> - qcom/sdm850/LENOVO/81JL/qcdsp2850.mbn
> - qcom/sdm850/LENOVO/81JL/qcvss850.mbn
> - qcom/sdm850/LENOVO/81JL/wlanmdsp.mbn
> - qcom/sdm850/LENOVO/81JL/qcslpi850.mbn
> 
> If we look at one of the recent platforms, e.g. SM8650-QRD, this list
> also grows up:
> - qcom/gen70900_sqe.fw (generic, non-signed)
> - qcom/gmu_gen70900.bin (generic, non-signed)
> - qcom/sm8650/gen70900_zap.mbn
> - qcom/sm8650/adsp.mbn
> - qcom/sm8650/adsp_dtb.mbn
> - qcom/sm8650/cdsp.mbn
> - qcom/sm8650/cdsp_dtb.mbn
> - qcom/sm8650/ipa_fws.mbn
> - qcom/sm8650/modem.mbn
> - qcom/sm8650/modem_dtb.mbn
> - qcom/sm8650/vpu33_4v.mbn (or maybe qcom/vpu-33/vpu_4v.mbn)
> 
> -- 
> With best wishes
> Dmitry
> 
> 
> 
> 
> 
> 
> 
> 
>
Dmitry Baryshkov May 27, 2024, 11:42 a.m. UTC | #7
On Thu, 23 May 2024 at 01:48, Bjorn Andersson <quic_bjorande@quicinc.com> wrote:
>
> On Tue, May 21, 2024 at 03:08:31PM +0200, Dmitry Baryshkov wrote:
> > On Tue, 21 May 2024 at 13:20, Kalle Valo <kvalo@kernel.org> wrote:
> > >
> > > Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes:
> > >
> > > > On Tue, 21 May 2024 at 12:52, <neil.armstrong@linaro.org> wrote:
> > > >>
> > > >> On 21/05/2024 11:45, Dmitry Baryshkov wrote:
> > > >> > Qualcomm platforms have different sets of the firmware files, which
> > > >> > differ from platform to platform (and from board to board, due to the
> > > >> > embedded signatures). Rather than listing all the firmware files,
> > > >> > including full paths, in the DT, provide a way to determine firmware
> > > >> > path based on the root DT node compatible.
> > > >>
> > > >> Ok this looks quite over-engineered but necessary to handle the legacy,
> > > >> but I really think we should add a way to look for a board-specific path
> > > >> first and fallback to those SoC specific paths.
> > > >
> > > > Again, CONFIG_FW_LOADER_USER_HELPER => delays.
> > >
> > > To me this also looks like very over-engineered, can you elaborate more
> > > why this is needed? Concrete examples would help to understand better.
> >
> > Sure. During the meeting last week Arnd suggested evaluating if we can
> > drop firmware-name from the board DT files. Several reasons for that:
> > - DT should describe the hardware, not the Linux-firmware locations
> > - having firmware name in DT complicates updating the tree to use
> > different firmware API (think of mbn vs mdt vs any other format)
> > - If the DT gets supplied by the vendor (e.g. for
> > SystemReady-certified devices), there should be a sync between the
> > vendor's DT, linux kernel and the rootfs. Dropping firmware names from
> > DT solves that by removing one piece of the equation
> >
> > Now for the complexity of the solution. Each SoC family has their own
> > firmware set. This includes firmware for the DSPs, for modem, WiFi
> > bits, GPU shader, etc.
> > For the development boards these devices are signed by the testing key
> > and the actual signature is not validated against the root of trust
> > certificate.
> > For the end-user devices the signature is actually validated against
> > the bits fused to the SoC during manufacturing process. CA certificate
> > (and thus the fuses) differ from vendor to vendor (and from the device
> > to device)
> >
> > Not all of the firmware files are a part of the public linux-firmware
> > tree. However we need to support the rootfs bundled with the firmware
> > for different platforms (both public and vendor). The non-signed files
> > come from the Adreno GPU and can be shared between platforms. All
> > other files are SoC-specific and in some cases device-specific.
> >
> > So for example the SDM845 db845c (open device) loads following firmware files:
> > Not signed:
> > - qcom/a630_sqe.fw
> > - qcom/a630_gmu.bin
> >
> > Signed, will work for any non-secured sdm845 device:
> > - qcom/sdm845/a630_zap.mbn
> > - qcom/sdm845/adsp.mbn
> > - qcom/sdm845/cdsp.mbn
> > - qcom/sdm485/mba.mbn
> > - qcom/sdm845/modem.mbn
> > - qcom/sdm845/wlanmdsp.mbn (loaded via TQFTP)
> > - qcom/venus-5.2/venus.mbn
> >
> > Signed, works only for DB845c.
> > - qcom/sdm845/Thundercomm/db845c/slpi.mbn
> >
> > In comparison, the SDM845 Pixel-3 phone (aka blueline) should load the
> > following firmware files:
> > - qcom/a630_sqe.fw (the same, non-signed file)
> > - qcom/a630_gmu.bin (the same, non-signed file)
> > - qcom/sdm845/Google/blueline/a630_zap.mbn
>
> How do you get from "a630_zap.mbn" to this? By extending the lookup
> table for every target, or what am I missing?

More or less so. Matching the root OF node gives us the firmware
location, then it gets prepended to all firmware targets. Not an ideal
solution, as there is no fallback support, but at least it gives us
some points to discuss (and to decide whether to move to some
particular direction or to abandon the idea completely, making Arnd
unhappy again).

>
> Regards,
> Bjorn
>
> > - qcom/sdm845/Google/blueline/adsp.mbn
> > - qcom/sdm845/Google/blueline/cdsp.mbn
> > - qcom/sdm845/Google/blueline/ipa_fws.mbn
> > - qcom/sdm845/Google/blueline/mba.mbn
> > - qcom/sdm845/Google/blueline/modem.mbn
> > - qcom/sdm845/Google/blueline/venus.mbn
> > - qcom/sdm845/Google/blueline/wlanmdsp.mbn
> > - qcom/sdm845/Google/blueline/slpi.mbn
> >
> > The Lenovo Yoga C630 WoS laptop (SDM850 is a variant of SDM845) uses
> > another set of files:
> > - qcom/a630_sqe.fw (the same, non-signed file)
> > - qcom/a630_gmu.bin (the same, non-signed file)
> > - qcom/sdm850/LENOVO/81JL/qcdxkmsuc850.mbn
> > - qcom/sdm850/LENOVO/81JL/qcadsp850.mbn
> > - qcom/sdm850/LENOVO/81JL/qccdsp850.mbn
> > - qcom/sdm850/LENOVO/81JL/ipa_fws.elf
> > - qcom/sdm850/LENOVO/81JL/qcdsp1v2850.mbn
> > - qcom/sdm850/LENOVO/81JL/qcdsp2850.mbn
> > - qcom/sdm850/LENOVO/81JL/qcvss850.mbn
> > - qcom/sdm850/LENOVO/81JL/wlanmdsp.mbn
> > - qcom/sdm850/LENOVO/81JL/qcslpi850.mbn
> >
> > If we look at one of the recent platforms, e.g. SM8650-QRD, this list
> > also grows up:
> > - qcom/gen70900_sqe.fw (generic, non-signed)
> > - qcom/gmu_gen70900.bin (generic, non-signed)
> > - qcom/sm8650/gen70900_zap.mbn
> > - qcom/sm8650/adsp.mbn
> > - qcom/sm8650/adsp_dtb.mbn
> > - qcom/sm8650/cdsp.mbn
> > - qcom/sm8650/cdsp_dtb.mbn
> > - qcom/sm8650/ipa_fws.mbn
> > - qcom/sm8650/modem.mbn
> > - qcom/sm8650/modem_dtb.mbn
> > - qcom/sm8650/vpu33_4v.mbn (or maybe qcom/vpu-33/vpu_4v.mbn)
> >
> > --
> > With best wishes
> > Dmitry
> >
> >
> >
> >
> >
> >
> >
> >
> >
Bjorn Andersson May 29, 2024, 2:28 a.m. UTC | #8
On Mon, May 27, 2024 at 02:42:44PM GMT, Dmitry Baryshkov wrote:
> On Thu, 23 May 2024 at 01:48, Bjorn Andersson <quic_bjorande@quicinc.com> wrote:
> >
> > On Tue, May 21, 2024 at 03:08:31PM +0200, Dmitry Baryshkov wrote:
> > > On Tue, 21 May 2024 at 13:20, Kalle Valo <kvalo@kernel.org> wrote:
> > > >
> > > > Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes:
> > > >
> > > > > On Tue, 21 May 2024 at 12:52, <neil.armstrong@linaro.org> wrote:
> > > > >>
> > > > >> On 21/05/2024 11:45, Dmitry Baryshkov wrote:
> > > > >> > Qualcomm platforms have different sets of the firmware files, which
> > > > >> > differ from platform to platform (and from board to board, due to the
> > > > >> > embedded signatures). Rather than listing all the firmware files,
> > > > >> > including full paths, in the DT, provide a way to determine firmware
> > > > >> > path based on the root DT node compatible.
> > > > >>
> > > > >> Ok this looks quite over-engineered but necessary to handle the legacy,
> > > > >> but I really think we should add a way to look for a board-specific path
> > > > >> first and fallback to those SoC specific paths.
> > > > >
> > > > > Again, CONFIG_FW_LOADER_USER_HELPER => delays.
> > > >
> > > > To me this also looks like very over-engineered, can you elaborate more
> > > > why this is needed? Concrete examples would help to understand better.
> > >
> > > Sure. During the meeting last week Arnd suggested evaluating if we can
> > > drop firmware-name from the board DT files. Several reasons for that:
> > > - DT should describe the hardware, not the Linux-firmware locations
> > > - having firmware name in DT complicates updating the tree to use
> > > different firmware API (think of mbn vs mdt vs any other format)
> > > - If the DT gets supplied by the vendor (e.g. for
> > > SystemReady-certified devices), there should be a sync between the
> > > vendor's DT, linux kernel and the rootfs. Dropping firmware names from
> > > DT solves that by removing one piece of the equation
> > >
> > > Now for the complexity of the solution. Each SoC family has their own
> > > firmware set. This includes firmware for the DSPs, for modem, WiFi
> > > bits, GPU shader, etc.
> > > For the development boards these devices are signed by the testing key
> > > and the actual signature is not validated against the root of trust
> > > certificate.
> > > For the end-user devices the signature is actually validated against
> > > the bits fused to the SoC during manufacturing process. CA certificate
> > > (and thus the fuses) differ from vendor to vendor (and from the device
> > > to device)
> > >
> > > Not all of the firmware files are a part of the public linux-firmware
> > > tree. However we need to support the rootfs bundled with the firmware
> > > for different platforms (both public and vendor). The non-signed files
> > > come from the Adreno GPU and can be shared between platforms. All
> > > other files are SoC-specific and in some cases device-specific.
> > >
> > > So for example the SDM845 db845c (open device) loads following firmware files:
> > > Not signed:
> > > - qcom/a630_sqe.fw
> > > - qcom/a630_gmu.bin
> > >
> > > Signed, will work for any non-secured sdm845 device:
> > > - qcom/sdm845/a630_zap.mbn
> > > - qcom/sdm845/adsp.mbn
> > > - qcom/sdm845/cdsp.mbn
> > > - qcom/sdm485/mba.mbn
> > > - qcom/sdm845/modem.mbn
> > > - qcom/sdm845/wlanmdsp.mbn (loaded via TQFTP)
> > > - qcom/venus-5.2/venus.mbn
> > >
> > > Signed, works only for DB845c.
> > > - qcom/sdm845/Thundercomm/db845c/slpi.mbn
> > >
> > > In comparison, the SDM845 Pixel-3 phone (aka blueline) should load the
> > > following firmware files:
> > > - qcom/a630_sqe.fw (the same, non-signed file)
> > > - qcom/a630_gmu.bin (the same, non-signed file)
> > > - qcom/sdm845/Google/blueline/a630_zap.mbn
> >
> > How do you get from "a630_zap.mbn" to this? By extending the lookup
> > table for every target, or what am I missing?
> 
> More or less so. Matching the root OF node gives us the firmware
> location, then it gets prepended to all firmware targets. Not an ideal
> solution, as there is no fallback support, but at least it gives us
> some points to discuss (and to decide whether to move to some
> particular direction or to abandon the idea completely, making Arnd
> unhappy again).
> 

I understand the desire to not put linux-firmware-specific paths in the
DeviceTree, but I think I'm less keen on having a big lookup table in
the kernel...

Regards,
Bjorn
Kalle Valo May 31, 2024, 6:48 p.m. UTC | #9
Bjorn Andersson <andersson@kernel.org> writes:

> On Mon, May 27, 2024 at 02:42:44PM GMT, Dmitry Baryshkov wrote:
>
>> On Thu, 23 May 2024 at 01:48, Bjorn Andersson <quic_bjorande@quicinc.com> wrote:
>> >
>> > On Tue, May 21, 2024 at 03:08:31PM +0200, Dmitry Baryshkov wrote:
>> > > On Tue, 21 May 2024 at 13:20, Kalle Valo <kvalo@kernel.org> wrote:
>> > > >
>> > > > Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes:
>> > > >
>> > > > > On Tue, 21 May 2024 at 12:52, <neil.armstrong@linaro.org> wrote:
>> > > > >>
>> > > > >> On 21/05/2024 11:45, Dmitry Baryshkov wrote:
>> > > > >> > Qualcomm platforms have different sets of the firmware files, which
>> > > > >> > differ from platform to platform (and from board to board, due to the
>> > > > >> > embedded signatures). Rather than listing all the firmware files,
>> > > > >> > including full paths, in the DT, provide a way to determine firmware
>> > > > >> > path based on the root DT node compatible.
>> > > > >>
>> > > > >> Ok this looks quite over-engineered but necessary to handle the legacy,
>> > > > >> but I really think we should add a way to look for a board-specific path
>> > > > >> first and fallback to those SoC specific paths.
>> > > > >
>> > > > > Again, CONFIG_FW_LOADER_USER_HELPER => delays.
>> > > >
>> > > > To me this also looks like very over-engineered, can you elaborate more
>> > > > why this is needed? Concrete examples would help to understand better.
>> > >
>> > > Sure. During the meeting last week Arnd suggested evaluating if we can
>> > > drop firmware-name from the board DT files. Several reasons for that:
>> > > - DT should describe the hardware, not the Linux-firmware locations
>> > > - having firmware name in DT complicates updating the tree to use
>> > > different firmware API (think of mbn vs mdt vs any other format)
>> > > - If the DT gets supplied by the vendor (e.g. for
>> > > SystemReady-certified devices), there should be a sync between the
>> > > vendor's DT, linux kernel and the rootfs. Dropping firmware names from
>> > > DT solves that by removing one piece of the equation
>> > >
>> > > Now for the complexity of the solution. Each SoC family has their own
>> > > firmware set. This includes firmware for the DSPs, for modem, WiFi
>> > > bits, GPU shader, etc.
>> > > For the development boards these devices are signed by the testing key
>> > > and the actual signature is not validated against the root of trust
>> > > certificate.
>> > > For the end-user devices the signature is actually validated against
>> > > the bits fused to the SoC during manufacturing process. CA certificate
>> > > (and thus the fuses) differ from vendor to vendor (and from the device
>> > > to device)
>> > >
>> > > Not all of the firmware files are a part of the public linux-firmware
>> > > tree. However we need to support the rootfs bundled with the firmware
>> > > for different platforms (both public and vendor). The non-signed files
>> > > come from the Adreno GPU and can be shared between platforms. All
>> > > other files are SoC-specific and in some cases device-specific.
>> > >
>> > > So for example the SDM845 db845c (open device) loads following firmware files:
>> > > Not signed:
>> > > - qcom/a630_sqe.fw
>> > > - qcom/a630_gmu.bin
>> > >
>> > > Signed, will work for any non-secured sdm845 device:
>> > > - qcom/sdm845/a630_zap.mbn
>> > > - qcom/sdm845/adsp.mbn
>> > > - qcom/sdm845/cdsp.mbn
>> > > - qcom/sdm485/mba.mbn
>> > > - qcom/sdm845/modem.mbn
>> > > - qcom/sdm845/wlanmdsp.mbn (loaded via TQFTP)
>> > > - qcom/venus-5.2/venus.mbn
>> > >
>> > > Signed, works only for DB845c.
>> > > - qcom/sdm845/Thundercomm/db845c/slpi.mbn
>> > >
>> > > In comparison, the SDM845 Pixel-3 phone (aka blueline) should load the
>> > > following firmware files:
>> > > - qcom/a630_sqe.fw (the same, non-signed file)
>> > > - qcom/a630_gmu.bin (the same, non-signed file)
>> > > - qcom/sdm845/Google/blueline/a630_zap.mbn
>> >
>> > How do you get from "a630_zap.mbn" to this? By extending the lookup
>> > table for every target, or what am I missing?
>> 
>> More or less so. Matching the root OF node gives us the firmware
>> location, then it gets prepended to all firmware targets. Not an ideal
>> solution, as there is no fallback support, but at least it gives us
>> some points to discuss (and to decide whether to move to some
>> particular direction or to abandon the idea completely, making Arnd
>> unhappy again).
>> 
>
> I understand the desire to not put linux-firmware-specific paths in the
> DeviceTree

Me too.

> but I think I'm less keen on having a big lookup table in the
> kernel...

Yeah, also for me this feels wrong. But on the other hand I don't have
anything better to suggest either...