On Fri, Jan 06, 2017 at 11:54:38AM +0000, Jon Hunter wrote: > There is a case where a child regulator is registered before its supply > and when the supply is registered successfully, the supply for the child > is then set. Although, this in itself is not a problem, a problem arises > when the supply is then unregistered again, due to the parent device > being probed deferred, after successfully registering the supply. This > leaves the regulator with an invalid reference to supply and can > eventually result in a kernel panic. Why is a parent device doing this? This doesn't seem like safe or helpful behaviour and with probe deferral we'd generally expect the device to acquire resources before it starts making use of them. > Addtionally, even in the normal case when a regulator is unregistered, > by unloading a driver, if the regulator happens to be a supply for > another regulator it is not removed. We can't completely stop people doing this but we do make fairly strong efforts to stop people pulling in use devices. > Fix this by scanning all the registered regulators when a regulator is > removed and remove it as a supply to any other regulator. There is a > possibility that a child regulator is in use when the supply is removed > and so WARN if this happens. This seems like storing up trouble for the future, we'll end up with live child devices with parents that weren't around or being refcounted through some of the lifetime of the device which will doubtless come back and bite us later. > Note that the debugfs node for the regulator supply must be freed before > the debugfs node for the regulator_dev and so ensure the regulator_dev > debugfs node is freed after the any supplies have been removed. Please don't mix different changes into one commit, as covered in SubmittingPatches please send one patch per change. This makes things easier to
Attachment:
signature.asc
Description: PGP signature
