linux-kernel - Re: [PATCH 1/4 v5] drivers: create a pin control subsystem v5

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] [day] [month] [year] [list]

Message-ID: <CACRpkdYj+4tPgBQWd6MhWJStkdSmorGDBUr68LtsWwnpfTo_5w@mail.gmail.com>
Date:	Fri, 2 Sep 2011 10:07:47 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dia.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Lee Jones <lee.jones@...aro.org>,
	Joe Perches <joe@...ches.com>,
	Russell King <linux@....linux.org.uk>,
	Linaro Dev <linaro-dev@...ts.linaro.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	David Brown <davidb@...eaurora.org>,
	Barry Song <21cnbao@...il.com>
Subject: Re: [PATCH 1/4 v5] drivers: create a pin control subsystem v5

On Thu, Sep 1, 2011 at 9:43 PM, Stephen Warren <swarren@...dia.com> wrote:

> Looking forward a little, I expect that different SoCs have such a
> different set of biasing/driver-strength/... options that actually having
> some formalized semantic representation of what those options are doesn't
> make sense; all we need is a standard API to set the values for a given
> pin or pingroup;

I'm still thinking about this thing, when I (and others) wer trying to
shoehorn this kind of stuff into the GPIO layer I actually started to
enumerate the different things you could do with a pin, beginning
like this:

+/*
+ * Bias modes for GPIOs - if you have more biases, add them here or provide
+ * custom enumerators for your driver if you find they are not generally
+ * useful.
+ *
+ * GPIO_CONFIG_BIAS_UNKNOWN: this bias mode is not known to us
+ * GPIO_CONFIG_BIAS_FLOAT: no specific bias, the GPIO will float or state
+ *     is not controlled by software
+ * GPIO_CONFIG_BIAS_PULL_UP: the GPIO will be pulled up (usually with high
+ *     impedance to VDD)
+ * GPIO_CONFIG_BIAS_PULL_DOWN: the GPIO will be pulled down (usually with high
+ *     impedance to GROUND)
+ * GPIO_BIAS_HIGH: the GPIO will be wired high, connected to VDD
+ * GPIO_BIAS_GROUND: the GPIO will be grounded, connected to GROUND
+ */
+#define GPIO_CONFIG_BIAS_UNKNOWN       0x1000
+#define GPIO_CONFIG_BIAS_FLOAT         0x1001
+#define GPIO_CONFIG_BIAS_PULL_UP       0x1002
+#define GPIO_CONFIG_BIAS_PULL_DOWN     0x1003
+#define GPIO_CONFIG_BIAS_HIGH          0x1004
+#define GPIO_CONFIG_BIAS_GROUND        0x1005
+
+/*
+ * Drive modes for GPIOs (output) - if you have more custom modes either
+ * add them here or keep them to your driver if you think they are not
+ * generally useful.
+ *
+ * GPIO_CONFIG_DRIVE_UNKNOWN: we don't know the drive mode of this GPIO, for
+ *     example since it is controlled by hardware or the information is not
+ *     accessible but we need a meaningful enumerator in e.g. initialization
+ *     code
+ * GPIO_CONFIG_DRIVE_PUSH_PULL: the GPIO will be driven actively high and
+ *     low, this is the most typical case and is typically achieved with two
+ *     active transistors on the output
+ * GPIO_CONFIG_DRIVE_OPEN_DRAIN: the GPIO will be driven with open drain (open
+ *     collector) which means it is usually wired with other output ports
+ *     which are then pulled up with an external resistor
+ * GPIO_CONFIG_DRIVE_OPEN_SOURCE: the GPIO will be driven with open drain
+ *     (open emitter) which is the same as open drain mutatis mutandis but
+ *     pulled to ground
+ * GPIO_CONFIG_DRIVE_OFF: the GPIO pin is set to inactive mode, off
+ */
+#define GPIO_CONFIG_DRIVE_UNKNOWN      0x2010
+#define GPIO_CONFIG_DRIVE_PUSH_PULL    0x2011
+#define GPIO_CONFIG_DRIVE_OPEN_DRAIN   0x2012
+#define GPIO_CONFIG_DRIVE_OPEN_SOURCE  0x2013
+#define GPIO_CONFIG_DRIVE_OFF          0x2014

The basic assumption is that there are not that infinitely many
things you may want to do with a pin after all.

I can already think about interesting enumerators for
GPIO_CONFIG_INPUT_SCHMITT_TRIGGER
GPIO_CONFIG_INPUT_LOAD_CAPACITANCE
etc. But not unenumerable things.

The upside of this scheme is that we might have some handle on
trying to consolidate common functionality between drivers,
also to sort of consolidate the knowledge of what you can
do with pins in one place, even if you can't share any code.

For a stupid example the generic debugfs files could give you a list
of all pins in any system and what bias mode they're in, no
matter what platform we're dealing with, which would give the
some kind of cosy consensus for developers that platforms
are not that different after all.

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/