RE: [PATCH 1/3] pinctrl: Introduce PINCTRL_STATE_DEFAULT define,and use it

[Stephen Warren]

Linus Walleij wrote at Thursday, February 23, 2012 11:09 PM:
> On Fri, Feb 24, 2012 at 1:04 AM, Stephen Warren <swarren@xxxxxxxxxx> wrote:
> 
> > This provides a single centralized name for the default state.
> >
> > Update PIN_MAP_* macros to use this state name, instead of requiring the
> > user to pass a state name in.
> >
> > Update documentation and mapping tables to use this.
> >
> > Signed-off-by: Stephen Warren <swarren@xxxxxxxxxx>
> 
> I like the direction this is taking for sure. This is however not
> working because it break U300, no hogs nor device requests work
> after this patch so I cannot apply it.

Ah, I think I see what's happening.

Right now, pinctrl_hog_maps() iterates over every map entry, and when
it finds a hog entry, it tries to get() and enable() that one entry.
get() again iterates over the mapping table finding every entry with
the same name. This all works fine if every hog entry in the mapping
table for a given pin controller has a different name. However, this
patch changes the name field to PINCTRL_STATE_DEFAULT in all cases,
so the first get() finds 3 matching table entries and enables them all,
then the outer loop in pinctrl_hog_maps() finds the second table entry
and calls get() again which again finds all 3 entries and tries to
enable them all.

I think the fix for this is to replace the body of pinctrl_hog_maps()
with:

static int pinctrl_hog_maps(struct pinctrl_dev *pctldev)
{
        int ret;

        INIT_LIST_HEAD(&pctldev->pinctrl_hogs);

        mutex_lock(&pinctrl_maps_mutex);
        ret = pinctrl_hog_map(pctldev, PINCTRL_STATE_DEFAULT);
        mutex_unlock(&pinctrl_maps_mutex);

        return ret;
}

Does that work better? If so, I can fold it into the patch and repost,
or you can fix it up as you apply; whichever you wish.

-- 
nvpublic

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/