lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 10 Nov 2015 09:52:34 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Andrew Duggan <aduggan@...aptics.com>
Cc:	Benjamin Tissoires <benjamin.tissoires@...il.com>,
	Linux Input <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Benjamin Tissoires <benjamin.tissoires@...hat.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Christopher Heiny <cheiny@...aptics.com>,
	Stephen Chandler Paul <cpaul@...hat.com>,
	Allie Xiong <axiong@...aptics.com>
Subject: Re: [PATCH 22/26] Input: synaptics-rmi4 - Add F30 support

On Mon, Nov 9, 2015 at 11:54 PM, Andrew Duggan <aduggan@...aptics.com> wrote:

> F30 is currently only used in touchpads and mostly used to report the the
> click of the tact switch on clickpads. When the GPIO interrupts we report
> the appropriate button event to the host. Because the GPIOs are wired to our
> ASIC and not to the host I'm not sure there is any benefit to exposing it to
> the host using gpio_chip.
>
> Dmitry asked a similar question and here is my response to him:
> http://www.spinics.net/lists/linux-input/msg40458.html

So I think this is basically a terminology problem. There are some lines
here that the firmware calls "GPIO" (GENERAL PURPOSE input/output)
but in practice it really doesn't mean that, right?

In practice this thing is not randomly connected to doorbells, relays,
I2C bitbanged buses or whatnot. It is connected to certain keys,
and it is used for input. So it is not GPIO at all, but special purpose
input. No output.

Then it should be contained totally inside the RMI4 driver and connect
directly to the input layer.

It doesn't matter if the Synaptics firmware and/or internal documentation
calls it GPIO, if it walks and talks and acts like a duck it is a duck.
So register an input device for it and dispatch input events and be
happy.

For LEDs it makes more sense to actually register with the LEDs
subsystem as it is clearly output-only.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ