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: <20090729210319.GB28753@linux-sh.org>
Date:	Thu, 30 Jul 2009 06:03:19 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	pHilipp Zabel <philipp.zabel@...il.com>
Cc:	Ian Molton <ian@...menth.co.uk>,
	Magnus Damm <magnus.damm@...il.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Guennadi Liakhovetski <g.liakhovetski@....de>,
	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 Wed, Jul 29, 2009 at 10:55:31PM +0200, pHilipp Zabel wrote:
> On Wed, Jul 29, 2009 at 10:17 PM, Paul Mundt<lethal@...ux-sh.org> wrote:
> > On Wed, Jul 29, 2009 at 02:51:36PM +0100, Ian Molton wrote:
> >> Magnus Damm wrote:
> >> >Note that I don't need clocklib to get the tmio_mmc driver working for
> >> >my platform. It's something _you_ need for the MFD chips. But you seem
> >> >to want me to fix it for you even though I don't have any particular
> >> >need for it.
> >>
> >> Actually, the tmio-mmc driver works perfectly on the MFD chips right
> >> now. These are the chips it was written to handle.
> >>
> > And these patches are fixing up the mmc driver to support the non-MFD
> > case. If you want to fix up the MFD driver to expose a similar interface
> > to the mmc one as what we are doing with the clock framework, that is
> > fine, but is likewise an unrelated change.
> >
> > Lets evaluate the clock options we have today:
> >
> > ? ? ? ?1) clock framework
> > ? ? ? ?2) clkdev
> 
> 2) is nothing more than an implementation detail of 1). How clk_get
> looks up the struct clk internally should not be of any concern to the
> consumer.
> 
For the sake of the driver, sure. On the architecture side it's a bit
more work. It is on my TODO list to add to the SH clock framework, but it
will take some work, and is out of scope for 2.6.32.

> [...]
> > If you can show what is wrong with how the clock framework is being used
> > in the patch that Guennadi posted, we will certainly rework it as
> > necessary. However, I will not at this point be merging clkdev in to my
> > architecture tree, and clocklib I have never supported. These are things
> > that can be done and supported incrementally, but making these
> > prerequisites is simply blocking progress, especially when there is no
> > consensus on the clkdev/clocklib parts.
> 
> Providing the clock consumer ID via platform data is wrong. As I
> understand it, that ID should be either NULL if the clock can be
> determined from the struct device pointer (i.e. if it's the only clock
> provided to that device), or it should be used to distinguish the
> device's clock input pins (in the tmio-mmc case that would be 'hclk'
> or 'clk32' if I remember the datasheet correctly).
> 
If that's the only issue, then yes, no problem. I agree that passing in
the clock string is not something we really want to be doing, so using
the virtualized clock name here sounds fine. We can mangle it on the
platform side until the clkdev implementation is completed, but none of
that matters to the driver at that point.

This should be taken care of in the next iteration of the patch. Thanks
for your comments!
--
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/