Re: [PATCH v2] ASoC: soc-core: Create device_link to ensure correct suspend order

[Richard Fitzgerald]

On 19/6/26 16:54, Charles Keepax wrote:
> On Fri, Jun 19, 2026 at 02:33:36PM +0100, Richard Fitzgerald wrote:
> > On 18/6/26 14:22, Marek Szyprowski wrote:
> > > On 18.06.2026 15:12, Richard Fitzgerald wrote:
> > > > On 18/6/26 13:58, Marek Szyprowski wrote:
> > > > > On 18.06.2026 13:22, Richard Fitzgerald wrote:
> > > > > > On 17/6/26 15:10, Marek Szyprowski wrote:
> > > > > > > On 11.06.2026 13:08, Richard Fitzgerald wrote:
> > > > Is the machine driver the parent of the codec driver?
> > >
> > > Yes, so this change fixes the issue:
> >
> > Right. I thought I'd tested that. But I haven't got any hardware that
> > uses that "for real", so obviously I messed up my testing there.
> >
> > It makes this whole device_link stuff less useful if you can't use it to
> > reorder a parent-child suspend order for when the parent-child
> > relationship isn't relevant to the order they should suspend.
>
> Yeah it is pretty confusing situation if the machine driver
> is the parent of the codec. What is the correct order for
> things to suspend in that case? I feel like probably the parent
> child relation takes precedent, but generally not making codecs
> children of the machine driver seems prudent.
>
> > If we skip entries that we can't re-order, is that simply adding
> > confusing complications and _mostly_ ASoC forces the correct order, but
> > in some cases it cannot and then it is up to those affected drivers to
> > figure it out themselves? Can we always guarantee that those drivers
> > will know which they are, or can it all break subtly because a driver
> > doesn't know that in some systems it becomes related to some other
> > driver?
>
> I dunno still feels like this change is an improvement to me. The
> core DAPM powers down the path, it needs the codecs available to
> do that. You fix some subtle issues just not all of them.
>
> > Mark - should we revert this because of too many corner cases in the
> > device_link code and go back to every codec driver with a system_suspend
> > installing its own device_link to ensure correct suspend order compared
> > to the machine driver?
>
> If you go back to this you still have a situation where ASoC
> mostly does the right order it just took you more code to get
> there. Also I think you would need to install the link from the
> machine driver, since the codec driver could be used in
> situations where it is or isn't a child of the machine driver, as
> you noted earlier.
>
> Personally I would vote for just skipping the case where the
> machine driver is a parent of the card.
>
> Thanks,
> Charles

We're still in the merge window, so it's not something anyone should be
using on critical hardware or daily driver PCs. We can think about it
for a few days.

We could also deal with the case that card->dev ==
component->dev->parent, then give some time for more people to test and
see if anything else breaks.