[PATCH 2/2] mtd: devices: Add Qualcomm SCM storage driver

[Junhao Xie]

On 2025/12/22 17:43, Konrad Dybcio wrote:
> On 12/19/25 6:12 PM, Junhao Xie wrote:
>> On 2025/12/19 20:05, Konrad Dybcio wrote:
>>> On 12/18/25 7:02 PM, Junhao Xie wrote:
>>>> Add MTD driver for accessing storage devices managed by Qualcomm's
>>>> TrustZone firmware. On some platforms, BIOS/firmware storage (typically
>>>> SPI NOR flash) is not directly accessible from the non-secure world and
>>>> all operations must go through SCM (Secure Channel Manager) calls.
>>>>
>>>> Signed-off-by: Junhao Xie <bigfoot at radxa.com>
>>>> Tested-by: Xilin Wu <sophon at radxa.com>
>>>> ---
> [...]
>
>>>> +	host->buffer_size = SZ_256K;
>>> Should this just be = host->info->page_size?
>> The value of page_size is smaller than what we want for
>> buffering SCM transfers. The buffer is intended for batching
>> larger operations, so a larger fixed size is used here.
>>
>> struct qcom_scm_storage_info:
>>   total_blocks = 8192
>>   block_size = 4096
>>   page_size = 256
>>   num_physical = 0
>>   manufacturer_id = 0
>>   serial_num = 1663215
>>   fw_version = 
>>   memory_type = NOR
> I don't see how the big buffer is any useful TBF - you read into this
> buffer before outputting to *buf and copy data from *buf into the
> host_buffer instead of writing straight from the former. If anything,
> that's an unnecessary copy.

The purpose of using a larger buffer here is to reduce the number of
SCM calls rather than to avoid memcpy.

Each QCOM_SCM_STORAGE_READ/WRITE involves an SMC transition with a
relatively high fixed overhead. Issuing calls at a 4 KiB granularity
would result in many SCM calls and poor throughput. The larger buffer
allows batching multiple contiguous blocks into a single SCM
transaction, significantly reducing the number of SMCs. In comparison,
the extra memcpy cost is negligible.

I agree that the current code always bouncing through the buffer is not
ideal. In v2, I will pass aligned accesses directly to
qcom_scm_storage_send_cmd() to avoid the extra copy, and only use the
bounce buffer for unaligned or partial accesses. I will also add a
comment explaining the rationale for the buffer size.

> Konrad
>

Thanks again for the review.

Best regards,
Junhao Xie