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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx # 7.2+
> > Signed-off-by: Koichiro Den <den@xxxxxxxxxxxxx>
> 
> > --- 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@xxxxxxxxx>
> Works fine on S4SK, so
> Tested-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
> 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@xxxxxxxxxxxxxx
> 
> 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