[PATCH] arm64: dts: renesas: r8a779f0: Set UFS lane count

[PATCH] arm64: dts: renesas: r8a779f0: Set UFS lane count

[Koichiro Den]

Since commit e72323f3b09f ("scsi: ufs: core: Configure only active lanes
during link"), the following error is observed on R-Car S4:

ufshcd-renesas e6860000.ufs: Tx lane mismatch [config,reported] [2,1]
ufshcd-renesas e6860000.ufs: link startup failed -67
ufshcd-renesas e6860000.ufs: error -ENOLINK: Initialization failed with error -67
ufshcd-renesas e6860000.ufs: probe with driver ufshcd-renesas failed with error -67

R-Car S4 has one UFS lane per direction, as described in section 152.1
of its hardware manual. Without lanes-per-direction, the UFS platform
driver defaults to two lanes.

Previously, the core used PA_CONNECTEDRXDATALANES and
PA_CONNECTEDTXDATALANES to configure the link without checking them
against lanes-per-direction, so the missing property did not prevent
initialization.

Explicitly set lanes-per-direction to 1, now that the validation is in
place.

Fixes: 5235d551779d ("arm64: dts: renesas: r8a779f0: Add UFS node")
Cc: stable@vger.kernel.org # 7.2+
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
 arch/arm64/boot/dts/renesas/r8a779f0.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a779f0.dtsi b/arch/arm64/boot/dts/renesas/r8a779f0.dtsi
index 69c247b7f0e2..1aeafa1b96e2 100644
--- a/arch/arm64/boot/dts/renesas/r8a779f0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a779f0.dtsi
@@ -901,6 +901,7 @@ ufs: ufs@e6860000 {
 			clocks = <&cpg CPG_MOD 1514>, <&ufs30_clk>;
 			clock-names = "fck", "ref_clk";
 			freq-table-hz = <200000000 200000000>, <38400000 38400000>;
+			lanes-per-direction = <1>;
 			power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
 			resets = <&cpg 1514>;
 			status = "disabled";

base-commit: eb3aaa2249eb2f4224bc27874f5d685471653142
-- 
2.51.0

Re: [PATCH] arm64: dts: renesas: r8a779f0: Set UFS lane count

[Geert Uytterhoeven]

Hi Den-san,

CC ufs

Thanks for your patch!

On Fri, 11 Sept 2026 at 09:31, Koichiro Den <den@valinux.co.jp> wrote:
> Since commit e72323f3b09f ("scsi: ufs: core: Configure only active lanes
> during link"), the following error is observed on R-Car S4:
>
> ufshcd-renesas e6860000.ufs: Tx lane mismatch [config,reported] [2,1]
> ufshcd-renesas e6860000.ufs: link startup failed -67
> ufshcd-renesas e6860000.ufs: error -ENOLINK: Initialization failed with error -67
> ufshcd-renesas e6860000.ufs: probe with driver ufshcd-renesas failed with error -67

This is very unfortunate...

> R-Car S4 has one UFS lane per direction, as described in section 152.1
> of its hardware manual. Without lanes-per-direction, the UFS platform
> driver defaults to two lanes.
>
> Previously, the core used PA_CONNECTEDRXDATALANES and
> PA_CONNECTEDTXDATALANES to configure the link without checking them
> against lanes-per-direction, so the missing property did not prevent
> initialization.
>
> Explicitly set lanes-per-direction to 1, now that the validation is in
> place.

Given this breaks backwards compatibility with existing DTBs, I think
this new check should be relaxed iff the DT property "lanes-per-direction" is
not present. Are any other platforms affected?
Possible solutions I see are:
  1. Skip the check completely, like commit 06a34d9c1f47b923 ("scsi:
     ufs: core: Skip link param validation when lanes_per_direction is
     unset") does for ufshcd-pci?
  2. Correct hba->lanes_per_direction based on the actual values of
     PA_CONNECTED[RT]XDATALANES?

Alternatively, ufshcd_init_lanes_per_dir() could override
hba->lanes_per_direction to one if "lanes-per-direction" is missing
and the device is compatible with renesas,r8a779f0-ufs.  Or perhaps
hba->lanes_per_direction could be preset in ufs-renesas.c, and not
overwritten by UFSHCD_DEFAULT_LANES_PER_DIRECTION when non-zero?

> Fixes: 5235d551779d ("arm64: dts: renesas: r8a779f0: Add UFS node")
> Cc: stable@vger.kernel.org # 7.2+
> Signed-off-by: Koichiro Den <den@valinux.co.jp>

> --- a/arch/arm64/boot/dts/renesas/r8a779f0.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a779f0.dtsi
> @@ -901,6 +901,7 @@ ufs: ufs@e6860000 {
>                         clocks = <&cpg CPG_MOD 1514>, <&ufs30_clk>;
>                         clock-names = "fck", "ref_clk";
>                         freq-table-hz = <200000000 200000000>, <38400000 38400000>;
> +                       lanes-per-direction = <1>;
>                         power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
>                         resets = <&cpg 1514>;
>                         status = "disabled";
>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Works fine on S4SK, so
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Will queue in renesas-fixes for v7.3.

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] arm64: dts: renesas: r8a779f0: Set UFS lane count

[Koichiro Den]

On Fri, Sep 11, 2026 at 10:44:56AM +0200, Geert Uytterhoeven wrote:
> Hi Den-san,
> 
> CC ufs
> 
> Thanks for your patch!
> 
> On Fri, 11 Sept 2026 at 09:31, Koichiro Den <den@valinux.co.jp> wrote:
> > Since commit e72323f3b09f ("scsi: ufs: core: Configure only active lanes
> > during link"), the following error is observed on R-Car S4:
> >
> > ufshcd-renesas e6860000.ufs: Tx lane mismatch [config,reported] [2,1]
> > ufshcd-renesas e6860000.ufs: link startup failed -67
> > ufshcd-renesas e6860000.ufs: error -ENOLINK: Initialization failed with error -67
> > ufshcd-renesas e6860000.ufs: probe with driver ufshcd-renesas failed with error -67
> 
> This is very unfortunate...
> 
> > R-Car S4 has one UFS lane per direction, as described in section 152.1
> > of its hardware manual. Without lanes-per-direction, the UFS platform
> > driver defaults to two lanes.
> >
> > Previously, the core used PA_CONNECTEDRXDATALANES and
> > PA_CONNECTEDTXDATALANES to configure the link without checking them
> > against lanes-per-direction, so the missing property did not prevent
> > initialization.
> >
> > Explicitly set lanes-per-direction to 1, now that the validation is in
> > place.
> 
> Given this breaks backwards compatibility with existing DTBs, I think
> this new check should be relaxed iff the DT property "lanes-per-direction" is
> not present. Are any other platforms affected?

I don't know yet. I see some other platforms omit the property, for which I'm
not sure whether they report two connected lanes. I haven't seen any other
reports so far unless I'm missing something.

> Possible solutions I see are:
>   1. Skip the check completely, like commit 06a34d9c1f47b923 ("scsi:
>      ufs: core: Skip link param validation when lanes_per_direction is
>      unset") does for ufshcd-pci?
>   2. Correct hba->lanes_per_direction based on the actual values of
>      PA_CONNECTED[RT]XDATALANES?
> 
> Alternatively, ufshcd_init_lanes_per_dir() could override
> hba->lanes_per_direction to one if "lanes-per-direction" is missing
> and the device is compatible with renesas,r8a779f0-ufs.  Or perhaps
> hba->lanes_per_direction could be preset in ufs-renesas.c, and not
> overwritten by UFSHCD_DEFAULT_LANES_PER_DIRECTION when non-zero?

The binding has stated from the beginning that "If not specified, default is 2
lanes per direction". That is why I thought it made sense to explicitly specify
one lane in the DT. For compatibility with existing DTBs, handling the missing
property in ufs_renesas_init() sounds reasonable, in addition to this DT patch,
as you suggested.
I'm not very familiar with this area, though, so just my two cents. Sorry.

> 
> > Fixes: 5235d551779d ("arm64: dts: renesas: r8a779f0: Add UFS node")
> > Cc: stable@vger.kernel.org # 7.2+
> > Signed-off-by: Koichiro Den <den@valinux.co.jp>
> 
> > --- a/arch/arm64/boot/dts/renesas/r8a779f0.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a779f0.dtsi
> > @@ -901,6 +901,7 @@ ufs: ufs@e6860000 {
> >                         clocks = <&cpg CPG_MOD 1514>, <&ufs30_clk>;
> >                         clock-names = "fck", "ref_clk";
> >                         freq-table-hz = <200000000 200000000>, <38400000 38400000>;
> > +                       lanes-per-direction = <1>;
> >                         power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
> >                         resets = <&cpg 1514>;
> >                         status = "disabled";
> >
> 
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Works fine on S4SK, so
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Will queue in renesas-fixes for v7.3.

Thanks for the review and testing!

Best regards,
Koichiro

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds