On Thu, Jul 21, 2022 at 07:21:45PM +0200, Marek Behún wrote:

Marvell documentation says that 2500base-x does not implement inband
AN.

Does Marvell documentation actually call it 2500base-x when it says it
doesn't support in-band autoneg?

But when it was first implemented, for some reason it was thought that
2500base-x is just 1000base-x at 2.5x speed, and 1000base-x does
support inband AN. Also it worked during tests for both switches and
SOC NICs, so it was enabled.

At the time 2500base-x was not standardized. Now 2500base-x is
stanradrized, and the standard says that 2500base-x does not support
clause 37 AN. I guess this is because where it is used, it is intended
to work with clause 73 AN somehow.

When you say 2500base-x is standardized, do you mean there is a document
somewhere which I could use to read more about this?

And then came 6373X switch, which didn't support clause 37 inband AN in
2500base-x mode (the AN reigster returned 0xffff or something when
2500base-x CMODE was set). Maybe 6373X finally supports clause 73 AN
(I don't know, but I don't think so) and that is the reason they now
forbid clause 37 AN in HW in 2500base-x.

But the problem is that by this time there is software out there then
expects 2500base-x to have clause 37 AN enabled. Indeed a passive SFP
cable did not work between MOX' SFP port and CN9130-CRB's SFP port
when used with Peridot (6190), if C37 AN was disabled on 6393x and left
enabled on Peridot.

I managed to work out how to enable C37 AN on 6393x:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=163000dbc772c1eae9bdfe7c8fe30155db1efd74

So currently we try to enable C37 AN in 2500base-x mode, although
the standard says that it shouldn't be there, and it shouldn't be there
presumably because they want it to work with C73 AN.

I don't know how to solve this issue. Maybe declare a new PHY interface
mode constant, 2500base-x-no-c37-an ?

So this is essentially what I'm asking, and you didn't necessarily fully
answer. I take it that there exist Marvell switches which enable in-band
autoneg for 2500base-x and switches which don't, and managed = "in-band-status"
has nothing to do with that decision. Right?

Is this by design of the 'managed' property, or is it an interpretation
quirk of Marvell drivers? Some other drivers enable in-band autoneg only
when manage = "in-band-status", and no one really said anything about
that during review, so I came to believe that this is the expectation.
I'm confused now, I was hoping Russell could clarify.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel