linux-kernel - Re: [PATCH 3/4] pinctrl: remove slew-rate parameter from tz1090

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: <CACRpkdZ6KOa=bXqm_S7LbUXp8AeWzCTCS6pRSFDiRu5ELgypQg@mail.gmail.com>
Date:	Thu, 27 Jun 2013 10:32:01 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	James Hogan <james.hogan@...tec.com>,
	Heiko Stübner <heiko@...ech.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <rob.herring@...xeda.com>
Subject: Re: [PATCH 3/4] pinctrl: remove slew-rate parameter from tz1090

On Tue, Jun 25, 2013 at 11:46 PM, Stephen Warren <swarren@...dotorg.org> wrote:
> On 06/25/2013 08:57 AM, James Hogan wrote:
>> 0: slow (half frequency)
>> 1: fast
>>
>> I just got a reply back from a hardware engineer, who said that the
>> relationship with the actual volts/usec will depend on both the drive
>> strength and the load on the pad, and that a definite answer probably
>> requires running a simulation.
>
> Tegra is similar here. The docs just say (for a 2-bit field expressed in
> binary) "Code 11 is the least slewing of the signal, code 00 is the
> highest slewing of the signal".
>
> I'm not sure that a generic parameter actually needs specific units. Why
> can't we simply specify the units as HW-defined, even while using a
> standardized DT property name and kernel-internal enum to represent the
> concept of slew rate?

That is fine I guess, that is how it is currently defined for the
kernel internals in
<linux/pinconf/pinconf-generic.h>:

 * @PIN_CONFIG_SLEW_RATE: if the pin can select slew rate, the argument to
 *      this parameter (on a custom format) tells the driver which alternative
 *      slew rate to use.

It's just that the very phrase "device tree" bring out the
standards body slow-and-impersonal considering all aspects
of the world side of me.

Unless someone from the DT camp think it is horrible to have
this value vendor-specific I'm all game.

But I guess it needs some binding doc for each and every pin
controller in that case, so referring to the generic binding will
not work. (And the driver needs to do some range checking
etc I guess.)

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/