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...