[PATCH 3/5] arm64: defconfig: Build interconnect driver for QCM2290

Bjorn Andersson andersson at kernel.org
Wed May 24 16:14:41 PDT 2023


On Wed, May 24, 2023 at 08:36:20AM +0200, Arnd Bergmann wrote:
> On Tue, May 23, 2023, at 23:11, Dmitry Baryshkov wrote:
> > On 23/05/2023 20:30, Konrad Dybcio wrote:
> >> 
> >> 
> >> On 23.05.2023 18:54, Vladimir Zapolskiy wrote:
> >>> Build Qualcomm QCM2290 interconnect driver.
> >>>
> >>> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy at linaro.org>
> >>> ---
> >> Do we know why some are =y and some are =m?
> >> 
> >> I'm for =y either way, if we can.
> >
> > I think this might change from platform to platform. What is the 
> > condition for selecting 'y' or 'm' for the core drivers? Is it 'should 
> > boot to rootfs without modules' or 'should boot to UART and load initrd 
> > without modules' ?
> 
> I think we are a bit inconsistent here. I'm generally fine taking
> changes that are required to boot into rootfs without initramfs,
> but would like everything else to be loadable modules.
> 
> Android tends to want everything as modules and require an initramfs
> for loading them, so I think platforms that are mostly Android
> specific lean towards that even for core drivers.
> 

I (any many other in the Qcom community) do most of my (our) testing and
development using a ramdisk-only approach and if systemd isn't provided
a valid /dev/console at launch, things doesn't work as expected...

So the inconsistency here relates to the fact that not all platforms has
the UART defined to depend on interconnect, once this is populated in
DT, we tend to be forced to move them to =y, together with GCC and
pinctrl-msm.


Looking to storage etc on a modern Qualcomm platform, the dependency
tree is growing quite a bit (regulators, genpd providers etc), and we
have UFS, SDHCI and NVME to support. So I think it's reasonable to have
the generic defconfig require that you use a initramfs to get further
(on the Qualcomm platforms).

Regards,
Bjorn



More information about the linux-arm-kernel mailing list