Add Adafruit's rpi_power_switch: Optionally uses GPIO pin to trigger shutdown

[brennen]

This adds the rpi_power_switch module, which lets a GPIO pin be configured to run shutdown -h.

This is mainly intended for use in conjunction with an Adafruit PiTFT and a tactile switch, but should be usable with just about any pushbutton or switch.

Submitting this here since it's definitely Pi-specific.

Code by @xobs, cc: @ladyada, @toddtreece.

[ladyada]

hiya folx! one of the neat things about this kernel module is it is always running, so even if there's a userspace lockup in someone's project, its still possible to get the pi to shutdown nicely. also, it will turn the pi back on after its been shutdown, which you cannot do in user space.

[pelwell]

Although I'm happy with the goals of this PR, the implementation needs some work before we'll accept it:

1. We're not going to accept any code that accesses the GPIO registers directly like this, when there is a generic GPIO API for linux drivers. See drivers/leds/leds-gpio.c for an example of how to use it. drivers/staging/media/lirc/lirc_rpi.c might also be useful, but this isn't the best example of kernel coding standards. The gpiolib API doesn't include a generic way to set the pull direction on a pin, but that's OK because...

2. Use Device Tree. The pinctrl infrastructure allows you to define the pins used by a module and their configuration for a number of states. The configuration includes the pull direction, so you don't need an API to set it dynamically. Device Tree parameters allow things like the GPIO number to be patched using entries in config.txt.
   Although we still support non-DT configurations, this won't always be the case, and choosing to go DT-only (by assuming that the pins are configured already) will make your code simpler.
   Another way to solve the pull problem for generic non-DT configurations is to make use of the default pull of the GPIOs - GPIO0-GPIO8 pull high, while GPIO9-GPIO27 pull low.

3. A bit of a tidy up wouldn't hurt - simply removing all of the commented out printk()s (you should be using pr_info, pr_err etc. anyway) would be an improvement,

4. A Copyright notice at the top of the C file would be a good idea.

5. Make the configuration option dependent on one of the Raspberry Pi platforms:

    depends on MACH_BCM2708 || MACH_BCM2709 || ARCH_BCM2835

I hope this list isn't too disheartening. With a bit of effort (mainly deleting code) you will end up with something that is usable on other platforms as well.

I'm happy to answer questions if you get stuck and need a few pointers - phil at raspberrypi dot org.

[brennen]

Thanks for taking the time to give detailed feedback. We'll see what we can do.

[Ruffio]

@brennen is this still relevant? If not, please close it.
@pelwell if this it still relevant, are the performed updates ok, and it can be merged?

[pelwell]

The driver still accesses the GPIO hardware directly to set pull directions, and it isn't even slightly Device Tree-aware. We won't accept this as-is.

[Ruffio]

@brennen do you want to 'fix' else I think this PR should be closed. Thanks

[brennen]

Hey folks. Sorry - it's been a while. We'll re-open when we get the bandwidth to beat this into shape, but for the moment I think it can stop cluttering your open PRs.