Thread (16 messages) flat view 16 messages, 5 authors, 2021-08-23

Re: [PATCH] PCI: rockchip-dwc: Potential error pointer dereference in probe

From: Mark Brown <broonie@kernel.org>
Date: 2021-08-13 15:32:37
Also in: kernel-janitors, linux-pci, linux-rockchip

On Fri, Aug 13, 2021 at 04:00:45PM +0100, Robin Murphy wrote:
On 2021-08-13 15:32, Mark Brown wrote:
quoted
It also encourages *really* bad practice with error handling, and in
general there are few use cases for optional regulators where there's
not some other actions that need to be taken in the case where the
supply isn't there (elimintating some operating points or features,
reconfiguring power internally and so on).  If we genuninely don't need
to do anything special one wonders why we're trying to turn the power on
in the first place.
Sure, once you get into it, regulators are arguably a rather deeper area
than GPIOs, so in terms of the NULL-safe aspect anything beyond
enable/disable - for the sake of keeping trivial usage simple - would be
pretty questionable for sure.
enable and disable are among my biggest worries frankly, if the device
was supposed to have power and that didn't work then there's probably
some kind of issue.
A lot of the usage of regulator_get_optional() seems to be just making sure
some external thing is powered between probe() and remove() if it's not
hard-wired already, so maybe something like a
devm_regulator_get_optional_enabled() could be an answer to that argument
without even touching the underlying API.
I'm fairly sure a lot of the regulator_get_optional() usage is just
abuse of the API, every so often I get fed up enough to send patches
converting users that look like you describe to normal regulator API
calls.  People really don't get the dummy regulator stuff and seem to
think that _get_optional() is what you use to avoid writing any error
handling code :(
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help