| Message ID | 1449668342-4446-1-git-send-email-linus.walleij@linaro.org |
|---|---|
| State | New |
| Headers | show |
On Wed, Dec 09, 2015 at 02:39:02PM +0100, Linus Walleij wrote: > We're planning to remove the gpiochip_add() function to swith > to gpiochip_add_data() with NULL for data argument. > > Cc: Ralf Baechle <ralf@linux-mips.org> > Cc: linux-mips@linux-mips.org > Signed-off-by: Linus Walleij <linus.walleij@linaro.org> > --- > Ralf: please ACK this so I can take it through the GPIO tree. Acked-by: Ralf Baechle <ralf@linux-mips.org> > BTW: would be nice if the MIPS GPIO drivers could move down > to drivers/gpio in the long run. I agree - but for practical reasons this won't happen quickly. Ralf -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 9, 2015 at 2:39 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > --- > Ralf: please ACK this so I can take it through the GPIO tree. > BTW: would be nice if the MIPS GPIO drivers could move down > to drivers/gpio in the long run. Is there a specific reason? I have no objections to moving it, but on the other hand I also like that (in this case) most/all chip-specific code is grouped together and not scattered around the tree. Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 9, 2015 at 10:44 PM, Manuel Lauss <manuel.lauss@gmail.com> wrote: > On Wed, Dec 9, 2015 at 2:39 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > >> --- >> Ralf: please ACK this so I can take it through the GPIO tree. >> BTW: would be nice if the MIPS GPIO drivers could move down >> to drivers/gpio in the long run. > > Is there a specific reason? I have no objections to moving it, but > on the other hand I also like that (in this case) most/all chip-specific > code is grouped together and not scattered around the tree. Here is a reason. This patch series. If I could just change all that and have the dependencies inside the GPIO tree, refactoring struggles would be so much easier. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/mips/alchemy/common/gpiolib.c b/arch/mips/alchemy/common/gpiolib.c index f9bc4f520440..e2606f8eb2fa 100644 --- a/arch/mips/alchemy/common/gpiolib.c +++ b/arch/mips/alchemy/common/gpiolib.c @@ -160,14 +160,14 @@ static int __init alchemy_gpiochip_init(void) switch (alchemy_get_cputype()) { case ALCHEMY_CPU_AU1000: - ret = gpiochip_add(&alchemy_gpio_chip[0]); + ret = gpiochip_add_data(&alchemy_gpio_chip[0], NULL); break; case ALCHEMY_CPU_AU1500...ALCHEMY_CPU_AU1200: - ret = gpiochip_add(&alchemy_gpio_chip[0]); - ret |= gpiochip_add(&alchemy_gpio_chip[1]); + ret = gpiochip_add_data(&alchemy_gpio_chip[0], NULL); + ret |= gpiochip_add_data(&alchemy_gpio_chip[1], NULL); break; case ALCHEMY_CPU_AU1300: - ret = gpiochip_add(&au1300_gpiochip); + ret = gpiochip_add_data(&au1300_gpiochip, NULL); break; } return ret;
We're planning to remove the gpiochip_add() function to swith to gpiochip_add_data() with NULL for data argument. Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> --- Ralf: please ACK this so I can take it through the GPIO tree. BTW: would be nice if the MIPS GPIO drivers could move down to drivers/gpio in the long run. --- arch/mips/alchemy/common/gpiolib.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)