From: Richard Fitzgerald <rf@opensource.cirrus.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
patches@opensource.cirrus.com
Subject: Re: [PATCH] ASoC: soc-core: Create device_link to ensure correct suspend order
Date: Tue, 2 Jun 2026 14:55:09 +0100 [thread overview]
Message-ID: <e2e34915-1194-4965-b02d-4e64b44a2701@opensource.cirrus.com> (raw)
In-Reply-To: <b9c0e5b3-13fa-4139-815f-5652ff494031@sirena.org.uk>
On 02/06/2026 2:46 pm, Mark Brown wrote:
> On Tue, Jun 02, 2026 at 02:34:53PM +0100, Richard Fitzgerald wrote:
>> On 02/06/2026 2:31 pm, Mark Brown wrote:
>
>>> Do we still have devices registering separate components with the same
>>> device for DMA and DAI operations? They'd end up duplicating the links
>>> here.
>
>> Ok, weird, but I agree it's possible for one driver to register multiple
>> components. I'll make a V2 that skips the device link if the component
>> dev is the same as the card dev.
>
> That wouldn't avoid the issue I think? The card is a separate device,
> but the DMA and DAI are two devices registered separately. This used to
> be because we had completely separate driver types for DMA and DAI,
> prior to the component refactoring. A simple move to component would
> keep two separate components, this could be refactored into a single
> component but that'd need to actually happen and I'm not sure we did
> that for everything. I was wondering if you'd checked already, sounds
> like no?
Oh, you mean two components with the same dev, so that the
device_link_add() gets called for the same (card,component) devices
multiple times?
I tested multiple calls for the same device pair, and it's ok.
This also covers the case where ASoC core now creates this device_link
and the codec driver also creates the same device_link between the
card and itself (hdac_hdmi does this).
From the kernel doc for device_link_add():
"if a device link between the given @consumer and @supplier pair
exists already when this function is called for them, the existing link
will be returned"
next prev parent reply other threads:[~2026-06-02 13:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 14:28 Richard Fitzgerald
2026-06-02 8:46 ` Charles Keepax
2026-06-02 13:31 ` Mark Brown
2026-06-02 13:34 ` Richard Fitzgerald
2026-06-02 13:46 ` Mark Brown
2026-06-02 13:55 ` Richard Fitzgerald [this message]
2026-06-02 14:52 ` Mark Brown
2026-06-05 8:55 ` Richard Fitzgerald
2026-06-05 16:32 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e2e34915-1194-4965-b02d-4e64b44a2701@opensource.cirrus.com \
--to=rf@opensource.cirrus.com \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=patches@opensource.cirrus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®