On Fri, Feb 09, 2018 at 02:10:00PM -0700, Diana Eichert wrote: > systemname$ ifconfig |grep flags > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768 > cnmac0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > cnmac1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > cnmac2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > cnmac3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > enc0: flags=0<> > pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33136 > > > systemname$ dmesg |grep phy > ukphy0 at cnmac0 phy 4: Generic IEEE 802.3u media interface, rev. 3: OUI > 0x180361, model 0x0004 > ukphy1 at cnmac1 phy 5: Generic IEEE 802.3u media interface, rev. 3: OUI > 0x180361, model 0x0004 > brgphy0 at cnmac2 phy 0: BCM5482 10/100/1000baseT PHY, rev. 2 > brgphy1 at cnmac3 phy 1: BCM5482 10/100/1000baseT PHY, rev. 2 > > I'm currently using cnmac0 on ukphy0 and I'm wondering if I should be > using cnmac2/3 on brgphy0/1 . > > Any thoughts? I know cnmac0/1 are Cu only, whereas cnmac2/3 could be > SFP if the switch they were connected on could be manipulated. I have > contacts at Cavium, but last time I asked about the internal switch on > an ARM64 box we use they would only release info under NDA. :-(
This is probably the same situation as the cu/sfp ports on the ERPro-8, where the phy driver needs some extra logic that controls whether cu or sfp is active, and which set of LEDs blinks when things happen. Without that, they're just regular copper ports, and I don't think there's any reason to prefer one set of interfaces over the other. >From memory there's code for this in linux. I had it half working at one point (packets in one direction through the sfp, but not the other, maybe) but I haven't looked at it in a while.
