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]

Date:   Tue, 22 Nov 2022 21:52:58 +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 Thu, Nov 03, 2022 at 11:23:17AM -0400, Krzysztof Kozlowski wrote:
> On 03/11/2022 08:28, Manivannan Sadhasivam wrote:
> > 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)
> 
> Yes and look at MMC - no need to define "max mode" supported by eMMC.
> You define the modes supported by controller but the memory capabilities
> are being autodetected and negotiated.
> 
> > 
> > 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.
> 
> It should be then referenced somewhere as it might be a reason to accept
> the property.
> 
> > 
> >> 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.
> 
> Not really if it is auto-detectable. Just because things are static is
> not the sole reason to put them into DT. The reason is - they are not
> detectable by OS/firmware thus we must have them in DT to be able to
> know it.
> 

Since I'm not able to get a link to the previous discussion, I'm gonna
implement the reinit support and post the next iteration. Let's see how it
turns up.

Thanks,
Mani

> 
> 
> Best regards,
> Krzysztof
> 

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