device tree binding documentation outdated

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Fri, Sep 27, 2013 at 06:05:52PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 27, 2013 at 09:15:54AM -0400, Jason Cooper wrote:
> > Russell,
> > 
> > On Fri, Sep 27, 2013 at 12:29:07AM +0100, Russell King - ARM Linux wrote:
> > > I haven't sorted out a rootfs for this yet, so it fails trying to find
> > > that.  (Rabeeh's kernel contained an initramfs buildroot image - it
> > > might be useful to find some way to load that as a separate image -
> > > does appended DT support that?)
> > 
> > yes, point to it in your config, kbuild will build the initramfs in.
> > Appending the dtb and running mkimage has been working fine for me.
> 
> Yes... if I could rip the initramfs out of Rabeeh's kernel.
> 
> Having sorted out the beer problem (pintctrl-names), I now have ethernet
> sort of working, but not quite.  It produces data on my LAN, but that
> data is not correct.
> 
> Here's an extract from the interesting bits that I captured using another
> machine (other bytes are zeros):
> 
> 	0x0000:  ffff ffff ffff d063 0000 0000 0800 4500
> 	0x0010:  0240 0000 0000 0800 4500 0240 0000 4000
> 	0x0020:  4011 38ae 0000 0000 4000 4011 38ae 0043
> 	0x0030:  0200 ffff ffff 0044 0043 022c ffff ffff
> 	0x0040:  0600 5fe9 bf2c 0000 0101 0600 5fe9 bfd8
> 	0x0050:  0002 0000 0000 0000 0000 0002 0000 0000
> 	0x0060:  0000 0000 0000 0000 0000 0000 0000 0000
> 	0x0070:  0000 0000 0000 0000 d063 0000 0000 0000
> 	0x0080:  0000 d063 0000 0000 0000 0000 0000 0000
> ...
> 	0x01d0:  0000 0000 0000 0000 0000 0000 0000 6382
> 	0x01e0:  0000 0000 0000 0000 0382 5363 3501 0137
> 	0x01f0:  0801 0306 5363 3501 0137 0000 0006 0c0f
> 	0x0200:  111a 28ff 0000 0000 0c0f 111a 0000 0000
> 
> That data has a pattern to it.  It's supposed to be a DHCP packet, which
> would be something like (this is from the same board but booting Rabeeh's
> kernel instead):
> 
> 	0x0000:  ffff ffff ffff d063 0000 0000 0800 4500
> 	0x0010:  0240 0000 4000 4011 38ae 0000 0000 ffff
> 	0x0020:  ffff 0044 0043 022c 0000 0101 0600 5e9a
> 	0x0030:  dac5 0000 0000 0000 0000 0000 0000 0000
> 	0x0040:  0000 0000 0000 d063 0000 0000 0000 0000
> 	0x0050:  0000 0000 0000 0000 0000 0000 0000 0000
> ...
> 	0x0110:  0000 0000 0000 6382 5363 3501 0137 0801
> 	0x0120:  0306 0c0f 111a 28ff 0000 0000 0000 0000
> 
> Now, there's a pattern to the corruption - let me rearrange them slightly:
> 
> ff ff ff ff ff ff d0 63
> 
> 00 00 00 00 08 00 45 00 02 40
> 00 00 00 00 08 00 45 00 02 40
> 
> 00 00 40 00 40 11 38 ae 00 00
> 00 00 40 00 40 11 38 ae
> 
> 00 43 02 00 ff ff ff ff 00 44
> 00 43 02 2c ff ff ff ff 06 00
> 5f e9 bf 2c 00 00 01 01 06 00
> 5f e9 bf d8
> 
> 00 02 00 00 00 00 00 00 00 00
> 00 02 00 00 00 00 00 00 00 00
> 
> 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00
> d0 63 00 00 00 00 00 00 00 00
> d0 63 00 00 00 00 00 00 00 00
> 00 00 00 00
> ...
> 
> 00 00 00 00 
> 00 00 00 00 00 00 00 00 00 00
> 63 82 00 00 00 00 00 00 00 00
> 03 82 53 63 35 01 01 37 08 01
> 03 06 53 63 35 01 01 37 00 00
> 00 06 0c 0f 11 1a 28 ff 00 00
> 00 00 0c 0f 11 1a 00 00 00 00
> 
> That's the same order of bytes as in the original packet.  Notice how there
> are identical bytes between ones below and above, and notice how the repeated
> groups of bytes are always 10 bytes apart.  No, it's not giving any errors
> in the interface which I ran tcpdump on!
> 
> I'm not yet sure what could cause this...

An interesting data point.  Connect it to a 100mbit switch and it works.
gigabit and it behaves as above.

So, the question is: does anyone have gigabit networking working on imx6
with recent DT based kernels?