Message ID | 53FF5097.7090000@c-s.fr (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
On Thu, Aug 28, 2014 at 5:53 PM, leroy christophe <christophe.leroy@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-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/spi/spi-fsl-spi.c b/drivers/spi/spi-fsl-spi.c index b3e7775..98ccd23 100644 --- a/drivers/spi/spi-fsl-spi.c +++ b/drivers/spi/spi-fsl-spi.c @@ -431,7 +431,7 @@ static int fsl_spi_setup(struct spi_device *spi) return -EINVAL; if (!cs) { - cs = kzalloc(sizeof *cs, GFP_KERNEL); + cs = devm_kzalloc(&spi->dev, sizeof(*cs), GFP_KERNEL); if (!cs) return -ENOMEM; spi->controller_state = cs;