On Thu, Aug 28, 2014 at 5:53 PM, leroy christophe <christophe.le...@c-s.fr> wrote: > > I've been able to identify the origin of the issue. It happens since the > below commit. > Do you know what should be done to fix that ? > > Christophe > >
Actually, more things are wrong with what the driver is doing. If inside spi_add_device() the call to device_add() fails, then that code bails out without any call to spi_cleanup() and the same memory will leak (Is this intended?). Basically, fsl_spi_setup allocates memory using devm_kzalloc, while device_add expects that any memory allocated via this way is only done in the device's probe function. The simple fix would be to do a normal allocation (revert the patch) and add a free to the cleanup() function. Unfortunately that doesn't fix the memleak I mentioned above. So, some outside-the-box thinking brings me to conclude that another way to fix this problem is to allocate the devm_kzalloc not on the device's resource list but on the controller's resources (it's controller state after all...). Regards, Stijn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
