linux-kernel - Re: [RFC] pinctrl: generic: Add DT bindings

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: <CACRpkdaXv=5PNt4EZPbcWzHYE4XAYmALqyV7v51QA+s63ZvFiQ@mail.gmail.com>
Date:	Mon, 24 Jun 2013 11:43:43 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	James Hogan <james.hogan@...tec.com>,
	"linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>
Subject: Re: [RFC] pinctrl: generic: Add DT bindings

On Wed, Jun 19, 2013 at 11:58 PM, Stephen Warren <swarren@...dotorg.org> wrote:
> On 06/11/2013 04:03 PM, Laurent Pinchart wrote:

>> +- tristate: A boolean, put the pin into high impedance state when set.

The other patch defines bias-high-impedance which is more likely
to be the string used.

Anyway:

> I don't think that a Boolean is appropriate here; it's really a tri-state:
>
> * Nothing is specified about the tristate value; don't touch that aspect
> of HW.
> * Turn tristate on.
> * Turn tristate off.

I was thinking more about using bias-disable; to explicitly turn that
off.

But maybe a specific disable option is needed, like for schmitt-trigger
(see below).

> This can be a meaningful distinction when relying on e.g. the bootloader
> having already set up the appropriate tristate value, or when
> dynamically switching between different pinctrl states and not wanting
> to affect tristate, or when piecing together multiple DT nodes that
> describe part of a state, where one node covers just muxing and the
> other just pin config (e.g. where the mux and pin config configuration
> registers in HW affect different overlapping groups).

OK point taken... although when we're dealing with generic pin config
the idea is not to cover everything but the majority of not-so-complicated
cases.

>> +- schmitt: An integer, enable or disable Schmitt trigger mode for the pins.
>> +  Valid values are
>> +    0: Schmitt trigger disabled (no hysteresis)
>> +    1: Schmitt trigger enabled
>
> A similar comment applies here.

The other patch adds:
input-schmitt-enable;
input-schmitt-disable;

So this is covered.

>> +- slew-rate: An integer controlling the pin slew rate. Values are device-
>> +  dependent.
>> +
>> +- drive-strength: An integer representing the drive strength of pins in mA.
>> +  Valid values are device-dependent.
>
> I'm still not convinced that requiring this to be in mA is a good idea.
> Different HW will use different units for documentation, or even specify
> no units at all, so it might not always be possible to represent this in
> terms of mA. Asking for the documentation to be re-written simply to
> support the DT binding just isn't going to happen.

We can add custom DT bindings for these. This is to cover those
where we know enough about it to actually use this generic binding.
If we don't really know what is happening we may as well call it
vendor,foo = <?>;

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/