Re: [PATCH v2 0/2] mtd: devices: Qualcomm SCM storage support

[Junhao Xie]

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