[1/2] net: phy: adin: clear the diag clock and set LINKING_EN during autoneg

The LINKING_EN bit is always cleared during reset. Initially it was set
during the downshift setup, because it's in the same register as the
downshift retry count (PHY_CTRL1).

This change moves the handling of LINKING_EN from the downshift handler to
the autonegotiation handler. Also, during autonegotiation setup, the
diagnostics clock is cleared.

This is being done as a prequel to the cable-diagnostics patch. When the
cable diagnostics finishes, the PHY state machine goes back into the PHY_UP
state and the autonegotiation is restarted (or better said, the
autonegotiation handler is called).
During this call, the diagnostics clock should be disabled, and the
LINKING_EN bit set in the PHY_CTRL1 register.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
 drivers/net/phy/adin.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

On Wed, Oct 21, 2020 at 04:51:39PM +0300, Alexandru Ardelean wrote:
> The LINKING_EN bit is always cleared during reset. Initially it was set
> during the downshift setup, because it's in the same register as the
> downshift retry count (PHY_CTRL1).

Hi Alexandru

For those of us how have not read the datasheet, could you give a
brief explanation what LINKING_EN does?
 
> This change moves the handling of LINKING_EN from the downshift handler to
> the autonegotiation handler. Also, during autonegotiation setup, the
> diagnostics clock is cleared.

And what is the diagnostics clock used for?

    Andrew

On Wed, Oct 21, 2020 at 4:58 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Wed, Oct 21, 2020 at 04:51:39PM +0300, Alexandru Ardelean wrote:
> > The LINKING_EN bit is always cleared during reset. Initially it was set
> > during the downshift setup, because it's in the same register as the
> > downshift retry count (PHY_CTRL1).
>
> Hi Alexandru
>
> For those of us how have not read the datasheet, could you give a
> brief explanation what LINKING_EN does?

So, clearing this bit puts the PHY in a standby-state.
The PHY doesn't do any autonegotiation or link handling.

>
> > This change moves the handling of LINKING_EN from the downshift handler to
> > the autonegotiation handler. Also, during autonegotiation setup, the
> > diagnostics clock is cleared.
>
> And what is the diagnostics clock used for?

The clock diagnostics is used for 2 things: the diagnostics block
[mostly for stuff like cable-diagnostics] and the frame-generator.
The frame-generator is an interesting feature of the PHY, that's not
useful for the current phylib; the PHY can send packages [like a
signal generator], and then these can be looped back, or sent over the
wire.
Maybe it's being used mostly internally by the group that created the PHY

Having said this, I'll include some comments for these in a V2 of this patchset.

>
>     Andrew

> The frame-generator is an interesting feature of the PHY, that's not
> useful for the current phylib; the PHY can send packages [like a
> signal generator], and then these can be looped back, or sent over the
> wire.

Many PHYs that that. I posted some patches to the list a few years ago
adding basic support for the Marvell PHY frame generator. They got
NACKed. The netlink API, and some of the infrastructure i added for
cable testing would make it possible to fix the issues that caused the
NACK.

> Having said this, I'll include some comments for these in a V2 of this patchset.

Thanks.

	Andrew

P.S.

Your mail is broken somehow:

Delivery has failed to these recipients or groups:

alexaundru.ardelean@analog.com
The email address you entered couldn't be found. Please check the recipient's
email address and try to resend the message. If the problem continues, please
contact your email admin.

On Wed, Oct 21, 2020 at 5:13 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > The frame-generator is an interesting feature of the PHY, that's not
> > useful for the current phylib; the PHY can send packages [like a
> > signal generator], and then these can be looped back, or sent over the
> > wire.
>

removed my typo-ed [work] email
i use gmail as a mirror-email for my work email, because.... reasons
and i added my work-email to the --cc list with a typo, because the
universe seems to have wanted that [in a manner of saying it]

> Many PHYs that that. I posted some patches to the list a few years ago
> adding basic support for the Marvell PHY frame generator. They got
> NACKed. The netlink API, and some of the infrastructure i added for
> cable testing would make it possible to fix the issues that caused the
> NACK.

i'll think about the frame-generator;

i was super-happy when the cable-test support was added;
when i first wrote the PHY, i actually wrote this logic for
cable-testing, then scrapped it because the code [without any
framework around it] just looked bad, and like it was asking to cause
trouble;

with this minimal framework in place, cable-testing looks like a neat
feature [and neatly implemented];
and it took me less than a day to write and test it;
so, thank you for this :)

>
> > Having said this, I'll include some comments for these in a V2 of this patchset.
>
> Thanks.
>
>         Andrew
>
> P.S.
>
> Your mail is broken somehow:
>
> Delivery has failed to these recipients or groups:
>
> alexaundru.ardelean@analog.com
> The email address you entered couldn't be found. Please check the recipient's
> email address and try to resend the message. If the problem continues, please
> contact your email admin.

> i'll think about the frame-generator;

Here were the two main problems i can remember with my first version:

How do you discover what is can actually do? You probably need to
collect up all the open PHY datasheets and get an idea what the
different vendors provide, what is common, what could be shared
extensions etc, and think about how you can describe the
capabilities. Probably a netlink call will be needed to return what
the hardware is capable of doing.

At the time, it was necessary to hold RTNL while performing packet
generation. That is bad, because it means most of the control plane
stops for all devices. We will need to copy some of the ideas from the
cable test to avoid this, adding a state to the state machine, etc.

      Andrew