linux-kernel - Re: MMC: Make the configuration memory resource optional

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]

Date:	Wed, 29 Jul 2009 21:35:46 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Magnus Damm <magnus.damm@...il.com>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Ian Molton <ian@...menth.co.uk>,
	Guennadi Liakhovetski <g.liakhovetski@....de>,
	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 Wed, Jul 29, 2009 at 09:27:54PM +0900, Magnus Damm wrote:
> On Wed, Jul 29, 2009 at 8:58 PM, Mark
> Brown<broonie@...nsource.wolfsonmicro.com> wrote:
> > Looking at the original patch I'm not sure exactly why it runs into
> > clock API issues so I'm not sure if this is a relevant concern or not
> > here but I'm mentioning it since I'd kind of expect an impact on the
> > SoCs from addressing it due to the way the clock API functions are
> > currently provided.
> 
> In my opinion this patch has nothing to do with the clock framework.
> 
> But fixing up clocklib properly would certainly be beneficial for
> everyone. Holding the driver hostage until clocklib is upstream
> however, that's just silly.
> 
It also presupposes that people want clocklib upstream. The last time I
saw it pass through my inbox, I wasn't convinced that it really bought us
anything. The ARM clkdev thing on the other hand is something I plan to
drag in on the SH side as well, but that too is a separate thing.

If folks are of the mindset that the current patch is a misuse of the
clock framework, then the objection needs to be specifically noted. I'm
willing to make concessions on the clock framework side if Ian has
problems with the current scheme, but I am not at all convinced of the
relative merit of clocklib, or holding drivers hostage to such. 
--
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/