DP83867IS: Linux driver supports retrieving settings and parameters from ACPI tables

Hi Rich!

Thanks for submitting your query, I'll gladly assist. Firstly I want to point you to our Github, where you can find our most up-to-date drivers.

Can you tell me more about this comment?

Rich Chen said:

DP83867 driver will send RESET commend via SGMii to reset DP83867 to default value

I want to confirm, are you saying that after Linux is loaded, the PHY is sending the SoC a RESET command via SGMII, where a pin reset is applied to the PHY? How do you know this? The driver should not be modifying the LED registers and the customer's implementation of writing the registers in the BIOS should work.

Regardless, if the PHY is RESET (i.e. low signal on the RESET pin) all the register values will revert to the default strap settings. 

Rich Chen said:

2. Does Linux driver support retrieving setting and parameters from ACPI tables?

The driver does not support this feature.

Regards,

Alvaro

Alvaro, 

1. When Linux boot up on x86, we add debug log in Linux driver and found RESET command will be sent from x86 via SGMII to DP83867 so all the registers in DP83867 got reset. It is not a hardware pin to reset DP83867 which we confirmed the reset pin status doesn't got chance.

2. Thanks for the confirmation. 

BR, Rich 

Hi Rich,

Thank you for confirming. Would it be possible to read the PHY's registers before and after x86 boots into Linux? I want to find where during the board bootup the registers are getting reset. Below I have the test procedure.

• Read Register 0x0 - 0x1F, 0x6E, & 0x6F 
  • During the BIOS initialization
  • After the Linux Kernel is loaded
    • Once the kernel registers are read, can you write Reg 0x1F = 8000
      • This is a digital restart in the PHY, and will revert all registers to their default strapped state
    •  Run the command:
      • ifconfig interface down
      • ifconfig interface up
        • interface can be eth0, whichever one the DP83867 is in your system, can be confirmed by running the following command:
          • dmesg | grep mdio
        • The purpose of this command is to reload the driver, to see if it is making any changes to the default values (acquired by running Reg 0x1F = 8000)

Could you please capture the requested data in a table like the one below? This will make it easier to review the changes.

Note: Reg 0x6E & 0x6F are extended registers, see Section 7.4.2.1.3 in the data sheet for more information. 

Regards,

Alvaro

Hi Alvaro,

We added some debug messages in the dp83867 driver to read the LED register values upon entering the driver’s init function, "dp83867_of_init." The values matched those configured in the BIOS. However, upon entering the driver’s reset function, "dp83867_phy_reset," the LED register values reverted to their default settings.

In "dp83867_phy_reset," the driver writes bit 15 of register 0x1F to 1. According to the datasheet, this initiates a full reset, including resetting all registers.

We are working on an x86 Linux system without DTS, so we configure the LED settings during the BIOS stage. Unfortunately, these settings are lost after the “dp83867_phy_reset”.

To resolve this, it may be necessary for the driver to check the register settings before performing the “Software Reset,” store the current settings, and then restore them after the reset is complete. Please advise. Thank you!

Best Regards,
Amy Shih
Advantech ICVG x86 Software
02-7732-3399 Ext. 1249 

Hi Amy,

Thank you for confirming, this is the issue. The DP83867 driver on our Github (linked below) does not set bit 15 of Reg 0x1F.

However the driver available on Kernel.org has the reset as you describe it. The screenshots below are from the Kernel.org link.

This is a very simply fix, only one variable needs to be changed! Please find the description below.

1. Confirm the driver you are using has both of these Macros declared: DP83867_SW_RESET & DP83867_SW_RESTART
   1. 
2. In the phy_reset function, change DP83867_SW_RESET to DP83867_SW_RESTART
   1. 
3. Make sure rebuild the file before testing

Regards,

Alvaro

Hi Alvaro,

Thank you for following up.

I traced the log of `dp83867.c` on Kernel.org and found that the commit "net: phy: dp83867: perform soft reset and retain established link" link introduced the use of `"DP83867_SW_RESTART"`. However, the subsequent commit "Revert 'net: phy: dp83867: perform soft reset and retain established link" link rolled back to `"DP83867_SW_RESET"`, resulting in a full reset, including registers.

Our customer prefers not to hard-code or rebuild the driver as a workaround for this issue. Based on your description, performing "DP83867_SW_RESET" may not be the correct action here. The best solution, in this case, would be for TI to upstream an updated driver to Kernel.org. Could you let me know if this is feasible? Thanks!

Best Regards,
Amy Shih
Advantech ICVG x86 Software
02-7732-3399 Ext. 1249 

Hi Amy,

My team is currently learning the upstream process. We will eventually push all of our up-to-date drivers to kernel.org, previously this was done by a 3rd party. Unfortunately it will be some time before the driver is upstreamed to the mainline Kernel. 

Regards,

Alvaro

Hi Alvaro,

Thank you for following up.
Currently, we will use the DP83867 driver from your GitHub. In the meantime, please let us know when the driver has been upstreamed to the mainline kernel.

Best Regards,

Amy Shih
Advantech ICVG x86 Software
02-7732-3399 Ext. 1249