linux-kernel - Re: [PATCH] gpio: add support for ITE IT87xx Super I/O GPIO.

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]

Message-ID: <20120319135636.GA30456@ericsson.com>
Date:	Mon, 19 Mar 2012 06:56:36 -0700
From:	Guenter Roeck <guenter.roeck@...csson.com>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	Diego Elio Pettenò <flameeyes@...meeyes.eu>,
	Grant Likely <grant.likely@...retlab.ca>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	Denis Turischev <denis@...pulab.co.il>
Subject: Re: [PATCH] gpio: add support for ITE IT87xx Super I/O GPIO.

On Mon, Mar 19, 2012 at 04:26:44AM -0400, Linus Walleij wrote:
> On Mon, Mar 19, 2012 at 1:54 AM, Guenter Roeck
> <guenter.roeck@...csson.com> wrote:
> > On Sun, Mar 18, 2012 at 07:14:45PM -0400, Linus Walleij wrote:
> >> On Sat, Mar 17, 2012 at 7:53 PM, Diego Elio Pettenņ
> >> <flameeyes@...meeyes.eu> wrote:
> >>
> >> > Another reason to have a MFD driver would be to allow tweaking the few
> >> > more knobs that (at least IT8728F) expose, such as the ability to switch
> >> > a few pre-defined inputs and outputs to GPIO instead, and so on...
> >>
> >> Hm that sounds an awful lot like pin multiplexing. Is that the case?
> >>
> > Depending on the chip configuration, a physical pin may be a GPIO pin, or a UART pin,
> > or a fan control pin, or a FD pin, or something else. This does not apply to all pins,
> > but to many of the GPIO pins.
> 
> OK that is pinmuxing, if that is to be software-controlled the place to do
> it is in drivers/pinctrl. (Documentation/pinctrl.txt gives the backrgound.)
> 
> The rule is in that case to put the driver below drivers/pinctrl/* and also
> expose a gpiolib interface from that driver.
> 
> As we convert drivers to the new pinctrl interfaces we tend to move them
> from drivers/gpio to drivers/pinctrl. But no biggie, if pinctrl is added later,
> it can be moved by then. I'm mainly concerned with blocking any
> extra custom interfaces to the gpio drivers.
> 
Personally I would not dare touch those pins. If a pin is configured as UART pin
(or whatever), it is quite unlikely that it is exposed as GPIO pin. Worst case,
changing the configuration may result in broken hardware. Not sure what is supposed
to be gained by enabling the user to do that.

Guenter
--
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/