linux-kernel - Re: [PATCH] ALSA: hda: cs35l41: Support ASUS 2023 laptops with missing DSD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87v8d6cm30.wl-tiwai@suse.de>
Date:   Wed, 23 Aug 2023 08:24:51 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     "Luke D. Jones" <luke@...nes.dev>
Cc:     tiwai@...e.com, james.schulman@...rus.com, david.rhodes@...rus.com,
        rf@...nsource.cirrus.com, linux-kernel@...r.kernel.org,
        sbinding@...nsource.cirrus.com, Jonathan LoBue <jlobue10@...il.com>
Subject: Re: [PATCH] ALSA: hda: cs35l41: Support ASUS 2023 laptops with missing DSD

On Wed, 23 Aug 2023 03:10:08 +0200,
Luke D. Jones wrote:
> 
> Support adding the missing DSD properties required  for ASUS ROG 2023
> laptops and other ASUS laptops to properly utilise the cs35l41.
> 
> This support includes both I2C and SPI connected amps.
> 
> The SPI connected amps may be required to use an external DSD patch
> to fix or add the "cs-gpios" property.
> 
> Co-developed-by: Jonathan LoBue <jlobue10@...il.com>
> Signed-off-by: Jonathan LoBue <jlobue10@...il.com>
> Co-developed-by: Luke D. Jones <luke@...nes.dev>
> Signed-off-by: Luke D. Jones <luke@...nes.dev>
> ---
>  sound/pci/hda/cs35l41_hda_property.c | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/sound/pci/hda/cs35l41_hda_property.c b/sound/pci/hda/cs35l41_hda_property.c
> index 673f23257a09..69879ab57918 100644
> --- a/sound/pci/hda/cs35l41_hda_property.c
> +++ b/sound/pci/hda/cs35l41_hda_property.c
> @@ -43,6 +43,31 @@ static int lenovo_legion_no_acpi(struct cs35l41_hda *cs35l41, struct device *phy
>  	return 0;
>  }
>  
> +/*
> + * The CSC3551 is used in almost the entire ASUS ROG laptop range in 2023, this is likely to
> + * also include many non ROG labelled laptops. It is also used with either I2C connection or
> + * SPI connection. The SPI connected versions may be missing a chip select GPIO and require
> + * an DSD table patch.
> + */
> +static int asus_rog_2023_no_acpi(struct cs35l41_hda *cs35l41, struct device *physdev, int id,
> +				const char *hid)
> +{
> +	struct cs35l41_hw_cfg *hw_cfg = &cs35l41->hw_cfg;
> +
> +	/* check SPI or I2C address to assign the index */
> +	cs35l41->index = (id == 0 || id == 0x40) ? 0 : 1;
> +	cs35l41->channel_index = 0;
> +	cs35l41->reset_gpio = gpiod_get_index(physdev, NULL, 0, GPIOD_OUT_HIGH);
> +	cs35l41->speaker_id = cs35l41_get_speaker_id(physdev, 0, 0, 2);
> +	hw_cfg->spk_pos = cs35l41->index;
> +	hw_cfg->gpio2.func = CS35L41_INTERRUPT;
> +	hw_cfg->gpio2.valid = true;
> +	hw_cfg->bst_type = CS35L41_EXT_BOOST_NO_VSPK_SWITCH;
> +	hw_cfg->valid = true;
> +
> +	return 0;
> +}
> +
>  struct cs35l41_prop_model {
>  	const char *hid;
>  	const char *ssid;
> @@ -53,6 +78,7 @@ struct cs35l41_prop_model {
>  const struct cs35l41_prop_model cs35l41_prop_model_table[] = {
>  	{ "CLSA0100", NULL, lenovo_legion_no_acpi },
>  	{ "CLSA0101", NULL, lenovo_legion_no_acpi },
> +	{ "CSC3551", NULL, asus_rog_2023_no_acpi },

I believe this breaks things badly.  cs35l41_add_dsd_properties() is
always called no matter whether _DSD is found or not.  So this will
override the setup of all machines with CSC3551 even if it has a
proper _DSD.

The existing entries of CLSA0100 and CLSA0101 are OK since
(supposedly) those never had _DSD.  The current code is a bit
misleading as if it's applicable easily, though.

That said, we have to apply the setup only conditionally for each
specific device.  One easy thing would be to move the function call
after _DSD check.  But, I *guess* that Stefan applied the function at
the top so that it may cover the all cases including incorrect _DSD
properties.

And, the question is how to be specific to each device.  This can be
messy, as the sub-codec driver is probed independently from Realtek
codec driver, hence you can't pass any flag from Realtek to CS driver
at the probe time.  In the end, we might need to keep another table of
IDs (either the same SSID or DMI) to distinguish which machine needs
which properties.


thanks,

Takashi