>>> Thanks for the report! However, this has been reported earlier during >>> the v2 review [1]. This is also why a fix have been provided [2] earlier >>> today. Notice that shape of link->exit() found here is shared by other >>> Intel boards e.g.: SOF ones. In general, the initial discussion >>> regarding card->remove() revealed some 'probe vs remove' problems within >>> the framework. >>> >>> >>> [1]: >>> https://lore.kernel.org/alsa-devel/69e4263a-e036-cb21-2360-55b06600911e@xxxxxxxxx/ >>> >>> >>> [2]: >>> https://lore.kernel.org/alsa-devel/1cff4ac0-6d45-95e1-ed9f-6abaded3f8b7@xxxxxxxxx/T/#t >>> >> >> It's rather difficult to follow these changes and error reports buried >> in email report sent on a Sunday of a three-day week-end for me. >> I also had additional errors not reported, >> >> [ 36.125113] kernel: rt286 i2c-INT343A:00: ASoC: unknown pin HV >> [ 36.125128] kernel: rt286 i2c-INT343A:00: ASoC: unknown pin VREF >> [ 36.125130] kernel: rt286 i2c-INT343A:00: ASoC: unknown pin LDO1 >> [ 36.125921] kernel: rt286 i2c-INT343A:00: ASoC: DAPM unknown pin LDO1 >> >> it's unclear to me why a dailink change in a machine driver would cause >> such codec-side issues. >> >> If the changes in this 17-patch series need to be tied to a framework >> fix, you have to make the dependencies explicit and better yet provide a >> self-contained patch series that does not introduce a temporary >> regression, or introduce the framework change first and clearly describe >> the dependency in a longer Broadwell-specific patchset. This is an 8-yr >> old device, it shouldn't be that hard. > > > The last part is not helpful in solving the problem. > > This reply comments 00/17 whereas in fact you are speaking solely about > 16/17. Because of that I'm suggesting: leave that patch (the 16/17 one) > out when merging. It will be send later once link->exit() issue is dealt > with. All other patches are independent of either of changes. That's fine with me. It wasn't self-explanatory from this cover letter or your earlier answer that this patch 16 can be dropped for now. If that patch is omitted, feel free to add my Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> > Simultaneously the link->exit() fix, which is the fruit of this > discussion, is still valid and can be send as standalone patch - what is > already the case [1]. That's fine as well. What I was arguing on is the relationship between patchsets and dependencies, what you are suggesting is perfectly acceptable.
