[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdZKE4TE6sN+evviB8uHU6ZZ9W4XCiPpOS6-YsDd7ZxMUg@mail.gmail.com>
Date: Thu, 5 Nov 2020 10:30:28 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Daniel Palmer <daniel@...f.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
devicetree <devicetree@...r.kernel.org>,
arm-kernel@...ts.infradead.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/5] gpio: msc313: MStar MSC313 GPIO driver
On Tue, Oct 20, 2020 at 1:59 PM Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
> On Mon, Oct 19, 2020 at 5:11 PM Daniel Palmer <daniel@...f.com> wrote:
> > +config GPIO_MSC313
> > + bool "MStar MSC313 GPIO support"
> > + default y if ARCH_MSTARV7
I think it is possible to write:
default ARCH_MSTARV7
For this.
> Why boolean?
I answered this question in some other mail but there is usually somewhat
a good reason for this but let's discuss it a bit.
The following usecase:
- You have a generic distribution such as Android
- The generic distribution does not use initramfs to support basic
drivers (does Android? Nowadays?)
- So all modules would need to load from actual storage media.
- The storage media is an SD card.
- The SD card reader has a card detect line connected to one
of the GPIO lines.
- Now we have catch-22 because there is no way to load the
GPIO driver modules from the storage media because the
driver is needed to mount the storage media.
I do not know if this "never happens" because every generic
distribution "should" be using initramfs for their drivers. But it
provides a convenient way for users to shoot themselves in the
foot and be frustrated about that their root filesystem is not
mounting.
I do not think this is limited to GPIO card detects but it is a very
immediate example.
What is the consensus here?
Yours,
Linus Walleij
Powered by blists - more mailing lists