On Tue, Nov 12, 2013 at 10:07:13AM +0000, Alexander Shiyan wrote:
> This patch adds a new driver for the beeper controlled via GPIO pin.
> The driver does not depend on the architecture and is positioned as
> a replacement for the specific drivers that are used for this function.
>
> Signed-off-by: Alexander Shiyan <shc_work@xxxxxxx>
> ---
> .../devicetree/bindings/input/gpio-beeper.txt | 15 +++
> drivers/input/misc/Kconfig | 9 ++
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/gpio-beeper.c | 129 +++++++++++++++++++++
> 4 files changed, 154 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/gpio-beeper.txt
> create mode 100644 drivers/input/misc/gpio-beeper.c
>
> diff --git a/Documentation/devicetree/bindings/input/gpio-beeper.txt b/Documentation/devicetree/bindings/input/gpio-beeper.txt
> new file mode 100644
> index 0000000..8081605
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/gpio-beeper.txt
> @@ -0,0 +1,15 @@
> +* GPIO beeper device tree bindings
> +
> +Registers a beeper connected to GPIO pin.
> +
> +Required properties:
> +- compatible: should be "gpio-beeper".
> +- gpios: From common gpio binding; gpio connection to beeper enable pin.
> +
> +Example:
> +
> +beeper: input@0 {
> + compatible = "gpio-beeper";
> + reg = <0>;
> + gpios = <&gpio3 23 0>;
> +};
What are the reg / unit-address for?
Also, a beeper doesn't strike me as an input device, regardless of how
the kernel sees it internally. I'd expect the node to just be named
"beeper" or something along those lines.
Otherwise I believe this looks sane.
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
