scsi: ufs: core: Skip link param validation when lanes_per_direction is unset

[PATCH] scsi: ufs: core: Skip link param validation when lanes_per_direction is unset

Posted by Daejun Park 3 weeks, 4 days ago

ufshcd_validate_link_params(), added by commit e72323f3b09f ("scsi: ufs:
core: Configure only active lanes during link"), is called
unconditionally from ufshcd_link_startup() and fails link startup with
-ENOLINK when the connected lane count read from the device differs from
hba->lanes_per_direction.

lanes_per_direction is only set by ufshcd-pltfrm (default 2, or the
"lanes-per-direction" devicetree property); ufshcd-pci controllers
(e.g. Intel) leave it 0. As the device always reports >= 1 connected
lanes, the check can never match and link startup always fails.
Reproduced with QEMU's UFS device.

Skip the check when lanes_per_direction is unset: with no expected value
to validate against, restore the behaviour from before that commit.

Fixes: e72323f3b09f ("scsi: ufs: core: Configure only active lanes during link")
Signed-off-by: Daejun Park <daejun7.park@samsung.com>
---
 drivers/ufs/core/ufshcd.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 1aad1c03c3fc..0a510f43ce76 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -5222,6 +5222,16 @@ static int ufshcd_validate_link_params(struct ufs_hba *hba)
 {
 	int ret, val;
 
+	/*
+	 * lanes_per_direction is only populated by the platform glue (it
+	 * defaults to 2 or is read from the "lanes-per-direction" devicetree
+	 * property). Controllers probed via ufshcd-pci leave it unset (0), in
+	 * which case there is no expected lane count to validate the connected
+	 * lanes against. Skip the check instead of failing link startup.
+	 */
+	if (!hba->lanes_per_direction)
+		return 0;
+
 	ret = ufshcd_dme_get(hba, UIC_ARG_MIB(PA_CONNECTEDTXDATALANES),
 			     &val);
 	if (ret)

base-commit: 016d484531e3169cd7bcb26e0ac2c5523080809f
-- 
2.43.0

Re: [PATCH] scsi: ufs: core: Skip link param validation when lanes_per_direction is unset

Posted by Martin K. Petersen 5 days, 16 hours ago

On Wed, 20 May 2026 16:00:09 +0900, Daejun Park wrote:

> ufshcd_validate_link_params(), added by commit e72323f3b09f ("scsi: ufs:
> core: Configure only active lanes during link"), is called
> unconditionally from ufshcd_link_startup() and fails link startup with
> -ENOLINK when the connected lane count read from the device differs from
> hba->lanes_per_direction.
> 
> lanes_per_direction is only set by ufshcd-pltfrm (default 2, or the
> "lanes-per-direction" devicetree property); ufshcd-pci controllers
> (e.g. Intel) leave it 0. As the device always reports >= 1 connected
> lanes, the check can never match and link startup always fails.
> Reproduced with QEMU's UFS device.
> 
> [...]

Applied to 7.2/scsi-queue, thanks!

[1/1] scsi: ufs: core: Skip link param validation when lanes_per_direction is unset
      https://git.kernel.org/mkp/scsi/c/06a34d9c1f47

-- 
Martin K. Petersen

Re: [PATCH] scsi: ufs: core: Skip link param validation when lanes_per_direction is unset

Posted by Martin K. Petersen 1 week, 5 days ago

Daejun,

> ufshcd_validate_link_params(), added by commit e72323f3b09f ("scsi:
> ufs: core: Configure only active lanes during link"), is called
> unconditionally from ufshcd_link_startup() and fails link startup with
> -ENOLINK when the connected lane count read from the device differs
> from hba->lanes_per_direction.

Applied to 7.2/scsi-staging, thanks!

-- 
Martin K. Petersen

Re: [PATCH] scsi: ufs: core: Skip link param validation when lanes_per_direction is unset

Posted by mani@kernel.org 2 weeks, 4 days ago

On Wed, May 20, 2026 at 04:00:09PM +0900, Daejun Park wrote:
> ufshcd_validate_link_params(), added by commit e72323f3b09f ("scsi: ufs:
> core: Configure only active lanes during link"), is called
> unconditionally from ufshcd_link_startup() and fails link startup with
> -ENOLINK when the connected lane count read from the device differs from
> hba->lanes_per_direction.
> 
> lanes_per_direction is only set by ufshcd-pltfrm (default 2, or the
> "lanes-per-direction" devicetree property); ufshcd-pci controllers
> (e.g. Intel) leave it 0. As the device always reports >= 1 connected
> lanes, the check can never match and link startup always fails.
> Reproduced with QEMU's UFS device.
> 
> Skip the check when lanes_per_direction is unset: with no expected value
> to validate against, restore the behaviour from before that commit.
> 
> Fixes: e72323f3b09f ("scsi: ufs: core: Configure only active lanes during link")
> Signed-off-by: Daejun Park <daejun7.park@samsung.com>

Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>

- Mani

> ---
>  drivers/ufs/core/ufshcd.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index 1aad1c03c3fc..0a510f43ce76 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -5222,6 +5222,16 @@ static int ufshcd_validate_link_params(struct ufs_hba *hba)
>  {
>  	int ret, val;
>  
> +	/*
> +	 * lanes_per_direction is only populated by the platform glue (it
> +	 * defaults to 2 or is read from the "lanes-per-direction" devicetree
> +	 * property). Controllers probed via ufshcd-pci leave it unset (0), in
> +	 * which case there is no expected lane count to validate the connected
> +	 * lanes against. Skip the check instead of failing link startup.
> +	 */
> +	if (!hba->lanes_per_direction)
> +		return 0;
> +
>  	ret = ufshcd_dme_get(hba, UIC_ARG_MIB(PA_CONNECTEDTXDATALANES),
>  			     &val);
>  	if (ret)
> 
> base-commit: 016d484531e3169cd7bcb26e0ac2c5523080809f
> -- 
> 2.43.0
> 

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH] scsi: ufs: core: Skip link param validation when lanes_per_direction is unset

Posted by Bart Van Assche 2 weeks, 4 days ago

On 5/20/26 12:00 AM, Daejun Park wrote:
> Skip the check when lanes_per_direction is unset: with no expected value
> to validate against, restore the behaviour from before that commit.

Reviewed-by: Bart Van Assche <bvanassche@acm.org>