| 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
| ||
|
Message-Id: <9C1AC001-2FA6-4C19-B9D3-23FB63BAF20B@opensource.wolfsonmicro.com> Date: Wed, 29 Jul 2009 14:11:52 +0100 From: Mark Brown <broonie@...nsource.wolfsonmicro.com> To: Ian Molton <ian@...menth.co.uk> Cc: Magnus Damm <magnus.damm@...il.com>, Guennadi Liakhovetski <g.liakhovetski@....de>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Pierre Ossman <drzeus@...eus.cx>, Magnus Damm <damm@...nsource.se> Subject: Re: MMC: Make the configuration memory resource optional On 29 Jul 2009, at 13:58, Ian Molton <ian@...menth.co.uk> wrote: > Magnus Damm wrote: > >>> Indeed. It's actually much worse than you say, each individual ARM >>> architecture has its own clock API implementation of varying >>> quality and >>> of course there are architectures that don't do the clock API at >>> all. >> Yeah. This is exactly why I don't want to block on the clocklib >> implementation. > > Yeah, good idea... lets ignore the problem until its so big we cant > fix it at all... The problem here is sufficiently substantial that I'd be impressed if we managed to get a good solution in within a single kernel release. This does help encourage people to keep local hacks but those are much more realistic. -- 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