All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Cezary Rojewski <cezary.rojewski@intel.com>,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: hdegoede@redhat.com, alsa-devel@alsa-project.org,
	broonie@kernel.org, tiwai@suse.com
Subject: Re: [PATCH] ASoC: Intel: Unify HDAudio-ext bus initialization
Date: Thu, 21 Oct 2021 14:08:55 -0500	[thread overview]
Message-ID: <290ccb39-94ee-3b13-f18b-4a7f145942e2@linux.intel.com> (raw)
In-Reply-To: <f9320fb8-4609-8399-9b57-440f6cfd48e3@intel.com>




>>> Well, please see the updated declaration of snd_hda_ext_bus_init() in
>>> this very patch and then the existing code of
>>> sound/soc/intel/skylake/skl.c - skl_create().
>>> Last argument in updated declaration reads 'modelname'. Skylake-driver
>>> has its own, SOF initializes it differently.
>>
>> Not sure why you have your own?
>>
> 
> Not sure I understand the question. If you are talking about changing
> string 'sklbus' to something else, then I don't believe mixing changes:
> update to actual values assigned and assignment relocation in one patch
> is good. I used 'sklbus' as that's what is being currently assigned to
> ->modelname within skl_create(). Such approach makes the change more
> transparent.

What I meant is that this 'modelname' is a module parameter for legacy
and SOF driver, it's attached to the bus, but eventually used by the codec

hda_codec.c:    if (codec->bus->modelname) {
hda_codec.c:            codec->modelname =
kstrdup(codec->bus->modelname, GFP_KERNEL);

and even further down used to apply board-specific fixups.

"sklbus" doesn't seem to be related to codecs, boards or fixups, so not
sure what this parameter does in the end?


  reply	other threads:[~2021-10-21 19:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-18 19:21 [PATCH] ASoC: Intel: Unify HDAudio-ext bus initialization Cezary Rojewski
2021-10-18 21:18 ` Pierre-Louis Bossart
2021-10-19  8:00   ` Cezary Rojewski
2021-10-19  9:16 ` Kai Vehmanen
2021-10-19 12:19   ` Cezary Rojewski
2021-10-19 16:58     ` Pierre-Louis Bossart
2021-10-19 17:32       ` Cezary Rojewski
2021-10-19 18:42         ` Pierre-Louis Bossart
2021-10-21 11:02           ` Cezary Rojewski
2021-10-21 17:19             ` Pierre-Louis Bossart
2021-10-21 18:38               ` Cezary Rojewski
2021-10-21 19:08                 ` Pierre-Louis Bossart [this message]
2021-10-24 17:42 ` kernel test robot
2021-10-24 17:42   ` kernel test robot

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=290ccb39-94ee-3b13-f18b-4a7f145942e2@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=hdegoede@redhat.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=tiwai@suse.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.