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] [day] [month] [year] [list]

Date:	Wed, 01 Apr 2009 20:00:28 +0100
From:	Ian Molton <ian@...menth.co.uk>
To:	Magnus Damm <magnus.damm@...il.com>
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

Magnus Damm wrote:

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

Which SoC? (I think you said before, but I forgot).

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

Great stuff.

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

The problem (as I pointed out, and you noted below) is that we cant only 
consider the SoC case because there ARE other current users of the 
device in-tree and they use MFD. They arent going away.

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

I dont mind tmio-mmc requiring the clk api. its only used on embedded 
platforms and these usually have clk support.

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

  Because that second iomem window is _purely_ in control of clock and 
power management.

Rather than design a bunch of special callbacks for clock control which 
will later be got rid of I think it is better that we create the proper 
infrastructure in the first place. Its on my to-do but IIRC Dmitry has 
done some work on it already and you're more than welcome to finish that 
work off.

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

If you dont want to extend the clk api to cover it, you can use a patch 
in your local tree?

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

Extand the clk API to be arch agnostic.

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

Because with clk API support it is not necessary.

> But... How do I use tmio_mmc with hardware that only has a single
> iomem window?

if you get the clk API support generalised, I personally promise I will 
rip out the second IO window myself and move it to the TMIO/ASIC3 MFD 
core (where it belongs). Then we both get what we want.

> I need that regardless of clock API, and that's what the
> code in this patch series is all about.

Not regardless. single IO window in the tmio-mmc driver is  _dependant_ 
on clk API support, IMO.

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