linux-kernel - Re: [PATCH 00/05] tmio_mmc: Minor fixes and cnf/irq changes

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, 1 Apr 2009 02:20:21 +0000
From:	Magnus Damm <magnus.damm@...il.com>
To:	Ian Molton <ian@...menth.co.uk>
Cc:	Pierre Ossman <drzeus@...eus.cx>, linux-kernel@...r.kernel.org,
	drzeus-wbsd@...eus.cx, akpm@...ux-foundation.org
Subject: Re: [PATCH 00/05] tmio_mmc: Minor fixes and cnf/irq changes

On 3/31/09, Ian Molton <ian@...menth.co.uk> wrote:
> Magnus Damm wrote:
>
>
> > Ping? Please let me know how you want me to rework the patches. Unless
> > they are ok as-is. Any feedback on how to rewrite them would be
> > greatly appreciated.
> >
>
>  I replied to this earlier. Basically, investigate using the clk API. You
> should also try to work out how your board controls  clock / power to the
> socckets (if it can at all).

The SoC is directly connected to the SD connector. I've verified this
by looking at board schematics. There is no power control hardware on
the boards that I've seen so far, but I'm currently working with
hardware designers to make sure they will add such capabilities to
future boards. The power will then be controlled by board specific
code, most likely using GPIO pins. The hardware block that the
tmio_mmc driver is handling does not have any power control
functionality.

As for the clock API, adding such a feature to the tmio_mmc driver is
not very complicated, especially for the SoC case where we already
have control over all system clocks.

>  Like I said though, IIRC the clk API had shortcommings last time I looked
> which made it impossible to use on MFD devices (its tied to the CPU
> architecture, wheras the MFDs are platform independant. Dmitry did some work
> on this, but I dont recall how far he got.

Some architectures may have clock framework support, some may not. I
guess wrapping the clock functions in #ifdefs is one (ugly) way to
support both cases. And if we consider MFD it certainly becomes more
complicated.

>  Let me know if you come up with answers / solutions to these probelms.
> Until then, NAK - lets do it the right way, one time only. Not hack and
> bodge it repeatedly.

So the current tmio_mmc driver does not use the clock API. With my
patches the clock API us still unused. I agree that working on adding
clock API support is needed, but I don't see how this is related to
single iomem window support.

Regardless of clock API, I still need a way to use the driver with a
single iomem window. Please propose how to use single iomem window
harware with tmio_mmc.

>  Sorry if that seems harsh, but I dont have time to review a hack thats
> going to end up replaced anyway when its done properly.

So exactly what is the "proper" solution for single iomem window support?

And why does single iomem window support have to block on clock API support?

>  Best starting point would be to look up Dmitrys work on making the clk api
> CPU agnostic (if that hasnt already been merged). Then tmio-mmc can be
> modified to reqest a clock from its parent device (be that an MFD core or a
> platform device or whatever).

Yes, that sounds like a good starting point for clock API support.

But... How do I use tmio_mmc with hardware that only has a single
iomem window? I need that regardless of clock API, and that's what the
code in this patch series is all about.

Thanks,

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