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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOesGMiLZGdjQTLj48B8dXV1vv2p-NG751m-bh61mJ-10N-rAw@mail.gmail.com>
Date:   Sun, 17 Jan 2021 17:29:58 -0800
From:   Olof Johansson <olof@...om.net>
To:     Alistair Francis <alistair@...stair23.me>
Cc:     Arnd Bergmann <arnd@...db.de>, Rob Herring <robh+dt@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Sascha Hauer <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        dl-linux-imx <linux-imx@....com>,
        Linux ARM Mailing List <linux-arm-kernel@...ts.infradead.org>,
        DTML <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        alistair23@...il.com
Subject: Re: [PATCH 2/2] remarkable2_defconfig: Add initial support for the reMarkable2

Hi Alistair,

On Sun, Jan 17, 2021 at 3:09 PM Alistair Francis <alistair@...stair23.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@...stair23.me>

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

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

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.

-Olof