From: "Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>
To: Richard Fitzgerald <rf@opensource.cirrus.com>,
broonie@kernel.org, pierre-louis.bossart@linux.intel.com,
yung-chuan.liao@linux.intel.com, kai.vehmanen@linux.intel.com,
peter.ujfalusi@linux.intel.com
Cc: alsa-devel@alsa-project.org, patches@opensource.cirrus.com,
linux-kernel@vger.kernel.org,
Cezary Rojewski <cezary.rojewski@intel.com>
Subject: Re: [PATCH 1/4] ASoC: soc-card: Add storage for PCI SSID
Date: Wed, 13 Sep 2023 12:56:03 +0200 [thread overview]
Message-ID: <92b2b69e-3175-651f-45bb-d9ae11eaec82@linux.intel.com> (raw)
In-Reply-To: <20230912163207.3498161-2-rf@opensource.cirrus.com>
On 9/12/2023 6:32 PM, Richard Fitzgerald wrote:
> Add members to struct snd_soc_card to store the PCI subsystem ID (SSID)
> of the soundcard.
>
> The PCI specification provides two registers to store a vendor-specific
> SSID that can be read by drivers to uniquely identify a particular
> "soundcard". This is defined in the PCI specification to distinguish
> products that use the same silicon (and therefore have the same silicon
> ID) so that product-specific differences can be applied.
>
> PCI only defines 0xFFFF as an invalid value. 0x0000 is not defined as
> invalid. So the usual pattern of zero-filling the struct and then
> assuming a zero value unset will not work. A flag is included to
> indicate when the SSID information has been filled in.
>
> Unlike DMI information, which has a free-format entirely up to the vendor,
> the PCI SSID has a strictly defined format and a registry of vendor IDs.
>
> It is usual in Windows drivers that the SSID is used as the sole identifier
> of the specific end-product and the Windows driver contains tables mapping
> that to information about the hardware setup, rather than using ACPI
> properties.
>
> This SSID is important information for ASoC components that need to apply
> hardware-specific configuration on PCI-based systems.
>
> As the SSID is a generic part of the PCI specification and is treated as
> identifying the "soundcard", it is reasonable to include this information
> in struct snd_soc_card, instead of components inventing their own custom
> ways to pass this information around.
>
> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
> ---
> include/sound/soc-card.h | 37 +++++++++++++++++++++++++++++++++++++
> include/sound/soc.h | 11 +++++++++++
> 2 files changed, 48 insertions(+)
>
> diff --git a/include/sound/soc-card.h b/include/sound/soc-card.h
> index fc94dfb0021f..e8ff2e089cd0 100644
> --- a/include/sound/soc-card.h
> +++ b/include/sound/soc-card.h
...
> diff --git a/include/sound/soc.h b/include/sound/soc.h
> index 509386ff5212..81ed08c5c67d 100644
> --- a/include/sound/soc.h
> +++ b/include/sound/soc.h
> @@ -929,6 +929,17 @@ struct snd_soc_card {
> #ifdef CONFIG_DMI
> char dmi_longname[80];
> #endif /* CONFIG_DMI */
> +
> +#ifdef CONFIG_PCI
> + /*
> + * PCI does not define 0 as invalid, so pci_subsystem_set indicates
> + * whether a value has been written to these fields.
> + */
> + unsigned short pci_subsystem_vendor;
> + unsigned short pci_subsystem_device;
> + bool pci_subsystem_set;
> +#endif /* CONFIG_PCI */
> +
> char topology_shortname[32];
>
> struct device *dev;
This looks bit weird to me, snd_soc_card is _generic_ struct which is
not device specific in any way, and now you add fields for PCI, can't
this somehow be done using drvdata or something?
next prev parent reply other threads:[~2023-09-13 10:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-12 16:32 [PATCH 0/4] ASoC: cs35l56: Use PCI SSID to select specific firmware Richard Fitzgerald
2023-09-12 16:32 ` [PATCH 1/4] ASoC: soc-card: Add storage for PCI SSID Richard Fitzgerald
2023-09-13 10:56 ` Amadeusz Sławiński [this message]
2023-09-13 12:58 ` Mark Brown
2023-09-13 13:29 ` Richard Fitzgerald
2023-09-12 16:32 ` [PATCH 2/4] ASoC: SOF: Pass PCI SSID to machine driver Richard Fitzgerald
2023-09-12 16:32 ` [PATCH 3/4] ASoC: Intel: sof_sdw: Copy PCI SSID to struct snd_soc_card Richard Fitzgerald
2023-09-12 16:32 ` [PATCH 4/4] ASoC: cs35l56: Use PCI SSID as the firmware UID Richard Fitzgerald
2023-09-12 17:39 ` [PATCH 0/4] ASoC: cs35l56: Use PCI SSID to select specific firmware Pierre-Louis Bossart
2023-09-14 11:19 ` 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=92b2b69e-3175-651f-45bb-d9ae11eaec82@linux.intel.com \
--to=amadeuszx.slawinski@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=cezary.rojewski@intel.com \
--cc=kai.vehmanen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@opensource.cirrus.com \
--cc=peter.ujfalusi@linux.intel.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=rf@opensource.cirrus.com \
--cc=yung-chuan.liao@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox