Re: [PATCH] arm64: defconfig: Change CONFIG_SM_TCSRCC_8750 from m to y

[Krzysztof Kozlowski <krzk@kernel.org>]

On 17/10/2025 08:57, Taniya Das wrote:
> 
> 
> On 10/17/2025 12:24 PM, Krzysztof Kozlowski wrote:
>> On 17/10/2025 07:56, Krzysztof Kozlowski wrote:
>>> On 17/10/2025 07:49, Taniya Das wrote:
>>>>
>>>>
>>>> On 10/17/2025 10:51 AM, Krzysztof Kozlowski wrote:
>>>>> On 17/10/2025 07:16, Taniya Das wrote:
>>>>>>
>>>>>>
>>>>>> On 10/17/2025 10:00 AM, Krzysztof Kozlowski wrote:
>>>>>>> On 16/10/2025 20:53, Taniya Das wrote:
>>>>>>>> The TCSR clock controller is required  during boot to provide the ref
>>>>>>>> clocks to the UFS controller. Setting CONFIG_SM_TCSRCC_8750 to y ensures
>>>>>>>> the UFS driver successfully probe and initialize the device.
>>>>>>>>
>>>>>>>> Without this change, the UFS subsystem fails to mount as a usable file
>>>>>>>> system during boot.
>>>>>>>
>>>>>>>
>>>>>>> That's not what I observed. UFS works fine, especially that it is a
>>>>>>> module, so no, this is not a desired change and explanation is not only
>>>>>>> insufficient but actually incorrect.
>>>>>>>
>>>>>>
>>>>>> Krzysztof, on Pakala MTP we are observing the below issue and it
>>>>>> requires the module of tscrcc to be loaded explicitly. This patch also
>>>>>> aligns to how it is on all other targets.
>>>>>>
>>>>>> /soc@0/phy@1d80000: Failed to get clk index: 2 ret: -517
>>>>>> [   10.496570] ufshcd-qcom 1d84000.ufs: freq-table-hz property not specified
>>>>>> [   10.503660] ufshcd-qcom 1d84000.ufs: ufshcd_populate_vreg: Unable to
>>>>>> find vdd-hba-supply regulator, assuming enabled
>>>>>> [   10.514548] ufshcd-qcom 1d84000.ufs: ufshcd_populate_vreg: Unable to
>>>>>> find vccq2-supply regulator, assuming enabled
>>>>>> [   10.565955] platform 1d80000.phy: deferred probe pending: (reason
>>>>>> unknown)
>>>>>> [   10.573078] platform 1d84000.ufs: deferred probe pending:
>>>>>> ufshcd-qcom: ufshcd_pltfrm_init() failed
>>>>>>
>>>>>
>>>>>
>>>>> I don't and I am testing regularly, so I assume you have incorrect
>>>>> config. Maybe I have incorrect one (which works), but then commit msg is
>>>>> incomplete - you must explain the bug and provide proof that this is the
>>>>> correct fix for it.
>>>>>
>>>>
>>>> We have tried booting up recently and and that is what we observed. The
>>>> patch from 'm' to 'y' helps the UFS probe is successful and the rootfs
>>>> is picked from ufs partitions. I will add these fail & success log
>>>> snippets in the commit text.
>>>
>>> That's not enough. You need to explain why UFS fails. After explaining
>>> this, I guess bug in UFS would be exposed thus that one should be fixed.
>>> You just provided band-aid without fixing the real problem.
>>>
>>> NAK
>>
>>
>> ... and to prove your analysis is wrong (because your setup is likely
>> having issues) I even tested now linux next with defconfig. Works all
>> fine on next-20251013. You did not share which kernel even has this
>> issue, maybe some downstream tree?
>>
> 
> I have added how the commandline looks like for the test. Are you using
> using the ramdisk as your rootfs?

Of course not. I am using full UFS rootfs. What test would be with
ramdisk with rootfs?

Best regards,
Krzysztof