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: > > On Tue, May 21, 2013 at 01:01:41AM +0200, Simon Baatz wrote: > > > 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. > > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
