linux-kernel - Re: [PATCH] arm64: defconfig: Change CONFIG_SM_TCSRCC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ay4vqro266o7lk4xq3lpjjsviyllxoymfsl6gi3h6nhalsnkke@5gcpxdsgszhq>
Date: Fri, 17 Oct 2025 14:47:27 -0700
From: Bjorn Andersson <andersson@...nel.org>
To: Taniya Das <taniya.das@....qualcomm.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, 
	Taniya Das <quic_tdas@...cinc.com>, linux-arm-msm@...r.kernel.org, 
	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 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@...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.
> > 
> 
> 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
>