[PATCH net-next 3/6] net: dsa: add support for retrieving the interface mode

[Vladimir Oltean]

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.