aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/regulator/lm363x-regulator.c
diff options
context:
space:
mode:
authorDmitry Torokhov <dmitry.torokhov@gmail.com>2019-09-04 14:42:00 -0700
committerMark Brown <broonie@kernel.org>2019-09-09 10:58:15 +0100
commitc0b913447b75538c3cf4b8016fd2e06509895020 (patch)
tree5d3e5ff2277b873387de2bab41addc78f7273050 /drivers/regulator/lm363x-regulator.c
parentMerge branch 'regulator-5.3' into regulator-5.4 (diff)
downloadlinux-dev-c0b913447b75538c3cf4b8016fd2e06509895020.tar.xz
linux-dev-c0b913447b75538c3cf4b8016fd2e06509895020.zip
regulator: slg51000: use devm_gpiod_get_optional() in probe
The CS GPIO line is clearly optional GPIO (and marked as such in the binding document) and we should handle it accordingly. The current code treats all errors as meaning that there is no GPIO defined, which is wrong, as it does not handle deferrals raised by the underlying code properly, nor does it recognize non-existing GPIO from any other initialization error. As far as I can see the only reason the driver, unlike all others, is using OF-specific devm_gpiod_get_from_of_node() so that it can assign a custom label to the selected GPIO line. Given that noone else needs that, it should not be doing that either. Let's switch to using more appropriate devm_gpiod_get_optional(). Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20190904214200.GA66118@dtor-ws Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'drivers/regulator/lm363x-regulator.c')
0 files changed, 0 insertions, 0 deletions