Messages in this thread | | | Date | Sat, 26 Sep 2015 21:30:59 +0200 | From | Olliver Schinagl <> | Subject | Re: gpios search behaviour for gpio from _DSD |
| |
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
| |