On Wed, Jul 04, 2012 at 09:26:58PM +0900, Alex Courbot wrote: > On 07/04/2012 07:48 PM, Sascha Hauer wrote:>> + > > This looses several resources allocated earlier, like the enable gpio > > and the pwm. This is really bad here since I have no regulator specified > > and devm_regulator_get returns with -EPROBE_DEFER. Next time the core > > tries to probe the driver the driver bails out because the gpio and the > > pwm is already requested. > That's very bad indeed. I assumed that the kernel would free > devm-allocated resources after probe returned -EPROBE_DEFER, so that > probe could reallocate them the next time it is called. Apparently > that was wrong. Do you know what would the right approach be in this > case? Does the kernel preserve the device structure and its > associated data between the two calls to probe? If so, I could just > check whether the private data has already been constructed to know > which state we are in and continue from there. I'd really expect the devm_ functions to behave as you expect - if they don't currently we should probably fix them so that they do otherwise we're going to be in for a lot of surprises and probe deferral becomes a lot more cumbersome to use. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
