DP83825I: Is this driver support in linux kernel 4.18?

Hi Shane,

Thanks for your reply. As u mentioned DP83822 do support the DP83825, but any changes is needed? like the register id (#define DP83825I_PHY_ID     0x2000a150) or any others 

Hi,

I'm not aware of any changes needed to get this driver working with DP83825. Are you having issues using this driver?

Best,

Shane

Hi,

I plan to use the DP83825I driver, but I'm concerned I might have overlooked something. I found this patchset (github.com/.../06acc17a96215a11134114aee26532b12dc8fde1 )—are there any other prerequisites for successfully bringing up the driver?

Thanks.

Good catch. Looking at the 4.18 driver I don't see definitions for DP83825. It seems this was updated in a later version of the driver.

I recommend using the patchset you've linked to add DP83825 support to this driver. If you run into any issues with this let me know.

Best,

Shane

Hi, thanks for your confirmation.

I've developed a device tree for the DP83825I PHY and would like your assistance in verifying its correctness especially the "compatible" property.

&mdio {
pinctrl-names = "default";
pinctrl-0 = <&mdio_pins>;
bus_freq = <2200000>;
status = "okay";
phy1: ethernet-phy@2 {
compatible = "ti,dp83825I", "ethernet-phy-ieee802.3-c22"; // compatible = "ti,dp83822", "ethernet-phy-ieee802.3-c22";
reg = <0x2>; /* PHY address */
};
phy2: ethernet-phy@3 {
compatible = "ti,dp83825I", "ethernet-phy-ieee802.3-c22"; // compatible = "ti,dp83822", "ethernet-phy-ieee802.3-c22";
reg = <0x3>; /* PHY address */
};
};

&pmx_core {
status = "okay";
rmii_pins: pinmux_rmii_pins {
pinctrl-single,bits = <
/*
* RMII_TXD_1, RMII_TXD_0, RMII_TXEN
* RMII_RXD_1, RMII_RXN_0, RMII_RXER
*/
0x38 0x88888800 0xffffff00
/*
* RMII_MHZ_50_CLK, RMII_CRS_DV
*/
0x3c 0x00000080 0x000000ff
>;
};
};

&eth0 {
pinctrl-names = "default";
pinctrl-0 = <&rmii_pins>;
ti,davinci-rmii-en = /bits/ 8 <1>;
phy-mode = "rmii";
phy-handle = <&phy1>;
status = "okay";
};

The compatible field you show looks correct relative to the patch.

Without the compatible field, the device tree will still probe the PHY address at reg = <x> and identify the PHY ID at this address, loading the corresponding driver.

Basically this field is not required and should not hurt if it is incorrect.

Best,

Shane

Thanks for your confirmation.

1 more question is regarding the driver, how can I specify it to use polling or interrupt mode in the device tree? And what is its default mode?

There shouldn't be a 'polling mode' or 'interrupt mode' in the driver. Polling vs interrupt methods of handling data would be set depending on each function individually. 

The driver for this PHY uses interrupts in certain cases, but does not use polling.

Best,

Shane

I see. Then do we have a test script like the sample below to test the DP83825I? 
chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/www.ti.com/.../snlu197.pdf

I'm struggling to open the chrome-extension link you've provided, but I see our USB2MDIO user's guide is included.

Do you need a test script similar to the example in the USB2MDIO users guide?

Best,

Shane

Hi Shane,

ya. I need the test script in the USB2MDIO for the DP83825I one, as the example is for the DP83867.

Thanks

I took that example script and adjusted it to fit the DP83825I register map. Try this and let me know if you run into issues:

begin

//delay 100
001f 8000 // restart core

0000 2100 // force 100Mbps, full-duplex

0019 0021 // 0021 - mdi , 4021 - mdix

// Enable BIST mode
//echo BIST
0016 7008 // use termination outside RJ45, Analog loopback //Continuous PRBS, Enable checker, Enable PRBS, Transmit 64 packets

001f 4000
//delay 200

// loop 5
// Reads GEN_STATUS
// NOTE: First read clears LH, Second read has actual status
// Value should be 7A08, PBRS checker locked and sync
0016
0016
// NOTE: First read clears LL, Second read has actual status
//0001 //bit 2 will give indication if we have link fails
//0001
001B 807D // lock & clear PRBS counters
001C // rd byte counter to observe bytes are indeed received
001B // rd errors counter. should read 0
// endloop

0000

end

Hi Shane, as you mentioned, it doesn't use a polling method for dp83825I. If I want to get an interrupt to the user space when the link status changes, is there anything that I should modify to achieve this?

Here is the device tree that i have.
phy: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c22"; // compatible = "ti,dp83822", "ethernet-phy-ieee802.3-c22";
reg = <0x0>; /* PHY address */
interrupt-parent = <&gpio>;
interrupts = <127 IRQ_TYPE_LEVEL_LOW>;
};

Hi Weihan,

The 825 driver does not contain any prints kernel log / user space to indicate link status interrupt changes - this is likely handled by MAC driver.

The PHY driver is responsible for configuring the correct interrupt on the PHY and reporting the link status to MAC driver. Can you read the PHY interrupt registers after boot to confirm the device tree sets the intended interrupt mode?

Best,

Shane