Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Russell King (Oracle)]

On Tue, Mar 08, 2022 at 12:54:09PM +0100, Giammarco lynx wrote:
> Hi Russell,
> 
> here is the output of devmem without sfp-bus.c quirk:
> 
> root at mcbin:~# devmem 0xf4133e10
> 0x0000600A

So yes, bit 14 is set, meaning it's in sync, but negotiation has not
completed. I think that probably means my theory that the module is
operating in SGMII mode is likely to be correct.

I would need to check, but I would guess that u-boot configures eth3
for SGMII at boot (despite it always being connected to a SFP cage
which doesn't actually make that much sense) and the SFP module
detects that the host is in SGMII mode at boot, and locks itself to
that.

When the kernel boots, it reconfigures the interface to be in
1000base-X mode, which would be way more sensible for the SFP cage
given that SFPs are normally used for fibre, and the GPON module
no longer links.

If we were to add hacks so that this module caused the mcbin to stay
in SGMII mode, this would break existing systems where the host
boots in 1000base-X mode, causing the module to lock to 1000base-X.
So, there is no solution here for the kernel that will work for
everyone.

This also means that what mode the module is in will depend on what
module was _previously_ inserted in the SFP cage, since that will
determine the host configuration at the point when the module is
inserted.

I guess the module has been designed with the assumption that the
host it is plugged into will only be capable of operating with a
single protocol.

I can't see a clean solution to this one that will work for everyone.
Sorry.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!