From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: [PATCH] ASoC: soc-core: Fix null pointer dereference in soc_find_component Date: Thu, 24 Jan 2019 18:44:12 +0000 Message-ID: <20190124184412.GH5641@sirena.org.uk> References: <20190115000610.GM11073@sirena.org.uk> <796a856c-a9a6-022d-da63-947279090198@linux.intel.com> <20190115211137.rhdyjadu7fppp3p4@lenny.lan> <044d59ba-094e-727d-14a9-6ebfc54cbbf4@linux.intel.com> <44029078-2749-5a3b-7b03-f38461bf268f@linux.intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7525625489379300076==" Return-path: Received: from heliosphere.sirena.org.uk (heliosphere.sirena.org.uk [172.104.155.198]) by alsa0.perex.cz (Postfix) with ESMTP id 97F792674A9 for ; Thu, 24 Jan 2019 19:44:17 +0100 (CET) In-Reply-To: <44029078-2749-5a3b-7b03-f38461bf268f@linux.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Pierre-Louis Bossart Cc: rohkumar@qti.qualcomm.com, alsa-devel@alsa-project.org, bgoswami@codeaurora.org, vinod.koul@linaro.org, lgirdwood@gmail.com, Curtis Malainey , plai@codeaurora.org, linux-kernel@vger.kernel.org, Ajit Pandey , tiwai@suse.com, Liam Girdwood , Matthias Reichl , Rohit kumar , asishb@codeaurora.org, srinivas.kandagatla@linaro.org, Curtis Malainey , Dylan Reid List-Id: alsa-devel@alsa-project.org --===============7525625489379300076== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Zi0sgQQBxRFxMTsj" Content-Disposition: inline --Zi0sgQQBxRFxMTsj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 22, 2019 at 08:01:15PM -0600, Pierre-Louis Bossart wrote: > changes are legitimate. To move forward, maybe it's not worth spending too > much time on a grand unification of string theory, there are simpler > solutions: the Intel machine drivers already do get the platform driver name > as an platform_data argument, so we could modify the dailinks platform names > before even registering the card. I tested with the attached Yes, that would be much better - it's vastly more idiomatic. The general idea is that a machine driver should know what it's expecting to find before it starts probing. --Zi0sgQQBxRFxMTsj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlxKB3wACgkQJNaLcl1U h9DWzAf+NtlimN/EneqIJgAU2m4qsSGsS9Mz520HmFrDdz20VvslFLxGcyQylwnY dytQj5u6mMW5FjRr1ZtxO/ILOPpuYU23IfhLmNkBdnCcPKNVZwO5YfoBA4tCnLS9 fh4A7gAXXxxPvwv22dQUzoj2O78yRGtNwmPl4r2Fz8cgUqqklLxpG1D/crEg3e0Y P6ghAMtQh0w72+9Op3rf9Cjhwuj7bXnvS+l4g9B9SkhAvUQX+9KCB3M/+bkSDuf6 m/ke2DVbmvi/w3VB2nscnAYt7XdnlzhG2siJl8Mj1CEIclBUte7s3qneDIPeSHvQ ojflN99K6KhrRzn6L0mH3ntAPU5h4w== =MyTR -----END PGP SIGNATURE----- --Zi0sgQQBxRFxMTsj-- --===============7525625489379300076== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============7525625489379300076==--