RE: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

-----Original Message-----
From: Scott Wood
Sent: Saturday, March 19, 2016 2:28 AM
To: Arnd Bergmann; Rob Herring
Cc: Yangbo Lu; linuxppc-dev@lists.ozlabs.org; devicetree@vger.kernel.org;
ulf.hansson@linaro.org; Zhao Qiang; Russell King; Bhupesh Sharma;
netdev@vger.kernel.org; Joerg Roedel; Kumar Gala; linux-
mmc@vger.kernel.org; linux-kernel@vger.kernel.org; Yang-Leo Li;
iommu@lists.linux-foundation.org; linux-i2c@vger.kernel.org; Claudiu
Manoil; Santosh Shilimkar; Xiaobo Xie; linux-clk@vger.kernel.org; linux-
arm-kernel@lists.infradead.org
Subject: Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-
R1.0-R2.0
=20
On 03/17/2016 12:06 PM, Arnd Bergmann wrote:

quoted

On Thursday 17 March 2016 12:01:01 Rob Herring wrote:

quoted

On Mon, Mar 14, 2016 at 05:45:43PM +0000, Scott Wood wrote:

quoted

quoted

quoted

quoted

This makes the driver non-portable. Better identify the specific
workarounds based on the compatible string for this device, or add
a boolean DT property for the quirk.

   Arnd

[Lu Yangbo-B47093] Hi Arnd, we did have a discussion about using DTS

in v1 before.

quoted

quoted

quoted

quoted

https://patchwork.kernel.org/patch/6834221/

We don't have a separate DTS file for each revision of an SOC and if

we did, we'd constantly have people using the wrong one.

quoted

quoted

quoted

quoted

In addition, the device tree is stable ABI and errata are often

discovered after device tree are deployed.

quoted

quoted

quoted

quoted

See the link for details.

So we decide to read SVR from the device-config/guts MMIO block

other than using DTS.

quoted

quoted

quoted

quoted

Thanks.

Also note that this driver is already only for fsl-specific
hardware, and it will still work even if fsl_guts doesn't find
anything to bind to
-- it just wouldn't be able to detect errata based on SVR in that

case.

quoted

quoted

IIRC, it is the same IP block as i.MX and Arnd's point is this won't
even compile on !PPC. It is things like this that prevent sharing the
driver.

=20
The whole point of using the MMIO SVR instead of the PPC SPR is so that
it will work on ARM...  The guts driver should build on any platform as
long as OF is enabled, and if it doesn't find a node to bind to it will
return 0 for SVR, and the eSDHC driver will continue (after printing an
error that should be removed) without the ability to test for errata
based on SVR.
=20

quoted

I think the first four patches take care of building for ARM, but the
problem remains if you want to enable COMPILE_TEST as we need for
certain automated checking.

=20
What specific problem is there with COMPILE_TEST?
=20

quoted

quoted

Dealing with Si revs is a common problem. We should have a common
solution. There is soc_device for this purpose.

Exactly. The last time this came up, I think we agreed to implement a
helper using glob_match() on the soc_device strings. Unfortunately
this hasn't happened then, but I'd still prefer that over yet another
vendor-specific way of dealing with the generic issue.

=20
soc_device would require encoding the SVR as a string and then decoding
the string, which is more complicated and error prone than having
platform-specific code test a platform-specific number.  And when would
it get registered on arm64, which doesn't have platform code?
=20
-Scott

[Lu Yangbo-B47093] Hi Arnd, could you answer Scott's questions?
If you don't oppose this patch, I'd like to rework a new version for mergin=
g.
Thanks.

:)