On Sep 17, 2012, at 8:09 PM, Huang Changming-R66093 wrote:

quoted

On Sep 17, 2012, at 7:36 AM, Chris Ball wrote:
=20

quoted

Hi,
=20
On Thu, Sep 13 2012, Kumar Gala wrote:

quoted

quoted

quoted

Can you list out which SoCs support it and which don't.  Having
this list will be useful in understanding which controller =

versions

quoted

supported it.

quoted

quoted

quoted

quoted

=20

P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, =

p3041)

quoted

support it.

quoted

quoted

=20
Based on this, why don't we use the HOSTVER register to detect =

instead

quoted

of device tree:

quoted

=20
I've got a mild preference for handling quirk assignment in the DT
rather than in driver code, so I'd prefer to just push the original
patch to mmc-next as-is.  Does that sound okay?

=20
Why?  I only ask because I agree with Scott that this means you have =

to

quoted

update your device tree to get proper functionality.
=20

When the new silicon does not support CMD23,
if we don't update the device tree, then we must update the SDHC =

driver.

I prefer to add the property in device tree,
because we just add this property in new device tree, we don't need =

more effort to modify driver.

=20

Jerry,

I think doing it driver makes more sense because:

1. means older device tree's still work
2. odds that CMD23 not being supported in future devices is near 0%
   (Now that we support AutoCMD23 [and thus CMD23] we aren't likely to =
stop supporting it in future)
3. If IP changes you are going to have to update driver anyways for new =
features

I really think we should NOT utilize device tree for this.

- k