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: <20090528130734.GB19523@sirena.org.uk>
Date:	Thu, 28 May 2009 14:07:35 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Jon Smirl <jonsmirl@...il.com>
Cc:	Robert Schwebel <r.schwebel@...gutronix.de>,
	Timur Tabi <timur@...escale.com>,
	Janboe Ye <yuan-bo.ye@...orola.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk, rmk@....linux.org.uk
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Wed, May 27, 2009 at 08:04:58PM -0400, Jon Smirl wrote:
> On Wed, May 27, 2009 at 6:24 PM, Mark Brown

> > Please read back over the original soc-of-simple thread, it goes into
> > the problems in a bit more detail.

...

> It's an evolutionary process, let's get ASoC loading all of the right
> modules first. Then we can move on to clocking, etc. I2C went through

As I have said a number of times with the exception of the AC97 the core
is basically there.  Certainly as far as loading modules goes the work
that needs doing is all at the driver level.  It'd be helpful if you'd
take this on board more - as things stand ASoC isn't doing any device
loading itself and relies on notifications from the individual drivers
that they're ready to use.

There's more stuff that needs doing in the core but I'm not going to
stop and wait for the drivers to catch up except in so much as it stops
other work - I only have the ability to test some devices and plenty of
stuff to be getting on with.  The feature is there if people want to use
it and I'm insisting on it for new CODEC drivers.

> the same process.  For example, the new efika-audio-fabric and
> pcm030-audio-fabric files should not be needed once the binding

As I have repeatedly explained to you there are particular issues with
AC97 which affect these drivers.

> When I disabled soc-of-simple that stop the autoloading of codecs on
> i2s. That needs to be fixed. Next kernel cycle I will be working on
> mpc5200 i2s.

This is going down to the individual drivers for your systems using old
device instantiation methods.  Someone needs to update the drivers.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ