Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a170e4e8-fc9d-9be1-35ba-733f24cb93e8@linaro.org>
Date:   Thu, 3 Nov 2022 11:23:17 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
Subject: Re: [PATCH v2 06/15] dt-bindings: ufs: Add "max-device-gear" property
 for UFS device
Content-Language: en-US
To:     Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc:     martin.petersen@oracle.com, jejb@linux.ibm.com,
        andersson@kernel.org, vkoul@kernel.org,
        krzysztof.kozlowski+dt@linaro.org, konrad.dybcio@somainline.org,
        robh+dt@kernel.org, quic_cang@quicinc.com,
        linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org,
        linux-scsi@vger.kernel.org, dmitry.baryshkov@linaro.org,
        ahalaney@redhat.com
References: <20221031180217.32512-1-manivannan.sadhasivam@linaro.org>
 <20221031180217.32512-7-manivannan.sadhasivam@linaro.org>
 <1fe8fd96-7770-0bda-c970-aa38d030ff3b@linaro.org>
 <20221103122850.GD8434@thinkpad>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <20221103122850.GD8434@thinkpad>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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