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] [day] [month] [year] [list]
Date:   Tue, 31 Oct 2023 10:47:45 +0100
From:   Cezary Rojewski <cezary.rojewski@...el.com>
To:     Takashi Iwai <tiwai@...e.de>,
        Brady Norander <bradynorander@...il.com>
CC:     Takashi Iwai <tiwai@...e.com>, Mark Brown <broonie@...nel.org>,
        <alsa-devel@...a-project.org>, <linux-kernel@...r.kernel.org>,
        "Jaroslav Kysela" <perex@...ex.cz>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Bard Liao <yung-chuan.liao@...ux.intel.com>,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>
Subject: Re: [PATCH v2] ALSA: hda: intel-dsp-cfg: Use AVS driver on
 SKL/KBL/APL Chromebooks

On 2023-10-31 9:07 AM, Takashi Iwai wrote:
> On Mon, 30 Oct 2023 19:58:52 +0100,
> Brady Norander wrote:
>>
>> The legacy SKL driver no longer works properly on these Chromebook
>> platforms. Use the new AVS driver by default instead.
>>
>> Signed-off-by: Brady Norander <bradynorander@...il.com>
> 
> It's fine to switch to the new and more maintained AVS (once after the
> topology is ready), but I wonder how the breakage of SKL happened.
> Was it our intentional breakage in the past?  If so, why can't we
> recover it?

To my knowledge, skylake-driver used in I2S configurations never worked 
on "bare" upstream. While I and the team have been sending plethora of 
fixes to upstream, it has always been done "after the fact".

Another topic is the topology. Again, from what I know, skylake-driver 
topology files were never pushed as an official package to any distro. 
In most cases, Chromebook-users were taking what we have done during 
recent up-revs for those devices onto their distros. Eventually 
avs-topology-xml/for-skylake-driver [1] and avsdk/for-skylake-driver [2] 
have been created to help downstream users. While the method is not 
perfect, it is certainly better than forcing users to switch to the 
avs-driver immediately without addressing any existing skylake-driver 
issues.


[1]: 
https://github.com/thesofproject/avs-topology-xml/tree/for-skylake-driver
[2]: https://github.com/thesofproject/avsdk/tree/for-skylake-driver

Czarek

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ