linux-kernel - Re: [PATCH v2 06/15] dt-bindings: ufs: Add "max-device-gear" property for UFS device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20221103122850.GD8434@thinkpad>
Date:   Thu, 3 Nov 2022 17:58:50 +0530
From:   Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     martin.petersen@...cle.com, jejb@...ux.ibm.com,
        andersson@...nel.org, vkoul@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, konrad.dybcio@...ainline.org,
        robh+dt@...nel.org, quic_cang@...cinc.com,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-phy@...ts.infradead.org,
        linux-scsi@...r.kernel.org, dmitry.baryshkov@...aro.org,
        ahalaney@...hat.com
Subject: Re: [PATCH v2 06/15] dt-bindings: ufs: Add "max-device-gear"
 property for UFS device

On Wed, Nov 02, 2022 at 03:09:50PM -0400, Krzysztof Kozlowski wrote:
> On 31/10/2022 14:02, Manivannan Sadhasivam wrote:
> > The maximum gear supported by the UFS device can be specified using the
> > "max-device-gear" property. This allows the UFS controller to configure the
> > TX/RX gear before starting communication with the UFS device.
> 
> This is confusing. The UFS PHY provides gear capability, so what is the
> "device" here? The attached memory? How could it report something else
> than phy?
> 

This is the norm with any storage protocol, right? Both host and device
(memory) can support different speeds and the OEM can choose to put any
combinations (even though it might not be very efficient).

For instance,

PHY (G4) -> Device (G3)

>From the host perspective we know what the PHY can support but that's not the
same with the device until probing it. And probing requires using a minimum
supported gear. For sure we can use something like G2/G3 and reinit later but
as I learnt, that approach was rejected by the community when submitted
by Qualcomm earlier.

> The last sentence also suggests that you statically encode gear to avoid
> runtime negotiation.
> 

Yes, the OEM should know what the max gear speed they want to run, so getting
this info from DT makes sense.

Thanks,
Mani

> Best regards,
> Krzysztof
> 

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