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]

Message-ID: <4A7A106B.2070809@mnementh.co.uk>
Date:	Thu, 06 Aug 2009 00:06:19 +0100
From:	Ian Molton <ian@...menth.co.uk>
To:	Guennadi Liakhovetski <g.liakhovetski@....de>
CC:	Magnus Damm <magnus.damm@...il.com>,
	pHilipp Zabel <philipp.zabel@...il.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	linux-kernel@...r.kernel.org, Pierre Ossman <drzeus@...eus.cx>
Subject: Re: MMC: Make the configuration memory resource optional

Guennadi Liakhovetski wrote:

>> Thats the HCLK frequency, not the card clock.
> 
> Sure, and the card clock is derived from the HCLK, as you describe below.

Ok, so then your controller (unless it uses a different scheme 
altogether for the card clock divider) probably has a max card clock of 
12MHz and a min of 24/512MHz.

I will change the driver so that it automatically alters the max 
frequency based on the presence of a function to (en,dis)able the 1:1 bit.

> I think, even getting the driver work with half the maximum speed (without 
> the 1:1 speed) would be a good progress for SH.

I'm fine with that. If someone who _has_ this hardware could get a 
'scope on the card clock and see what frequencies actually appear out 
there, I'd _really_ appreciate it.

In the meantime, I'm going to assume it follows the scheme above.

> And I personally have no 
> idea how I could "find" that divider-disable bit.

Just how sure are you that your chip _doesnt_ have the cnf area, before 
we go to far on this... how did you arrive at that conclusion?

Have you checked to see if it appears at other offsets than it does in 
the MFD chips ?

> Please notice, that I'm 
> away for a week starting tomorrow, hopefully, Magnus will be able to 
> further work with you on this during this time.

Hope so - It was aloways my goal to make tmio-mmc reuseable - thats why 
I pushed for the MFD framework in the first place...

-Ian
--
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/