Any chance to integrate the eth fix into the 4.x kernel tree?

[umiddelb]

Hi,

some Pine64 boards need a fix in order to gain acceptable network speed. Is there any chance to integrate this fix into the 4.x kernel tree?

Cheers Uli

[apritzel]

Thanks for the report and: "Maybe", but definitely not in this form: 1) a64-v6-wip is outdated, sunxi64-4.9-testing is more up-to-date. 2) This Ethernet driver is doomed anyway, since it will be replaced by enhancing the existing Designware driver, as this is what the IP is. 3) This apparently only affects Pine64 boards, doesn't it? So at the very least this would need to be paired with a DT property to only enable it only on Pine64 boards. ifdef'ing is totally out of question. 4) I wonder if this can be done by firmware, to keep the kernel clean from nasty workarounds. But I am afraid a PHY reset would clear this setting. 5) Does this anyhow relate to the existing GMAC RX/TX delay settings? 6) We would need a better description of the bug and workaround and a break down of the actual bits to set, ideally as macros. From skimming over the thread it's just about clearing one bit (RX delay), so why isn't the patch just doing that? 7) The patch commit message is a bit vague, also it speaks of "supposedly" fixing the issue. I would love to see more confidence or testing reports here.

Anyway, those branches are not meant for actual users, they are more documentating the current state of development and can be used for testing or basing patches against. Any fix would need to be made against the upstream kernel, once the driver has been merged.

Cheers, Andre

[ioft]

Hi,

thanks for your clarification. Yes, only some Pine64 boards seem to be affected.

I've tried the sunxi64-4.9-testing branch. Network speed is considerable OK (700 Mbit/s) compared to the patched BSP kernel (reaching 800-900 Mbit/s).

Cheers Uli

[apritzel]

IIRC we don't have any specific RX/TX delay in the default DT, which is not optimal for the Pine64 (however is totally fine for the other A64 and H5 boards here). I measured 950 MBit easily with the BananaPi M64 (I think). So you could give it a try by either adding: tx-delay = <3>; rx-delay = <0>; into the DT node or following the instructions here to do this at runtime from Linux: https://github.com/igorpecovnik/lib/issues/546#issuecomment-264740802

Andre.

[umiddelb]

tlim mentioned a difference between setting the rx delay to 0 or to disable rx delay at all ("setting Rx-delay = 0 does not work since that setting still results in a 2ns delay regardless; the Rx-delay actually has to be disabled."). How can this be done with the methods described above?

[apritzel]

Not easily, because the workaround requires a series of MDIO requests to be made. Eventually I think there would be a DT property to trigger this workaround, something like: disable-rx-delay; It might be a PHY node property (instead of an Ethernet MAC driver one) and may even live in the PHY code, because it is a PHY fix. But I don't believe there will be any patch for the existing driver, as this is a dead horse anyway. It remains to be seen if this can be patched already into the existing generic PHY driver, though I doubt that this would be easily doable in an upstreamable fashion.

[khenriks]

Would it be possible to make a tiny kernel module that just pokes the requisite bits? I know it would be kind of hacky, but for those with bad boards, it would make things more usable. I don't know much about this stuff, though, so I don't know if this would actually be a viable approach.

[khenriks]

I really needed this in order for mainline kernels to be usable, since I have several of the affected boards. I've snooped around and it looks like this fix can be applied from userspace, so I coded up something to do it. I've put it up in a gist here if anyone else wants it. I'm planning to run it from my initramfs, and anticipate I'll be all set.