drivers/firmware/qcom/qcom_scm.c | 161 ++++++++++++++++++++ drivers/firmware/qcom/qcom_scm.h | 3 + drivers/mtd/devices/Kconfig | 17 +++ drivers/mtd/devices/Makefile | 1 + drivers/mtd/devices/qcom_scm_storage.c | 265 +++++++++++++++++++++++++++++++++ include/linux/firmware/qcom/qcom_scm.h | 34 +++++ 6 files changed, 481 insertions(+)
This patch series adds support for accessing storage devices managed by
Qualcomm TrustZone firmware via SCM (Secure Channel Manager) by
introducing a new MTD driver.
On some Qualcomm platforms, firmware or BIOS-related storage (typically
SPI NOR flash) is not directly accessible from the non-secure world.
All read, write, and erase operations must be performed through SCM
interfaces provided by the secure firmware. As a result, existing MTD
SPI NOR drivers cannot be used directly on these systems.
This series introduces a new MTD device driver that exposes such
firmware-managed storage as a standard MTD device in the Linux kernel.
The driver is built on top of the existing Qualcomm SCM infrastructure
and integrates with the MTD subsystem to provide a uniform interface to
userspace.
This driver has been tested on Radxa Dragon Q6A, based on the Qualcomm
QCS6490 SoC, with a Winbond W25Q256JWPIQ SPI NOR flash device.
Note that this platform previously used the standard Qualcomm Linux
firmware, which allowed direct access to the QSPI controller without
needing this driver. However, we plan to migrate to a Windows-compatible
firmware which is more feature-complete but restricts direct access.
Device tree changes for this transition will be sent separately.
If kernel boots with EL2, access to the SCM storage will be denied. This
needs more investigation.
Changes in v2:
- Convert enum qcom_scm_storage_result to macro definitions
- Use __qcom_scm_is_call_available() instead of a machine allowlist
- Add missing __packed annotations and endianness handling
- Introduce struct qcom_scm_storage_payload to improve readability
- Always compiled-in qcom_scm_storage_send_cmd() and qcom_scm_storage_init()
https://lore.kernel.org/lkml/F138514E18CB55B6+20251218180205.930961-1-bigfoot@radxa.com/
Tested-by: Xilin Wu <sophon@radxa.com>
Signed-off-by: Junhao Xie <bigfoot@radxa.com>
---
Junhao Xie (2):
firmware: qcom: scm: Add SCM storage interface support
mtd: devices: Add Qualcomm SCM storage driver
drivers/firmware/qcom/qcom_scm.c | 161 ++++++++++++++++++++
drivers/firmware/qcom/qcom_scm.h | 3 +
drivers/mtd/devices/Kconfig | 17 +++
drivers/mtd/devices/Makefile | 1 +
drivers/mtd/devices/qcom_scm_storage.c | 265 +++++++++++++++++++++++++++++++++
include/linux/firmware/qcom/qcom_scm.h | 34 +++++
6 files changed, 481 insertions(+)
---
base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
change-id: 20260126-scm-storage-v2-0a4f3e900b88
Best regards,
--
Junhao Xie <bigfoot@radxa.com>
On 1/26/2026 3:44 AM, Junhao Xie wrote: > This patch series adds support for accessing storage devices managed by > Qualcomm TrustZone firmware via SCM (Secure Channel Manager) by > introducing a new MTD driver. > > On some Qualcomm platforms, firmware or BIOS-related storage (typically > SPI NOR flash) is not directly accessible from the non-secure world. > All read, write, and erase operations must be performed through SCM > interfaces provided by the secure firmware. As a result, existing MTD > SPI NOR drivers cannot be used directly on these systems. > > This series introduces a new MTD device driver that exposes such > firmware-managed storage as a standard MTD device in the Linux kernel. > The driver is built on top of the existing Qualcomm SCM infrastructure > and integrates with the MTD subsystem to provide a uniform interface to > userspace. > > This driver has been tested on Radxa Dragon Q6A, based on the Qualcomm > QCS6490 SoC, with a Winbond W25Q256JWPIQ SPI NOR flash device. > > Note that this platform previously used the standard Qualcomm Linux > firmware, which allowed direct access to the QSPI controller without > needing this driver. However, we plan to migrate to a Windows-compatible > firmware which is more feature-complete but restricts direct access. > Device tree changes for this transition will be sent separately. > > If kernel boots with EL2, access to the SCM storage will be denied. This > needs more investigation. So you plan to enable this driver only w/ the Gunyah based configuration and disable for the KVM one through the devicetree overlay ? I just don't want to break the KVM boot flow on other platforms supporting qcs6490. > > Changes in v2: > - Convert enum qcom_scm_storage_result to macro definitions > - Use __qcom_scm_is_call_available() instead of a machine allowlist > - Add missing __packed annotations and endianness handling > - Introduce struct qcom_scm_storage_payload to improve readability > - Always compiled-in qcom_scm_storage_send_cmd() and qcom_scm_storage_init() > https://lore.kernel.org/lkml/F138514E18CB55B6+20251218180205.930961-1-bigfoot@radxa.com/ > > Tested-by: Xilin Wu <sophon@radxa.com> > Signed-off-by: Junhao Xie <bigfoot@radxa.com> > --- > Junhao Xie (2): > firmware: qcom: scm: Add SCM storage interface support > mtd: devices: Add Qualcomm SCM storage driver > > drivers/firmware/qcom/qcom_scm.c | 161 ++++++++++++++++++++ > drivers/firmware/qcom/qcom_scm.h | 3 + > drivers/mtd/devices/Kconfig | 17 +++ > drivers/mtd/devices/Makefile | 1 + > drivers/mtd/devices/qcom_scm_storage.c | 265 +++++++++++++++++++++++++++++++++ > include/linux/firmware/qcom/qcom_scm.h | 34 +++++ > 6 files changed, 481 insertions(+) > --- > base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377 > change-id: 20260126-scm-storage-v2-0a4f3e900b88 > > Best regards,
On 2026/1/29 5:43, Trilok Soni wrote: > On 1/26/2026 3:44 AM, Junhao Xie wrote: >> This patch series adds support for accessing storage devices managed by >> Qualcomm TrustZone firmware via SCM (Secure Channel Manager) by >> introducing a new MTD driver. >> >> On some Qualcomm platforms, firmware or BIOS-related storage (typically >> SPI NOR flash) is not directly accessible from the non-secure world. >> All read, write, and erase operations must be performed through SCM >> interfaces provided by the secure firmware. As a result, existing MTD >> SPI NOR drivers cannot be used directly on these systems. >> >> This series introduces a new MTD device driver that exposes such >> firmware-managed storage as a standard MTD device in the Linux kernel. >> The driver is built on top of the existing Qualcomm SCM infrastructure >> and integrates with the MTD subsystem to provide a uniform interface to >> userspace. >> >> This driver has been tested on Radxa Dragon Q6A, based on the Qualcomm >> QCS6490 SoC, with a Winbond W25Q256JWPIQ SPI NOR flash device. >> >> Note that this platform previously used the standard Qualcomm Linux >> firmware, which allowed direct access to the QSPI controller without >> needing this driver. However, we plan to migrate to a Windows-compatible >> firmware which is more feature-complete but restricts direct access. >> Device tree changes for this transition will be sent separately. >> >> If kernel boots with EL2, access to the SCM storage will be denied. This >> needs more investigation. > So you plan to enable this driver only w/ the Gunyah based configuration > and disable for the KVM one through the devicetree overlay ? I just > don't want to break the KVM boot flow on other platforms supporting > qcs6490. On systems booted with EL2/KVM, the SCM storage GET_INFO call currently returns -EINVAL. If a platform does not support SPI-NOR or SCM storage, __qcom_scm_is_call_available() will cause the initialization to bail out early. There is no DT-based enable/disable mechanism, and this should not affect KVM boot flow on other platforms. Other QCS6490 LE platforms do not support SCM storage, as the LE firmware does not support SPI-NOR boot. Radxa Dragon Q6A uses WP firmware and boots from SPI-NOR. The root cause of SCM storage being unavailable under EL2/KVM is still under investigation. [ 0.770124] qcom_scm: convention: smc arm 64 [ 0.775005] qcom_scm firmware:scm: qseecom: found qseecom with version 0x1402000 [ 0.782990] qcom_scm firmware:scm: scm storage get info failed: -22 [ 0.999095] qcom_qseecom qcom_qseecom: setting up client for qcom.tz.uefisecapp Thanks for your reply. Best regards, Junhao Xie
On 1/29/26 1:47 PM, Junhao Xie wrote:
> On 2026/1/29 5:43, Trilok Soni wrote:
>
>> On 1/26/2026 3:44 AM, Junhao Xie wrote:
>>> This patch series adds support for accessing storage devices managed by
>>> Qualcomm TrustZone firmware via SCM (Secure Channel Manager) by
>>> introducing a new MTD driver.
>>>
>>> On some Qualcomm platforms, firmware or BIOS-related storage (typically
>>> SPI NOR flash) is not directly accessible from the non-secure world.
>>> All read, write, and erase operations must be performed through SCM
>>> interfaces provided by the secure firmware. As a result, existing MTD
>>> SPI NOR drivers cannot be used directly on these systems.
>>>
>>> This series introduces a new MTD device driver that exposes such
>>> firmware-managed storage as a standard MTD device in the Linux kernel.
>>> The driver is built on top of the existing Qualcomm SCM infrastructure
>>> and integrates with the MTD subsystem to provide a uniform interface to
>>> userspace.
>>>
>>> This driver has been tested on Radxa Dragon Q6A, based on the Qualcomm
>>> QCS6490 SoC, with a Winbond W25Q256JWPIQ SPI NOR flash device.
>>>
>>> Note that this platform previously used the standard Qualcomm Linux
>>> firmware, which allowed direct access to the QSPI controller without
>>> needing this driver. However, we plan to migrate to a Windows-compatible
>>> firmware which is more feature-complete but restricts direct access.
>>> Device tree changes for this transition will be sent separately.
>>>
>>> If kernel boots with EL2, access to the SCM storage will be denied. This
>>> needs more investigation.
>> So you plan to enable this driver only w/ the Gunyah based configuration
>> and disable for the KVM one through the devicetree overlay ? I just
>> don't want to break the KVM boot flow on other platforms supporting
>> qcs6490.
>
> On systems booted with EL2/KVM, the SCM storage GET_INFO call currently
> returns -EINVAL. If a platform does not support SPI-NOR or SCM storage,
> __qcom_scm_is_call_available() will cause the initialization to bail out early.
>
> There is no DT-based enable/disable mechanism, and this should not affect
> KVM boot flow on other platforms.
>
> Other QCS6490 LE platforms do not support SCM storage, as the LE firmware
> does not support SPI-NOR boot. Radxa Dragon Q6A uses WP firmware and boots
> from SPI-NOR.
>
> The root cause of SCM storage being unavailable under EL2/KVM is still under
> investigation.
>
> [ 0.770124] qcom_scm: convention: smc arm 64
> [ 0.775005] qcom_scm firmware:scm: qseecom: found qseecom with version 0x1402000
> [ 0.782990] qcom_scm firmware:scm: scm storage get info failed: -22
> [ 0.999095] qcom_qseecom qcom_qseecom: setting up client for qcom.tz.uefisecapp
I think you need to create a shmbridge when running without gunyah, see
e.g.
4a7d6a78fbc6 ("firmware: qcom_scm: Add a prep version of auth_and_reset function")
where the memory is bridged right before the call. Without knowing any
better I would guesstimate you may need to qcom_tzalloc (which does that
under the hood) the 'struct qcom_scm_storage_info info' which you pass
to that func in qcom_scm_storage_init()
Konrad
On Mon, Jan 26, 2026 at 07:44:50PM +0800, Junhao Xie wrote: > This patch series adds support for accessing storage devices managed by > Qualcomm TrustZone firmware via SCM (Secure Channel Manager) by > introducing a new MTD driver. > > On some Qualcomm platforms, firmware or BIOS-related storage (typically > SPI NOR flash) is not directly accessible from the non-secure world. > All read, write, and erase operations must be performed through SCM > interfaces provided by the secure firmware. As a result, existing MTD > SPI NOR drivers cannot be used directly on these systems. > > This series introduces a new MTD device driver that exposes such > firmware-managed storage as a standard MTD device in the Linux kernel. > The driver is built on top of the existing Qualcomm SCM infrastructure > and integrates with the MTD subsystem to provide a uniform interface to > userspace. > > This driver has been tested on Radxa Dragon Q6A, based on the Qualcomm > QCS6490 SoC, with a Winbond W25Q256JWPIQ SPI NOR flash device. > > Note that this platform previously used the standard Qualcomm Linux > firmware, which allowed direct access to the QSPI controller without > needing this driver. However, we plan to migrate to a Windows-compatible > firmware which is more feature-complete but restricts direct access. > Device tree changes for this transition will be sent separately. > > If kernel boots with EL2, access to the SCM storage will be denied. This > needs more investigation. > Sorry, I missed your reply to me on v1. You replied that this allow your users to update "BIOS" firmware directly from Linux, which I can see being more convenient than relying on UEFI update capsules, in particular in a development environment. The concern I have with this is that I don't think an end-user of such system, has a way to recover from breaking the content on their SPI-NOR. As such, exposing such a convenient interface for the end-user to brick their devices is probably not a good idea. I think we should somehow lock the interface down to be read-only by default, and perhaps have some mechanism to unlock the write mode (like a module parameter expecting the sentence "YES, I DO HAVE THE FIREHOSE PROGRAMMER FOR THIS BOARD"). I don't believe you answered my question regarding how to access this interface from the kernel. On many of these devices we can find the MAC addresses of the system in the "DPP" partition. Do you have any ideas about how we could access this from within the kernel? Regards, Bjorn > Changes in v2: > - Convert enum qcom_scm_storage_result to macro definitions > - Use __qcom_scm_is_call_available() instead of a machine allowlist > - Add missing __packed annotations and endianness handling > - Introduce struct qcom_scm_storage_payload to improve readability > - Always compiled-in qcom_scm_storage_send_cmd() and qcom_scm_storage_init() > https://lore.kernel.org/lkml/F138514E18CB55B6+20251218180205.930961-1-bigfoot@radxa.com/ > > Tested-by: Xilin Wu <sophon@radxa.com> > Signed-off-by: Junhao Xie <bigfoot@radxa.com> > --- > Junhao Xie (2): > firmware: qcom: scm: Add SCM storage interface support > mtd: devices: Add Qualcomm SCM storage driver > > drivers/firmware/qcom/qcom_scm.c | 161 ++++++++++++++++++++ > drivers/firmware/qcom/qcom_scm.h | 3 + > drivers/mtd/devices/Kconfig | 17 +++ > drivers/mtd/devices/Makefile | 1 + > drivers/mtd/devices/qcom_scm_storage.c | 265 +++++++++++++++++++++++++++++++++ > include/linux/firmware/qcom/qcom_scm.h | 34 +++++ > 6 files changed, 481 insertions(+) > --- > base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377 > change-id: 20260126-scm-storage-v2-0a4f3e900b88 > > Best regards, > -- > Junhao Xie <bigfoot@radxa.com> >
On 2026/1/29 4:42, Bjorn Andersson wrote: > On Mon, Jan 26, 2026 at 07:44:50PM +0800, Junhao Xie wrote: >> This patch series adds support for accessing storage devices managed by >> Qualcomm TrustZone firmware via SCM (Secure Channel Manager) by >> introducing a new MTD driver. >> >> On some Qualcomm platforms, firmware or BIOS-related storage (typically >> SPI NOR flash) is not directly accessible from the non-secure world. >> All read, write, and erase operations must be performed through SCM >> interfaces provided by the secure firmware. As a result, existing MTD >> SPI NOR drivers cannot be used directly on these systems. >> >> This series introduces a new MTD device driver that exposes such >> firmware-managed storage as a standard MTD device in the Linux kernel. >> The driver is built on top of the existing Qualcomm SCM infrastructure >> and integrates with the MTD subsystem to provide a uniform interface to >> userspace. >> >> This driver has been tested on Radxa Dragon Q6A, based on the Qualcomm >> QCS6490 SoC, with a Winbond W25Q256JWPIQ SPI NOR flash device. >> >> Note that this platform previously used the standard Qualcomm Linux >> firmware, which allowed direct access to the QSPI controller without >> needing this driver. However, we plan to migrate to a Windows-compatible >> firmware which is more feature-complete but restricts direct access. >> Device tree changes for this transition will be sent separately. >> >> If kernel boots with EL2, access to the SCM storage will be denied. This >> needs more investigation. >> > Sorry, I missed your reply to me on v1. > > > You replied that this allow your users to update "BIOS" firmware > directly from Linux, which I can see being more convenient than relying > on UEFI update capsules, in particular in a development environment. > > The concern I have with this is that I don't think an end-user of such > system, has a way to recover from breaking the content on their SPI-NOR. > > As such, exposing such a convenient interface for the end-user to brick > their devices is probably not a good idea. > > I think we should somehow lock the interface down to be read-only by > default, and perhaps have some mechanism to unlock the write mode (like > a module parameter expecting the sentence "YES, I DO HAVE THE FIREHOSE > PROGRAMMER FOR THIS BOARD"). > > > I don't believe you answered my question regarding how to access this > interface from the kernel. On many of these devices we can find the MAC > addresses of the system in the "DPP" partition. Do you have any ideas > about how we could access this from within the kernel? > > Regards, > Bjorn I agree with your point. I will add a module param in v3 for default read-only mode. e.g.: /sys/module/qcom_scm_storage/parameters/allow_write For something like the "DPP" partition, I think it's better to access it from userspace than from kernel. Best regards, Junhao Xie
Hi, >> I don't believe you answered my question regarding how to access this >> interface from the kernel. On many of these devices we can find the MAC >> addresses of the system in the "DPP" partition. Do you have any ideas >> about how we could access this from within the kernel? >> >> Regards, >> Bjorn > > I agree with your point. I will add a module param in v3 for default > read-only mode. e.g.: /sys/module/qcom_scm_storage/parameters/allow_write > > For something like the "DPP" partition, I think it's better to access it > from userspace than from kernel. If it's a MAC address that you are accessing, direct userspace does not sound like a good fit. If I may, NVMEM cells are there exactly for this purpose: identifying the content of a subpart of a storage device in a storage agnostic way. The NVMEM cells are made available to in-kernel drivers (ie. network devices have all the infrastructure to get the MAC address from there) and their content is also exposed to userspace through sysfs now. Thanks, Miquèl
On 2026/1/30 22:10, Miquel Raynal wrote: > Hi, > >>> I don't believe you answered my question regarding how to access this >>> interface from the kernel. On many of these devices we can find the MAC >>> addresses of the system in the "DPP" partition. Do you have any ideas >>> about how we could access this from within the kernel? >>> >>> Regards, >>> Bjorn >> I agree with your point. I will add a module param in v3 for default >> read-only mode. e.g.: /sys/module/qcom_scm_storage/parameters/allow_write >> >> For something like the "DPP" partition, I think it's better to access it >> from userspace than from kernel. > If it's a MAC address that you are accessing, direct userspace does not > sound like a good fit. If I may, NVMEM cells are there exactly for this > purpose: identifying the content of a subpart of a storage device in a > storage agnostic way. The NVMEM cells are made available to in-kernel > drivers (ie. network devices have all the infrastructure to get the MAC > address from there) and their content is also exposed to userspace > through sysfs now. Qualcomm's SPI-NOR boot firmware uses a GPT partition table. The "DPP" partition contains a FAT file system, and the MAC address is stored in one of these files. Because the data is stored inside a filesystem rather than at a fixed offset, it does not fit well with the NVMEM model, which assumes simple offset-based access. Accessing this would require the kernel to directly read files from a filesystem, which is generally not appropriate, so this should probably not be accessed from kernel. > Thanks, > Miquèl Best regards, Junhao Xie
>>> For something like the "DPP" partition, I think it's better to access it >>> from userspace than from kernel. >> If it's a MAC address that you are accessing, direct userspace does not >> sound like a good fit. If I may, NVMEM cells are there exactly for this >> purpose: identifying the content of a subpart of a storage device in a >> storage agnostic way. The NVMEM cells are made available to in-kernel >> drivers (ie. network devices have all the infrastructure to get the MAC >> address from there) and their content is also exposed to userspace >> through sysfs now. > > Qualcomm's SPI-NOR boot firmware uses a GPT partition table. The "DPP" > partition contains a FAT file system, and the MAC address is stored in > one of these files. > > Because the data is stored inside a filesystem rather than at a fixed > offset, it does not fit well with the NVMEM model, which assumes simple > offset-based access. Not anymore, there are nvmem layouts now that are much more flexible, so if a network driver shall get this MAC address, it is still doable. Otherwise there is no such need, and in the case of a file in a FAT filesystem, I guess it is preferable to use mtdblock/ubiblock in order to expose a block device and mount it from userspace. Please note that exposing a FAT filesystem on top of a SPI NOR is very inappropriate. FAT is a block filesystem, not aware of all the MTD specificities (like bad blocks). Cheers, Miquèl
On 1/26/26 12:44 PM, Junhao Xie wrote: > This patch series adds support for accessing storage devices managed by > Qualcomm TrustZone firmware via SCM (Secure Channel Manager) by > introducing a new MTD driver. > > On some Qualcomm platforms, firmware or BIOS-related storage (typically > SPI NOR flash) is not directly accessible from the non-secure world. > All read, write, and erase operations must be performed through SCM > interfaces provided by the secure firmware. As a result, existing MTD > SPI NOR drivers cannot be used directly on these systems. > > This series introduces a new MTD device driver that exposes such > firmware-managed storage as a standard MTD device in the Linux kernel. > The driver is built on top of the existing Qualcomm SCM infrastructure > and integrates with the MTD subsystem to provide a uniform interface to > userspace. [...] > Junhao Xie (2): > firmware: qcom: scm: Add SCM storage interface support > mtd: devices: Add Qualcomm SCM storage driver > > drivers/firmware/qcom/qcom_scm.c | 161 ++++++++++++++++++++ > drivers/firmware/qcom/qcom_scm.h | 3 + > drivers/mtd/devices/Kconfig | 17 +++ > drivers/mtd/devices/Makefile | 1 + > drivers/mtd/devices/qcom_scm_storage.c | 265 +++++++++++++++++++++++++++++++++ > include/linux/firmware/qcom/qcom_scm.h | 34 +++++ > 6 files changed, 481 insertions(+) > --- > base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377 This is 6.19-rc7, please rebase on linux-next/master (the series doesn't currently apply because this base is essentially a full release behind) Konrad
On 2026/1/28 21:26, Konrad Dybcio wrote: > On 1/26/26 12:44 PM, Junhao Xie wrote: >> Junhao Xie (2): >> firmware: qcom: scm: Add SCM storage interface support >> mtd: devices: Add Qualcomm SCM storage driver >> >> drivers/firmware/qcom/qcom_scm.c | 161 ++++++++++++++++++++ >> drivers/firmware/qcom/qcom_scm.h | 3 + >> drivers/mtd/devices/Kconfig | 17 +++ >> drivers/mtd/devices/Makefile | 1 + >> drivers/mtd/devices/qcom_scm_storage.c | 265 +++++++++++++++++++++++++++++++++ >> include/linux/firmware/qcom/qcom_scm.h | 34 +++++ >> 6 files changed, 481 insertions(+) >> --- >> base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377 > This is 6.19-rc7, please rebase on linux-next/master (the series > doesn't currently apply because this base is essentially a full release > behind) I will rebase the series onto linux-next/master in v3. > Konrad Best regards, Junhao Xie
Hello, >> Junhao Xie (2): >> firmware: qcom: scm: Add SCM storage interface support >> mtd: devices: Add Qualcomm SCM storage driver >> >> drivers/firmware/qcom/qcom_scm.c | 161 ++++++++++++++++++++ >> drivers/firmware/qcom/qcom_scm.h | 3 + >> drivers/mtd/devices/Kconfig | 17 +++ >> drivers/mtd/devices/Makefile | 1 + >> drivers/mtd/devices/qcom_scm_storage.c | 265 +++++++++++++++++++++++++++++++++ >> include/linux/firmware/qcom/qcom_scm.h | 34 +++++ >> 6 files changed, 481 insertions(+) >> --- >> base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377 > > This is 6.19-rc7, please rebase on linux-next/master (the series > doesn't currently apply because this base is essentially a full release > behind) If I may, I even skipped the mail entirely because it was not about mtd in the end. There is a single big patch labelled "firmware: qcom:". I believe the series would better be split in smaller chunks. Typically one for the storage support and another one for the firmware part, at least. Thanks, Miquèl
On Wed, Jan 28, 2026 at 03:13:59PM +0100, Miquel Raynal wrote: > Hello, > > >> Junhao Xie (2): > >> firmware: qcom: scm: Add SCM storage interface support > >> mtd: devices: Add Qualcomm SCM storage driver > >> > >> drivers/firmware/qcom/qcom_scm.c | 161 ++++++++++++++++++++ > >> drivers/firmware/qcom/qcom_scm.h | 3 + > >> drivers/mtd/devices/Kconfig | 17 +++ > >> drivers/mtd/devices/Makefile | 1 + > >> drivers/mtd/devices/qcom_scm_storage.c | 265 +++++++++++++++++++++++++++++++++ > >> include/linux/firmware/qcom/qcom_scm.h | 34 +++++ > >> 6 files changed, 481 insertions(+) > >> --- > >> base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377 > > > > This is 6.19-rc7, please rebase on linux-next/master (the series > > doesn't currently apply because this base is essentially a full release > > behind) > > If I may, I even skipped the mail entirely because it was not about mtd > in the end. There is a single big patch labelled "firmware: qcom:". I > believe the series would better be split in smaller chunks. Typically > one for the storage support and another one for the firmware part, at > least. > The firmware patch adds wrappers for the secure world interface, which without the MTD driver will lack consumers of the API - i.e. I'd prefer not to pick that part, or parts thereof, alone. So I think it does make sense to introduce the two parts together in one series (if you have any requests for splitting the MTD patch up in any way I have no objections). This leaves us with the practical problem of getting it merged, which I believe would best be handled by me picking the firmware patch and sharing this in an immutable branch with you, once we're happy with the set (which won't be for 6.20). I hope you're okay with such plan? Regards, Bjorn > Thanks, > Miquèl
Hello Bjorn, >> If I may, I even skipped the mail entirely because it was not about mtd >> in the end. There is a single big patch labelled "firmware: qcom:". I >> believe the series would better be split in smaller chunks. Typically >> one for the storage support and another one for the firmware part, at >> least. >> > > The firmware patch adds wrappers for the secure world interface, which > without the MTD driver will lack consumers of the API - i.e. I'd prefer > not to pick that part, or parts thereof, alone. Yes, I understand. > So I think it does make sense to introduce the two parts together in one > series (if you have any requests for splitting the MTD patch up in any > way I have no objections). > > This leaves us with the practical problem of getting it merged, which I > believe would best be handled by me picking the firmware patch and > sharing this in an immutable branch with you, once we're happy with the > set (which won't be for 6.20). Works for me! I'll send a minor review with a couple of comments, but we can apply this close after next -rc1, if you are good with the fw part. Thanks, Miquèl
© 2016 - 2026 Red Hat, Inc.