Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

On Mon, Jan 15, 2018 at 5:22 PM, Ludovic Desroches wrote: > Add a consumer variant to GPIO request relative functions. The goal > is to fix the bad ownership, which is arbitrary set to > "range->name:gpio", of a GPIO. For this patch on its own (apart from the

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

On Mon, Jan 15, 2018 at 5:22 PM, Ludovic Desroches wrote: > Add a consumer variant to GPIO request relative functions. The goal > is to fix the bad ownership, which is arbitrary set to > "range->name:gpio", of a GPIO. For this patch on its own (apart from the context): I what you want to

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

On Wed, Jan 17, 2018 at 06:07:02PM +0200, Andy Shevchenko wrote: > On Wed, Jan 17, 2018 at 4:54 PM, Ludovic Desroches > wrote: > > On Tue, Jan 16, 2018 at 04:33:29PM +0200, Andy Shevchenko wrote: > > >> First of all, the main architectural issue with current pin

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

On Wed, Jan 17, 2018 at 06:07:02PM +0200, Andy Shevchenko wrote: > On Wed, Jan 17, 2018 at 4:54 PM, Ludovic Desroches > wrote: > > On Tue, Jan 16, 2018 at 04:33:29PM +0200, Andy Shevchenko wrote: > > >> First of all, the main architectural issue with current pin control > >> design is so called

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

On Wed, Jan 17, 2018 at 4:54 PM, Ludovic Desroches wrote: > On Tue, Jan 16, 2018 at 04:33:29PM +0200, Andy Shevchenko wrote: >> First of all, the main architectural issue with current pin control >> design is so called "states". It's quite artificial entity which

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

On Wed, Jan 17, 2018 at 4:54 PM, Ludovic Desroches wrote: > On Tue, Jan 16, 2018 at 04:33:29PM +0200, Andy Shevchenko wrote: >> First of all, the main architectural issue with current pin control >> design is so called "states". It's quite artificial entity which is >> not represented by

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

On Tue, Jan 16, 2018 at 04:33:29PM +0200, Andy Shevchenko wrote: > On Tue, Jan 16, 2018 at 11:01 AM, Ludovic Desroches > wrote: > > On Mon, Jan 15, 2018 at 10:19:39PM +0200, Andy Shevchenko wrote: > >> On Mon, Jan 15, 2018 at 6:22 PM, Ludovic Desroches > >>

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

On Tue, Jan 16, 2018 at 04:33:29PM +0200, Andy Shevchenko wrote: > On Tue, Jan 16, 2018 at 11:01 AM, Ludovic Desroches > wrote: > > On Mon, Jan 15, 2018 at 10:19:39PM +0200, Andy Shevchenko wrote: > >> On Mon, Jan 15, 2018 at 6:22 PM, Ludovic Desroches > >> wrote: > >> > >> Did I miss cover

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

On Tue, Jan 16, 2018 at 11:01 AM, Ludovic Desroches wrote: > On Mon, Jan 15, 2018 at 10:19:39PM +0200, Andy Shevchenko wrote: >> On Mon, Jan 15, 2018 at 6:22 PM, Ludovic Desroches >> wrote: >> >> Did I miss cover letter for this?

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

On Tue, Jan 16, 2018 at 11:01 AM, Ludovic Desroches wrote: > On Mon, Jan 15, 2018 at 10:19:39PM +0200, Andy Shevchenko wrote: >> On Mon, Jan 15, 2018 at 6:22 PM, Ludovic Desroches >> wrote: >> >> Did I miss cover letter for this? > It seems: https://lkml.org/lkml/2018/1/15/841 >> > Add a

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

Hi, On Mon, Jan 15, 2018 at 10:19:39PM +0200, Andy Shevchenko wrote: > On Mon, Jan 15, 2018 at 6:22 PM, Ludovic Desroches > wrote: > > Did I miss cover letter for this? > It seems: https://lkml.org/lkml/2018/1/15/841 > > Add a consumer variant to GPIO request

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

Hi, On Mon, Jan 15, 2018 at 10:19:39PM +0200, Andy Shevchenko wrote: > On Mon, Jan 15, 2018 at 6:22 PM, Ludovic Desroches > wrote: > > Did I miss cover letter for this? > It seems: https://lkml.org/lkml/2018/1/15/841 > > Add a consumer variant to GPIO request relative functions. The goal > >

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

On Mon, Jan 15, 2018 at 6:22 PM, Ludovic Desroches wrote: Did I miss cover letter for this? > Add a consumer variant to GPIO request relative functions. The goal > is to fix the bad ownership, which is arbitrary set to > "range->name:gpio", of a GPIO. Hmm...

Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

On Mon, Jan 15, 2018 at 6:22 PM, Ludovic Desroches wrote: Did I miss cover letter for this? > Add a consumer variant to GPIO request relative functions. The goal > is to fix the bad ownership, which is arbitrary set to > "range->name:gpio", of a GPIO. Hmm... It's supposed to be name of the

[RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

Add a consumer variant to GPIO request relative functions. The goal is to fix the bad ownership, which is arbitrary set to "range->name:gpio", of a GPIO. There is a lack of configuration features for GPIO. For instance, we can't set the bias. Some pin controllers manage both device's pins and

[RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

Add a consumer variant to GPIO request relative functions. The goal is to fix the bad ownership, which is arbitrary set to "range->name:gpio", of a GPIO. There is a lack of configuration features for GPIO. For instance, we can't set the bias. Some pin controllers manage both device's pins and

[RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

Add a consumer variant to GPIO request relative functions. The goal is to fix the bad ownership, which is arbitrary set to "range->name:gpio", of a GPIO. There is a lack of configuration features for GPIO. For instance, we can't set the bias. Some pin controllers manage both device's pins and

[RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

Add a consumer variant to GPIO request relative functions. The goal is to fix the bad ownership, which is arbitrary set to "range->name:gpio", of a GPIO. There is a lack of configuration features for GPIO. For instance, we can't set the bias. Some pin controllers manage both device's pins and