leandrof/linux
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

regulator: Documentation fix for regulator error notification helper

Browse Source 
The helper to send IRQ notification for regulator errors had still
old description mentioning calling BUG() as a last resort when
error status reading has kept failing for more times than a given
threshold.

The impementation calling BUG() did never end-up in-tree but was
replaced by hopefully more sophisticated handler trying to power-off
the system.

Fix the documentation to reflect actual behaviour.

Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20210823075651.GA3717293@localhost.localdomain
Signed-off-by: Mark Brown <broonie@kernel.org>
This commit is contained in:
Matti Vaittinen 2021-08-23 10:56:51 +03:00 committed by Mark Brown
parent c049742fbc
commit ad3ead1efe
No known key found for this signature in database
GPG Key ID: 24D68B725D5487D0
2 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
drivers/regulator/irq_helpers.c
View File

@ -184,7 +184,7 @@ static irqreturn_t regulator_notifier_isr(int irq, void *data)
* If retry_count exceeds the given safety limit we call IC specific die * If retry_count exceeds the given safety limit we call IC specific die
* handler which can try disabling regulator(s). * handler which can try disabling regulator(s).
* *
* If no die handler is given we will just bug() as a last resort. * If no die handler is given we will just power-off as a last resort.
* *
* We could try disabling all associated rdevs - but we might shoot * We could try disabling all associated rdevs - but we might shoot
* ourselves in the head and leave the problematic regulator enabled. So * ourselves in the head and leave the problematic regulator enabled. So

7
include/linux/regulator/driver.h
View File

@ -527,8 +527,8 @@ struct regulator_irq_data {
* active events as core does not clean the map data. * active events as core does not clean the map data.
* REGULATOR_FAILED_RETRY can be returned to indicate that the * REGULATOR_FAILED_RETRY can be returned to indicate that the
* status reading from IC failed. If this is repeated for * status reading from IC failed. If this is repeated for
* fatal_cnt times the core will call die() callback or BUG() * fatal_cnt times the core will call die() callback or power-off
* as a last resort to protect the HW. * the system as a last resort to protect the HW.
* @renable: Optional callback to check status (if HW supports that) before * @renable: Optional callback to check status (if HW supports that) before
* re-enabling IRQ. If implemented this should clear the error * re-enabling IRQ. If implemented this should clear the error
* flags so that errors fetched by regulator_get_error_flags() * flags so that errors fetched by regulator_get_error_flags()
@ -537,7 +537,8 @@ struct regulator_irq_data {
* REGULATOR_FAILED_RETRY can be returned to * REGULATOR_FAILED_RETRY can be returned to
* indicate that the status reading from IC failed. If this is * indicate that the status reading from IC failed. If this is
* repeated for 'fatal_cnt' times the core will call die() * repeated for 'fatal_cnt' times the core will call die()
* callback or BUG() as a last resort to protect the HW. * callback or if die() is not populated then attempt to power-off
* the system as a last resort to protect the HW.
* Returning zero indicates that the problem in HW has been solved * Returning zero indicates that the problem in HW has been solved
* and IRQ will be re-enabled. Returning REGULATOR_ERROR_ON * and IRQ will be re-enabled. Returning REGULATOR_ERROR_ON
* indicates the error condition is still active and keeps IRQ * indicates the error condition is still active and keeps IRQ