netdev - Marvell DSA switch 88E6165

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <380acbbedb5de9bbaa01735b22eacc10@partychief.com>
Date:	Sun, 04 Mar 2012 19:09:10 +0100
From:	mdsmith@...tychief.com
To:	<netdev@...r.kernel.org>
Subject: Marvell DSA switch 88E6165 - CPU port in PHY mode

Hello - have a question about the net/dsa driver code, how does one 
bring up the CPU connected port on the switch when it isn't in RGMII 
mode, i.e. with the built-in GPHY enabled.

Normally (at least according to Marvell documentation, existing 
reference designs and Lennert's DSA driver code) the CPU Ethernet 
interface is connected to the switch port as RGMII. Due to a hardware 
design constraint our new platform has the following arrangement - both 
Ethernet ports on the Kirkwood 6282 SoC are wired to a 1121 dual phy 
(this is a system on module), the only way to connect to GE00 & GE01 is 
via a copper interface. Reading the data sheet for the 6165 switch chip 
we noticed that Port 4 can be configured as a copper interface using the 
built-in PHY (using P4_MODE[2:0]) so it seemed that the configuration 
described below is feasible:

+-----------+          +-----------+
|           |          |           |
|           |   RGMII  |           | PHY
|       GE00+----------+           +-------------------------- 
1000baseT MDI eth0
|           |          |  88E1121R |
|           |          |  dual phy |       +-----------+
|           |   RGMII  |           | PHY  4|          0+------ 
1000baseT MDI lan0
|       GE01+----------+           +-------+  88E6165 1+------ 
1000baseT MDI lan1
|           |          |           |       |  switch  2+------ 
1000baseT MDI lan2
| 88F6282   |          |           |       |          3+------ 
1000baseT MDI lan3
| SoC       |          |           |       |  port5    |
|           |          | MDC/MDIO  |       |  disabled |
|        SMI+----------+[0:1]------+-------+[8]        |
|           |          |           |       |           |
+-----------+          +-----------+       +-----------+

To summarize:
- GE00's PHY is directly wired to an RJ45, this interface works fine.
- GE01's PHY is wired to switch port 4 (hardware strapped to GPHY 
mode), cannot bring this link up.
- SMI bus is shared between the 1121 dual PHY and the 6165 switch, we 
can talk to both chips fine (6165 via indirect register access)

I believe my Kirkwood platform initialization code is good as the 
kernel finds GE00, GE01 and the switch. I did have to tweak the 
mach-orion/common.c platform code slightly to associate GE01 with the 
switch CPU port (d->netdev = &orion_ge01.dev;). Relevant kernel output 
(I have eth0 plugged into an upstream switch and lan0 connected to 
another external standalone switch):

mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
mv643xx_eth smi: probed
mv643xx_eth_port mv643xx_eth_port.0: eth0: port 0 with MAC address 
00:50:43:22:2
6:29
mv643xx_eth_port mv643xx_eth_port.1: eth1: port 0 with MAC address 
00:50:43:72:2
6:29
<snip>
eth1[0]: detected a Marvell 88E6165 switch
dsa slave smi: probed
<snip>
ADDRCONF(NETDEV_UP): eth0: link is not ready
<snip>
mv643xx_eth_port mv643xx_eth_port.0: eth0: link up, 1000 Mb/s, full 
duplex, flow
control disabled
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
<snip>
ADDRCONF(NETDEV_UP): eth1: link is not ready
<snip>
lan0: link up, 1000 Mb/s, full duplex, flow control disabled
ADDRCONF(NETDEV_CHANGE): lan0: link becomes ready

I see eth0 come up, good. I don't see eth1 come up which means that the 
6165 switch Port 4 is not up. I see lan0 come up when I plug it into an 
external switch.

mii-tool confirms that eth1 has no link.

root@...tme:~# mii-tool -v eth1
eth1: 10 Mbit, full duplex, no link
product info: vendor 00:50:43, model 11 rev 3
basic mode:   10 Mbit, full duplex
basic status: no link
capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 
10baseT-FD 10baseT-HD
advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
root@...tme:~# mii-tool -v lan0
lan0: negotiated 1000baseT-FD flow-control, link ok
product info: vendor 00:50:43, model 11 rev 1
basic mode:   autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 
10baseT-FD 10baseT-HD
advertising:  1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 
10baseT-HD
link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 
10baseT-FD 10baseT-HD flow-control

I've gone through the DSA code and cannot see exactly where one can 
modify the CPU connected port to be PHY instead of RGMII. Nearest I 
could find was in mv88e6123_61_65_setup_port where various registers are 
written to to initialize the different ports, there is a reference to 
forcing the CPU connected port to 1000Mb/s full duplex so I thought it 
would be logical to add some register writes to power up the PHY. 
However this still doesn't bring the PHY up...

Any ideas on how I can bring my board up correctly?
Or is this just not possible with this hardware configuration? I find 
it hard to believe because DSA switches can be daisy chained across any 
port using copper (or other media).

thanks for your help…
Matthew D. Smith

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html