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: <F46914AEC2663F4A9BB62374E5EEF8F8480DD236@SHSMSX101.ccr.corp.intel.com>
Date:	Thu, 27 Aug 2015 01:50:35 +0000
From:	"Lin, Mengdong" <mengdong.lin@...el.com>
To:	Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
	"Jie, Yang" <yang.jie@...el.com>
CC:	Takashi Iwai <tiwai@...e.de>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"Luis R. Rodriguez" <mcgrof@...e.com>,
	"joonas.lahtinen@...ux.intel.com" <joonas.lahtinen@...ux.intel.com>,
	Tom Gundersen <teg@...m.no>, Ming Lei <ming.lei@...onical.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
	Kay Sievers <kay@...y.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Luis Rodriguez <mcgrof@...not-panic.com>,
	lkml <linux-kernel@...r.kernel.org>,
	yalin wang <yalin.wang2010@...il.com>
Subject: RE: Problems loading firmware using built-in drivers with kernels
 that use initramfs.

> -----Original Message-----
> From: Liam Girdwood [mailto:liam.r.girdwood@...ux.intel.com]
> Sent: Wednesday, August 26, 2015 5:01 PM
> To: Jie, Yang
> Cc: Takashi Iwai; Dmitry Torokhov; Luis R. Rodriguez;
> joonas.lahtinen@...ux.intel.com; Tom Gundersen; Ming Lei; Al Viro; Greg
> Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; Luis Rodriguez;
> lkml; yalin wang; Lin, Mengdong
> Subject: Re: Problems loading firmware using built-in drivers with kernels that
> use initramfs.
> 
> On Wed, 2015-08-26 at 08:29 +0000, Jie, Yang wrote:
> > > -----Original Message-----
> > > From: Liam Girdwood [mailto:liam.r.girdwood@...ux.intel.com]
> 
> > > I think the options are to either :-
> > >
> > > 1) Don not support audio DSP drivers using topology data as built-in
> drivers.
> > > Audio is not really a critical system required for booting anyway.
> > >
> > > 2) Create a default PCM for every driver that has topology data on
> > > the assumption that every sound card will at least 1 PCM. This PCM
> > > can then be re-configured when the FW is loaded.
> >
> > Yep, this case is quite similar with what Linus described.
> >
> > Is it possible that we can probe pcm device after firmware is loaded
> > for this case?
> >
> 
> The PCM devices are defined in the topology data so it is only possible to
> create the PCM device *after* the firmware is loaded in these drivers.
> 
> Liam

It seems this can prevent audio device driver in built-in mode to use topology drivers.

If topology is present, the vendor driver also uses request_firmware() to load the topology data file in the probe phase. Then ASoC core will create the sound card and its PCM devices. 

Shall we force the device drivers that depends on topology to be configured as modules?

Thanks
Mengdong 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ