| Message ID | 1412626635-7404-2-git-send-email-mpa@pengutronix.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Oct 06, 2014 at 10:17:11PM +0200, Markus Pargmann wrote: > Most drivers do not set the ena_gpio field of struct regulator_config > before passing it to the regulator core. This is fine as long as the > gpio identifier that is passed is a positive integer. But the gpio > identifier 0 is also valid. So we are not able to decide wether we got a > real gpio identifier or not. > > To be able to decide if it is a valid gpio that got passed, this patch > adds a ena_gpio_valid field that should be set if ena_gpio is a valid > gpio and should be used. It is a preperation patch for multiple patches > that adapt the drivers and fix the regulator core checks for this field. This should be part of the patch adding meaningful behaviour for the flag, it's pointless separately.
Hi, On Tue, Oct 07, 2014 at 12:53:35PM +0100, Mark Brown wrote: > On Mon, Oct 06, 2014 at 10:17:11PM +0200, Markus Pargmann wrote: > > Most drivers do not set the ena_gpio field of struct regulator_config > > before passing it to the regulator core. This is fine as long as the > > gpio identifier that is passed is a positive integer. But the gpio > > identifier 0 is also valid. So we are not able to decide wether we got a > > real gpio identifier or not. > > > > To be able to decide if it is a valid gpio that got passed, this patch > > adds a ena_gpio_valid field that should be set if ena_gpio is a valid > > gpio and should be used. It is a preperation patch for multiple patches > > that adapt the drivers and fix the regulator core checks for this field. > > This should be part of the patch adding meaningful behaviour for the > flag, it's pointless separately. I tried to keep the series bisectable while having different patches for the drivers and the core. By splitting this 'ena_gpio_valid' field into a seperate patch, the rest of the drivers will still compile and work until the core condition was changed to ena_gpio_valid. But I can squash the three patches into one. Best regards, Markus
On Tue, Oct 07, 2014 at 03:03:20PM +0200, Markus Pargmann wrote: > On Tue, Oct 07, 2014 at 12:53:35PM +0100, Mark Brown wrote: > > This should be part of the patch adding meaningful behaviour for the > > flag, it's pointless separately. > I tried to keep the series bisectable while having different patches for > the drivers and the core. By splitting this 'ena_gpio_valid' field into > a seperate patch, the rest of the drivers will still compile and work > until the core condition was changed to ena_gpio_valid. > But I can squash the three patches into one. No, I think this is missing the point a bit - if we need to introduce this such that all drivers are instantly buggy without an update that's probably an indication that we're introducing compatibility problems.
On Tue, Oct 07, 2014 at 05:19:33PM +0100, Mark Brown wrote: > On Tue, Oct 07, 2014 at 03:03:20PM +0200, Markus Pargmann wrote: > > On Tue, Oct 07, 2014 at 12:53:35PM +0100, Mark Brown wrote: > > > > This should be part of the patch adding meaningful behaviour for the > > > flag, it's pointless separately. > > > I tried to keep the series bisectable while having different patches for > > the drivers and the core. By splitting this 'ena_gpio_valid' field into > > a seperate patch, the rest of the drivers will still compile and work > > until the core condition was changed to ena_gpio_valid. > > > But I can squash the three patches into one. > > No, I think this is missing the point a bit - if we need to introduce > this such that all drivers are instantly buggy without an update that's > probably an indication that we're introducing compatibility problems. Yes, it was designed to not be compatible with the old way of setting up ena_gpio. But I think it shouldn't be a problem to get it backwads compatible. I will fix the series and send the next version with one core patch and another one which adds ena_gpio_valid to the drivers. Thanks, Markus
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h index bbe03a1924c0..c561f0faaf61 100644 --- a/include/linux/regulator/driver.h +++ b/include/linux/regulator/driver.h @@ -292,6 +292,8 @@ struct regulator_desc { * NULL). * @regmap: regmap to use for core regmap helpers if dev_get_regulator() is * insufficient. + * @ena_gpio_valid: GPIO controlling regulator enable is valid and should be + * used. * @ena_gpio: GPIO controlling regulator enable. * @ena_gpio_invert: Sense for GPIO enable control. * @ena_gpio_flags: Flags to use when calling gpio_request_one() @@ -303,6 +305,7 @@ struct regulator_config { struct device_node *of_node; struct regmap *regmap; + bool ena_gpio_valid; int ena_gpio; unsigned int ena_gpio_invert:1; unsigned int ena_gpio_flags;
Most drivers do not set the ena_gpio field of struct regulator_config before passing it to the regulator core. This is fine as long as the gpio identifier that is passed is a positive integer. But the gpio identifier 0 is also valid. So we are not able to decide wether we got a real gpio identifier or not. To be able to decide if it is a valid gpio that got passed, this patch adds a ena_gpio_valid field that should be set if ena_gpio is a valid gpio and should be used. It is a preperation patch for multiple patches that adapt the drivers and fix the regulator core checks for this field. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> --- include/linux/regulator/driver.h | 3 +++ 1 file changed, 3 insertions(+)