[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180717213736.3cd0a747@bbrezillon>
Date: Tue, 17 Jul 2018 21:37:36 +0200
From: Boris Brezillon <boris.brezillon@...tlin.com>
To: Janusz Krzysztofik <jmkrzyszt@...il.com>
Cc: Miquel Raynal <miquel.raynal@...tlin.com>,
Richard Weinberger <richard@....at>,
David Woodhouse <dwmw2@...radead.org>,
Brian Norris <computersforpeace@...il.com>,
Marek Vasut <marek.vasut@...il.com>,
Krzysztof Kozlowski <krzk@...nel.org>,
Vladimir Zapolskiy <vz@...ia.com>,
Gregory CLEMENT <gregory.clement@...tlin.com>,
Shreeya Patel <shreeya.patel23498@...il.com>,
Arvind Yadav <arvind.yadav.cs@...il.com>,
linux-mtd@...ts.infradead.org, linux-omap@...r.kernel.org,
linux-kernel@...r.kernel.org,
Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: [PATCH v3] mtd: rawnand: ams-delta: use GPIO lookup table
Hi Janusz,
On Mon, 9 Jul 2018 21:38:50 +0200
Janusz Krzysztofik <jmkrzyszt@...il.com> wrote:
> Now as Amstrad Delta board - the only user of this driver - provides
> GPIO lookup tables, switch from GPIO numbers to GPIO descriptors and
> use the table to locate required GPIO pins.
>
> Declare static variables for storing GPIO descriptors and replace
> gpio_ function calls with their gpiod_ equivalents.
>
> Pin naming used by the driver should be followed while respective GPIO
> lookup table is initialized by a board init code.
>
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@...il.com>
> ---
> Changlog:
> v1: Fix handling of devm_gpiod_get_optional() return values - thanks to
> Andy Shevchenko.
> v2: Remove problematic error code conversion, no longer needed if used
> on top of commit d08605a64e67 ("ARM: OMAP1: ams-delta: move late
> devices back to init_machine") already in linux-next and commit
> 8853daf3b4ac ("gpiolib: Defer on non-DT find_chip_by_name()
> failure") just applied to linux-gpio/devel.
Sorry, but we can't apply this patch now because of the dependency on
those 2 commits. I guess it's not a big issue if we defer it to 4.20.
Alternatively, we could consider queuing it to mtd/fixes after 4.19-rc1
is out, but we'll need a good reason to do that (like a regression
that this patch is supposed to fix). Note for your future contributions:
for this kind of cross-subsystem changes, it's better to let everything
go through a single tree (usually done by sending all patches in a
single series and explaining the dependencies between the patches in
the cover letter), but it's already too late here (I guess d08605a64e67
is in the omap tree and 8853daf3b4ac in the gpio one).
Regards,
Boris
Powered by blists - more mailing lists