Hi Krzysztof, On Wed, 12 Mar 2025 at 12:34, Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote: > > On 12/03/2025 12:10, Christopher Obbard wrote: > > Hi Krzysztof, > > > > On Wed, 12 Mar 2025 at 09:56, Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote: > >> > >> On 11/03/2025 20:15, Christopher Obbard wrote: > >>> Hi Dmitry, > >>> > >>> On Tue, 11 Mar 2025 at 19:58, Dmitry Baryshkov <lumag@xxxxxxxxxx> wrote: > >>>> > >>>> On Tue, Mar 11, 2025 at 07:10:06PM +0100, Christopher Obbard wrote: > >>>>> I sent this patch to start the discussion, some things I found: > >>>>> > >>>>> 1) Some interconnects are missing from arm defconfig. Should they be =y too ? > >>>> > >>>> No, unless those are required for the UART console. > >>> > >>> OK, that makes sense. FWIW the cryptic (to me, at least) commit log on > >>> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6eee808134ecf1c1093ff1ddfc056dc5e469d0c3 > >>> made me think that the interconnects should be built-in on all devices. > >>> > >>> Of course, the real problem here is RB3gen2 not actually finding the > >>> UFS/eMMC device due to no interconnect driver. > >>> Until now, I have been building that into the kernel. I will > >>> investigate instead shoving into the initrd (in both debian and > >>> fedora) which should solve my issue and render this patchset useless. > >> > >> For Qualcomm platforms you are expected to always have initramfs, thus > >> you will have the modules for UFS/eMMC mounts. I don't understand the > >> problem which you were trying to solve. > >> > >> The interconnects were built in *only* because of need for serial > >> console. Only. > > > > Thanks for confirming. It is all clear now. > > > > Consider this patch dropped from my side. > > > > For reference, I am working on updating initramfs generation tools in > > Debian/Fedora to include the required interconnect modules. Currently > > the interconnect drivers are built as modules in these distros, but > > are not included in the initrd. That is where my confusion initially > > stemmed from. > > Sure. This defconfig is anyway for us - developers, not for the distros > to use directly. Distros have much bigger configs and use almost > everything as module. Completely agree - my usual workflow is to build with the kernel's defconfig (disto config is generally huge) and install the resulting kernel into my Debian image. Installing a kernel built with `make bindeb-pkg` then calls update-initramfs to create the initrd - which then should pack the RIGHT modules needed for loading storage/network boot/etc into the initrd. In this case it simply didn't yet copy that module into the initrd in Debian, so I will sort it out in the distro space ;-). We can likely stop this discussion now as it's clear to everyone what's going on I think. Thanks, Chris
