Hi Janusz,
On mer., juil. 18 2018, Janusz Krzysztofik <jmkrzy...@gmail.com> wrote:
> This is a follow up of initial submission of a series consisted of
> 6 changes, 3 of which have been already applied or reworkeed.
>
> V2 changelog:
> [PATCH 1/6] ARM: OMAP1: ams-delta: add GPIO lookup tables
> - already in mainline, commit 68e62a15a914
> [PATCH 2/6] Input: ams_delta_serio: use GPIO lookup table
> - reworked and submitted as a series, already in linux-omap,
> commit 68e62a15a914 ("ARM: OMAP1: ams-delta: drop GPIO lookup
> table for serio device") followed by 9 more
> [PATCH 3/6] ASoC: ams_delta: use GPIO lookup table
> - already in mainline, commit d65777d1a2cd
> [PATCH 4/6] fbdev: omapfb: lcd_ams_delta: use GPIO lookup table
> - resubmitting as [PATCH v2 1/3 v2]
> 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")
> and commit 8853daf3b4ac ("gpiolib: Defer on non-DT
> find_chip_by_name() failure") already in linux-next
> [PATCH 5/6] mtd: rawnand: ams-delta: use GPIO lookup table
> - resubmitting as [PATCH v2 2/3 v4]
> v2: Fix handling of devm_gpiod_get_optional() return values -
> thanks to Andy Shevchenko.
> v3: 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") and
> commit 8853daf3b4ac ("gpiolib: Defer on non-DT
> find_chip_by_name() failure") already in linux-next - thanks
> to Boris Brezillon
> v4: fix style issue - thanks to Boris Brezillon
> [PATCH 6/6] ARM: OMAP1: ams-delta: make board header file local to
> mach-omap1
> - resending as [PATCH v2 3/3]
>
> Dependency on commit 8853daf3b4ac ("gpiolib: Defer on non-DT
> find_chip_by_name() failure") is not critical - it is not needed for
> clean build or run, it only prevents from potential future changes to
> driver initializaton order during device_initcall.
>
> I'm submitting the three patches in series because the last one depends
> on the other two.
I think that being in CC in this series is a mistake as I don't see
anything related what I have done in this series.
Gregory
>
> Thanks,
> Janusz
>
--
Gregory Clement, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
