On Wed, Aug 13, 2014 at 6:16 PM, Grygorii Strashko <grygorii.strashko@xxxxxx> wrote: > Some SoCs (like Keystone) may require to perform special > sequence of operations to assign output GPIO value, so default > implementation of .set() callback from gpio-syscon driver > can't be used. > > Hence, add optional, SoC specific callback to assign output > gpio value. > > Signed-off-by: Grygorii Strashko <grygorii.strashko@xxxxxx> Hm :-/ I didn't realize this wasn't a quite so straight-forward a syscon GPIO driver. Now I start to think that it looks kludgy to bolt this onto the other driver and think we may need to go back to the other version which puts it as a separate driver. I guess that is what you refer to as v1? I have a hard time to make my mind up about these syscon things, sorry :-( Now I have to ask you: which way do you prefer to do it, if you can choose freely? The initial driver or augmenting the syscon driver (patch v1)? 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