DP83867IS: Unstable link unless forcing MDI master mode

Hi Jesse,

Please share the schematic (can email to e-mayhew@ti.com for private share).

It's possible the master/slave resolution with the link partner is failing until DP83867 is forced into master mode - I would like to confirm the configuration of the DP83867 and its link partner.

The register workaround with 0x31[7] = 0 is sufficient if RX_CTRL cannot be strapped.

Thank you,

Evan

Hey Evan,

I've sent you an email with the schematics, the link partner in this instance is a netgear GS108v4 but we've seen this less regularly on other switches, though finding some sort of trigger or way it starts failing is difficult, sometimes it stays good for long periods and then goes bad often

We've tried heating up the components to see if temp had any influence but that didn't seem to be the case

Thank you for the confirmation on the register,

Jesse

Hi Jesse,

Thank you for sharing the schematic - I don't see any issues with the pinout.

How are you setting the device in master mode? Please share the following register dumps:

- Working case with forced master mode, registers 0x0 to 0x1F, and any additional registers you are writing

- Failing unstable link case, registers 0x0 and 0x1F

Thank you,

Evan

Hello Evan,

Apologies for the late reply, we shifted a bit in our debugging and stumbled upon what we think is an undocumented issue related to the missing RX_CTRL bootstrap in mode 3.

We noticed that the module we are using was enabling EEE, and if we look in the phy driver call to check EEE capability, it says that it is EEE capable.

Manually forcing EEE off seems to resolve our issues, we were not able to find this in any datasheet or errata except in a forum thread from a couple years ago.

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/716392/dp83867ir-eee-energy-efficient-ethernet-with-dp83867

The datasheet also seems to not be fully correct, as it says the only DEVAD supported is 0x1F, however the PCS is defined and accessible, so with the following commands

phytool write eth0/0/0x0d 0x3
phytool write eth0/0/0x0e 0x14
phytool write eth0/0/0x0d 0x4003
phytool read eth0/0/0x0e

We read back 0x6 which matches with the EEE cap for 100/1000 that we are seeing, but it's confusing because the datasheet specifies that the only supported DEVAD should be 0x1F.

We have also tried a couple things such as setting/clearing the test mode bit in CFG4/0x31 and then doing SW resets, but none of this clears the EEE capabilities in the PCS register.

Would you be able to verify this issue exists as described? Is this something the ethernet/kernel/uboot team would be able to upstream a driver patch for? We can also look into trying to do this ourselves if we know what a proper fix for this would look like if you are able to confirm the issue and a potential workaround.

Thank you,

Jesse

Hi Jesse,

To clarify, setting RX_CTRL in mode 3 to disable EEE is resolving the issue?

EEE is a deprecated feature on DP83867IS, there are reserved registers in PCS space for EEE but they should not be modified for the application.

What driver are you using? We are not currently able to upstream drivers to the official Kernel, but we can patch and share drivers from our internal repo.

Thank you,

Evan

Hey Evan,

We are not modifying these registers, we are not even able to hence my initial ask for the workaround.

Our electronics engineer is currently modifying one of our boards to strap RX_CTRL in mode 3 and we assume this will resolve the issue based on the linked thread.

We're using the standard kernel driver for dp83867 (on version 5.10.120) but we found another workaround that already exists in the kernel (broken eee seems to be that common), by adding the 'eee-broken-100tx' and 'eee-broken-1000t' properties to the phy, this disables their advertisement and seems to do the job, but it would be good to have some confirmation on the existence of this issue and to what extent it will be fixed by the pin strapping, as we need to keep this in mind for future designs.

We think this behavior should at least be documented with more emphasis on the pin strapping being required and causing this EEE issue if not done, on top of the internal test mode that needs to be disabled, or put as an errata because it was quite difficult to track down as there's no obvious errors going on that notify you this is going, it was especially confusing because the extended space only talks of custom access with 0x1F but access to device 3 for the PCS space is possible, hence I initially didn't look much further into EEE as a possible cause.

Hey Evan,

At this moment this workaround will suffice for us, after a day of testing on multiple devices we've seen no further issues.

Fully agree on the documentation gap, if it can help even one person avoid the headache of debugging this that would be great! The way my team was currently reading the documentation it was as if the CFG4 bit 7 workaround was sufficient to get it working properly, so it's good to hear that will be addressed with more emphasis.

I very much appreciate you taking the time to look into it and taking the feedback, thanks for the help!

Thank you,

Jesse