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

[Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>]

On 18-04-2026 04:29, Dmitry Baryshkov wrote:
> 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.
> 

Then it makes sense to make CONFIG_MSM_SDHCI or 
CONFIG_MSM_SDHCI_MSM(qcom specific config) as module too?
https://elixir.bootlin.com/linux/v7.0/source/arch/arm64/configs/defconfig#L1279

Not sure why it's enabled as builtin for all vendors.

-- 
Regards
Kuldeep