linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
To: "broonie@kernel.org" <broonie@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jonathanh@nvidia.com" <jonathanh@nvidia.com>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
	"kuninori.morimoto.gx@renesas.com"
	<kuninori.morimoto.gx@renesas.com>,
	"tiwai@suse.com" <tiwai@suse.com>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"perex@perex.cz" <perex@perex.cz>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: [PATCH v2 9/9] ASoC: tegra_sgtl5000: fix platform name vs. of_node assignement
Date: Wed, 17 Oct 2018 21:33:00 +0000	[thread overview]
Message-ID: <1539811978.6233.63.camel@toradex.com> (raw)
In-Reply-To: <20181017191633.GL24097@sirena.org.uk>

On Wed, 2018-10-17 at 20:16 +0100, Mark Brown wrote:
> On Wed, Oct 17, 2018 at 02:28:22PM +0000, Marcel Ziswiler wrote:
> 
> > Some questions:
> > - How exactly are devm allocations supposed to work concerning
> > probe
> > deferrals?
> 
> Probe deferrals are just normal probe errors, any devm_ allocated
> stuff
> gets unwound.

OK, that is where my understanding was weary. So you are saying
anything should really get allocated again upon the second time.

> > - Does or should the platform get cleared during a probe deferral
> > cycle?
> > - If so, why does that not work?
> 
> Is something writing to static data when it should be writing to
> dynamically allocated data?  That's what this sounds like, we
> shouldn't
> be modifying any static data and any data dynamically allocated
> during
> probe ought to be being discarded.

OK, I believe I start to see what you are saying. I guess the bug lays
in soc-core then not properly discarding the platform and the second
time around it is using a stale pointer to that which now of course
points to whatever happens to be there! Let me try a few more things
and I will cook up a proper patch to fix that...

> > - Or is some special implicit probe deferral handling missing in
> > soc-
> > core?
> 
> Like I say a probe deferral is just a normal error.

Yeah, right. Thanks!

  parent reply	other threads:[~2018-10-17 21:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-16 10:47 [PATCH v2 0/9] ARM: dts: tegra: last minute fixes Marcel Ziswiler
2018-10-16 10:47 ` [PATCH v2 1/9] ARM: tegra: fix simple-panel compatibles Marcel Ziswiler
2018-10-16 10:47 ` [PATCH v2 2/9] ARM: tegra: apalis-tk1/colibri_t20/t30: eval/iris: fix regulator gpio enable Marcel Ziswiler
2018-10-16 10:47 ` [PATCH v2 3/9] ARM: tegra: colibri_t20: reorder pmic properties Marcel Ziswiler
2018-10-16 10:47 ` [PATCH v2 4/9] ARM: tegra: apalis-tk1: further regulator clean-up Marcel Ziswiler
2018-10-16 10:47 ` [PATCH v2 5/9] ARM: tegra: apalis_t30/tk1: annotate power I2C being on-module Marcel Ziswiler
2018-10-16 10:47 ` [PATCH v2 6/9] ARM: tegra: colibri_t30: further regulator clean-up Marcel Ziswiler
2018-10-16 10:47 ` [PATCH v2 7/9] ARM: tegra: apalis_t30: " Marcel Ziswiler
2018-10-16 10:47 ` [PATCH v2 8/9] ASoC: tegra_sgtl5000: fix device_node refcounting Marcel Ziswiler
2018-10-17 10:57   ` Jon Hunter
2018-10-16 10:47 ` [PATCH v2 9/9] ASoC: tegra_sgtl5000: fix platform name vs. of_node assignement Marcel Ziswiler
2018-10-17 12:32   ` Jon Hunter
2018-10-17 14:28     ` Marcel Ziswiler
2018-10-17 19:16       ` Mark Brown
2018-10-17 19:50         ` Jon Hunter
2018-10-17 21:33         ` Marcel Ziswiler [this message]
2018-10-16 11:58 ` [PATCH v2 0/9] ARM: dts: tegra: last minute fixes Mark Brown
2018-10-16 12:10   ` Marcel Ziswiler
2018-10-17 10:51   ` Marcel Ziswiler
2018-10-17 11:44     ` 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=1539811978.6233.63.camel@toradex.com \
    --to=marcel.ziswiler@toradex.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.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=linux@armlinux.org.uk \
    --cc=perex@perex.cz \
    --cc=thierry.reding@gmail.com \
    --cc=tiwai@suse.com \
    --subject='Re: [PATCH v2 9/9] ASoC: tegra_sgtl5000: fix platform name vs. of_node assignement' \
    /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

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).