Re: [PATCH] arm64: defconfig: Enable Qualcomm UFS and QMP UFS PHY drivers as built-in

[Shawn Guo <shengchao.guo@oss.qualcomm.com>]

On Fri, Apr 17, 2026 at 10:44:20AM +0200, Krzysztof Kozlowski wrote:
> On 17/04/2026 10:37, Shawn Guo wrote:
> > On Fri, Apr 17, 2026 at 10:14:23AM +0200, Krzysztof Kozlowski wrote:
> >> On 17/04/2026 05:55, Shawn Guo wrote:
> >>> UFS is the primary storage for Linux rootfs across the breadth of
> >>> Qualcomm development boards - Mobile, Automotive and IoT.  With
> >>> Qualcomm UFS host controller driver (SCSI_UFS_QCOM) and the UFS PHY
> >>> driver (PHY_QCOM_QMP_UFS) as modules, developers need an initramfs
> >>
> >> Yes, you always need initramfs and every developer has it.
> >>
> >>> to boot from UFS, which adds friction to daily development workflows.
> >>
> >> No friction, it's both standard, easy and all of Qualcomm and Linaro
> >> developers have it solved long time ago.
> > 
> > I'm looking at a kernel regression by running git bisect, where kernel
> > version string varies for every single boot.  How do you usually deal
> > with it by using initramfs?
> 
> No difference from every other build and boot? I build kernel and the
> same step I have initramfs with modules. Whether I bisect or build
> kernel for normal boot is exactly the same.
> 
> The only difference is `git bisect good`.

So we have to rebuild initramfs for every single bisect.  But isn't
built-in make it easier and faster for the whole bisect process?

It's especially useful for tasks where we do not even need to make modules,
like debugging built-in drivers.

> > If using initramfs is standard and easy, I wonder why Qualcomm QLI
> > (meta-qcom) kernel has UFS drivers as built-in.
> 
> This I don't know. Distros do various things, but of course there might
> be an argument I do not know (e.g. like it was why distros do not make
> IPV6 a module).

We can consult internally, but saving use of initramfs could be part of
it, I would guess.

Shawn