On Tue, Jul 10, 2018 at 7:56 PM Janusz Krzysztofik <jmkrzy...@gmail.com> wrote:
> > - .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
>
> This is OK but not enough for clean build of board-ams-delta.c when merged
> into current linux-next as one more struct fixed_voltage_config introduced
> there
> recently - keybrd_pwr_config - needs removal of .gpio member (respective
> lookup
> table with NULL function name is already there).
>
> > @@ -538,6 +546,7 @@ static struct gpiod_lookup_table
> > *ams_delta_gpio_tables[] __initdata = {
> > };
> >
> > static struct gpiod_lookup_table *late_gpio_tables[] __initdata = {
> > + &ams_delta_nreset_gpiod_table,
>
> That is also OK but may raise a conflict when merged into current linux-next
> where late_gpio_tables[] has been removed from board-ams-delta.c and its
> content integrated into ams_delta_gpio_tables[].
>
> > &ams_delta_lcd_gpio_table,
> > &ams_delta_nand_gpio_table,
> > };
>
> If that makes your life easier, I can prepare a fix for board-ams-delta.c on
> top of your patch. In that case you can add my:
> Reviewed-by: Janusz Krzysztofik <jmkrzy...@gmail.com>
Hm it's a bit of cross-tree conflict going on here I guess.
Do you have some idea about how serious the conflicts will be?
Is it just one patch to the ARM SoC OMAP tree or several?
It's a bit of Mark's pick, there are several ways to go about it:
1. Simply defer this to the next kernel cycle when your change is upstream
and avoid all fuzz (totally OK as long as one is not impatient).
I'm definately not in a hurry.
2. Mark applies this, conflicts appear in linux-next, you help Stephen
to solve it and later on Torvalds has to solve it. Then we need to
know how serious the conflicts are.
3. Apply this patch with fixes to the ARM SoC tree. Which makes it hard to
pull out so I'm not so sure about that.
4. An immutable branch with the ARM SoC change for Mark to pull
before applying this so I can rebase this patch on that.
5. Pick some patch from ARM SoC and apply it *also* to the regulator
tree and then this on top so I can rebase the changes and avoid
all conflicts. (We do this sometimes as some last resort.)
6. ...?
BTW I like your OMAP1 cleanups a lot!
Yours,
Linus Walleij
