linux-kernel - RE: [PATCH 2/2] ASoC: Intel: sof

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: <CY5PR11MB6257D168A60B712088BC7CF797339@CY5PR11MB6257.namprd11.prod.outlook.com>
Date:   Thu, 27 Oct 2022 00:13:27 +0000
From:   "Lu, Brent" <brent.lu@...el.com>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>
CC:     "C, Balamurugan" <balamurugan.c@...el.com>,
        "Rojewski, Cezary" <cezary.rojewski@...el.com>,
        Chao Song <chao.song@...ux.intel.com>,
        "Kai Vehmanen" <kai.vehmanen@...ux.intel.com>,
        "Wang, Rander" <rander.wang@...el.com>,
        Bard Liao <yung-chuan.liao@...ux.intel.com>,
        Takashi Iwai <tiwai@...e.com>,
        "Song, Gongjun" <gongjun.song@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
        "Chiang, Mac" <mac.chiang@...el.com>,
        Mark Brown <broonie@...nel.org>,
        "Reddy, Muralidhar" <muralidhar.reddy@...el.com>,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
        Ajye Huang <ajye.huang@...il.com>,
        "Peter Ujfalusi" <peter.ujfalusi@...ux.intel.com>,
        "Gopal, Vamshi Krishna" <vamshi.krishna.gopal@...el.com>,
        "Zhi, Yong" <yong.zhi@...el.com>
Subject: RE: [PATCH 2/2] ASoC: Intel: sof_rt5682: quirk auto detection

> 
> This is a bit confusing: this quirk does not work for Volteer
> 
> 	{
> 		.callback = sof_rt5682_quirk_cb,
> 		.matches = {
> 			DMI_MATCH(DMI_PRODUCT_FAMILY,
> "Google_Volteer"),
> 			DMI_MATCH(DMI_OEM_STRING, "AUDIO-
> MAX98373_ALC5682I_I2S_UP4"),
> 		},
> 		.driver_data = (void *)(SOF_RT5682_MCLK_EN |
> 					SOF_RT5682_SSP_CODEC(0) |
> 					SOF_SPEAKER_AMP_PRESENT |
> 
> 	SOF_MAX98373_SPEAKER_AMP_PRESENT |
> 					SOF_RT5682_SSP_AMP(2) |
> 					SOF_RT5682_NUM_HDMIDEV(4)),
> 	},

I checked Volteer reference kit, it should use SSP1 for amplifier. It seems to me 
this quirk is for some customer variants which implements MAX98373 on SSP2.

> 
> Same for Brya and all usages of SSP_AMP(2)
> 
> 

It's a compromise that Google implements amplifiers on SSP2 on Brya so they can 
connect SDW codec to SSP1 pins, but we asked customers to implement amplifiers 
on SSP1 to reserve BT offload capability.

> > -	{
> > -		.name = "adl_rt1019_rt5682s",
> > -		.driver_data = (kernel_ulong_t)(SOF_RT5682_MCLK_EN |
> > -					SOF_RT5682_SSP_CODEC(0) |
> > -
> 	SOF_RT5682S_HEADPHONE_CODEC_PRESENT |
> 
> and HEADPHONE_CODEC_PRESENT is not handled either.
> 

Headphone type will be detected later in the sof_audio_probe().

> > -					SOF_SPEAKER_AMP_PRESENT |
> > -					SOF_RT1019_SPEAKER_AMP_PRESENT
> |
> > -					SOF_RT5682_SSP_AMP(1) |
> > -					SOF_RT5682_NUM_HDMIDEV(4)),
> > -	},
> 
> Overall I doubt that the SOC alone can tell you what the quirk is.
> 
> Maybe it's a default to avoid repeats of the same baseline configuration, but
> there's not much else that can be infer from an SOC definition in light of the
> creativity of our hardware friends who routinely swap interfaces.

I'm thinking about using kernel module parameters for those boards which do not
use default SSP port allocation. Not sure it's doable for machine driver module.

Regards,
Brent