Re: [PATCH v2 3/3] pinctrl / gpio: Introduce .set_config() callback for GPIO chips

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Tue, Jan 24, 2017 at 12:11 PM, Mika Westerberg
<mika.westerberg@xxxxxxxxxxxxxxx> wrote:
> On Mon, Jan 23, 2017 at 06:11:07PM +0100, Johan Hovold wrote:
>> On Mon, Jan 23, 2017 at 03:34:34PM +0300, Mika Westerberg wrote:
>> > Currently we already have two pin configuration related callbacks
>> > available for GPIO chips .set_single_ended() and .set_debounce(). In
>> > future we expect to have even more, which does not scale well if we need
>> > to add yet another callback to the GPIO chip structure for each possible
>> > configuration parameter.
>> >
>> > Better solution is to reuse what we already have available in the
>> > generic pinconf.
>> >
>> > To support this, we introduce a new .set_config() callback for GPIO
>> > chips. The callback takes a single packed pin configuration value as
>> > parameter. This can then be extended easily beyond what is currently
>> > supported by just adding new types to the generic pinconf enum.
>> >
>> > If the GPIO driver is backed up by a pinctrl driver the GPIO driver can
>> > just assign gpiochip_generic_config() (introduced in this patch) to
>> > .set_config and that will take care configuration requests are directed
>> > to the pinctrl driver.
>> >
>> > We then convert the existing drivers over .set_config() and finally
>> > remove the .set_single_ended() and .set_debounce() callbacks.
>> >
>> > Suggested-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
>> > Signed-off-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>
>> For greybus and USB serial:

>>
>> Acked-by: Johan Hovold <johan@xxxxxxxxxx>
>
> Thanks!
>
>> Note however that this patch fails to apply to linux-next (conflicts in
>> pinctrl as well as staging).
>
> Indeed, it does. I did the series on top of v4.10-rc5 but looks like
> there are some changes in linux-next that I missed.
>
> I'll rebase the series on top of linux-next and resend.

If the conflicts are just with the GPIO tree then the  "devel" branch
in the GPIO tree is what you should base it on.

If there are conflicts with other trees including pinctrl it should
probably be based on v4.10-rcN and end up in my face, in this case
maybe I should just make an immutable branch in the GPIO tree and
pull to both itself and pincontrol and resolve the conflicts if they are
clashing.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html