Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1283768 > unrolled thread
| Started by | Mark Brown <broonie@kernel.org> |
|---|---|
| First post | 2015-12-04 13:10 +0100 |
| Last post | 2015-12-09 13:40 +0100 |
| Articles | 4 — 3 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.
Re: [PATCH v7 0/5] mfd: tps65912: Driver rewrite with DT support Mark Brown <broonie@kernel.org> - 2015-12-04 13:10 +0100
Re: [PATCH v7 0/5] mfd: tps65912: Driver rewrite with DT support "Andrew F. Davis" <afd@ti.com> - 2015-12-07 21:00 +0100
Re: [PATCH v7 0/5] mfd: tps65912: Driver rewrite with DT support Mark Brown <broonie@kernel.org> - 2015-12-08 20:20 +0100
Re: [PATCH v7 0/5] mfd: tps65912: Driver rewrite with DT support Linus Walleij <linus.walleij@linaro.org> - 2015-12-09 13:40 +0100
| From | Mark Brown <broonie@kernel.org> |
|---|---|
| Date | 2015-12-04 13:10 +0100 |
| Subject | Re: [PATCH v7 0/5] mfd: tps65912: Driver rewrite with DT support |
| Message-ID | <qBXlx-2ur-33@gated-at.bofh.it> |
[Multipart message — attachments visible in raw view] — view raw
On Tue, Nov 24, 2015 at 04:26:24PM +0000, Lee Jones wrote: > On Wed, 18 Nov 2015, Andrew F. Davis wrote: > > Documentation/devicetree/bindings/mfd/tps65912.txt | 50 ++ > > drivers/gpio/Kconfig | 2 +- > > drivers/gpio/gpio-tps65912.c | 317 ++++----- > > drivers/mfd/Kconfig | 20 +- > > drivers/mfd/Makefile | 3 +- > > drivers/mfd/tps65912-core.c | 290 ++++----- > > drivers/mfd/tps65912-i2c.c | 219 +++---- > > drivers/mfd/tps65912-irq.c | 217 ------- > > drivers/mfd/tps65912-spi.c | 219 +++---- > > drivers/regulator/Kconfig | 2 +- > > drivers/regulator/tps65912-regulator.c | 710 +++++---------------- > > include/linux/mfd/tps65912.h | 208 +++--- > Just waiting for the regulator Ack now, right? No, you also need to work out what to do about the GPIO driver not building in -next due to interface changes in gpiolib.
[toc] | [next] | [standalone]
| From | "Andrew F. Davis" <afd@ti.com> |
|---|---|
| Date | 2015-12-07 21:00 +0100 |
| Message-ID | <qDa6Z-st-5@gated-at.bofh.it> |
| In reply to | #1283768 |
On 12/04/2015 06:02 AM, Mark Brown wrote: > On Tue, Nov 24, 2015 at 04:26:24PM +0000, Lee Jones wrote: >> On Wed, 18 Nov 2015, Andrew F. Davis wrote: > >>> Documentation/devicetree/bindings/mfd/tps65912.txt | 50 ++ >>> drivers/gpio/Kconfig | 2 +- >>> drivers/gpio/gpio-tps65912.c | 317 ++++----- >>> drivers/mfd/Kconfig | 20 +- >>> drivers/mfd/Makefile | 3 +- >>> drivers/mfd/tps65912-core.c | 290 ++++----- >>> drivers/mfd/tps65912-i2c.c | 219 +++---- >>> drivers/mfd/tps65912-irq.c | 217 ------- >>> drivers/mfd/tps65912-spi.c | 219 +++---- >>> drivers/regulator/Kconfig | 2 +- >>> drivers/regulator/tps65912-regulator.c | 710 +++++---------------- >>> include/linux/mfd/tps65912.h | 208 +++--- > >> Just waiting for the regulator Ack now, right? > > No, you also need to work out what to do about the GPIO driver not > building in -next due to interface changes in gpiolib. > 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? -- 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] | [next] | [standalone]
| From | Mark Brown <broonie@kernel.org> |
|---|---|
| Date | 2015-12-08 20:20 +0100 |
| Message-ID | <qDvXP-6mP-3@gated-at.bofh.it> |
| In reply to | #1285878 |
[Multipart message — attachments visible in raw view] — view raw
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.
[toc] | [prev] | [next] | [standalone]
| From | Linus Walleij <linus.walleij@linaro.org> |
|---|---|
| Date | 2015-12-09 13:40 +0100 |
| Message-ID | <qDMci-8ov-3@gated-at.bofh.it> |
| In reply to | #1286782 |
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... 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