linux-kernel - Re: [PATCH 03/05] tmio_mmc: Break out cnf area operations

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: <aec7e5c30903111913y38041a68r4742779103c7df1b@mail.gmail.com>
Date:	Thu, 12 Mar 2009 11:13:49 +0900
From:	Magnus Damm <magnus.damm@...il.com>
To:	Ian Molton <ian@...menth.co.uk>
Cc:	linux-kernel@...r.kernel.org, drzeus-wbsd@...eus.cx,
	akpm@...ux-foundation.org
Subject: Re: [PATCH 03/05] tmio_mmc: Break out cnf area operations

On Wed, Mar 11, 2009 at 11:39 PM, Ian Molton <ian@...menth.co.uk> wrote:
> Magnus Damm wrote:
>>
>> From:  Magnus Damm <damm@...nsource.se>
>>
>> Break out tmio_mmc io operations for the cnf area.
>> This moves similar register operations into one place.
>
> Not sure about this one yet. AFAICT this totally disables the HBA power
> control.

Hm, my plan was not to introduce any changes to the register accesses.
With this patch code is only broken out, and the patch after this
makes it possible to use this driver without the cnf block. For
hardware with the cnf block included there should be no change. Unless
I made some mistake that is. =)

> I'm wondering if this is a common problem.
>
> It seems to me  that its likely that clock and power control are often
> external to the host controller chip. (not just on TMIO MMC).

I agree. These patches show just that.

> I think it'd be a good idea if we came up with an infrastructre that allowed
> a set of clock / power control callbacks into the platform code.
>
> Whats your use case for this? samee applies to the related cnf patch too.

Please wait for platform data patches. They will be sent out late
before -rc1 if we can agree on some way to make the cnf area optional.
Without that (this patch and the next) we can't really use this driver
so platform data patches are pointless. =)

This is lucky guesswork. I just happened to figure out that I can use
the tmio_mmc driver to drive the ctl block of this hardware. As for
memory window setup, voltage control, and hotplug - I have no idea. No
docs apart from the Toshiba docs that I can find online. But breaking
out the power control and hotplug management sounds like a good plan.

As for clock control, maybe breaking out that as well is a good idea.
At least part of it. The first thought that pops into my mind is to
tie in the clock framework. So we can use clk_enable() and
clk_disable() for run time power management and call clk_get_rate() to
figure out the parent clock rate and use that to calculate the divider
for CTL_SD_CARD_CLK_CTL. Not sure if the clock framework is supported
on your target platforms though.

Do you have any recommended hardware platform to test this driver?
I'll try to find such hardware platform (or similar) so I have
something to compare with. Unfortunately I don't have that much time
to spend on this. But an hour here and there is probably fine.

How would you like to proceed? I'd prefer to merge this first and
break out after, but I'm not sure if that fits well with your plan.

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/