summaryrefslogtreecommitdiffstats
path: root/drivers/spmi
diff options
context:
space:
mode:
authorPhilipp Zabel <p.zabel@pengutronix.de>2017-07-12 17:51:22 +0200
committerPhilipp Zabel <p.zabel@pengutronix.de>2017-07-19 12:10:48 +0200
commit21240eb94f1f6df30aa88f7e7b754ed46024d666 (patch)
treeb81abf9a23450b19e795c5916c880643b8b397cb /drivers/spmi
parent17c82e206d2a3cd876b64921c59116f1ecdce6ad (diff)
downloadlinux-stable-21240eb94f1f6df30aa88f7e7b754ed46024d666.tar.gz
linux-stable-21240eb94f1f6df30aa88f7e7b754ed46024d666.tar.bz2
linux-stable-21240eb94f1f6df30aa88f7e7b754ed46024d666.zip
reset: make (de)assert report success for self-deasserting reset drivers
By now there are drivers using shared reset controls and (de)assert calls on platforms with self-deasserting reset lines and thus reset drivers that do not implement .assert() and .deassert(). As long as the initial state of the reset line is deasserted, there is no reason for a reset_control_assert call to return an error for shared reset controls, or for a reset_control_deassert call to return an error for either shared or exclusive reset controls: after a call to reset_control_deassert the reset line is guaranteed to be deasserted, and after a call to reset_control_assert it is valid for the reset line to stay deasserted for shared reset controls. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Diffstat (limited to 'drivers/spmi')
0 files changed, 0 insertions, 0 deletions