[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdYk=dN8P9X=t0JhRuSVormm5fTeAT1Zwy98Q+F0XFTEpQ@mail.gmail.com>
Date: Wed, 7 Dec 2022 22:09:35 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: "larry.lai" <larry.lai@...jingtech.com>
Cc: lee@...nel.org, andriy.shevchenko@...ux.intel.com, pavel@....cz,
linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
linux-leds@...r.kernel.org, GaryWang@...on.com.tw,
musa.lin@...jingtech.com, jack.chang@...jingtech.com,
noah.hung@...jingtech.com
Subject: Re: [RFC 0/3] Add support control UP board CPLD/FPGA pin control
On Wed, Dec 7, 2022 at 5:36 PM larry.lai <larry.lai@...jingtech.com> wrote:
> The UP board <http://www.upboard.com> is the computer board for
> Professional Makers and Industrial Applications. We want to upstream
> the UP board 40-pin GP-bus Kernel driver for giving the users better
> experience on the software release. (not just download from UP board
> github)
>
> These patches are generated from the Linux kernel mainline tag v6.0.
Why are these patches tagged RFC now? Weird.
Came to think of this:
Shouldn't the subdrivers for pin control LED etc have:
default MFD_INTEL_UPBOARD_FPGA
i.e become y if the core driver is y, becomes m if the core driver is m.
Of course it is possible to run around in menuconfig and activate them
all manually interactively and be frustrated that something is missing
still but setting them default like this saves everybody's time. Activate
the MFD core driver and everything else comes with it, then it can
be turned off at request.
Yours,
Linus Walleij
Powered by blists - more mailing lists