linux-kernel - Re: [PATCH] RFC: pinctrl: grab default handler with bus notifiers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <50A5341A.4040806@wwwdotorg.org>
Date:	Thu, 15 Nov 2012 11:27:38 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Stephen Warren <swarren@...dia.com>,
	Anmar Oueja <anmar.oueja@...aro.org>,
	Felipe Balbi <balbi@...com>, Benoit Cousson <b-cousson@...com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Mitch Bradley <wmb@...mworks.com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Kevin Hilman <khilman@...com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	Rickard Andersson <rickard.andersson@...ricsson.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Russell King <linux@....linux.org.uk>
Subject: Re: [PATCH] RFC: pinctrl: grab default handler with bus notifiers

On 11/15/2012 10:24 AM, Linus Walleij wrote:
> On Thu, Nov 15, 2012 at 3:26 PM, Thomas Petazzoni
> <thomas.petazzoni@...e-electrons.com> wrote:
> 
>> At ELCE, I've discussed with one person having an interesting use case:
>> they are using the same pin for two different purposes during the
>> system operation.
>>
>> At boot time, this pin is muxed as a SPI pin and is used to program the
>> bitstream of a FPGA. This is done in Linux, through a userspace
>> application.
>>
>> Then, once it is done, this pin is remuxed as a UART pin, and used to
>> communicate with another device on the board.
> 
> This is not related to the current discussion but interesting
> anyway...
> 
>> If the pinctrl configuration is done at probe() time inside the driver
>> core, then how can this kind of use case be supported? If each driver
>> does its own muxing, we could think of letting the SPI and UART driver
>> only do their muxing when the device is opened, and remove their muxing
>> when the device is closed, so that such sharing of pins for two
>> separate functions could be supported. Is this something we want to
>> support?
> 
> This is trivial to support after this commit in the current patch
> queue:
> commit 1a78958dc212f3698fdc543857af80155cb30f7f
> pinctrl: reserve pins when states are activated
> 
> Just define function maps for both devices using the same
> pins. Since the devices need to actively release their
> pins they need to go to a state which does not mux in
> any pins, so that the pins will be free:ed.
> 
> This state can be any arbitrary string, but if so desired
> for consistency we can define something like
> #define PINCTRL_STATE_DECOUPLED "decoupled"
> in include/linux/pinctrl/pinctrl-state.h to clearly
> mark that this is a state where the device is not
> using any pins at all.

Well, you'd also need to explicitly code the pinmux logic into the UART
driver, so that the UART's default state didn't prevent the SPI driver
from temporarily acquiring the pin to program the FPGA. It's rather
nasty to put that into the UART driver, which would presumably otherwise
be completely generic and not need runtime pinmux state changes. I
wonder if interjecting a mux driver between the UART/SPI and the pins
would help here, although presumably the UART driver would still need
some way of interacting with the mux driver which wouldn't be any better...

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