Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210117035140.1437-1-alistair@alistair23.me> <20210117035140.1437-2-alistair@alistair23.me>
 <CAOesGMiLZGdjQTLj48B8dXV1vv2p-NG751m-bh61mJ-10N-rAw@mail.gmail.com> <CAKmqyKO_xxrzMHB7Fuxq_5xT6JH8sOudKAKgug_FiS08MiJ94w@mail.gmail.com>
In-Reply-To: <CAKmqyKO_xxrzMHB7Fuxq_5xT6JH8sOudKAKgug_FiS08MiJ94w@mail.gmail.com>
From:   Olof Johansson <olof@lixom.net>
Date:   Sun, 17 Jan 2021 18:03:43 -0800
Message-ID: <CAOesGMh9X3OwzftRQYVsz6=Wv_wkm-wh_ucN91e6FCbjnG3X+g@mail.gmail.com>
Subject: Re: [PATCH 2/2] remarkable2_defconfig: Add initial support for the reMarkable2
To:     Alistair Francis <alistair23@gmail.com>
Cc:     Alistair Francis <alistair@alistair23.me>,
        Arnd Bergmann <arnd@arndb.de>,
        Rob Herring <robh+dt@kernel.org>,
        Shawn Guo <shawnguo@kernel.org>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Sascha Hauer <kernel@pengutronix.de>,
        Fabio Estevam <festevam@gmail.com>,
        dl-linux-imx <linux-imx@nxp.com>,
        Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>,
        DTML <devicetree@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi,

On Sun, Jan 17, 2021 at 5:36 PM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Sun, Jan 17, 2021 at 5:30 PM Olof Johansson <olof@lixom.net> wrote:
> >
> > Hi Alistair,
> >
> > On Sun, Jan 17, 2021 at 3:09 PM Alistair Francis <alistair@alistair23.me> wrote:
> > >
> > > 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 <alistair@alistair23.me>
> >
> > It's awesome to see upstream support for contemporary consumer
> > products being posted, thanks!
>
> No worries!
>
> >
> > 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.

> > 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