arch/arm64/configs/defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
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>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
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
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
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
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
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.
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. >
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
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
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
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 >
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
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
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
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
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
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
© 2016 - 2026 Red Hat, Inc.