[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8580ae8e-50e9-481c-b9f3-125b6d1cb494@kernel.org>
Date: Fri, 17 Oct 2025 08:54:44 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Taniya Das <quic_tdas@...cinc.com>,
Taniya Das <taniya.das@....qualcomm.com>,
Bjorn Andersson <andersson@...nel.org>, linux-arm-msm@...r.kernel.org
Cc: linux-arm-kernel@...ts.infradead.org,
Ajit Pandey <ajit.pandey@....qualcomm.com>,
Imran Shaik <imran.shaik@....qualcomm.com>,
Jagadeesh Kona <jagadeesh.kona@....qualcomm.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: defconfig: Change CONFIG_SM_TCSRCC_8750 from m to
y
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@...hy@...0000: 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?
Best regards,
Krzysztof
Powered by blists - more mailing lists