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: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20260520070009epcms2p6542f3abb7660839e9d8140b3f2f145c3@epcms2p6
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
{
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)