All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	rajeev kumar <rajeevkumar.linux@gmail.com>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>,
	Vijendar Mukunda <Vijendar.Mukunda@amd.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	perex@perex.cz
Subject: Re: [PATCH 1/8] drm/amd/amdgpu: Added asic_type as ACP DMA driver platform data
Date: Wed, 28 Jun 2017 18:54:06 +0100	[thread overview]
Message-ID: <20170628175406.5yykiv33xdcs6qnr@sirena.org.uk> (raw)
In-Reply-To: <CADnq5_MT+h6nOmXfVi42tH9G917wTRguBdMC02zmgRuH2dD-iA@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1231 bytes --]

On Fri, Jun 23, 2017 at 01:05:37PM -0400, Alex Deucher wrote:
> On Fri, Jun 23, 2017 at 12:43 PM, Christian König

> > Have the painkillers jellyfied my brain or are you setting a pointer in the
> > amdgpu device structure to some variable on the stack?

> > If it's just for initialization then that's probably ok, but I would reset
> > the pointer at the end of the function.

> > Otherwise somebody might have the idea to dereference it later on and that
> > can only lead to trouble.

> I think it's ok because the hotplug of the audio device is triggered
> from this function, so the audio device should be probed by the time
> this variable goes out of scope.  That said, it would probably be

No, that's in no way safe.  There is no guarantee that probe is going to
happen on any particular schedule, if the other driver isn't registered
yet it'll need to wait for that to happen for example.  You will often
get away with it but that's at best going to be vulnerable to framework
changes (what if someone decides to kick off the probe on a separate
CPU in an effort to reduce boot time?).

> better to use the asic_type from the GPU driver instance directly
> rather than a stack variable.

Yes.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2017-06-28 17:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-23 16:34 [PATCH 0/8] Add ASoC support for AMD Stoney APUs Alex Deucher
2017-06-23 16:35 ` [PATCH 3/8] drm/amd/amdgpu: Added a dwc quirk for Stoney platform Alex Deucher
2017-06-28 18:02   ` Mark Brown
2017-06-23 16:35 ` [PATCH 5/8] ASoC: AMD: DMA driver changes for Stoney Platform Alex Deucher
     [not found] ` <1498235706-31111-1-git-send-email-alexander.deucher-5C7GfCeVMHo@public.gmane.org>
2017-06-23 16:34   ` [PATCH 1/8] drm/amd/amdgpu: Added asic_type as ACP DMA driver platform data Alex Deucher
     [not found]     ` <1498235706-31111-2-git-send-email-alexander.deucher-5C7GfCeVMHo@public.gmane.org>
2017-06-23 16:43       ` Christian König
2017-06-23 17:05         ` Alex Deucher
2017-06-26 13:29           ` Christian König
2017-06-28 17:54           ` Mark Brown [this message]
2017-06-23 16:35   ` [PATCH 2/8] ASoC: dwc: Added a quirk DW_I2S_QUIRK_16BIT_IDX_OVERRIDE to dwc driver Alex Deucher
2017-06-28 19:23     ` Applied "ASoC: dwc: Added a quirk DW_I2S_QUIRK_16BIT_IDX_OVERRIDE to dwc driver" to the asoc tree Mark Brown
2017-06-23 16:35   ` [PATCH 4/8] ASoC: AMD: added condition checks for CZ specific code Alex Deucher
2017-06-28 18:05     ` Mark Brown
2017-06-29 12:58       ` Mukunda, Vijendar
2017-06-30 10:16         ` Mark Brown
2017-06-23 16:35   ` [PATCH 6/8] ASoC: AMD: Buffer related changes for Stoney Alex Deucher
2017-06-23 16:35   ` [PATCH 7/8] drm/amd/amdgpu: Disable ACP Power Gating for Stoney platform Alex Deucher
2017-06-23 16:35   ` [PATCH 8/8] ASoC: AMD: Add machine driver for cz rt5650 Alex Deucher
2017-06-23 20:01     ` Pierre-Louis Bossart

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=20170628175406.5yykiv33xdcs6qnr@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=Vijendar.Mukunda@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=lgirdwood@gmail.com \
    --cc=perex@perex.cz \
    --cc=rajeevkumar.linux@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.