[0/3] Add GPIO brownout detection support

Message

Marco Felsch Sept. 25, 2018, 9:42 a.m. UTC

Hi,

this small series adds a generic gpio-based brownout detection driver to
inform the userspace that something went wrong.

Additional there is a optional support to release devices from their
drivers, because there are board power designs which cut of external
devices supply immediately and keep the host (SoC) alive for a few
seconds to switch into a safe state. Due to the hard power cut some
external devices throw interrupts and depending of the amount of
external devices these interrupts will flood the host. The driver
unloads all specified devices from their drivers so the interrupts are
ignored. At the moment only spi and i2c devices are supported.

I've tested the driver on a customer arm based board, but other testers
are welcome. Maybe there are problems unloading device drivers which have a
incorrect .remove() or devm_alloc() order. Then these drivers must be
fixed.

Regards,
Marco

Marco Felsch (3):
  spi: switch to SPDX license identifier
  spi: make OF helper available for others
  Input: add generic gpio brownout driver

 .../bindings/input/gpio-brownout.txt          |  36 ++++
 drivers/input/misc/Kconfig                    |  12 ++
 drivers/input/misc/Makefile                   |   1 +
 drivers/input/misc/gpio-brownout.c            | 166 ++++++++++++++++++
 drivers/spi/spi.c                             |  18 +-
 include/linux/spi/spi.h                       |  30 ++--
 6 files changed, 239 insertions(+), 24 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/gpio-brownout.txt
 create mode 100644 drivers/input/misc/gpio-brownout.c

Comments

Mark Brown Sept. 25, 2018, 5:09 p.m. UTC | #1

On Tue, Sep 25, 2018 at 11:42:27AM +0200, Marco Felsch wrote:

> Marco Felsch (3):
>   spi: switch to SPDX license identifier

This seems like a completely unrelated change, why is it part of this
series?

>   spi: make OF helper available for others
>   Input: add generic gpio brownout driver
> 
>  .../bindings/input/gpio-brownout.txt          |  36 ++++
>  drivers/input/misc/Kconfig                    |  12 ++
>  drivers/input/misc/Makefile                   |   1 +
>  drivers/input/misc/gpio-brownout.c            | 166 ++++++++++++++++++
>  drivers/spi/spi.c                             |  18 +-
>  include/linux/spi/spi.h                       |  30 ++--
>  6 files changed, 239 insertions(+), 24 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/input/gpio-brownout.txt
>  create mode 100644 drivers/input/misc/gpio-brownout.c
> 
> -- 
> 2.19.0
>

Marco Felsch Sept. 26, 2018, 8:15 a.m. UTC | #2

On 18-09-25 10:09, Mark Brown wrote:
> On Tue, Sep 25, 2018 at 11:42:27AM +0200, Marco Felsch wrote:
> 
> > Marco Felsch (3):
> >   spi: switch to SPDX license identifier
> 
> This seems like a completely unrelated change, why is it part of this
> series?

You're right. I saw the old header during my work on this topic. I can
exclude it as a own patch.

Regards,
Marco

> 
> >   spi: make OF helper available for others
> >   Input: add generic gpio brownout driver
> > 
> >  .../bindings/input/gpio-brownout.txt          |  36 ++++
> >  drivers/input/misc/Kconfig                    |  12 ++
> >  drivers/input/misc/Makefile                   |   1 +
> >  drivers/input/misc/gpio-brownout.c            | 166 ++++++++++++++++++
> >  drivers/spi/spi.c                             |  18 +-
> >  include/linux/spi/spi.h                       |  30 ++--
> >  6 files changed, 239 insertions(+), 24 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/input/gpio-brownout.txt
> >  create mode 100644 drivers/input/misc/gpio-brownout.c
> > 
> > -- 
> > 2.19.0
> >

Mark Brown Sept. 26, 2018, 12:19 p.m. UTC | #3

On Wed, Sep 26, 2018 at 10:15:44AM +0200, Marco Felsch wrote:
> On 18-09-25 10:09, Mark Brown wrote:

> > > Marco Felsch (3):
> > >   spi: switch to SPDX license identifier

> > This seems like a completely unrelated change, why is it part of this
> > series?

> You're right. I saw the old header during my work on this topic. I can
> exclude it as a own patch.

OK, no need to resend or anything here but in general it's a better idea
to do that - it avoids confusion with dependencies or with things
getting tied up in review of the rest of the series when they don't need
to be.