linux-kernel - Re: [PATCH 1/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration

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:	Wed, 15 Apr 2015 11:51:32 -0500
From:	Nishanth Menon <nm@...com>
To:	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>,
	Tony Lindgren <tony@...mide.com>
CC:	Linus Walleij <linus.walleij@...aro.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Linux-OMAP <linux-omap@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Lokesh Vutla <lokeshvutla@...com>
Subject: Re: [PATCH 1/2] pinctrl: bindings: pinctrl: Add support for TI's
 IODelay configuration

On 04/14/2015 08:29 PM, Lennart Sorensen wrote:
> On Tue, Mar 17, 2015 at 06:41:51PM -0700, Tony Lindgren wrote:
>> Yeah agreed. I suggest discussing the binding and the generic
>> parsing code for it first :)
>>  
>> It seems with the generic binding the actual driver should be
>> just the hardware specific code hopefully.
> 
> Did this thread go anywhere in the last month?  I am certainly looking
> forward to seeing what the resolution is to this, given for our use the
> boot loader setup is not appealing at all.
> 
I am yet to post a new revision to this series - few other stuff got
in the way. IODelay driver in no way removes the constraint that the
SoC architecture has - most of the pins still need to be muxed in
bootloader - we cannot escape that. The reasoning for doing the mux in
bootloader is independent of the need for iodelay.

Reasoning for mux in bootloader is because the mux and pull fields are
glitchy - much more than previous generations of TI SoCs and
significantly long enough to cause issues depending on the pins being
muxed.

Reasoning for iodelay is different - it is a hardware block meant to
control the timing of signals in a particular signal path to ensure
that specification compliance is met.

Lets try not to mix the two.

-- 
Regards,
Nishanth Menon
--
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/