On Mon, Nov 26, 2018 at 10:53:40PM +0100, Linus Walleij wrote:
> The managed resources pretty much assume
> that you tie resources to the device model and let kref inside the
> kobject in struct device do all refcounting and that essentially
> collides with the refcounting inside the regulator cor
On Mon, Nov 26, 2018 at 10:53 PM Linus Walleij wrote:
> I suspect maybe the lesser evil is to bite the bullet, invent
> gpiod_get_from_of_node() which is the missing API (we currently
> only have devm_gpiod_get_from_of_node()) and simply
> fix up the converted regulator drivers to avoid devm_*
>
On Mon, Nov 26, 2018 at 10:53:40PM +0100, Linus Walleij wrote:
> On Fri, Nov 23, 2018 at 2:25 PM Mark Brown wrote:
> I suspect maybe the lesser evil is to bite the bullet, invent
> gpiod_get_from_of_node() which is the missing API (we currently
> only have devm_gpiod_get_from_of_node()) and simply
On Fri, Nov 23, 2018 at 2:25 PM Mark Brown wrote:
> The situation with descriptor based GPIOs is a bug - the reason why the
> core does the request in the legacy case is precisely the problem Linus
> identified. Once a GPIO is shared all the users of the GPIO need to
> coordinate with each other
On Mon, Nov 26, 2018 at 02:54:28PM +, Mark Brown wrote:
> On Mon, Nov 26, 2018 at 02:30:28PM +, Charles Keepax wrote:
>
> > Would there perhaps be milage in looking at just making
> > the regulator core request the GPIO, rather than the end
> > drivers? Gives us a single request/free point
On Mon, Nov 26, 2018 at 02:30:28PM +, Charles Keepax wrote:
> Would there perhaps be milage in looking at just making
> the regulator core request the GPIO, rather than the end
> drivers? Gives us a single request/free point. We don't need
> any special flags in the GPIO layer, as its just a s
On Mon, Nov 26, 2018 at 02:09:27PM +, Mark Brown wrote:
> On Mon, Nov 26, 2018 at 01:00:01PM +, Charles Keepax wrote:
> > On Fri, Nov 23, 2018 at 01:25:22PM +, Mark Brown wrote:
>
> > > help the multiple users find each other somehow. I think what we want
> > > to do here is either pu
On Mon, Nov 26, 2018 at 01:00:01PM +, Charles Keepax wrote:
> On Fri, Nov 23, 2018 at 01:25:22PM +, Mark Brown wrote:
> > help the multiple users find each other somehow. I think what we want
> > to do here is either push the gpiod requests into the regulator core or
> > change things so
On Fri, Nov 23, 2018 at 01:25:22PM +, Mark Brown wrote:
> On Fri, Nov 23, 2018 at 10:57:29AM +, Charles Keepax wrote:
>
> > It's fixing something in the case of two regulators using the
> > same GPIO. The direction this patch chain takes is that the end
> > drivers own the GPIOs not the re
On Fri, Nov 23, 2018 at 10:57:29AM +, Charles Keepax wrote:
> It's fixing something in the case of two regulators using the
> same GPIO. The direction this patch chain takes is that the end
> drivers own the GPIOs not the regulator core (except for the
> legacy case). So both of the end driver
On Fri, Nov 23, 2018 at 10:40:57AM +0100, Linus Walleij wrote:
> On Thu, Nov 22, 2018 at 6:30 PM Charles Keepax
> wrote:
>
> > Currently, a GPIO can be requested multiple times when the
> > NONEXCLUSIVE flag is set, however it must still be freed a single
> > time. This makes client code rather c
On Thu, Nov 22, 2018 at 6:30 PM Charles Keepax
wrote:
> Currently, a GPIO can be requested multiple times when the
> NONEXCLUSIVE flag is set, however it must still be freed a single
> time. This makes client code rather complex, since multiple drivers
> may request the GPIO but only a single one
Hi Charles,
On 2018-11-22 18:30, Charles Keepax wrote:
> Currently, a GPIO can be requested multiple times when the
> NONEXCLUSIVE flag is set, however it must still be freed a single
> time. This makes client code rather complex, since multiple drivers
> may request the GPIO but only a single one
13 matches
Mail list logo
