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. Best regards, Krzysztof
