On Tue, Dec 8, 2015 at 8:16 PM, Mark Brown <broonie@xxxxxxxxxx> 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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
