[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdYTPc9b0ys-rMJ6VJSxVX9uubq6r1QFk4bQN5rMiqQPMQ@mail.gmail.com>
Date: Mon, 19 Mar 2012 15:05:55 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Guenter Roeck <guenter.roeck@...csson.com>
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 2:56 PM, Guenter Roeck
<guenter.roeck@...csson.com> wrote:
> On Mon, Mar 19, 2012 at 04:26:44AM -0400, Linus Walleij wrote:
>> 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.)
(...)
>>
> 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.
Define "user", pinctrl does not have userspace interfaces if that's
what you mean.
If you mean "kernel programmer", these creatures seem to not respect what
they should and shouldn't poke at ;-)
The usecase is typically if the hardware is used in two different systems
where the ROM/bootcode/etc does not set up muxing correctly, or are setup
in a sub-optimal way (e.g. working but consuming too much power) and the
kernel needs to get involved. Unless you have any scenario like that, no
need to worry about it.
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