Thread (36 messages) 36 messages, 6 authors, 2018-01-03

[EXT] Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

From: Stefan Chulski <hidden>
Date: 2018-01-03 17:01:23
Also in: lkml, netdev

quoted
quoted
-----Original Message-----
Hi Russell,

Indeed. RGMII MAC behaves same way, although it shouldn't be named
as 'in- band' to be on par with the specifications. Anyway - this
one is rather a stub for being able to work with ACPI, so once the
MDIO bus works there, this will be out of any concerns.
Hi Marcin,

This is correct.
"in-band" supported only for SGMII mode.
IRQ link interrupt depend on "in-band"' auto negation only if "in-band"'
enabled.
quoted
But IRQ link interrupt could be triggered with "in-band", "out-band" or with
specific fixed speed/duplex/flow_contol.

Hi Stefan,

How does this work in RGMII mode - is this handled by the PP2 polling the PHY
to get the speed, duplex and flow control settings?
IRQ interrupt doesn't handled speed, duplex and flow control settings.
It's just raised if number of criterions met:
1) Physical signal detected by MAC
2) MAC auto negotiation succeeded(valid only auto negotiation enabled in MAC and "in-band" bypass disabled)

So if auto negotiation mechanism disabled in MAC or bypassed, link status would changes to up and IRQ interrupt be triggered.

In case of RGMII mode obviously we don't have "in-band" auto negotiation and "out-band" cannot be used in Kernel(due to missed locks).
So auto negotiation should be disabled on MAC level and speed/duplex/flow_contol would be negotiate by PHY. 
phylink/phylib infrastructure should provide speed/duplex/flow_contol(that were agreed between PHY's) to ppv2 driver.

Stefan.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help