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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
