MMC is *still* broken...

[Russell King - ARM Linux]

On Sun, Jun 08, 2014 at 11:55:19AM +0200, Hans de Goede wrote:
> 4) Implementation wise I think we all agree that we want to use a platform
> device + driver. So the mmc-core would check for a subnode with reg == 0 and if
> there is one instantiate a platform device from this, using the subnode as the
> platform devices of_node, and the platform driver for the powerup will be bound
> using the compatible string of the subnode.

I really don't think so on the platform device/driver issue.  Greg keeps
saying that he wants to kill these off, so really we need to stop inventing
new use cases for them.  We're just making more work for ourselves for
when Greg decides to put a block on any further platform drivers - at that
point, we will be forced to rewrite it not to use platform drivers.

So, we need to take account of that today, and *not* use a platform device/
driver for this.

What's also disappointing is that we're close to six months on this issue,
and we still don't have a proper solution to the problem, meanwhile we have
devices out there in the wild where mainline kernels can't be used with
wifi/bt because of our lack of progress on this issue.

While it is important to get interfaces correct, we also can't sit around
being indecisive like this - because the result is we just end up driving
people away from mainline to vendor kernels.  That's exactly what has
been happening.

99% of people run Jon Nettleton's kernels on the Cubox-i because that's
the only modern kernel which supports most of the hardware... why should
anyone bother with mainline given that even 9 months down the line (it's
been 9 months since developers had the initial hardware), mainline kernels
remain mostly crippled on this hardware... anything beyond MMC or NFS boot
and basic GUI... forget it with mainline... not even the eSATA port works
with mainline kernels.

This rather makes me wonder why I'm even bothering _trying_ to get support
for this hardware into mainline - I'm probably completely wasting my time
on that.

(Note: I'm not blaming you, Hans, for this - I'm merely pointing out the
amount of time that has been collectively wasted on this topic and we
*still* seem to be no closer to any kind of solution to it.  Much of that
is because we can't decide on a reasonable DT description.  Board files
with platform data was /loads/ easier because we could come up with
solutions to these kinds of problems much faster there...)

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.