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

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

[Shawn Guo]

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
to boot from UFS, which adds friction to daily development workflows.
Promote both to built-in to allow booting directly from UFS without
an initramfs.

PHY_QCOM_QMP is a menuconfig umbrella for all Qualcomm QMP PHY drivers.
Setting it to built-in is required to allow any of its sub-drivers to be
built-in.  Since only the UFS PHY (PHY_QCOM_QMP_UFS) needs to be
built-in for the rootfs use case, the PCIe and USB sub-drivers
(PHY_QCOM_QMP_PCIE, PHY_QCOM_QMP_PCIE_8996, PHY_QCOM_QMP_USB) are
explicitly set to module to avoid unnecessarily inflating the kernel
image.  The combo PHY sub-driver (PHY_QCOM_QMP_COMBO) is naturally
capped at module by its dependencies on TYPEC=m and DRM=m.

Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
 arch/arm64/configs/defconfig | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index dd1ac01ee29b..f6ac2d29cbdf 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1316,7 +1316,7 @@ CONFIG_SCSI_UFSHCD=y
 CONFIG_SCSI_UFS_BSG=y
 CONFIG_SCSI_UFSHCD_PLATFORM=y
 CONFIG_SCSI_UFS_CDNS_PLATFORM=m
-CONFIG_SCSI_UFS_QCOM=m
+CONFIG_SCSI_UFS_QCOM=y
 CONFIG_SCSI_UFS_MEDIATEK=y
 CONFIG_SCSI_UFS_HISI=y
 CONFIG_SCSI_UFS_RENESAS=m
@@ -1783,7 +1783,10 @@ CONFIG_PHY_MTK_MIPI_DSI=m
 CONFIG_PHY_MTK_DP=m
 CONFIG_PHY_QCOM_EDP=m
 CONFIG_PHY_QCOM_PCIE2=m
-CONFIG_PHY_QCOM_QMP=m
+CONFIG_PHY_QCOM_QMP=y
+CONFIG_PHY_QCOM_QMP_PCIE=m
+CONFIG_PHY_QCOM_QMP_PCIE_8996=m
+CONFIG_PHY_QCOM_QMP_USB=m
 CONFIG_PHY_QCOM_QUSB2=m
 CONFIG_PHY_QCOM_EUSB2_REPEATER=m
 CONFIG_PHY_QCOM_M31_USB=m
-- 
2.43.0

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

[Krzysztof Kozlowski]

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.

> Promote both to built-in to allow booting directly from UFS without
> an initramfs.
> 
> PHY_QCOM_QMP is a menuconfig umbrella for all Qualcomm QMP PHY drivers.
> Setting it to built-in is required to allow any of its sub-drivers to be
> built-in.  Since only the UFS PHY (PHY_QCOM_QMP_UFS) needs to be
> built-in for the rootfs use case, the PCIe and USB sub-drivers
> (PHY_QCOM_QMP_PCIE, PHY_QCOM_QMP_PCIE_8996, PHY_QCOM_QMP_USB) are
> explicitly set to module to avoid unnecessarily inflating the kernel
> image.  The combo PHY sub-driver (PHY_QCOM_QMP_COMBO) is naturally
> capped at module by its dependencies on TYPEC=m and DRM=m.
> 
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
>  arch/arm64/configs/defconfig | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index dd1ac01ee29b..f6ac2d29cbdf 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -1316,7 +1316,7 @@ CONFIG_SCSI_UFSHCD=y
>  CONFIG_SCSI_UFS_BSG=y
>  CONFIG_SCSI_UFSHCD_PLATFORM=y
>  CONFIG_SCSI_UFS_CDNS_PLATFORM=m
> -CONFIG_SCSI_UFS_QCOM=m
> +CONFIG_SCSI_UFS_QCOM=y

No, I reiterated this many times on the list, so once more: no.

This is fine as module.

Best regards,
Krzysztof

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

[Shawn Guo]

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?

If using initramfs is standard and easy, I wonder why Qualcomm QLI
(meta-qcom) kernel has UFS drivers as built-in.

Shawn

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

[Krzysztof Kozlowski]

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

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

Best regards,
Krzysztof

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

[Shawn Guo]

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

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

[Krzysztof Kozlowski]

On 17/04/2026 12:37, 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?

You rebuild initramfs anyway always but itself it is fast command. Your
change does not matter here - changed nothing. You anyway have to
rebuild it so the modules will be placed there.

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

Nothing stops you from make it built-in, if you prefer. For me it is one
argument ("-S qcom") for my build script. Other has other ways (scripts
have even helper for that).

Best regards,
Krzysztof

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