Hey Mika,
Thanks for your reply.
On 24-09-15 10:43, Mika Westerberg wrote:
On Thu, Sep 24, 2015 at 09:25:06AM +0200, Olliver Schinagl wrote:
Hey list, Mika,
With commit 0d9a693cc86 the following snippet of code was added:
+ /* Try first from _DSD */
+ for (i = 0; i < ARRAY_SIZE(suffixes); i++) {
+ if (con_id && strcmp(con_id, "gpios")) {
+ snprintf(propname, sizeof(propname), "%s-%s",
+ con_id, suffixes[i]);
and I was wondering why the gpios suffix is singled out. Are we not allowed
to check for all the strings in the suffixes array? Is gpios special or is
gpio simply not allowed. If that strcmp check would be removed, would bad
things happen?
We default to "gpios". So if you pass "reset" we actually look for
proprerty "reset-gpios". This is the recommend syntax AFAIK.
What i ment is, without strcmp, the loop would test for:
reset-gpio and then reset-gpios (and then gpio and gpios)
So why the strcmp at all, Why only reset-gpios? Will the _DSD or acpi
break and if we probe for reset-gpio (first, instead of reset-gpios)?
I'm asking because i'm trying some work on gpio lib and this section is
getting reworked too. While doing that I want to remove the strcmp.
Hence, the question if things break on the ACPI side (I'm mostly failiar
with OF.
Also, just to educate myself, isn't relying on left to right parsing
complier specifc? E.g. if con_id is null, we end up passing NULL to strcmp
and atleast for libc can cause segfaults iirc.
'&&' is so called short circuit operator so if we already know that
con_id is NULL we never evaluate the remaining conditions.
I just looked it up and of course you are right and I learned something new:
(4). Unlike the bitwise binary & operator, the && operator guarantees
left-to-right evaluation; there is a sequence point after the evaluation
of the first operand. If the first operand compares equal to 0, the
second operand is not evaluated.
So && is guaranteed left to right.
Olliver
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
