[PATCH RFC/RFT 1/5] ufs: ufs-qcom: Fix UFS base region name in MCQ case

Konrad Dybcio posted 5 patches 3 months ago
[PATCH RFC/RFT 1/5] ufs: ufs-qcom: Fix UFS base region name in MCQ case
Posted by Konrad Dybcio 3 months ago
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

There is no need to reinvent the wheel. There are no users yet, and the
dt-bindings were never updated to accommodate for this, so fix it while
we still easily can.

Fixes: c263b4ef737e ("scsi: ufs: core: mcq: Configure resource regions")
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
 drivers/ufs/host/ufs-qcom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index 318dca7fe3d735431e252e8a2a699ec1b7a36618..8dd9709cbdeef6ede5faa434fcb853e11950721f 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -1899,7 +1899,7 @@ static void ufs_qcom_config_scaling_param(struct ufs_hba *hba,
 
 /* Resources */
 static const struct ufshcd_res_info ufs_res_info[RES_MAX] = {
-	{.name = "ufs_mem",},
+	{.name = "std",},
 	{.name = "mcq",},
 	/* Submission Queue DAO */
 	{.name = "mcq_sqd",},

-- 
2.50.0
Re: [PATCH RFC/RFT 1/5] ufs: ufs-qcom: Fix UFS base region name in MCQ case
Posted by Manivannan Sadhasivam 3 months ago
On Fri, Jul 04, 2025 at 07:36:09PM GMT, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> 
> There is no need to reinvent the wheel. There are no users yet, and the
> dt-bindings were never updated to accommodate for this, so fix it while
> we still easily can.
> 

What are you fixing here? Please be explicit. "std" region is not at all in the
device memory map? Or it was present in some earlier ones and removed in the
final tape out version?

- Mani

> Fixes: c263b4ef737e ("scsi: ufs: core: mcq: Configure resource regions")
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
>  drivers/ufs/host/ufs-qcom.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
> index 318dca7fe3d735431e252e8a2a699ec1b7a36618..8dd9709cbdeef6ede5faa434fcb853e11950721f 100644
> --- a/drivers/ufs/host/ufs-qcom.c
> +++ b/drivers/ufs/host/ufs-qcom.c
> @@ -1899,7 +1899,7 @@ static void ufs_qcom_config_scaling_param(struct ufs_hba *hba,
>  
>  /* Resources */
>  static const struct ufshcd_res_info ufs_res_info[RES_MAX] = {
> -	{.name = "ufs_mem",},
> +	{.name = "std",},
>  	{.name = "mcq",},
>  	/* Submission Queue DAO */
>  	{.name = "mcq_sqd",},
> 
> -- 
> 2.50.0
> 

-- 
மணிவண்ணன் சதாசிவம்
Re: [PATCH RFC/RFT 1/5] ufs: ufs-qcom: Fix UFS base region name in MCQ case
Posted by Konrad Dybcio 3 months ago
On 7/8/25 12:34 PM, Manivannan Sadhasivam wrote:
> On Fri, Jul 04, 2025 at 07:36:09PM GMT, Konrad Dybcio wrote:
>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> There is no need to reinvent the wheel. There are no users yet, and the
>> dt-bindings were never updated to accommodate for this, so fix it while
>> we still easily can.
>>
> 
> What are you fixing here? Please be explicit. "std" region is not at all in the
> device memory map? Or it was present in some earlier ones and removed in the
> final tape out version?
> 
> - Mani

I simply failed to describe the issue.

As of today, the MCQ code refers to the region that our bindings call
"std" by the name "ufs_mem" (which this patch fixes).
Totally same thing in hardware, but it would obviously not work without
DT changes (which would be rightfully rejected as there is no reason to
change the name).

Konrad
Re: [PATCH RFC/RFT 1/5] ufs: ufs-qcom: Fix UFS base region name in MCQ case
Posted by Bart Van Assche 3 months ago
On 7/4/25 10:36 AM, Konrad Dybcio wrote:
> There is no need to reinvent the wheel. There are no users yet, and the
> dt-bindings were never updated to accommodate for this, so fix it while
> we still easily can.

The patch description should explain why this patch is considered a fix
and also why the kernel driver is modified instead of the device tree.

Thanks,

Bart.