On Fri, Jan 1, 2016 at 3:27 PM, Matthias Brugger <matthias.bgg@xxxxxxxxx> wrote: > On January 1, 2016 3:56:01 AM EET, Daniel Kurtz <djkurtz@xxxxxxxxxxxx> wrote: >>> It's fairly clear that there's at least a case for simplifying the >>> existing practice here, for example by moving everything into a >>single >>> (perhaps aliased) initcall rather than by randomly picking a level >>per >>> system or by actually fiddling with the link ordering if the case is >>> sufficiently clear that pinctrl in general ought to load earlier than >>it >>> does. >> >>Nothing above sounds like a reason not to merge this patch, however. >>Why should we block useful patches that use existing tools to fix real >>architecture-specific issues until new infrastructure is merged that >>solves general problems? > > I think what Mark means is, that we define some pinctrl_initcall which > is a macro to subsys_initcall (or arch_initcall or similar). We apply this > to all pinctrl drivers including the one from Mediatek. This way at least > we have a common method and changing the behaviour in the future is > easier to handle. That would be pinctrl_soc_initcall() in that case. Just pinctrl_initcall() would assume it's for all drivers and there is a bunch of them that are just fine with simple device_initcall()s. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html