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

[Dmitry Baryshkov]

On Fri, Apr 17, 2026 at 06:37:06PM +0800, Shawn Guo wrote:
> 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?

No. Insted you package modules as a separate .cpio.gz archive,
concatenate it with the initramfs and boot the kernel.

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

Having the meta-qcom hat on:
- If we know that the kernel is going to be used on Qualcomm hardware,
  it makese sense to enable necessary drivers as built-in to save time,
  boot time and to ease overall integration.

- Having the general defconfig, it doesn't make sense to make users of
  all other platforms suffer and loose their memory by having
  Qualcomm-specific drivers loaded, if that's not an absolute
  requirement.

-- 
With best wishes
Dmitry