Re: Commit 8ae030c34 breaks USB on the Raspberry Pi 4

On Wed, 15 Sept 2021 at 10:54, nicolas saenz julienne [off-list ref] wrote:

On Wed, 2021-09-15 at 09:55 +0200, Michael Stapelberg wrote:

quoted

Hey Nicolas

On Wed, 15 Sept 2021 at 09:42, nicolas saenz julienne [off-list ref] wrote:

quoted

Hi Michael,

On Wed, 2021-09-15 at 08:33 +0200, Michael Stapelberg wrote:

quoted

Thanks for your mail.

My system does not use any Linux kernel modules (=m), all required
code is compiled into the kernel itself (=y).
The root file system does not contain any .ko files.

Are you building your own kernels? Then I suggest to configure the
raspberrypi-reset driver as builtin (=y) so it's available in your kernel
image.

Yes, I have already done that. I was more interested in fixing this
problem for others, and/or avoiding similar problems in the future.

quoted

Could you provide more information on how your system/rootfs is built and
setup?

Please see https://gokrazy.org/, specifically https://gokrazy.org/quickstart/.
The source for the gokr-packer tool is at
https://github.com/gokrazy/tools/tree/master/cmd/gokr-packer

In summary, my tool builds a read-only SquashFS root file system that
directly starts processes written in Go.
The boot partition (FAT32 for the Raspberry Pi) contains only the
Linux kernel and Raspberry Pi firmware files.

Thanks for the info.

IMO the solution is to maintain your own configuration. The decision not to use
kernel modules, even if reasonable given the scope of gokrazy, is a big
deviation from how the kernel is regularly consumed. The majority of the arm64
defconfig users need the kernel image to be as small as possible to avoid
bloating the boot partition, and allowing for reasonable boot speeds (imagine
having to load a 1GB kernel image from the SD card).

Yep, effectively I am maintaining my own configuration, but I still
run defconfig before applying my own additions to .config.

I think that in general I do want the changes that defconfig brings,
so defconfig+additions is the only way I see, and I thought this was
best practice?

Are you saying there might be a better option? Or perhaps the best
move is to just support modules in gokrazy after all.

Thanks for your advice,

Regards,
Nicolas

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel