[PATCH V3 00/10] mmc_of_parse() adaptations, DT support for Sheevaplugs

On Wed, May 22, 2013 at 09:25:02PM +0200, Simon Baatz wrote:

Hi Jason,

On Tue, May 21, 2013 at 09:14:55AM -0400, Jason Cooper wrote:

quoted

On Tue, May 21, 2013 at 01:01:41AM +0200, Simon Baatz wrote:

quoted

Hi,

	V3 changes:
	- Patch 01/10: Added EPROBE_DEFER case to mmc_of_parse() 
	- Added Acked-By to (unmodified) patches 02 and 03.

	V2 changes:
	- Converted mvsdio to use mmc_of_parse()
	- Adapted DTS files using mvsdio accordingly
	- Changed mmc_of_parse() to return errors to the caller

While adding DT support for the Sheevaplugs by Globalscale Technologies
(Kirkwood), it turned out that the DT binding of mvsdio lacked features to
properly support the hardware (active high/low of CD and WP pins could not
be described in DT).

This is standard functionality provided by the mmc_of_parse() helper
function.  However, mmc_of_parse() may allocate GPIO lines.  If the
allocation fails, it outputs an error, but does not return an error to its
caller.  Therefore, a proposal to handle errors in mmc_of_parse() is made.

The patch set is structured as follows:

1   Adapt mmc_of_parse() to return errors
2-6 Handle errors in current drivers using mmc_of_parse() (compile tested
    only)
7-8 Convert mvsdio and respective dts files to mmc_of_parse() (tested on
    kirkwood)
9   Add dts files for (eSATA) Sheevaplug
10  Add DT support for (eSATA) Sheevaplug

Patches 7, 9, and 10 already pulled into mvebu/dt.  You can drop those
from this series if you need to do another revision.

If you don't mind too much, as this crosses two trees, I would prefer
to keep the series "self-contained" if people want to test.

That's fine, you can host the series in a single branch for folks to
pull and test.  From our side, 7, 9 and 10 need to go through arm-soc,
and the rest need to go through -mmc.  There is _no_ build or merge
dependency between the two.

Additionally, I have two Acked-bys for 9 and 10 from Andrew that are
not part of the patches yet.

Yes, I saw those after I sent the PR.  I sent that a little too fast.
I'm developing a new system and still working out the kinks.  Sorry
about that.

quoted

quoted

I could only test on an eSATA Sheevaplug. I found patches with
different LEDs for the Sheevaplug.  Thus, I would highly appreciate if
someone with the hardware could give this a spin on a non-eSATA
version.  

I happen to have one.  Unfortunately, it is currently my primary email
server, dhcp, dns, file server, and a few other irreplaceable things. :(
I *really* need to upgrade/reconfigure ...

FYI:

$ uname -r
2.6.30.2

Yikes.  I'm so embarrassed.  :(  However,

$ uptime
 07:16:42 up 251 days, 0 min,...

before that was over 400 days, then I had an ups failure.

Even without reinstalling, can you please have a look if your
"plug:green:health" LED is really green (mine is blue)?  And if your
kernel already has a "plug:red:misc" LED could you verify whether it
is really there?  Do you happen to know which board revision you
have?

I have one directory under /sys/class/leds, plug:green:health.  It
controls a *blue* led.  There is also a green led, not enumerated.  I'm
sure the results would be better with a more recent kernel...

thx,

Jason.