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.
