<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 28, 2014 at 5:53 PM, leroy christophe <span dir="ltr"><<a href="mailto:christophe.leroy@c-s.fr" target="_blank">christophe.leroy@c-s.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've been able to identify the origin of the issue. It happens since the below commit.<br>
Do you know what should be done to fix that ?<br>
<br>
Christophe<br></blockquote><div><br></div><div>Actually, more things are wrong with what the driver is doing.<br>If inside spi_add_device()  the call to device_add() fails, then that<br>code bails out without any call to spi_cleanup() and the same<br>
memory will leak (Is this intended?).<br><br></div><div>Basically, fsl_spi_setup allocates memory using devm_kzalloc, while<br></div><div>device_add expects that any memory allocated via this way is only<br>done in the device's probe function.<br>
<br></div><div>The simple fix would be to do a normal allocation (revert the patch) and<br>add a free to the cleanup() function. Unfortunately that doesn't fix the<br>memleak I mentioned above.<br><br></div><div>So, some outside-the-box thinking brings me to conclude that another way<br>
to fix this problem is to allocate the devm_kzalloc not on the device's resource<br>list but on the controller's resources (it's controller state after all...).<br></div><div><br></div><div>Regards,<br>Stijn<br>
</div></div></div></div>