[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdbrPf0Tomq7PWWoTbAUss+D8qVWctE_mPg9SkZu=JtLkQ@mail.gmail.com>
Date: Tue, 14 Mar 2017 10:49:37 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Cc: Benjamin Tissoires <benjamin.tissoires@...hat.com>,
"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Linux Input <linux-input@...r.kernel.org>,
Darren Hart <dvhart@...radead.org>,
platform-driver-x86 <platform-driver-x86@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 0/4] gpio: make gpiod_count() API consistent
On Tue, Feb 28, 2017 at 10:48 AM, Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
> On Mon, 2017-02-27 at 09:27 +0100, Benjamin Tissoires wrote:
>> On Feb 20 2017 or thereabouts, Andy Shevchenko wrote:
>> > There are three possibilities in gpiod_count(): ACPI, OF, and
>> > platform data.
>> >
>> > Some of them return 0, which requires to be handled separately,
>> > though
>> > developers rather lazy and just shadow an actual error code.
>> >
>> > Let's make this API consistent by not allowing 0 in returned value.
>> >
>> > There are luckily only 3 users right now, one of them handles this
>> > properly, the rest is converted in this series.
>> >
>> > Series is supposed to go through GPIO tree.
>> >
>> > Andy Shevchenko (4):
>> > gpio: acpi: Don't return 0 on acpi_gpio_count()
>> > gpio: of: Don't return 0 on dt_gpio_count()
>> > platform/x86: surface3_button: Propagate error from gpiod_count()
>> > Input: soc_button_array - Propagate error from gpiod_count()
>>
>> Not sure if this still matters, but still:
>> Acked-by: Benjamin Tissoires <benjamin.tissoires@...hat.com>
>
> I'm sure it is.
>
> Linus, is your plan to go through queue after merge window is closed?
Yes sorry for the delay, it was a busy merge window etc.
I'd like to have some nod from Mika/Rafael that this is what
we want to do. If I don't hear anything I guess I will just
merge them, it looks right to me.
Yours,
Linus Walleij
Powered by blists - more mailing lists