Atheros 8035 PHY only works when at803x_config_init() is commented out

Hello everyone,

I have a weird problem, that I've only started investigating, and I'd be grateful if anyone can help me along.

I have an ARM-based SoC that provides (AFAIU) an Atheros 8035 PHY.

If I enable the driver in my kernel (CONFIG_AT803X_PHY) then something goes wrong, and the system cannot load the nfsroot. Bizarrely, DHCP seems to work (so there is limited connectivity) but then the NFS server just times out.

However, if I just comment this line:

    //.config_init = at803x_config_init,

in at803x_driver[0]
then everything seems to work. (At least, the system sets the PHY to Gbit, and manages to download the nfsroot.)

If I'm reading the code right (big "if"), when config_init is NULL, then phy_init_hw() turns into a NOP?

So either at803x_config_init() or something called from phy_init_hw() seems to be hosing this system's networking?

Sprinkling printk over phy_init_hw shows no errors (no premature exit) and phydev->drv->config_init(phydev) returns 0.

Maybe I didn't set something up correctly, and phy_write() is scribbling over the wrong register?

Does anyone see something I missed?

Quoted 24 lines · Mason

Hello everyone,

I have a weird problem, that I've only started investigating, and I'd be grateful if anyone can help me along.

I have an ARM-based SoC that provides (AFAIU) an Atheros 8035 PHY.

If I enable the driver in my kernel (CONFIG_AT803X_PHY) then something goes wrong, and the system cannot load the nfsroot. Bizarrely, DHCP seems to work (so there is limited connectivity) but then the NFS server just times out.

However, if I just comment this line:

    //.config_init = at803x_config_init,

in at803x_driver[0]
then everything seems to work. (At least, the system sets the PHY to Gbit, and manages to download the nfsroot.)

If I'm reading the code right (big "if"), when config_init is NULL, then phy_init_hw() turns into a NOP?

So either at803x_config_init() or something called from phy_init_hw() seems to be hosing this system's networking?

Quoted 7 lines

Sprinkling printk over phy_init_hw shows no errors (no premature exit) and phydev->drv->config_init(phydev) returns 0.

Maybe I didn't set something up correctly, and phy_write() is scribbling over the wrong register?

Does anyone see something I missed?

So one possibility could be that the bootloader initializes the PHY in a certain way, typically by applying workarounds, and your config_init() callback is not restoring any of theses, which is why, after phy_init_hw(), which does a software reset of the PHY, all of these workarounds are wiped out, and your PHY behaves funky.

The reason why config_init() needs to put the PHY back into a fully functional state is because the PHY library should be able to software reset the PHY when it needs to, but also be able to deal with deep sleep modes etc.. where the PHY could loose its settings, yet the kernel should be able to bring you back in a good state.

An easy way to bypass that is to provide a soft_reset calback which does nothing, and see if calling either at803x_config_init(), or genphy_config_init() is sufficient to preserve the PHY settings. Although the real solution is to look at what the bootloader does on that front and replicate it in the config_init() callback.

Hope this helps.

Quoted 22 lines · Mason

I have a weird problem, that I've only started investigating, and I'd be grateful if anyone can help me along.

I have an ARM-based SoC that provides (AFAIU) an Atheros 8035 PHY.

If I enable the driver in my kernel (CONFIG_AT803X_PHY) then something goes wrong, and the system cannot load the nfsroot. Bizarrely, DHCP seems to work (so there is limited connectivity) but then the NFS server just times out.

However, if I just comment this line:

     //.config_init = at803x_config_init,

in at803x_driver[0]
then everything seems to work. (At least, the system sets the PHY to Gbit, and manages to download the nfsroot.)

If I'm reading the code right (big "if"), when config_init is NULL, then phy_init_hw() turns into a NOP?

So either at803x_config_init() or something called from phy_init_hw() seems to be hosing this system's networking?

Quoted 7 lines

Sprinkling printk over phy_init_hw shows no errors (no premature exit) and phydev->drv->config_init(phydev) returns 0.

Maybe I didn't set something up correctly, and phy_write() is scribbling over the wrong register?

Does anyone see something I missed?

So one possibility could be that the bootloader initializes the PHY in a certain way, typically by applying workarounds, and your config_init() callback is not restoring any of theses, which is why, after phy_init_hw(), which does a software reset of the PHY, all of these workarounds are wiped out, and your PHY behaves funky.

The reason why config_init() needs to put the PHY back into a fully functional state is because the PHY library should be able to software reset the PHY when it needs to, but also be able to deal with deep sleep modes etc.. where the PHY could loose its settings, yet the kernel should be able to bring you back in a good state.

An easy way to bypass that is to provide a soft_reset callback which does nothing, and see if calling either at803x_config_init(), or genphy_config_init() is sufficient to preserve the PHY settings. Although the real solution is to look at what the bootloader does on that front and replicate it in the config_init() callback.

[ Problem with Atheros AR8035 PHY reset ]

Quoted 44 lines · Florian Fainelli

Quoted 22 lines · Mason

I have a weird problem, that I've only started investigating, and I'd be grateful if anyone can help me along.

I have an ARM-based SoC that provides (AFAIU) an Atheros 8035 PHY.

If I enable the driver in my kernel (CONFIG_AT803X_PHY) then something goes wrong, and the system cannot load the nfsroot. Bizarrely, DHCP seems to work (so there is limited connectivity) but then the NFS server just times out.

However, if I just comment this line:

     //.config_init = at803x_config_init,

in at803x_driver[0]
then everything seems to work. (At least, the system sets the PHY to Gbit, and manages to download the nfsroot.)

If I'm reading the code right (big "if"), when config_init is NULL, then phy_init_hw() turns into a NOP?

So either at803x_config_init() or something called from phy_init_hw() seems to be hosing this system's networking?

Quoted 7 lines

Sprinkling printk over phy_init_hw shows no errors (no premature exit) and phydev->drv->config_init(phydev) returns 0.

Maybe I didn't set something up correctly, and phy_write() is scribbling over the wrong register?

Does anyone see something I missed?

So one possibility could be that the bootloader initializes the PHY in a certain way, typically by applying workarounds, and your config_init() callback is not restoring any of theses, which is why, after phy_init_hw(), which does a software reset of the PHY, all of these workarounds are wiped out, and your PHY behaves funky.

The reason why config_init() needs to put the PHY back into a fully functional state is because the PHY library should be able to software reset the PHY when it needs to, but also be able to deal with deep sleep modes etc.. where the PHY could loose its settings, yet the kernel should be able to bring you back in a good state.

Quoted 5 lines

An easy way to bypass that is to provide a soft_reset callback which does nothing, and see if calling either at803x_config_init(), or genphy_config_init() is sufficient to preserve the PHY settings. Although the real solution is to look at what the bootloader does on that front and replicate it in the config_init() callback.

Here is the data sheet for the AR8035:
http://www.redeszone.net/app/uploads/2014/04/AR8035.pdf

It seems the problem comes from the fact that the PHY treats HW reset and SW reset differently:

HW reset: registers are set to specific values SW reset: some bits are retained across reset

Case in point: the control register (BMCR)
HW reset: BMCR = 0x3100
SW reset: retain bits[6,8,12,13] / other bits = 0

(0x3100 means bit_6=0, bit_8=bit_12=bit_13=1)

When we execute this line from genphy_soft_reset()

     phy_write(phydev, MII_BMCR, BMCR_RESET);

we reset the bits in BMCR, and SW reset does not restore them.

It seems to me (please tell me if I am wrong) that it should be safe for all PHYs to write old_val | BMCR_RESET, instead of just BMCR_RESET. Thus...

On chips that REALLY reset, the old_val bits will be discarded; while on chips that retain some bits, we do want to keep them.

Quoted 12 lines · Florian Fainelli

So one possibility could be that the bootloader initializes the PHY in a certain way, typically by applying workarounds, and your config_init() callback is not restoring any of theses, which is why, after phy_init_hw(), which does a software reset of the PHY, all of these workarounds are wiped out, and your PHY behaves funky.

The reason why config_init() needs to put the PHY back into a fully functional state is because the PHY library should be able to software reset the PHY when it needs to, but also be able to deal with deep sleep modes etc.. where the PHY could loose its settings, yet the kernel should be able to bring you back in a good state.

Quoted 5 lines

An easy way to bypass that is to provide a soft_reset callback which does nothing, and see if calling either at803x_config_init(), or genphy_config_init() is sufficient to preserve the PHY settings. Although the real solution is to look at what the bootloader does on that front and replicate it in the config_init() callback.

Here is the data sheet for the AR8035:
http://www.redeszone.net/app/uploads/2014/04/AR8035.pdf

It seems the problem comes from the fact that the PHY treats HW reset and SW reset differently:

HW reset: registers are set to specific values SW reset: some bits are retained across reset

Case in point: the control register (BMCR)
HW reset: BMCR = 0x3100
SW reset: retain bits[6,8,12,13] / other bits = 0

(0x3100 means bit_6=0, bit_8=bit_12=bit_13=1)

When we execute this line from genphy_soft_reset()

     phy_write(phydev, MII_BMCR, BMCR_RESET);

we reset the bits in BMCR, and SW reset does not restore them.

It seems to me (please tell me if I am wrong) that it should be safe for all PHYs to write old_val | BMCR_RESET, instead of just BMCR_RESET. Thus...

On chips that REALLY reset, the old_val bits will be discarded; while on chips that retain some bits, we do want to keep them.

So the patch would go something like below. What do you think?

Quoted 47 lines · Mason

Quoted 12 lines · Florian Fainelli

So one possibility could be that the bootloader initializes the PHY in a certain way, typically by applying workarounds, and your config_init() callback is not restoring any of theses, which is why, after phy_init_hw(), which does a software reset of the PHY, all of these workarounds are wiped out, and your PHY behaves funky.

The reason why config_init() needs to put the PHY back into a fully functional state is because the PHY library should be able to software reset the PHY when it needs to, but also be able to deal with deep sleep modes etc.. where the PHY could loose its settings, yet the kernel should be able to bring you back in a good state.

Quoted 5 lines

An easy way to bypass that is to provide a soft_reset callback which does nothing, and see if calling either at803x_config_init(), or genphy_config_init() is sufficient to preserve the PHY settings. Although the real solution is to look at what the bootloader does on that front and replicate it in the config_init() callback.

Here is the data sheet for the AR8035:
http://www.redeszone.net/app/uploads/2014/04/AR8035.pdf

It seems the problem comes from the fact that the PHY treats HW reset and SW reset differently:

HW reset: registers are set to specific values SW reset: some bits are retained across reset

Case in point: the control register (BMCR)
HW reset: BMCR = 0x3100
SW reset: retain bits[6,8,12,13] / other bits = 0

(0x3100 means bit_6=0, bit_8=bit_12=bit_13=1)

When we execute this line from genphy_soft_reset()

      phy_write(phydev, MII_BMCR, BMCR_RESET);

we reset the bits in BMCR, and SW reset does not restore them.

It seems to me (please tell me if I am wrong) that it should be safe for all PHYs to write old_val | BMCR_RESET, instead of just BMCR_RESET. Thus...

On chips that REALLY reset, the old_val bits will be discarded; while on chips that retain some bits, we do want to keep them.

Quoted 1 line

So the patch would go something like below. What do you think?

I don't think that'll work, because writing a 1 into the RESET bit of the register causes the PHY to enter its software reset routine immediately. The other bits should hence be reset to their defaults, regardless of what you set them to at the same time.

My suggestion is to dump the entire register set when at803x_config_init() is entered and again when it's left. Then try to find the differences and see if you can bring the PHY into the needed mode through the existing configuration hooks in the kernel.

Note that it really should be possible for the kernel to bring the PHY into the mode needed for your board. Relying on the bootloader to do the magic is fragile, and as Florian said, this will break once a suspend mode switches off the power domain that feeds the PHY.

Quoted 4 lines · Daniel Mack

My suggestion is to dump the entire register set when at803x_config_init() is entered and again when it's left. Then try to find the differences and see if you can bring the PHY into the needed mode through the existing configuration hooks in the kernel.

[    0.685330] IDX= 1 796d != 7949
[    0.688490] IDX= 5 c1e1 != 0000
[    0.691647] IDX= 6 000f != 0004
[    0.694803] IDX=10 3800 != 0000
[    0.697960] IDX=17 bc10 != 0012
[    0.701115] IDX=19 7400 != 0000
[    0.704271] IDX=27 060e != 0600

Hmmm, didn't expect so many differences. I'll have to take a closer look.

For the record, I dumped the PHY registers
A) upon entering phy_init_hw
B) before leaving phy_init_hw (thus right after at803x_config_init)

IDX 1: b2 LINK STATUS, b5 AUTO-NEGOTIATION COMPLETE => Difference in status bits, seems reasonable

IDX 5: Link partner ability (base page)
=> seems reasonable (no partner yet?)

IDX 6: Auto-Negotiation Expansion
=> seems reasonable (no partner yet?)

IDX 10: 1000 BASE-T Status (HW reset = SW reset = 0)
(ALSO: Contents of this register clear after a read operation has occurred.) => Looks like my own read cleared it

IDX 17: PHY-Specific Status
b1 = "POLARITY (real time)"?
=> Difference in status bits, seems reasonable? (

IDX 19: Interrupt Status
=> Looks like some interrupt requests might have been discarded?

IDX 27: This register is undocumented

Nothing looks suspicious, except maybe the Interrupt Status?

What about the debug registers, such as the one that configures the RGMII TX/RX clock delay (4.2.25, 4.2.26). These are indirectly addressed, see at803x_config_init().

Quoted 15 lines · Mason

Quoted 4 lines · Daniel Mack

My suggestion is to dump the entire register set when at803x_config_init() is entered and again when it's left. Then try to find the differences and see if you can bring the PHY into the needed mode through the existing configuration hooks in the kernel.

[    0.685330] IDX= 1 796d != 7949
[    0.688490] IDX= 5 c1e1 != 0000
[    0.691647] IDX= 6 000f != 0004
[    0.694803] IDX=10 3800 != 0000
[    0.697960] IDX=17 bc10 != 0012
[    0.701115] IDX=19 7400 != 0000
[    0.704271] IDX=27 060e != 0600

Quoted 1 line

Hmmm, didn't expect so many differences. I'll have to take a closer look.

For the record, I dumped the PHY registers
A) upon entering phy_init_hw
B) before leaving phy_init_hw (thus right after at803x_config_init)

IDX 1: b2 LINK STATUS, b5 AUTO-NEGOTIATION COMPLETE => Difference in status bits, seems reasonable

IDX 5: Link partner ability (base page)
=> seems reasonable (no partner yet?)

IDX 6: Auto-Negotiation Expansion
=> seems reasonable (no partner yet?)

IDX 10: 1000 BASE-T Status (HW reset = SW reset = 0) (ALSO: Contents of this register clear after a read operation has occurred.)
=> Looks like my own read cleared it

IDX 17: PHY-Specific Status
b1 = "POLARITY (real time)"?
=> Difference in status bits, seems reasonable? (

IDX 19: Interrupt Status
=> Looks like some interrupt requests might have been discarded?

IDX 27: This register is undocumented

Nothing looks suspicious, except maybe the Interrupt Status?

Is speed auto-negotiation supposed to be complete when phy_init_hw exits?

Quoted 1 line · Mason

Is speed auto-negotiation supposed to be complete when phy_init_hw exits?

There is no such guarantee, and the PHY state machine is started later, which will take care of auto-neg and other things.

Quoted 4 lines · Florian Fainelli

Quoted 1 line · Mason

Is speed auto-negotiation supposed to be complete when phy_init_hw exits?

Quoted 2 lines

There is no such guarantee, and the PHY state machine is started later, which will take care of auto-neg and other things.

That's what I thought.

So it's expected that many status bits will only change later.

You didn't comment on my patch. What's your take on it?

Quoted 6 lines · Mason

Quoted 4 lines · Florian Fainelli

Quoted 1 line · Mason

Is speed auto-negotiation supposed to be complete when phy_init_hw exits?

Quoted 8 lines

Quoted 2 lines

There is no such guarantee, and the PHY state machine is started later, which will take care of auto-neg and other things.

That's what I thought.

So it's expected that many status bits will only change later.

You didn't comment on my patch. What's your take on it?

Quoting IEEE 802.3 section 2, paragraph 22.2.4.1:

"Resetting a PHY is accomplished by setting bit 0.15 to a logic one. This action shall set the status and control registers to their default states. As a consequence this action may change the internal state of the PHY and the state of the physical link associated with the PHY. This bit is self-clearing, and a PHY shall return a value of one in bit 0.15 until the reset process is completed. A PHY is not required to accept a write transaction to the control register until the reset process is completed, and writes to bits of the control register other than 0.15 may have no effect until the reset process is completed. The reset process shall be completed within 0.5 s from the setting of bit 0.15"

So even though this is not extremely specific about whether or not doing a RMW instead of W is accepted, considering that this resets the PHY internal state, and the fact that there is a lack of clarify on whether setting any bits other than 15 is going to fall under the "A PHY is not required to accept a write transaction to the control register until the reset process is completed" statement, setting only this bit at least guarantees that you are back into your reset defaults.

As Daniel suggested, I would be looking for undocumented/proprietary registers for reasons as to why your PHY is not working, in particular (RG)MII tuning.

Quoted 38 lines · Florian Fainelli

Quoted 6 lines · Mason

Quoted 4 lines · Florian Fainelli

Quoted 1 line · Mason

Is speed auto-negotiation supposed to be complete when phy_init_hw exits?

Quoted 8 lines

Quoted 2 lines

There is no such guarantee, and the PHY state machine is started later, which will take care of auto-neg and other things.

That's what I thought.

So it's expected that many status bits will only change later.

You didn't comment on my patch. What's your take on it?

Quoting IEEE 802.3 section 2, paragraph 22.2.4.1:

"Resetting a PHY is accomplished by setting bit 0.15 to a logic one. This action shall set the status and control registers to their default states. As a consequence this action may change the internal state of the PHY and the state of the physical link associated with the PHY. This bit is self-clearing, and a PHY shall return a value of one in bit 0.15 until the reset process is completed. A PHY is not required to accept a write transaction to the control register until the reset process is completed, and writes to bits of the control register other than 0.15 may have no effect until the reset process is completed. The reset process shall be completed within 0.5 s from the setting of bit 0.15"

So even though this is not extremely specific about whether or not doing a RMW instead of W is accepted, considering that this resets the PHY internal state, and the fact that there is a lack of clarify on whether setting any bits other than 15 is going to fall under the "A PHY is not required to accept a write transaction to the control register until the reset process is completed" statement, setting only this bit at least guarantees that you are back into your reset defaults.

Quoted 3 lines

As Daniel suggested, I would be looking for undocumented/proprietary registers for reasons as to why your PHY is not working, in particular (RG)MII tuning.

Am I the only having problems with the AR8035? :-(

The standard driver works for everyone but me?

Did you take a look at the data sheet? Do you understand the difference between "Hardware Reset" and "Software Reset"?

Maybe on my PHY, writing BMCR_RESET to BMCR triggers a SW reset, while it triggers a HW reset on other boards?

Would that be possible?

Also, why do you say the PHY is not working? When I apply the patch I proposed, it doesn't malfunction.

Quoted 27 lines · Mason

Quoted 25 lines · Florian Fainelli

Quoting IEEE 802.3 section 2, paragraph 22.2.4.1:

"Resetting a PHY is accomplished by setting bit 0.15 to a logic one. This action shall set the status and control registers to their default states. As a consequence this action may change the internal state of the PHY and the state of the physical link associated with the PHY. This bit is self-clearing, and a PHY shall return a value of one in bit 0.15 until the reset process is completed. A PHY is not required to accept a write transaction to the control register until the reset process is completed, and writes to bits of the control register other than 0.15 may have no effect until the reset process is completed. The reset process shall be completed within 0.5 s from the setting of bit 0.15"

So even though this is not extremely specific about whether or not doing a RMW instead of W is accepted, considering that this resets the PHY internal state, and the fact that there is a lack of clarify on whether setting any bits other than 15 is going to fall under the "A PHY is not required to accept a write transaction to the control register until the reset process is completed" statement, setting only this bit at least guarantees that you are back into your reset defaults.

As Daniel suggested, I would be looking for undocumented/proprietary registers for reasons as to why your PHY is not working, in particular (RG)MII tuning.

Quoted 6 lines

Am I the only having problems with the AR8035? :-(

The standard driver works for everyone but me?

Did you take a look at the data sheet? Do you understand the difference between "Hardware Reset" and "Software Reset"?

I did not.

Quoted 2 lines

Also, why do you say the PHY is not working? When I apply the patch I proposed, it doesn't malfunction.

There are no BMCR registers that would affect directly the passing of unicast or broadcast traffic with distinction, which is how you originally reported the problem, or maybe that was a bad description of the issue?

Have you checked the Ethernet MAC MIB counters to see if there are any errors reported differently from the working case to the non-working case? What about your link partner, what does it looks like on its end when it does not work?

Quoted 28 lines · Florian Fainelli

Quoted 27 lines · Mason

Quoted 25 lines · Florian Fainelli

Quoting IEEE 802.3 section 2, paragraph 22.2.4.1:

"Resetting a PHY is accomplished by setting bit 0.15 to a logic one. This action shall set the status and control registers to their default states. As a consequence this action may change the internal state of the PHY and the state of the physical link associated with the PHY. This bit is self-clearing, and a PHY shall return a value of one in bit 0.15 until the reset process is completed. A PHY is not required to accept a write transaction to the control register until the reset process is completed, and writes to bits of the control register other than 0.15 may have no effect until the reset process is completed. The reset process shall be completed within 0.5 s from the setting of bit 0.15"

So even though this is not extremely specific about whether or not doing a RMW instead of W is accepted, considering that this resets the PHY internal state, and the fact that there is a lack of clarify on whether setting any bits other than 15 is going to fall under the "A PHY is not required to accept a write transaction to the control register until the reset process is completed" statement, setting only this bit at least guarantees that you are back into your reset defaults.

As Daniel suggested, I would be looking for undocumented/proprietary registers for reasons as to why your PHY is not working, in particular (RG)MII tuning.

Quoted 8 lines

Quoted 6 lines

Am I the only having problems with the AR8035? :-(

The standard driver works for everyone but me?

Did you take a look at the data sheet? Do you understand the difference between "Hardware Reset" and "Software Reset"?

I did not.

If I understand your quote from the standard correctly, then the behavior documented in the data sheet looks very non-compliant to my untrained eye.

Quoted 7 lines

Quoted 2 lines

Also, why do you say the PHY is not working? When I apply the patch I proposed, it doesn't malfunction.

There are no BMCR registers that would affect directly the passing of unicast or broadcast traffic with distinction, which is how you originally reported the problem, or maybe that was a bad description of the issue?

I didn't say anything about unicast vs broadcast.

When I run the unpatched code, it looks like the PHY negotiates only 10 Mbps Half-duplex, then DHCP appears to succeed (IIUC only the very first packets are broadcast), and then the system hangs trying to mount the root filesystem over NFS.

I actually left it running over lunch break, and according to the kernel's time stamps, the system seems to have managed to mount the root file system after 2000+ seconds.

Quoted 5 lines

Have you checked the Ethernet MAC MIB counters to see if there are any errors reported differently from the working case to the non-working case? What about your link partner, what does it looks like on its end when it does not work?

Should I use ethtool for this?

Or do it directly with kernel code? (If so which API?)

The catch is that I need the network to get a running system. No network, no root file system.

Maybe I need to write the kernel to non-volatile storage.

Going on a wild goose hunt...

Somewhat related discussion
https://community.freescale.com/thread/289362

Let me check how u-boot handles the AR8035.
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/net/phy/atheros.c

static int ar8035_config(struct phy_device *phydev)

{
	int regval;

	phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x0007);
	phy_write(phydev, MDIO_DEVAD_NONE, 0xe, 0x8016);
	phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x4007);
	regval = phy_read(phydev, MDIO_DEVAD_NONE, 0xe);
	phy_write(phydev, MDIO_DEVAD_NONE, 0xe, (regval|0x0018));

	phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);
	regval = phy_read(phydev, MDIO_DEVAD_NONE, 0x1e);
	phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, (regval|0x0100));

	phydev->supported = phydev->drv->features;

	return 0;
}

Data sheet states:
Register 0xd = "MMD Access Control".
Register 0xe = "MMD Access Control Data".

MMD register access:
See detail in register description
example: Write 0x8000 to Register 0 of MMD3
1. Write 0x3 to register 0xD:
0xD=0x0003;(function= address; set the device address)
2. Write 0x0 to register 0xE: 0xE=0x0; (set the register offset address)
3. Write 0x4003 to register
0xD:0xD=0x4003;(function=data; keep the device address)
4. Read register 0xE:0xE==(data from register 0x0 of MMD3)
5. Write 0x8000 to register 0xE
:0xE=0x8000(write 0x8000 to register 0x0 of MMD3)
Please Note:Read operation please refers to process 1 ~ 4

Important note:
CLK_25M default outputs 25MHz, can be configured to 50MHz, 62.5MHz, or 125MHz by register MMD7 8016[4:3].

Ah yes, there it is on page 58:
Device address = 7, address offset = 0x8016 (Hex)
4:3 Select_clk125m
CLK_25M output clock select
00=25M
01=50M
10=62.5M
11=125M

So...

	phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x0007);
	phy_write(phydev, MDIO_DEVAD_NONE, 0xe, 0x8016);
	phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x4007);
	regval = phy_read(phydev, MDIO_DEVAD_NONE, 0xe);
	phy_write(phydev, MDIO_DEVAD_NONE, 0xe, (regval|0x0018));

R[0xd] = 0x0007  ; select MMD7
R[0xe] = 0x8016  ; offset 0x8016, so 
R[0xd] = 0x4007  ; select "data, no post increment" for MMD7

then we read the current value of MMD7/offset=0x8016 and set bits 3 and 4 on top of that => 125 MHz clock

HW reset val = 0
SW reset val = retain previous value
so the reset in Linux shouldn't affect this...

	phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);
	regval = phy_read(phydev, MDIO_DEVAD_NONE, 0x1e);
	phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, (regval|0x0100));

set debug port offset to 5 (DR5)
read current value
set bit 8 (rgmii_tx_clk_dly)

Rgmii tx clock delay control bit:
1 = rgmii tx clock delay enable
0 = rgmii tx clock delay disable.

AFAICT, the Linux code doesn't RMW, it just blindly writes AT803X_DEBUG_RGMII_TX_CLK_DLY. Dunno if it makes any difference...

Meh, I'm still grasping at straws...

Regards.

Am I the only having problems with the AR8035? :-(

The standard driver works for everyone but me?

Quoted 3 lines · Mason

Am I the only having problems with the AR8035? :-(

The standard driver works for everyone but me?

Works well on a imx6q-hummingboard:

fec 2188000.ethernet eth0: Freescale FEC PHY driver [Atheros 8035 ethernet] (mii_bus:phy_addr=2188000.ethernet:00, irq=-1)

Quoted 10 lines · Fabio Estevam

Quoted 3 lines · Mason

Am I the only having problems with the AR8035? :-(

The standard driver works for everyone but me?

Works well on a imx6q-hummingboard:

fec 2188000.ethernet eth0: Freescale FEC PHY driver [Atheros 8035 ethernet] (mii_bus:phy_addr=2188000.ethernet:00, irq=-1)

Forgot to point out that we also have a 8035 fixup in arch/arm/mach-imx/mach-imx6q.c. Search for ar8035_phy_fixup().

The standard driver works for everyone but me?

Did you take a look at the data sheet? Do you understand the difference between "Hardware Reset" and "Software Reset"?

Maybe on my PHY, writing BMCR_RESET to BMCR triggers a SW reset, while it triggers a HW reset on other boards?

Also, why do you say the PHY is not working? When I apply the patch I proposed, it doesn't malfunction.

Quoted 2 lines · Mason

Am I the only having problems with the AR8035? :-( The standard driver works for everyone but me?

A company I used to work with ships various hardware models in quantities which features this chip, and they're using the unpatched mainline kernel version of the driver.

Quoted 2 lines

Did you take a look at the data sheet? Do you understand the difference between "Hardware Reset" and "Software Reset"?

I did, most notably because I was desperately trying to find a sane way to conduct a full reset of the PHY to work around a confirmed bug in the DIE of the chip which causes the internal state machine to lock up on link loss under certain conditions.

Unfortunately, I failed to find a way to really put the chip into complete reset state through the registers. Instead, I added a possibility to let the driver pull the hardware reset (see 13a56b4493).

Other than that, however, I didn't encounter any problems.

Quoted 2 lines

Maybe on my PHY, writing BMCR_RESET to BMCR triggers a SW reset, while it triggers a HW reset on other boards?

AFAIK, the chip does not do this, no. But even if it did,

Quoted 2 lines

Also, why do you say the PHY is not working? When I apply the patch I proposed, it doesn't malfunction.

You're referring to the one that removes the phy init routine?

I'd still go and check if there's anything in one of the chained bootloaders that does some magic. One other thing that might give you a hint is to manually pull the RESET line low for a short time right when the kernel decompressor is started. That way, the kernel has to deal with a device that has just seen a hardware reset. Just see if that makes any difference.

Also, some delays in between the register writes during initialization might also be worth a try. But that's all just random guessing right now, sorry.

Quoted 3 lines · Daniel Mack

A company I used to work with ships various hardware models in quantities which features this chip, and they're using the unpatched mainline kernel version of the driver.

Quoted 4 lines

Quoted 2 lines

Maybe on my PHY, writing BMCR_RESET to BMCR triggers a SW reset, while it triggers a HW reset on other boards?

AFAIK, the chip does not do this, no. But even if it did,

Did you forget to finish that sentence? :-)

Quoted 6 lines

I'd still go and check if there's anything in one of the chained bootloaders that does some magic. One other thing that might give you a hint is to manually pull the RESET line low for a short time right when the kernel decompressor is started. That way, the kernel has to deal with a device that has just seen a hardware reset. Just see if that makes any difference.

I'd force a HW reset by jiggling the appropriate GPIO pin? Like you did in the at803x.c driver?

Quoted 28 lines · Mason

Here is the data sheet for the AR8035:
http://www.redeszone.net/app/uploads/2014/04/AR8035.pdf

It seems the problem comes from the fact that the PHY treats HW reset and SW reset differently:

HW reset: registers are set to specific values SW reset: some bits are retained across reset

Case in point: the control register (BMCR)
HW reset: BMCR = 0x3100
SW reset: retain bits[6,8,12,13] / other bits = 0

(0x3100 means bit_6=0, bit_8=bit_12=bit_13=1)

When we execute this line from genphy_soft_reset()

     phy_write(phydev, MII_BMCR, BMCR_RESET);

we reset the bits in BMCR, and SW reset does not restore them.

It seems to me (please tell me if I am wrong) that it should be safe for all PHYs to write old_val | BMCR_RESET, instead of just BMCR_RESET. Thus...

On chips that REALLY reset, the old_val bits will be discarded; while on chips that retain some bits, we do want to keep them.

Quoted 1 line

So the patch would go something like below. What do you think?

I don't think that'll work, because writing a 1 into the RESET bit of the register causes the PHY to enter its software reset routine immediately. The other bits should hence be reset to their defaults, regardless of what you set them to at the same time.