Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1292319 > unrolled thread

Re: [PATCH v7 0/5] mfd: tps65912: Driver rewrite with DT support

Started by"Andrew F. Davis" <afd@ti.com>
First post2015-12-15 17:20 +0100
Last post2015-12-22 10:20 +0100
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v7 0/5] mfd: tps65912: Driver rewrite with DT support "Andrew F. Davis" <afd@ti.com> - 2015-12-15 17:20 +0100
    Re: [PATCH v7 0/5] mfd: tps65912: Driver rewrite with DT support Linus Walleij <linus.walleij@linaro.org> - 2015-12-22 10:20 +0100

#1292319 — Re: [PATCH v7 0/5] mfd: tps65912: Driver rewrite with DT support

From"Andrew F. Davis" <afd@ti.com>
Date2015-12-15 17:20 +0100
SubjectRe: [PATCH v7 0/5] mfd: tps65912: Driver rewrite with DT support
Message-ID<qG0ut-6y5-13@gated-at.bofh.it>
On 12/09/2015 06:35 AM, Linus Walleij wrote:
> On Tue, Dec 8, 2015 at 8:16 PM, Mark Brown <broonie@kernel.org> wrote:
>> On Mon, Dec 07, 2015 at 01:58:47PM -0600, Andrew F. Davis wrote:
>>
>>> As all of this driver should be taken though the MFD tree how
>>> can this gpiolib change be handled? If we have gpio.parent it
>>> will not build on MFD, with gpio.dev it will fail to build when
>>> the changes are merged from the gpio subsystem. As the change
>>> has not been merged into linux-next as far a I can tell maybe
>>> this should be taken as is, then when the gpiolib change is
>>> made this can be changed with all the other drivers?
>>
>> Do a cross tree merge in one direction or the other between MFD and GPIO.
>
> If Lee makes an immutable branch with this stuff on it I can
> pull that in and put a fix on top of it (like I recently did with
> the ASoC AC97 codec). I have "only" renamed
> the .dev field of struct gpio_chip to .parent but I'm bombing
> out another 150 or so patches today, ridding all GPIO drivers
> in the kernel of container_of().
>
> A bit painful but nothing to what tglx has gone through for
> refactoring IRQ chips...
>

Is there anything I can do to help this along? This series
and the tps65086 series have been blocked for months on
trivial issues. (Not sure why the tps65086 hasn't been taken,
it doesn't have this problem, I'd be OK with this getting
stalled for a bit longer if someone could look at the other
one)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1296634

FromLinus Walleij <linus.walleij@linaro.org>
Date2015-12-22 10:20 +0100
Message-ID<qIrgT-23R-15@gated-at.bofh.it>
In reply to#1292319
On Tue, Dec 15, 2015 at 5:16 PM, Andrew F. Davis <afd@ti.com> wrote:

> Is there anything I can do to help this along? This series
> and the tps65086 series have been blocked for months on
> trivial issues. (Not sure why the tps65086 hasn't been taken,
> it doesn't have this problem, I'd be OK with this getting
> stalled for a bit longer if someone could look at the other
> one)

Lee can you merge the core driver if it's OK? Then we have
includes etc in place to merge subdrivers for the next merge
window.

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

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web