On pią, 2014-10-31 at 10:32 +0000, Mark Brown wrote: > On Fri, Oct 31, 2014 at 08:51:38AM +0100, Krzysztof Kozlowski wrote: > > > However new DT style parsing (regulator_of_get_init_data()) does the > > basic parsing stuff and this removes a lot of code from driver. The > > driver no longer parses all regulaotrs but the regulator core does it. > > Unfortunately regulator core does not parse custom bindings (like such > > GPIOs) so I would have to iterate once again through all regulators just > > to find "gpios" property. > > We could always add a callback for the driver to handle any custom > properties... one of the advantages of an OS like Linux is that we can > improve the core code. I thought about this - adding a callback, called on each child in regulator_of_get_init_data(). However the reason behind this callback is to parse GPIO and set config.ena_gpio. However in that context the regulator_config is const so the callback cannot change it. Unless it casts it to non-const... which isn't what we want I think. So now I wonder whether adding generic bindings for ena_gpio make sense. These would look like bindings for fixed-regulator (with "ena-" prefix). Unfortunately this would duplicate a little the ena_gpio in regulator_config... but to me it seems more appropriate. What do you think about adding generic bindings for ena_gpio? Best regards, Krzysztof -- 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
