linux-kernel - Re: [PATCH] pinctrl: bcm2835: make use of of_property_read_u32

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: <1364451516.15039.11.camel@gitbox>
Date:	Thu, 28 Mar 2013 19:18:36 +1300
From:	Tony Prisk <linux@...sktech.co.nz>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	linux-rpi-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pinctrl: bcm2835: make use of
 of_property_read_u32_index()

On Wed, 2013-03-27 at 23:09 -0600, Stephen Warren wrote:
> Use the new standard API of_property_read_u32_index() instead of open-
> coding it.
> 
> Signed-off-by: Stephen Warren <swarren@...dotorg.org>
> ---
> Note: This depends on the proposed patch "of: Add support for reading
> a u32 from a multi-value property" by Tony Prisk.
> 
> BTW, I realized why I didn't create that standard API, but wrote custom
> prop_u32() instead; the code has already looked up the properties, and
> validated their length, so prop_u32() can simply index into the property
> data, whereas of_property_read_u32_index() needs to go search for the
> property and re-validate it every time, so there's a bunch more overhead.
> It also means duplicating the property name, although I could use a
> define for that. I'm not entirely convinced that using this standard API
> is a win in this case. LinusW, Tony, what do you think?
> ---

When I was writing the function I had a similar thought about the fact
we need to work out the length first, which as you mentioned, requires
all the prior work on the property anyway.

I didn't bring it up, because I thought someone might say 'hey, you
should add a function to get the count as well' :)

In both the brcm and vt8500 use cases, we will have the issue of
multiple lookups on the same property using 'generic' functions. Price
we have to pay for generic code?

Regards
Tony P

--
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/