Re: [PATCH] x86/x86_64_defconfig: Enable the serial console

Borislav Petkov
2020-10-11T19:06:34Z

On Sun, Oct 11, 2020 at 07:05:55PM +0200, Enric Balletbo i Serra wrote:
> For x86:
> 1. You send a patch to list enabling the CONFIG_YOUR_V4L2_DEVICE=m
> 2. The patch is rejected because doesn't fit the requirements (is not common
> enough)

Well, what if that config option enables hardware which is ARM-only.
Then it doesn't make any sense to enable it in the x86 defconfig.

> 3. If you're lucky someone will tell you to send the patch, to the specific
> KernelCI x86 fragment project.

You lost me here: there's a specific fragment project?!?

> 4. You send a patch to the separate KernelCI x86 project.
> 5. The patch is accepted and merged.
> 6. KernelCI builds linux-next, boots the kernel on the hardware, detects a
> new v4l2 device, and runs the v4l2-compliance tests.
>
>
> Of course you can skip 1-3 if you know already that. Another example:

So this second example confused me even more. Looking at your original
patch, you want this enabled in the defconfig:

config SERIAL_8250_DW
tristate "Support for Synopsys DesignWare 8250 quirks"
depends on SERIAL_8250
select SERIAL_8250_DWLIB
help
Selecting this option will enable handling of the extra features
present in the Synopsys DesignWare APB UART.

and for that you need those other two: X86_AMD_PLATFORM_DEVICE and
MFD_INTEL.

What I don't get is why can't you have a .config.snippet which enables
what you need on the chromebooks and you can have all the serial you
want. And the net card driver for that matter.

And in all that, I still don't get why this is relevant for the upstream
kernel.

By this logic, other projects would start wanting to add more to
defconfig and which would slowly turn into an allmodconfig. So you can
simply build an allmodconfig kernel and do *all* your testing with it,
just like the distros ship an allmodconfig-like kernel. Problem solved.

/me is more confused.

--
Regards/Gruss,
Boris.