linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthias Reichl <hias@horus.com>
To: Mark Brown <broonie@kernel.org>
Cc: Jon Hunter <jonathanh@nvidia.com>,
	alsa-devel@alsa-project.org,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Marcel Ziswiler <marcel.ziswiler@toradex.com>,
	Takashi Iwai <tiwai@suse.com>,
	linux-kernel@vger.kernel.org,
	Marcel Ziswiler <marcel@ziswiler.com>,
	linux-tegra@vger.kernel.org
Subject: Re: [alsa-devel] [PATCH v1 3/3] ASoC: soc-core: fix platform name vs. of_node assignement
Date: Tue, 18 Dec 2018 18:40:40 +0100	[thread overview]
Message-ID: <20181218174040.k7u26vnnoplllnwb@camel2.lan> (raw)
In-Reply-To: <20181021112301.GC8554@sirena.org.uk>

Hi Mark,

On Sun, Oct 21, 2018 at 12:23:01PM +0100, Mark Brown wrote:
> On Fri, Oct 19, 2018 at 11:22:46AM +0100, Jon Hunter wrote:
> 
> > Looking at snd_soc_init_platform(), it seems that the platform pointer
> > can be allocated by the machine driver and so if it is not allocated by
> > the core, then I don't think we should clear it here. Seems we need a
> > way to determine if this was allocated by the core.
> 
> Indeed, this is a bit of a mess.  We probably shouldn't be modifying the
> data that the drivers passed in, otherwise we get into trouble like
> this.   That suggests that we should copy the data, probably all of it.
> I will try to have a proper look at this next week.

did you find the time to look into this?

The downstream Raspberry Pi kernel contains a bunch of machine drivers
that are implemented in a similar way as the tegra_sgtl5000 driver
(static card and dai link structs, dai_link->platform_of_node filled
in from device tree) which are breaking in 4.20 on deferred probing.

Switching these drivers to dynamically allocated dai link structs,
like 76836fd35492 "ASoC: omap-abe-twl6040: Fix missing audio card
caused by deferred probing" would be a possibility, but if there's
some solution on the horizon that doesn't require changes to the
driver code it'd be easier to wait for that.

so long,

Hias

> > Furthermore, it seems that it is possible that there is more than one
> > link that might be to be cleared.
> 
> Yes, that's an issue as well.



> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel


  reply	other threads:[~2018-12-18 17:47 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-18 11:18 [PATCH v1 0/3] ASoC: last minute fixes Marcel Ziswiler
2018-10-18 11:18 ` [PATCH v1 1/3] ASoC: tegra_sgtl5000: fix device_node refcounting Marcel Ziswiler
2018-10-18 11:18 ` [PATCH v1 2/3] ASoC: soc-core: fix trivial checkpatch issues Marcel Ziswiler
2018-10-19 12:26   ` Applied "ASoC: soc-core: fix trivial checkpatch issues" to the asoc tree Mark Brown
2018-10-19 12:34   ` Mark Brown
2018-10-18 11:18 ` [PATCH v1 3/3] ASoC: soc-core: fix platform name vs. of_node assignement Marcel Ziswiler
2018-10-19 10:22   ` Jon Hunter
2018-10-21 11:23     ` Mark Brown
2018-12-18 17:40       ` Matthias Reichl [this message]
2019-01-03 16:42         ` [alsa-devel] " Jon Hunter
2019-01-08  2:25           ` Kuninori Morimoto
2019-01-08 10:50             ` Jon Hunter
2019-01-08 12:03               ` Jon Hunter
2019-01-08 15:48                 ` Jon Hunter
2019-01-08 16:09                   ` Mark Brown
2019-01-09  1:51                   ` Kuninori Morimoto
2019-01-09 11:03                     ` Jon Hunter
2019-01-09 12:53                       ` Mark Brown
2019-01-09 14:11                         ` Jon Hunter
2019-01-09 14:14                           ` Mark Brown
2019-01-10  1:16                             ` Kuninori Morimoto
2019-01-10  3:46                               ` Kuninori Morimoto
2019-01-10 10:56                               ` Jon Hunter
2019-01-11  0:52                                 ` Kuninori Morimoto
2019-01-11  8:41                                   ` Jon Hunter
2019-01-11  8:51                                     ` Kuninori Morimoto
2019-01-11  9:15                                       ` Jon Hunter
2019-01-14 23:02                                         ` Mark Brown
2019-01-15 15:26                                           ` Jon Hunter
2019-01-15 18:07                                             ` Matthias Reichl
2019-01-08 15:33         ` 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=20181218174040.k7u26vnnoplllnwb@camel2.lan \
    --to=hias@horus.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=marcel.ziswiler@toradex.com \
    --cc=marcel@ziswiler.com \
    --cc=tiwai@suse.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;
as well as URLs for NNTP newsgroup(s).