Re: [PATCH 2/2] remarkable2_defconfig: Add initial support for the reMarkable2

On Sun, Jan 17, 2021 at 6:03 PM Olof Johansson [off-list ref] wrote:

Hi,

On Sun, Jan 17, 2021 at 5:36 PM Alistair Francis [off-list ref] wrote:

quoted

On Sun, Jan 17, 2021 at 5:30 PM Olof Johansson [off-list ref] wrote:

quoted

Hi Alistair,

On Sun, Jan 17, 2021 at 3:09 PM Alistair Francis [off-list ref] wrote:

quoted

This defconfig is based on the one released by reMarkable with their
4.14 kernel. I have updated it to match the latest kernels.

Signed-off-by: Alistair Francis <redacted>

It's awesome to see upstream support for contemporary consumer
products being posted, thanks!

No worries!

quoted

When it comes to a dedicated defconfig, is that necessary in this
case? The needed drivers should be possible to enable either in
imx_v6_v7_defconfig, or in multi_v7_defconfig (or, rather, both)?

Most of the defconfi could be shared with a standard imx7 config, but
some of the extra components like the Wacom digitiser,
cyttsp5_i2c_adapter, max77818 and bd71815 might be better off in it's
own defconfig.

If the maintainers are happy with enabling some of those in a imx7
defconfig then I'm happy to do that. I have tried to split out the
config changes (I have two otehr series that build on this one) so it
should be easy to rebase it all on a standard one.

Yeah, enabling those in imx_v6_v7_defconfig and multi_v7_defconfig is
fine (or, really, desirable and preferred).

Please enable as modules where possible (i.e anything that's fine to
wait loading until after rootfs is mounted), to avoid kernel image
growth on platforms that don't need those drivers.

I just sent a v2 of this series. Patch 1 is the same but I'm now using
the imx_v6_v7_defconfig in patch 2 and 3.

I only need a single change so hopefully that's fine. I'm sure more
features will need to be enabled but they can come with future
patches.

Alistair

quoted

quoted

Adding new defconfigs is something we're avoiding as much as possible,
since it adds CI overhead, and defconfigs easily get churny due to
options moving around.

In some cases we do it once per SoC family (i.e. the i.MX defconfigs),
but we avoid it for products.

Makes sense, I will update my patches not to use a custom defconfig.

Awesome, thanks!


-Olof