All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: tiwai@suse.de, alsa-devel@alsa-project.org, broonie@kernel.org
Subject: Re: [PATCH] ALSA: core: sysfs: show components string
Date: Tue, 24 Mar 2020 18:01:53 +0900	[thread overview]
Message-ID: <20200324090152.GA14579@workstation> (raw)
In-Reply-To: <a74e4b68-d6f6-c12d-d600-d8cb7321cc00@linux.intel.com>

On Tue, Mar 24, 2020 at 12:12:15AM -0500, Pierre-Louis Bossart wrote:
> when people report that their microphone is not reported by PulseAudio/UCM,
> it's very helpful to know what UCM was supposed to use in the first place.
> We don't have a debugger or step-by-step mechanisms to figure out what the
> configurations are.

If I get your intension correctly, the addition of sysfs node is just to
investigate which use-case configuration is applied in cases that people
get issues. If so, it's really exaggerative in a point of the concept of
sysfs.

I have two alternatives. If it's possible to focus on ALSA SoC part only,
addition of node to debugfs is reasonable for this purpose.

Another alternative is to change output of 'cards' node of procfs. The
latter is commonly available for all cases. For example:

diff --git a/sound/core/init.c b/sound/core/init.c
index b02a99766351..9a04974c1d19 100644
--- a/sound/core/init.c
+++ b/sound/core/init.c
@@ -805,6 +805,8 @@ static void snd_card_info_read(struct snd_info_entry *entry,
                                        card->shortname);
                        snd_iprintf(buffer, "                      %s\n",
                                        card->longname);
+                       snd_iprintf(buffer, "                      %s\n",
+                                       card->component);
                }
                mutex_unlock(&snd_card_mutex);
        }

(If you're investigating to use rules of udevd for automated application
of UCM-based operation, there's a space to investigate the merit to expose
information via sysfs node. But actually you're not...)


Regards

Takashi Sakamoto

  reply	other threads:[~2020-03-24  9:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-23 19:36 [PATCH] ALSA: core: sysfs: show components string Pierre-Louis Bossart
2020-03-23 19:41 ` Mark Brown
2020-03-23 20:21   ` Pierre-Louis Bossart
2020-03-23 20:23   ` Takashi Iwai
2020-03-24  1:53 ` Takashi Sakamoto
2020-03-24  3:34   ` Pierre-Louis Bossart
2020-03-24  4:33     ` Takashi Sakamoto
2020-03-24  5:12       ` Pierre-Louis Bossart
2020-03-24  9:01         ` Takashi Sakamoto [this message]
2020-03-24 13:15           ` Pierre-Louis Bossart
2020-03-24 13:45             ` Jaroslav Kysela
2020-03-24 14:56             ` Takashi Iwai
2020-03-24 14:59               ` Pierre-Louis Bossart
2020-03-24 11:54     ` 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=20200324090152.GA14579@workstation \
    --to=o-takashi@sakamocchi.jp \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    --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.