linux-kernel - Re: Correct modules for Bay Trail MAX98090 soc?

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 12 Aug 2016 06:37:11 -0500
From:	Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Laura Abbott <labbott@...hat.com>, Jie Yang <yang.jie@...el.com>,
	Takashi Iwai <tiwai@...e.com>,
	Vinod Koul <vinod.koul@...el.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	alsa-devel@...a-project.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Correct modules for Bay Trail MAX98090 soc?

On 8/12/16 4:53 AM, Mark Brown wrote:
> On Thu, Aug 11, 2016 at 06:31:27PM -0500, Pierre-Louis Bossart wrote:
>> On 8/11/16 3:42 PM, Laura Abbott wrote:
>
>>> which changed the dependencies for CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH.
>>> The set of options Fedora selects means that
>>> CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH
>>> can't be selected. Is there another driver that's supposed to replace
>>> CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH on Bay Trail or do the dependencies
>>> need to be updated? The bugzilla has alsa-info for working and non-
>>> working cases and the Fedora config is attached.
>
>> If you remove support for all other baytrail options this driver should
>> still be there and selectable. We just can't support both this driver for
>> Chromebooks and the rest for other machines with the same distribution at
>> the moment.
>
> That sounds like a regression, what's the plan to fix it.

The simple fix is easy: disable all other codecs and the
BYT_MAX98090 option will be enabled. BYT_MAX98090 relies on the 'old' 
non-dpcm driver which is used only for Chromebooks with Baytrail, which 
never enable any other codecs, so there was never any issue before.
If there is a need for concurrency, then a new machine driver based on 
the dpcm Atom driver needs to be created. I don't have a Baytrail 
chromebook so don't want to commit on the change.