[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190325150237.GH7284@sirena.org.uk>
Date: Mon, 25 Mar 2019 15:02:37 +0000
From: Mark Brown <broonie@...nel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc: alsa-devel@...a-project.org, Jie Yang <yang.jie@...ux.intel.com>,
linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
Jarkko Nikula <jarkko.nikula@...ux.intel.com>,
Curtis Malainey <cujomalainey@...omium.org>,
Guenter Roeck <linux@...ck-us.net>
Subject: Re: [alsa-devel] [PATCH] ASoC: intel: Fix crash at suspend/resume
after failed codec registration
On Mon, Mar 25, 2019 at 09:18:04AM -0400, Pierre-Louis Bossart wrote:
> On 3/25/19 8:12 AM, Mark Brown wrote:
> > These are driver specific issues not device model issues as far as I can
> > see? The issue fixed by this as is that you're storing a pointer in the
> > ASoC level (not device model level) probe that you don't free when the
> > component is unbound, causing you to dereference it later during
> > suspend. There is absolutely no problem with the machine driver not
> > being guaranteed to bind at the time it's initially registered, that's
> > perfectly normal and should cause no problems.
> Agree, what I was referring is that if the machine probe and card
> registration fails (not just deferred), the parent acpi/pci driver isn't
> notified - there is just no means to provide that information and that leads
> to all kinds of configuration issues.
If there are issues here they could happen via means other than a probe
failing so there's a problem whatever is going on - someone manually
unbinding a device for example.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists