mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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"


  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®