[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0f08376b-569a-48d6-a551-e10b72b32354@acm.org>
Date: Mon, 15 Sep 2025 15:06:11 -0700
From: Bart Van Assche <bvanassche@....org>
To: Bean Huo <beanhuo@...pp.de>, avri.altman@....com,
alim.akhtar@...sung.com, jejb@...ux.ibm.com, martin.petersen@...cle.com,
can.guo@....qualcomm.com, ulf.hansson@...aro.org, jens.wiklander@...aro.org
Cc: linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
mikebi@...ron.com, lporzio@...ron.com, Bean Huo <beanhuo@...ron.com>
Subject: Re: [RFC PATCH v1 2/2] scsi: ufs: core: Add OP-TEE based RPMB driver
for UFS devices
On 9/15/25 2:46 PM, Bean Huo wrote:
> + * UFS OPTEE based RPMB Driver
Is the correct spelling OPTEE or OP-TEE?
> +#define UFS_RPMB_SEC_PROTOCOL 0xEC /* JEDEC UFS application */
> +#define UFS_RPMB_REGION_0 0x01 /* SECURITY PROTOCOL SPECIFIC: RPMB Protocl ID, Region 0 */
Do these constants come from a standard? If so, please mention this.
> + u8 cdb[12] = { 0, };
Using "{ 0 }" or "{ 0, }" as an initializer is outdated. Please use "{}"
instead.
> + if (need_result_read) {
> + struct rpmb_frame *frm_resp = (struct rpmb_frame *)resp;
> + memset(frm_resp, 0, sizeof(*frm_resp));
> + frm_resp->req_resp = cpu_to_be16(RPMB_RESULT_READ);
> + ret = ufs_sec_submit(hba, UFS_RPMB_REGION_0, resp, resp_len, true);
> + }
Please leave a blank line between declarations and statements.
> + u32 cid[4] = { 0 };
Same comment here about zero-initialization.
> + /*
> + * Use serial number as device ID. Copy ASCII serial number data.
> + * This provides a unique device identifier for RPMB operations.
> + */
> + strncpy((char *)cid, sn, sizeof(cid) - 1);
strncpy() into an u32 array? Really? There are multiple alternatives
available in the kernel that are better than strncpy(). Are you sure
that you want to use strncpy()? Additionally, does copying a string into
a u32 array introduce any endianness issues?
> +MODULE_DESCRIPTION("UFS RPMB integration into the RPBM framework using SCSI Secure In/Out");
RPBM or RPMB?
> } else {
> - str = kmemdup(uc_str, uc_str->len, GFP_KERNEL);
> + str = kmemdup(uc_str->uc, uc_str->len, GFP_KERNEL);
Is the above change perhaps a bug fix that is completely independent of
the rest of this patch?
Thanks,
Bart.
Powered by blists - more mailing lists