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: <CACRpkdbnf2MJtnYrwGMVWyz4S=7tuDKv84p7eNgveSNCeLv15g@mail.gmail.com>
Date:	Mon, 10 Jun 2013 15:39:26 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Heiko Stübner <heiko@...ech.de>
Cc:	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 0/2] pinctrl: common handling of generic pinconfig props
 in dt

On Mon, Jun 10, 2013 at 3:06 PM, Heiko Stübner <heiko@...ech.de> wrote:
> Am Montag, 10. Juni 2013, 14:52:13 schrieb Linus Walleij:
>> On Sun, Jun 9, 2013 at 1:59 AM, Heiko Stübner <heiko@...ech.de> wrote:
>> > following your suggestions for a common handling of things like pulls in
>> > dt, I've come up with the following solution - hopefully I've gotten the
>> > correct meaning of your explanaitions.
>> >
>> > It handles all the pinconfigs that either ignore the argument, or have
>> > very simple one, like PIN_CONFIG_OUTPUT does.
>>
>> OK patches applied. It needs some rough fixes like NULL check
>> on kmalloc() but it'll do for a starter.
>
> gah, sorry ... I have urge to crawl under a rock now for forgetting something
> this obvious ;-) .
>
> Apart from the NULL check what more did I mess up? Should I send a fixup patch
> or do you want to do it?

I can fix this.

But now I just wondered about one thing:

Does this design imply that we will never be able to support any
more than 32 bits (well, the number of bits in unsigned long)
i.e. 32 different generic pin configurations?

In that case I suspect this might not be so wise. :-(

What about instead of using bitstuffed numbers using some
representation similar to what can be found in
Documentation/devicetree/bindings/pinctrl/ste,nomadik.txt

So instead of using <dt-bindings/pinctrl/pinconfig.h> and
enumerators it would be more like using node properties
like this:

my_config: my_config {
        bias-disable;
        drive-push-pull = <6>;
        output-high;
};

It will make the device trees bigger for sure, but maybe more
readable as well?

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ