All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Linus Walleij <linus.walleij@linaro.org>,
	Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	Ludovic Desroches <ludovic.desroches@atmel.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/2] get pinctrl more flexible for per pin muxing controllers
Date: Wed, 10 Jun 2015 08:14:50 -0600	[thread overview]
Message-ID: <5578465A.9090503@wwwdotorg.org> (raw)
In-Reply-To: <CACRpkdawFrfzHf+8vMLz07-r4J48bAVibV++K31dNQ+D-85ZMg@mail.gmail.com>

On 06/10/2015 01:33 AM, Linus Walleij wrote:
> On Wed, Jun 3, 2015 at 3:31 PM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>> Le 04/05/2015 10:56, Ludovic Desroches a écrit :
>>>
>>> The way pins, groups and functions are tied is too constraining for some
>>> controllers. It concerns mainly the ones we don't care about groups and
>>> functions, each pin can be muxed to any functions.
>>> The goal of these two patches is too remove some of the constraints.
>>>
>>> I have added the prototype of a pin controller and device tree to show the
>>> way I want to use these changes. I couldn't test it on boards using generic
>>> pinconf so I am not sure that I don't break something...
>>>
>>>
>>> Ludovic Desroches (4):
>>>    pinctrl: change function behavior for per pin muxing controllers
>>>    pinctrl: introduce complex pin description
>>
>> Linus,
>>
>> Ludovic sent this series nearly one month ago. It was posted after a RFC
>> series on the same topic two months ago. As we don't see any comment on
>> neither of them we assume that it's okay to include them.
>
> It's a quite big patch and I need help reviewing it and thinking of
> some possible consequences.
>
> Stephen, can you give me a hand with this?

I don't have the patch in my list archive, which goes back 60 days.

Judging purely by the patch description, the patch sounds incorrect. 
There's nothing in pinctrl that prevents a particular pin controller 
from supporting all mux functions on all pins or groups. Simply return 
the same list of functions for every pin.
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/2] get pinctrl more flexible for per pin muxing controllers
Date: Wed, 10 Jun 2015 08:14:50 -0600	[thread overview]
Message-ID: <5578465A.9090503@wwwdotorg.org> (raw)
In-Reply-To: <CACRpkdawFrfzHf+8vMLz07-r4J48bAVibV++K31dNQ+D-85ZMg@mail.gmail.com>

On 06/10/2015 01:33 AM, Linus Walleij wrote:
> On Wed, Jun 3, 2015 at 3:31 PM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>> Le 04/05/2015 10:56, Ludovic Desroches a ?crit :
>>>
>>> The way pins, groups and functions are tied is too constraining for some
>>> controllers. It concerns mainly the ones we don't care about groups and
>>> functions, each pin can be muxed to any functions.
>>> The goal of these two patches is too remove some of the constraints.
>>>
>>> I have added the prototype of a pin controller and device tree to show the
>>> way I want to use these changes. I couldn't test it on boards using generic
>>> pinconf so I am not sure that I don't break something...
>>>
>>>
>>> Ludovic Desroches (4):
>>>    pinctrl: change function behavior for per pin muxing controllers
>>>    pinctrl: introduce complex pin description
>>
>> Linus,
>>
>> Ludovic sent this series nearly one month ago. It was posted after a RFC
>> series on the same topic two months ago. As we don't see any comment on
>> neither of them we assume that it's okay to include them.
>
> It's a quite big patch and I need help reviewing it and thinking of
> some possible consequences.
>
> Stephen, can you give me a hand with this?

I don't have the patch in my list archive, which goes back 60 days.

Judging purely by the patch description, the patch sounds incorrect. 
There's nothing in pinctrl that prevents a particular pin controller 
from supporting all mux functions on all pins or groups. Simply return 
the same list of functions for every pin.

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Linus Walleij <linus.walleij@linaro.org>,
	Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	Ludovic Desroches <ludovic.desroches@atmel.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/2] get pinctrl more flexible for per pin muxing controllers
Date: Wed, 10 Jun 2015 08:14:50 -0600	[thread overview]
Message-ID: <5578465A.9090503@wwwdotorg.org> (raw)
In-Reply-To: <CACRpkdawFrfzHf+8vMLz07-r4J48bAVibV++K31dNQ+D-85ZMg@mail.gmail.com>

On 06/10/2015 01:33 AM, Linus Walleij wrote:
> On Wed, Jun 3, 2015 at 3:31 PM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>> Le 04/05/2015 10:56, Ludovic Desroches a écrit :
>>>
>>> The way pins, groups and functions are tied is too constraining for some
>>> controllers. It concerns mainly the ones we don't care about groups and
>>> functions, each pin can be muxed to any functions.
>>> The goal of these two patches is too remove some of the constraints.
>>>
>>> I have added the prototype of a pin controller and device tree to show the
>>> way I want to use these changes. I couldn't test it on boards using generic
>>> pinconf so I am not sure that I don't break something...
>>>
>>>
>>> Ludovic Desroches (4):
>>>    pinctrl: change function behavior for per pin muxing controllers
>>>    pinctrl: introduce complex pin description
>>
>> Linus,
>>
>> Ludovic sent this series nearly one month ago. It was posted after a RFC
>> series on the same topic two months ago. As we don't see any comment on
>> neither of them we assume that it's okay to include them.
>
> It's a quite big patch and I need help reviewing it and thinking of
> some possible consequences.
>
> Stephen, can you give me a hand with this?

I don't have the patch in my list archive, which goes back 60 days.

Judging purely by the patch description, the patch sounds incorrect. 
There's nothing in pinctrl that prevents a particular pin controller 
from supporting all mux functions on all pins or groups. Simply return 
the same list of functions for every pin.

  reply	other threads:[~2015-06-10 14:14 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-04  8:56 [PATCH 0/2] get pinctrl more flexible for per pin muxing controllers Ludovic Desroches
2015-05-04  8:56 ` Ludovic Desroches
2015-05-04  8:56 ` Ludovic Desroches
2015-05-04  8:56 ` [PATCH 1/2] pinctrl: change function behavior " Ludovic Desroches
2015-05-04  8:56   ` Ludovic Desroches
2015-05-04  8:56   ` Ludovic Desroches
     [not found] ` <1430729776-27797-1-git-send-email-ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2015-05-04  8:56   ` [PATCH 2/2] pinctrl: introduce complex pin description Ludovic Desroches
2015-05-04  8:56     ` Ludovic Desroches
2015-05-04  8:56     ` Ludovic Desroches
2015-05-04  8:56   ` [PROTO] pinctrl: rough draft for a future controller Ludovic Desroches
2015-05-04  8:56     ` Ludovic Desroches
2015-05-04  8:56     ` Ludovic Desroches
2015-05-04  8:56   ` [PROTO] ARM: at91/dt: proto dt Ludovic Desroches
2015-05-04  8:56     ` Ludovic Desroches
2015-05-04  8:56     ` Ludovic Desroches
2015-06-03 13:31 ` [PATCH 0/2] get pinctrl more flexible for per pin muxing controllers Nicolas Ferre
2015-06-03 13:31   ` Nicolas Ferre
2015-06-03 13:31   ` Nicolas Ferre
     [not found]   ` <556F01CC.8020305-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2015-06-10  7:33     ` Linus Walleij
2015-06-10  7:33       ` Linus Walleij
2015-06-10  7:33       ` Linus Walleij
2015-06-10 14:14       ` Stephen Warren [this message]
2015-06-10 14:14         ` Stephen Warren
2015-06-10 14:14         ` Stephen Warren
2015-06-10 15:00         ` Ludovic Desroches
2015-06-10 15:00           ` Ludovic Desroches
2015-06-10 15:00           ` Ludovic Desroches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5578465A.9090503@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ludovic.desroches@atmel.com \
    --cc=nicolas.ferre@atmel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.