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

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

[Taniya Das]

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.

Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
---
 arch/arm64/configs/defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index e3a2d37bd10423b028f59dc40d6e8ee1c610d6b8..85e3afc07598a99cfdf804ce1f320ed76717fcc3 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1449,7 +1449,7 @@ CONFIG_SM_GPUCC_8550=m
 CONFIG_SM_GPUCC_8650=m
 CONFIG_SM_TCSRCC_8550=y
 CONFIG_SM_TCSRCC_8650=y
-CONFIG_SM_TCSRCC_8750=m
+CONFIG_SM_TCSRCC_8750=y
 CONFIG_SA_VIDEOCC_8775P=m
 CONFIG_SM_VIDEOCC_8250=y
 CONFIG_SM_VIDEOCC_8550=m

---
base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
change-id: 20251016-update_defconfig_tcsrcc_sm8750-5ce7d157b7aa

Best regards,
-- 
Taniya Das <taniya.das@oss.qualcomm.com>

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

[Krzysztof Kozlowski]

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.

Best regards,
Krzysztof

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

[Taniya Das]

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

-- 
Thanks,
Taniya Das

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

[Krzysztof Kozlowski]

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.


Best regards,
Krzysztof

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

[Taniya Das]

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.

[    0.000000] Machine model: Qualcomm Technologies, Inc. SM8750 MTP
....
[    3.133373] ufshcd-qcom 1d84000.ufs: freq-table-hz property not specified
[    3.144480] ufshcd-qcom 1d84000.ufs: ufshcd_populate_vreg: Unable to
find vdd-hba-supply regulator, assuming enabled
[    3.144585] ufshcd-qcom 1d84000.ufs: ufshcd_populate_vreg: Unable to
find vccq2-supply regulator, assuming enabled
[    3.227770] ufshcd-qcom 1d84000.ufs: Resource ufs_mem not provided
[    3.238319] ufshcd-qcom 1d84000.ufs: MCQ mode is disabled, err=-19
[    3.244707] scsi host0: ufshcd
[    3.255170] scsi 0:0:0:49488: Well-known LUN    KIOXIA
THGJFLT2E46BATPB 0100 PQ: 0 ANSI: 6
[    3.272001] scsi 0:0:0:49476: Well-known LUN    KIOXIA
THGJFLT2E46BATPB 0100 PQ: 0 ANSI: 6
[    3.287011] scsi 0:0:0:49456: Well-known LUN    KIOXIA
THGJFLT2E46BATPB 0100 PQ: 0 ANSI: 6
[    3.304264] scsi 0:0:0:0: Direct-Access     KIOXIA   THGJFLT2E46BATPB
0100 PQ: 0 ANSI: 6
[    3.331545] sd 0:0:0:0: [sda] 121774080 4096-byte logical blocks:
(499 GB/465 GiB)


Thanks,
Taniya.

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

[Krzysztof Kozlowski]

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

> 
> [    0.000000] Machine model: Qualcomm Technologies, Inc. SM8750 MTP
> ....
> [    3.133373] ufshcd-qcom 1d84000.ufs: freq-table-hz property not specified
> [    3.144480] ufshcd-qcom 1d84000.ufs: ufshcd_populate_vreg: Unable to
> find vdd-hba-supply regulator, assuming enabled
> [    3.144585] ufshcd-qcom 1d84000.ufs: ufshcd_populate_vreg: Unable to
> find vccq2-supply regulator, assuming enabled
> [    3.227770] ufshcd-qcom 1d84000.ufs: Resource ufs_mem not provided
> [    3.238319] ufshcd-qcom 1d84000.ufs: MCQ mode is disabled, err=-19



Best regards,
Krzysztof

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

[Krzysztof Kozlowski]

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?


Best regards,
Krzysztof

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

[Taniya Das]

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?

> 
> Best regards,
> Krzysztof

-- 
Thanks,
Taniya Das

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

[Krzysztof Kozlowski]

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

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

[Konrad Dybcio]

On 10/17/25 8:54 AM, 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:

[...]

>>> 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?

Is there a chance you have the TCSR module packed in initramfs and
Taniya doesn't?

Konrad

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

[Krzysztof Kozlowski]

On 17/10/2025 10:15, Konrad Dybcio wrote:
> On 10/17/25 8:54 AM, 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:
> 
> [...]
> 
>>>> 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?
> 
> Is there a chance you have the TCSR module packed in initramfs and
> Taniya doesn't?

Of course that's a chance, since I have all modules packed. Why would
someone pack UFS to initramfs but not its dependencies? It would never
work, actually, nothing would work...

If initramfs does not have necessary modules, way to fix it is to add
these modules, not make the symbol enabled.

Best regards,
Krzysztof

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

[Taniya Das]

On 10/17/2025 11:26 AM, 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.
> 

When the kernel commandline uses is 'root=PARTLABEL=system', the  is a
dependency of the UFS driver on the TCSRCC clockref during bootup and
the TCSRCC made as a module will not provide the clocks unless we
explicitly load the modules. To meet this dependency we need to load
TCSRCC statically and move CONFIG_SM_TCSRCC_8750 from 'm' to 'y.
This will help the UFS partitions to be identified and then the rootfs
to be mounted from the partitions.

> NAK
> 
>>
>> [    0.000000] Machine model: Qualcomm Technologies, Inc. SM8750 MTP
>> ....
>> [    3.133373] ufshcd-qcom 1d84000.ufs: freq-table-hz property not specified
>> [    3.144480] ufshcd-qcom 1d84000.ufs: ufshcd_populate_vreg: Unable to
>> find vdd-hba-supply regulator, assuming enabled
>> [    3.144585] ufshcd-qcom 1d84000.ufs: ufshcd_populate_vreg: Unable to
>> find vccq2-supply regulator, assuming enabled
>> [    3.227770] ufshcd-qcom 1d84000.ufs: Resource ufs_mem not provided
>> [    3.238319] ufshcd-qcom 1d84000.ufs: MCQ mode is disabled, err=-19
> 
> 
> 
> Best regards,
> Krzysztof

-- 
Thanks,
Taniya Das

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

[Krzysztof Kozlowski]

On 17/10/2025 08:55, Taniya Das wrote:
> 
> 
> On 10/17/2025 11:26 AM, 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.
>>
> 
> When the kernel commandline uses is 'root=PARTLABEL=system', the  is a
> dependency of the UFS driver on the TCSRCC clockref during bootup and
> the TCSRCC made as a module will not provide the clocks unless we

No, that's not true. cmdline does not matter here at all.

> explicitly load the modules. To meet this dependency we need to load

root= has nothing to do with modules.

> TCSRCC statically and move CONFIG_SM_TCSRCC_8750 from 'm' to 'y.

No.

> This will help the UFS partitions to be identified and then the rootfs
> to be mounted from the partitions.

No, it's completely different problem. Now you are mixing UFS partitions
with root= argument.



Best regards,
Krzysztof

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

[Bjorn Andersson]

On Fri, Oct 17, 2025 at 12:25:37PM +0530, Taniya Das wrote:
> 
> 
> On 10/17/2025 11:26 AM, 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.
> > 
> 
> When the kernel commandline uses is 'root=PARTLABEL=system', the  is a
> dependency of the UFS driver on the TCSRCC clockref during bootup and
> the TCSRCC made as a module will not provide the clocks unless we
> explicitly load the modules.

defconfig has CONFIG_SCSI_UFS_QCOM=m so your test system is obviously
loading some modules.

This implies that you're:
1) not packing the tcsrcc into your ramdisk, or
2) doing something non-standard in your ramdisk which breaks automatic module
   loading, or 
3) there's an actual issue somewhere causing the probe deferral not to
   happen

So, please look at your commit message and ask yourself *why* UFS
doesn't find the clock, *why* does =y help, etc?


We should only use =y for things required to reach and execute the
content of the ramdisk. As such, I agree with Krzysztof, this patch is
not correct.

Regards,
Bjorn

> To meet this dependency we need to load
> TCSRCC statically and move CONFIG_SM_TCSRCC_8750 from 'm' to 'y.
> This will help the UFS partitions to be identified and then the rootfs
> to be mounted from the partitions.
> 
> > NAK
> > 
> >>
> >> [    0.000000] Machine model: Qualcomm Technologies, Inc. SM8750 MTP
> >> ....
> >> [    3.133373] ufshcd-qcom 1d84000.ufs: freq-table-hz property not specified
> >> [    3.144480] ufshcd-qcom 1d84000.ufs: ufshcd_populate_vreg: Unable to
> >> find vdd-hba-supply regulator, assuming enabled
> >> [    3.144585] ufshcd-qcom 1d84000.ufs: ufshcd_populate_vreg: Unable to
> >> find vccq2-supply regulator, assuming enabled
> >> [    3.227770] ufshcd-qcom 1d84000.ufs: Resource ufs_mem not provided
> >> [    3.238319] ufshcd-qcom 1d84000.ufs: MCQ mode is disabled, err=-19
> > 
> > 
> > 
> > Best regards,
> > Krzysztof
> 
> -- 
> Thanks,
> Taniya Das
> 

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

[Bjorn Andersson]

On Fri, Oct 17, 2025 at 11:19:51AM +0530, 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.

Please don't, there's nothing useful in either log, so dumping them in
the git history will serve no purpose.

Regards,
Bjorn

> 
> [    0.000000] Machine model: Qualcomm Technologies, Inc. SM8750 MTP
> ....
> [    3.133373] ufshcd-qcom 1d84000.ufs: freq-table-hz property not specified
> [    3.144480] ufshcd-qcom 1d84000.ufs: ufshcd_populate_vreg: Unable to
> find vdd-hba-supply regulator, assuming enabled
> [    3.144585] ufshcd-qcom 1d84000.ufs: ufshcd_populate_vreg: Unable to
> find vccq2-supply regulator, assuming enabled
> [    3.227770] ufshcd-qcom 1d84000.ufs: Resource ufs_mem not provided
> [    3.238319] ufshcd-qcom 1d84000.ufs: MCQ mode is disabled, err=-19
> [    3.244707] scsi host0: ufshcd
> [    3.255170] scsi 0:0:0:49488: Well-known LUN    KIOXIA
> THGJFLT2E46BATPB 0100 PQ: 0 ANSI: 6
> [    3.272001] scsi 0:0:0:49476: Well-known LUN    KIOXIA
> THGJFLT2E46BATPB 0100 PQ: 0 ANSI: 6
> [    3.287011] scsi 0:0:0:49456: Well-known LUN    KIOXIA
> THGJFLT2E46BATPB 0100 PQ: 0 ANSI: 6
> [    3.304264] scsi 0:0:0:0: Direct-Access     KIOXIA   THGJFLT2E46BATPB
> 0100 PQ: 0 ANSI: 6
> [    3.331545] sd 0:0:0:0: [sda] 121774080 4096-byte logical blocks:
> (499 GB/465 GiB)
> 
> 
> Thanks,
> Taniya.
> 

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

[Taniya Das]

On 10/18/2025 3:11 AM, Bjorn Andersson wrote:
> On Fri, Oct 17, 2025 at 11:19:51AM +0530, 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.
> 
> Please don't, there's nothing useful in either log, so dumping them in
> the git history will serve no purpose.
> 

Sure, Bjorn, will let the team get the correct fix.

> Regards,
> Bjorn
> 
>>
>> [    0.000000] Machine model: Qualcomm Technologies, Inc. SM8750 MTP
>> ....
>> [    3.133373] ufshcd-qcom 1d84000.ufs: freq-table-hz property not specified
>> [    3.144480] ufshcd-qcom 1d84000.ufs: ufshcd_populate_vreg: Unable to
>> find vdd-hba-supply regulator, assuming enabled
>> [    3.144585] ufshcd-qcom 1d84000.ufs: ufshcd_populate_vreg: Unable to
>> find vccq2-supply regulator, assuming enabled
>> [    3.227770] ufshcd-qcom 1d84000.ufs: Resource ufs_mem not provided
>> [    3.238319] ufshcd-qcom 1d84000.ufs: MCQ mode is disabled, err=-19
>> [    3.244707] scsi host0: ufshcd
>> [    3.255170] scsi 0:0:0:49488: Well-known LUN    KIOXIA
>> THGJFLT2E46BATPB 0100 PQ: 0 ANSI: 6
>> [    3.272001] scsi 0:0:0:49476: Well-known LUN    KIOXIA
>> THGJFLT2E46BATPB 0100 PQ: 0 ANSI: 6
>> [    3.287011] scsi 0:0:0:49456: Well-known LUN    KIOXIA
>> THGJFLT2E46BATPB 0100 PQ: 0 ANSI: 6
>> [    3.304264] scsi 0:0:0:0: Direct-Access     KIOXIA   THGJFLT2E46BATPB
>> 0100 PQ: 0 ANSI: 6
>> [    3.331545] sd 0:0:0:0: [sda] 121774080 4096-byte logical blocks:
>> (499 GB/465 GiB)
>>
>>
>> Thanks,
>> Taniya.
>>

-- 
Thanks,
Taniya Das

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

[Dmitry Baryshkov]

On Fri, Oct 17, 2025 at 10:46:43AM +0530, 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

This will also require you to set CONFIG_SCSI_UFS_QCOM=y (=m in
defconfig), CONFIG_PHY_QCOM_QMP_UFS=y (also =m in defconfig), etc. So, I
doubt that you are using defconfig as is. Please extend your
configuration in order to pick this module.

Note, defconfig is supposed to be used by multiple platforms and
multiple defice. As sych we can't enable all bootable devices. It is
expected that the users either change their configuration or use
initramfs. Only "working console" is expected to be working with the
defconfig and that's only because systemd doesn't reopen /dev/console
after probing modules. If it were, we could have moved all pinctrl,
interconnect and other similar drivers to =m in order to make the
footprint smaller for other platforms.

-- 
With best wishes
Dmitry

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

[Taniya Das]

On 10/19/2025 5:27 PM, Dmitry Baryshkov wrote:
> On Fri, Oct 17, 2025 at 10:46:43AM +0530, 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
> 
> This will also require you to set CONFIG_SCSI_UFS_QCOM=y (=m in
> defconfig), CONFIG_PHY_QCOM_QMP_UFS=y (also =m in defconfig), etc. So, I
> doubt that you are using defconfig as is. Please extend your
> configuration in order to pick this module.
> 
> Note, defconfig is supposed to be used by multiple platforms and
> multiple defice. As sych we can't enable all bootable devices. It is
> expected that the users either change their configuration or use
> initramfs. Only "working console" is expected to be working with the
> defconfig and that's only because systemd doesn't reopen /dev/console
> after probing modules. If it were, we could have moved all pinctrl,
> interconnect and other similar drivers to =m in order to make the
> footprint smaller for other platforms.
> 

I agree not all configs should be made y, but expected the required
configurations should be made available. I will share this feedback to
the team and also ensure this expectation is taken care.

-- 
Thanks,
Taniya Das