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: <bba5dc19-c0c4-2409-6cd2-c8fa91950444@linux.intel.com>
Date:   Wed, 26 Oct 2022 20:30:00 -0500
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     "Lu, Brent" <brent.lu@...el.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



On 10/26/22 19:13, Lu, Brent wrote:
>>
>> 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.

I appreciate what you are trying to suggest, and I am all for trying to
put this proliferation of quirks under control, but the autodetection
based on rules seems out-of-reach if we don't first cleanup the existing
quirks.

If "volteer" and "brya" mean different things to different people, and
reference and derivatives are not well identified, the odds of
regressions seem very high to me.

> 
>>> -	{
>>> -		.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.

That's not a working solution IMHO, the kernel parameters should be used
by expert developers only for specific and short-term debug. It's not
possible to add a dependency on kernel parameters, that would prevent a
kernel update.