linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Rohit kumar <rohitkr@codeaurora.org>,
	plai@codeaurora.org, bgoswami@codeaurora.org,
	asishb@codeaurora.org, lgirdwood@gmail.com, perex@perex.cz,
	tiwai@suse.com, alsa-devel@alsa-project.org,
	linux-kernel@vger.kernel.org, rohkumar@qti.qualcomm.com,
	srinivas.kandagatla@linaro.org, vinod.koul@linaro.org,
	Ajit Pandey <ajitp@codeaurora.org>,
	Liam Girdwood <liam.r.girdwood@linux.intel.com>
Subject: Re: [alsa-devel] [PATCH] ASoC: soc-core: Fix null pointer dereference in soc_find_component
Date: Tue, 15 Jan 2019 00:06:10 +0000	[thread overview]
Message-ID: <20190115000610.GM11073@sirena.org.uk> (raw)
In-Reply-To: <4886ed21-65d2-159d-afcd-bb26dcde636e@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]

On Fri, Jan 11, 2019 at 03:49:08PM -0600, Pierre-Louis Bossart wrote:

> Adding some traces I can see that the the platform name we use doesn't seem
> compatible with your logic. All the Intel boards used a constant platform
> name matching the PCI ID, see e.g. [1], which IIRC is used to bind
> components. Liam, do you recall in more details if this is really required?

That's telling me that either snd_soc_find_components() isn't finding
components in the same way that we do when we bind things which isn't
good or we're binding links without having fully matched everything on
the link which also isn't good.  

Without a system that shows the issue I can't 100% confirm but I think
it's the former - I'm fairly sure that those machines are relying on the
component name being initialized to fmt_single_name() in
snd_soc_component_initialize().  That is supposed to wind up using
dev_name() (which would be the PCI address for a PCI device) as the
basis of the name.  What I can't currently see is how exactly that gets
bound (or how any of the other links avoid trouble for that matter).  We
could revert and push this into cards but I would rather be confident
that we understand what's going on, I'm not comfortable that we aren't
just pushing the breakage around rather than fixing it.  Can someone
with an x86 system take a look and confirm exactly what's going on with
binding these cards please?

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

  parent reply	other threads:[~2019-01-15  0:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-11  8:14 [PATCH] ASoC: soc-core: Fix null pointer dereference in soc_find_component Rohit kumar
2019-01-11 15:44 ` [alsa-devel] " Pierre-Louis Bossart
2019-01-11 21:49   ` Pierre-Louis Bossart
2019-01-12  6:07     ` Rohit kumar
2019-01-14 15:40       ` Liam Girdwood
2019-01-15  0:06     ` Mark Brown [this message]
2019-01-15  3:08       ` Pierre-Louis Bossart
2019-01-15 19:35       ` Pierre-Louis Bossart
2019-01-15 21:07         ` Mark Brown
2019-01-15 21:11         ` Matthias Reichl
2019-01-15 21:16           ` Pierre-Louis Bossart
2019-01-15 21:41             ` Mark Brown
2019-01-15 21:48               ` Matthias Reichl
2019-01-18 23:02             ` Pierre-Louis Bossart
     [not found]               ` <CAOReqxjhZAzOpr-bGcV6uxPsOEid--Ym2Y0YZMHkybgZSePvtQ@mail.gmail.com>
2019-01-19  1:15                 ` Curtis Malainey
2019-01-21 18:30                   ` Mark Brown
2019-01-22 20:11                   ` Pierre-Louis Bossart
2019-01-23  1:36                     ` Curtis Malainey
2019-01-23  2:01                       ` Pierre-Louis Bossart
2019-01-24 18:44                         ` Mark Brown
2019-01-24 19:07                           ` Pierre-Louis Bossart
2019-01-24 19:26                             ` Mark Brown
2019-01-25  1:32                               ` Curtis Malainey
2019-01-21 19:17               ` Mark Brown
2019-01-14 23:26 ` 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=20190115000610.GM11073@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=ajitp@codeaurora.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=asishb@codeaurora.org \
    --cc=bgoswami@codeaurora.org \
    --cc=lgirdwood@gmail.com \
    --cc=liam.r.girdwood@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=plai@codeaurora.org \
    --cc=rohitkr@codeaurora.org \
    --cc=rohkumar@qti.qualcomm.com \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=tiwai@suse.com \
    --cc=vinod.koul@linaro.org \
    /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).