Message-ID: <4A6F30AF.4000004@mnementh.co.uk>
Date:	Tue, 28 Jul 2009 18:09:03 +0100
From:	Ian Molton <ian@...menth.co.uk>
To:	Guennadi Liakhovetski <g.liakhovetski@....de>
CC:	linux-kernel@...r.kernel.org, Magnus Damm <damm@...nsource.se>,
	akpm@...ux-foundation.org, Matt Fleming <matt@...sole-pimps.org>,
	Philip Langdale <philipl@...rt.org>,
	Dmitry Baryshkov <dbaryshkov@...il.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>
Subject: Re: [PATCH] tmio_mmc: Optionally support using platform clock

Guennadi Liakhovetski wrote:

> Hi Ian

Hi!

> Thanks for the review.

No problem - I hope you dont feel that I am picking on you in particular 
here, this problem is not isolated to your patches.

> I understand your concerns. Of course, the _proper_ solution would be to 
> implement an architecture-independent clock API, something like what 
> clocklib was trying to do. So, yes, if clocklib were in place now, I 
> certainly would have used it.

Which is of course a chicken/egg situation. I dealt with this a number 
of times during the e-series development, and every time, integration 
with mainline has gone more swiftly and with better quality, when the 
job was done properly to begin with.

> I searched for those clocklib submission attempts (Dmitry added to CC). 

Also adding RMK to the CC:

> Last one I can find (maybe I missed some) is from July 2008 - more than a 
> year ago. So, looks like our options currently are:
> 
> 1. wait for new submissions of clocklib - if any are planned

Dmitry: whats the current status of your clocklib work?

> 2. develop a completely new arch-independent clock API approach

No chance.

> 3. take over patches from Dmitry and bring them to a state acceptable for 
> mainline

Take over / collaborate with. I'll happily help people push these patches.

> I personally don't have free (as in beer) time to work on 2 or 3. Anyone?

If I can find out what the current state of this stuff is, I'll help get 
it working - I can test / update all the TC6x and T7x MFD devices (and 
probably asic3 too)

> So, unless we hear, that one of the 1-3 is going to happen real soon now, 
> I think, it would be unfair to leave SuperH without a proper MMC driver in 
> the mainline for an indefinite time, when one can be trivially achieved.

Yes, because listening makes code write itself...

If the changes are so trivial, it wont hurt to maintain them as a patch. 
certainly tmio-mmc doesnt change very rapidly so the patch wont need 
regenerating much. You already have this patchset.

So since thats taken care of, we're all now free to work on updating 
the clock API. And once thats done, you can drop your patch and add one 
line to create / alias the clock in your superH platform code.

> As for your debugging concern, we could allow configuration-less operation 
> only on SuperH in tmio_mmc, how about that?

No. The correct way to support optional parts of the hardware is to 
simply not access them when they are not there.

As I said, I'll happily take a patch to abstract power control for the 
tmio-mmc driver. This should remove most of the config area accesses 
from the driver (and shrink your patch!). The remainder are all about 
clock config, and will disappear once we sort the clock API.

Mainline isn't about 'fair' its about 'right'.

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

Powered by blists - more mailing lists