[Patch V2 2/2] i2c: mv64xxx: Remove internal compatible string from Documentation

[arnd@arndb.de (Arnd Bergmann)]

On Monday 28 July 2014 15:27:16 Andrew Lunn wrote:
> > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
> > > index 5c30026921ae..6eb6f6e40ba1 100644
> > > --- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
> > > +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
> > > @@ -9,11 +9,6 @@ Required properties :
> > >                       - "allwinner,sun6i-a31-i2c"
> > >                       - "marvell,mv64xxx-i2c"
> > >                       - "marvell,mv78230-i2c"
> > > -                     - "marvell,mv78230-a0-i2c"
> > > -                       * Note: Only use "marvell,mv78230-a0-i2c" for a
> > > -                         very rare, initial version of the SoC which
> > > -                         had broken offload support.  Linux
> > > -                         auto-detects this and sets it appropriately.
> > 
> > I think we're losing knowledge here.  *We* know that attempting to
> > enable transaction offload on A0 SoCs is bad news.  Other OS's would now
> > need to dig through the Linux kernel code for clues as to what's
> > happening.
> > 
> > Perhaps we should retain the info in the form of a note at the bottom of
> > this file?
> 
> Hi Jason
> 
> I did wounder about this a bit. I've not looked, but now that XP
> datasheets are public, i assume there is an errata for this, so it at
> least should be documented by Marvell. But anybody looking in
> /proc/device-tree on an A0 is going to see this undocumented string
> which might raise questions.
> 
> So i'm happy to document it at the end of the binding.
> 
> Arnd, what do you say?

The final consequence of the API change would be to no longer
change the compatible string in the fixup, but instead to call an
API from the driver to find out the SoC revision when it encounters
an mv78230-i2c.

I remember this being discussed when the quirk was initially added,
but it seemed cleaner to handle this in the platform code at the time
when it was just for one particular board. Now that it's basically
an accepted feature of the i2c device that you have to know the
SoC version, that should probably become a proper API.

Also, we now have drivers/soc/ and can move the soc-id code there
with a publically documented API.

I agree it's sad to lose the knowledge about the revision, but we
already have that as we now accept the generic string even on the
a0 machines other than ax3.

	Arnd