[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 11 Nov 2016 12:32:11 -0800
From: Tony Lindgren <tony@...mide.com>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Haojian Zhuang <haojian.zhuang@...aro.org>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Grygorii Strashko <grygorii.strashko@...com>,
Nishanth Menon <nm@...com>,
"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linux-OMAP <linux-omap@...r.kernel.org>
Subject: Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs
* Tony Lindgren <tony@...mide.com> [161111 12:27]:
> * Linus Walleij <linus.walleij@...aro.org> [161111 12:17]:
> > On Tue, Oct 25, 2016 at 11:02 PM, Tony Lindgren <tony@...mide.com> wrote:
> >
> > > Having the pin control framework call pin controller functions
> > > before it's probe has finished is not nice as the pin controller
> > > device driver does not yet have struct pinctrl_dev handle.
> > >
> > > Let's fix this issue by adding deferred work for hogs. This is
> > > needed to be able to add pinctrl generic helper functions.
> > >
> > > Note that the pinctrl functions already take care of the necessary
> > > locking.
> > >
> > > Signed-off-by: Tony Lindgren <tony@...mide.com>
> >
> > I don't see why this is necessary?
>
> It's needed because the pin controller driver has not yet
> finished it's probe at this point. We end up calling functions
> in the device driver where no struct pinctrl_dev is yet known
> to the driver. Asking a device driver to do something before
> it's probe is done does not quite follow the Linux driver model :)
To clarify, that's an issue with multiple instances of the same
driver probing as there's no static pointer to driver specific
data.
Regards,
Tony
Powered by blists - more mailing lists