linux-kernel - Re: [PATCH 1/2] pinctrl: add function to parse generic pinconfig properties from a dt node

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]

Message-ID: <CACRpkdb-vbdQJOeZvCEsKLatK-0BhEfUTJqmGURJGf1NWx__Ew@mail.gmail.com>
Date:	Thu, 13 Jun 2013 10:11:28 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Heiko Stübner <heiko@...ech.de>
Cc:	James Hogan <james.hogan@...tec.com>,
	Patrice Chotard <patrice.chotard.st@...il.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] pinctrl: add function to parse generic pinconfig
 properties from a dt node

Tisdagen den 13:e Juni 2013 klock 12:22 AM, skrev Heiko Stübner
<heiko@...ech.de>:
> Am Mittwoch, 12. Juni 2013, 16:55:12 schrieb James Hogan:

>> > +static struct pinconf_generic_dt_params dt_params[] = {
>> > +   { "bias-disable", PIN_CONFIG_BIAS_DISABLE, 0 },
>> > +   { "bias-high-impedance", PIN_CONFIG_BIAS_HIGH_IMPEDANCE, 0 },
>> > +   { "bias-bus-hold", PIN_CONFIG_BIAS_BUS_HOLD, 0 },
>> > +   { "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 0 },
>> > +   { "bias-pull-down", PIN_CONFIG_BIAS_PULL_DOWN, 0 },
>> > +   { "bias-pull-pin-default", PIN_CONFIG_BIAS_PULL_PIN_DEFAULT, 0 },
>> > +   { "drive-push-pull", PIN_CONFIG_DRIVE_PUSH_PULL, 0 },
>> > +   { "drive-open-drain", PIN_CONFIG_DRIVE_OPEN_DRAIN, 0 },
>> > +   { "drive-open-source", PIN_CONFIG_DRIVE_OPEN_SOURCE, 0 },
>> > +   { "drive-strength", PIN_CONFIG_DRIVE_STRENGTH, 0 },
>> > +   { "input-schmitt-enable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
>> > +   { "input-schmitt-disable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 0 },
>> > +   { "input-schmitt", PIN_CONFIG_INPUT_SCHMITT, 0 },
>> > +   { "input-debounce", PIN_CONFIG_INPUT_DEBOUNCE, 0 },
>> > +   { "power-source", PIN_CONFIG_POWER_SOURCE, 0 },
>> > +   { "slew-rate", PIN_CONFIG_SLEW_RATE, 0 },
>> > +   { "low-power-mode", PIN_CONFIG_LOW_POWER_MODE, 0 },
>> > +   { "output-low", PIN_CONFIG_OUTPUT, 0, },
>> > +   { "output-high", PIN_CONFIG_OUTPUT, 1, },
>>
>> shouldn't half of these default to 1 instead of 0? i.e. it's much nicer
>> for the lone flag "bias-pull-up" to enable pull up rather than disable
>> it (you even do this in the DT example in the bindings doc).
>
> on closer inspection it seems that you may be right.

Heiko can you write a patch for this? You can hit both this code and
the Rockchip driver at the same time for sure. Please check that
the bindings are consistent.

> The documentation to the
> options in the pinconf-generic header even tells that for example the pull
> options do have a 0 or 1 argument.

Yeah. Well.

Actually there has been plans to have the argument represent the
number of Ohms on the pull-up, but we haven't seen any hardware
that can actually select that.

Maybe we should add that now? It will still be that != 0 implies
enablement on platforms that does not support specifying the
pull up/down resistance.

> But I'm not sure if I understand everything correctly :-) ... isn't the bias-
> disable the opposite of turning on a pull (like the sh-pfc/pinctrl does) and
> same with switching from one pull type to another, i.e. activating a pull up
> would turn off a pull down and on the whole making the argument redundant?

This is true, and the plan is surely for the core to not allow or print
a big fat warning if someone does something really stupid like
activate pull up and pull down at the same time (unless s/he's
constructing a heater radiator or something).

Currently we don't make any sanity checks like that, BUT your
generic parser could actually be extended to do that.

Patches welcome ;-)

> The only other candidate I could find was low-power-mode which really could
> use a "1" as default. All the other pinconf options either use custom
> arguments or ignore teir argument.

A "1" for what? Not quite following....

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/