OMAP 4430 SDP: rather sick with recent kernels

[Peter Rosin]

Russel King wrote:
*snip*
> Now, we have this call to snd_soc_of_parse_audio_routing(), which
> allocates some memory, copies the old routes into it, and then adds
> to them from DT.  That explains why the pointer and number of routes
> are different - there's 19 routes in omap4-sdp.dts - 17 + 19 = 36.
> So that doesn't work - but importantly, it does point towards a
> possible culpret - snd_soc_of_parse_audio_routing().
> 
> This is obvious when you stop and think about what it's doing, this is
> truely where this bug lies, and it /is/ in generic ASoC code.
> 
> The problem is that this function doesn't consider the implications of
> deferred probing.  Let's see what happens if we defer, and re-do the
> ABE initialisation, including calling this function:
> 
> 17 + 19 = 36. - first probe
> 17 + 19 + 19 = 55. - second probe
> 
> Oh - that works in terms of the number, and it would also explain why
> the table has been screwed - because the second time we memcpy(), we're
> memcpy()ing from data which was allocated via devm_kzalloc(), and thus
> would have been freed after the first failed probe.
> 
> Mark - this is a core ASoC problem.

Sorry about this, I wasn't even aware of deferred probing when I wrote
f8781db8aeb1. From my point of view, it is certainly possible to solve this
in the card driver which needs to add card dapm routes instead. So, a
revert is fine by me, if no better solution comes up.

Cheers,
Peter