All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: nikesh@opensource.wolfsonmicro.com
Cc: lgirdwood@gmail.com, perex@perex.cz, tiwai@suse.de,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	patches@opensource.wolfsonmicro.com,
	nikesh <Nikesh.Oswal@wolfsonmicro.com>
Subject: Re: [PATCH v2] ASOC: dapm: add params_select callback
Date: Fri, 28 Feb 2014 11:23:59 +0900	[thread overview]
Message-ID: <20140228022359.GD9383@sirena.org.uk> (raw)
In-Reply-To: <1393517900-27126-1-git-send-email-nikesh@opensource.wolfsonmicro.com>

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

On Thu, Feb 27, 2014 at 04:18:20PM +0000, nikesh@opensource.wolfsonmicro.com wrote:
> From: nikesh <Nikesh.Oswal@wolfsonmicro.com>

As I said in my reply to your earlier patch:

| You need to fix both your git and e-mail setups, you should be using
| "Nikesh Oswal" or similar as your real name and more importantly your

Please don't ignore review comments, it tends not to be helpful.

Please do also use subject lines matching the style for the subsystem.

> dai-link params for codec-codec links were fixed. The fixed link between
> codec and another chip which may be another codec, baseband, bluetooth
> codec etc may require run time configuaration changes. This change
> provides an optional callback to select one of the param from a list
> of params.

OK, so the question now is why is this being done using a callback and
why is that callback picking from a list of predefined configurations?
You've not motivated this decision at all and it's not obvious to me
that it's the best approach (for example, why not just let the machine
driver set the parameters at any time rather than have it wait for a
callback)?

The picking from a list is especially odd, what I said in my previous
review was:

| If you look at the existing interface you'll also see that it takes an
| array of parameters rather than just a single parameter.  The idea was
| to extend the interface to provide a control to userspace allowing
| selection of one of the configurations from a list for use with cases
| like modems which can switch between 8kHz and 16kHz modes.

but if the selection is done purely in kernel space and we're not
constructing an enum then it's less clear that this is helpful.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

      reply	other threads:[~2014-02-28  2:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-27 16:18 [PATCH v2] ASOC: dapm: add params_select callback nikesh
2014-02-28  2:23 ` Mark Brown [this message]

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=20140228022359.GD9383@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=Nikesh.Oswal@wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nikesh@opensource.wolfsonmicro.com \
    --cc=patches@opensource.wolfsonmicro.com \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.de \
    /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.