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: <aec7e5c30908021952j7947b513w7d62f2c4d87bd3c5@mail.gmail.com>
Date:	Mon, 3 Aug 2009 11:52:00 +0900
From:	Magnus Damm <magnus.damm@...il.com>
To:	Ian Molton <ian@...menth.co.uk>
Cc:	Guennadi Liakhovetski <g.liakhovetski@....de>,
	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>,
	Magnus Damm <damm@...nsource.se>
Subject: Re: MMC: Make the configuration memory resource optional

On Fri, Jul 31, 2009 at 4:21 AM, Ian Molton<ian@...menth.co.uk> wrote:
> Guennadi Liakhovetski wrote:
>
>> While you're at it, please, consider swapping the two lines in
>> tmio_mmc_probe():
>>
>> -       tmio_mmc_clk_stop(host);
>>        reset(host);
>> +       tmio_mmc_clk_stop(host);
>>
>> Otherwise, I think, reset causes problems trying to access the controller
>> with disabled clock. At least this is needed on SuperH.
>
> Interesting. I'll see what the result of this is on TMIO - This sequence was
> garnered from the WinCE driver for the chip.
>
> I cant see _why_ this should be a problem, as this disables the card clock,
> not HCLK. Could you debug further in tmio_mmc_clk_stop() please and see if
> reordering only one of the two IO accesses cures this?

I wonder if the clock framework patch from Guennadi ties in the clock
that drives the TMIO block, instead of the interface clock that is
used to communicate with the physical media? That would explain the
reordering of the tmio_mmc_clk_stop() function.

In my mind, using the clock framework to control the interface clock
sounds like a good plan. As for the clock that drives the TMIO block
itself (that Guennadi's patch tries to control) - on a second thought
it may make more sense to use the upcoming Runtime PM framework to
control that one.

Making use of the Runtime PM comes with a big advantage - it will
provide use with hooks to allow saving and restoring register context
so the power domain containing the TMIO block can be powered off
during runtime.

I'd be happy to fix up the Runtime PM related parts of the tmio_mmc
driver if you'd like. The Runtime PM changes will of course "just
work" in the MFD case - ie do nothing unless your architecture has
support for it.

The recently posted Runtime PM patch for the SuperH Mobile I2C driver
may serve as an example:
http://patchwork.kernel.org/patch/38514/

Another solution is of course to use two clocks in TMIO driver - one
for the interface clock and one for the hardware block itself. This
may be better if you want to control the hardware block clocks from
the MFD layer in the future. Let me know what you think.

Thanks for your help.

Cheers,

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