summaryrefslogtreecommitdiff
path: root/drivers/net/dsa
AgeCommit message (Collapse)AuthorFilesLines
2016-06-17dsa: b53: fix big-endian register accessArnd Bergmann1-12/+8
The b53 dsa register access confusingly uses __raw register accessors when both the CPU and the device are big-endian, but it uses little- endian accessors when the same device is used from a little-endian CPU, which makes no sense. This uses normal accessors in device-endianess all the time, which will work in all four combinations of register and CPU endianess, and it will have the same barrier semantics in all cases. This also seems to take care of a (false positive) warning I'm getting: drivers/net/dsa/b53/b53_mmap.c: In function 'b53_mmap_read64': drivers/net/dsa/b53/b53_mmap.c:109:10: error: 'hi' may be used uninitialized in this function [-Werror=maybe-uninitialized] *val = ((u64)hi << 32) | lo; I originally planned to submit another patch for that warning and did this one as a preparation cleanup, but it does seem to be sufficient by itself. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-10net: dsa: b53: Plug in VLAN supportFlorian Fainelli2-26/+243
Add support for configuration VLANs on B53 devices by implementing the port VLAN add/del/dump functions. We currently default to a behavior which is equivalent to having VLAN filtering turned on, where all VLANs not programmed into the VLAN port-based vector will be discarded on ingress. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-10net: dsa: b53: Add bridge supportFlorian Fainelli3-3/+174
Add support for HW bridging by tying the ports together in the same port VLAN mask when they belong to the same bridge, and isolating them to be alone with the CPU port when they are not. Propagate STP states from the bridge layer to the switch's HW mapping when requested. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-10net: dsa: b53: Implement ARL add/del/dump operationsFlorian Fainelli3-0/+382
Adds support for FDB add/delete/dump using the ARL read/write logic and the ARL search logic for faster dumps. The code is made flexible enough it could support devices with a different register layout like BCM5325 and BCM5365 which have fewer number of entries or pack values into a single 64 bits register. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-10net: dsa: b53: Add BCM7445 quirkFlorian Fainelli1-0/+11
The Broadcom BCM7445 STB chip has an issued in its revision D0 which was previously worked around in drivers/net/dsa/bcm_sf2.c where we may end-up double programming the integrated BCM7445 switch (bcm_sf2) and an external Broadcom switch such as BCM53125, since these are mostly register compatible. Add a small quirk which just defers probing until we are sitting on the slave DSA MDIO bus, which will allow us to intercept reads/writes and funnel them through the SF2 internal MDIO master (which happens to disconnect its pseudo PHY). Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-10net: dsa: b53: Add support for Broadcom RoboSwitchFlorian Fainelli11-0/+3268
This patch adds support for Broadcom's BCM53xx switch family, also known as RoboSwitch. Some of these switches are ubiquituous, found in home routers, Wi-Fi routers, DSL and cable modem gateways and other networking related products. This drivers adds the library driver (b53_common.c) as well as a few bus glue drivers for MDIO, SPI, Switch Register Access Block (SRAB) and memory-mapped I/O into a SoC's address space (Broadcom BCM63xx/33xx). Basic operations are supported to bring the Layer 1/2 up and running, but not much more at this point, subsequent patches add the remaining features. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-10net: dsa: bcm_sf2: Add VLAN supportFlorian Fainelli2-1/+275
Add support for configuring VLANs on the Broadcom Starfigther2 switch. This is all done through the bridge vlan facility just like other DSA drivers. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-10net: dsa: bcm_sf2: Add VLAN registers definitionsFlorian Fainelli1-0/+70
Add the definitions for the VLAN registers that we are going to manipulate in subsequent patches. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-10net: dsa: bcm_sf2: Move setup function at the far endFlorian Fainelli1-119/+119
Re-order the bcm_sf2_sw_setup() function so that it is at the far end of the driver to avoid any kind of forward declarations. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-10net: dsa: bcm_sf2: Split fast age into a helper functionFlorian Fainelli1-7/+13
Add a helper function to fast age something that is controlled by the caller: port, VLAN. We will use this to implement a VLAN fast age operation. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-08net: dsa: bcm_sf2: Register our slave MDIO busFlorian Fainelli2-81/+140
Register a slave MDIO bus which allows us to divert problematic read/writes towards conflicting pseudo-PHY address (30). Do no longer rely on DSA's slave_mii_bus, but instead provide our own implementation which offers more flexibility as to what to do, and when to register it. We need to register it by the time we are able to get access to our memory mapped registers, which is not until drv->setup() time. In order to avoid forward declarations, we need to re-order the function bodies a bit. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05net: dsa: Add new binding implementationAndrew Lunn1-0/+7
The existing DSA binding has a number of limitations and problems. The main problem is that it cannot represent a switch as a linux device, hanging off some bus. It is limited to one CPU port. The DSA platform device is artificial, and does not really represent hardware. Implement a new binding which can be embedded into any type of node on a bus to represent one switch device, and its links to other switches. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05net: dsa: mv88e6xxx: Refactor MDIO so driver registers mdio busAndrew Lunn2-9/+86
Have the switch driver register its own MDIO bus. This allows for an mdio property in the device tree, with child nodes for phys, which can be referenced via phandles, etc. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05net: dsa: mv88e6xxx: Rename _phy_ to _mdio_Andrew Lunn1-63/+63
The switch implements a generic MDIO bus, which could host more than PHYs. It is conventional to use _mdio_ or _mii_ in the function name, so rename them. Also postfix make the historically first read/write function with _direct, to help distinguish it from _indirect and _ppu. While touching these functions, remove some of the _ prefixes, which we are deprecating. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05net: dsa: mv88e6xxx: Only support EDSA taggingAndrew Lunn1-6/+2
The merged driver no longer offers the option to use DSA tagging. So remove the code to setup the switch to do DSA tagging and hard code the use of EDSA. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>y Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05net: dsa: Copy the routing table into the switch structureAndrew Lunn1-2/+2
The new binding will not have a chip data structure, it will place the routing directly into the switch structure. To enable backwards compatibility, copy the routing from the chip data into the switch structure. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05net: dsa: Remove dynamic allocate of routing tableAndrew Lunn1-2/+1
With a maximum of four switches, the size of the routing table is the same as the pointer to it. Removing it makes the code simpler. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05net: dsa: Add a ports structure and use it in the switch structureAndrew Lunn2-13/+18
There are going to be more per-port members added to the switch structure. So add a port structure and move the netdev into it. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05net: dsa: mv88e6xxx: fix circular lock in PPU workVivien Didelot1-4/+9
Lock debugging shows that there is a possible circular lock in the PPU work code. Switch the lock order of smi_mutex and ppu_mutex to fix this. Here's the full trace: [ 4.341325] ====================================================== [ 4.347519] [ INFO: possible circular locking dependency detected ] [ 4.353800] 4.6.0 #4 Not tainted [ 4.357039] ------------------------------------------------------- [ 4.363315] kworker/0:1/328 is trying to acquire lock: [ 4.368463] (&ps->smi_mutex){+.+.+.}, at: [<8049c758>] mv88e6xxx_reg_read+0x30/0x54 [ 4.376313] [ 4.376313] but task is already holding lock: [ 4.382160] (&ps->ppu_mutex){+.+...}, at: [<8049cac0>] mv88e6xxx_ppu_reenable_work+0x28/0xd4 [ 4.390772] [ 4.390772] which lock already depends on the new lock. [ 4.390772] [ 4.398963] [ 4.398963] the existing dependency chain (in reverse order) is: [ 4.406461] [ 4.406461] -> #1 (&ps->ppu_mutex){+.+...}: [ 4.410897] [<806d86bc>] mutex_lock_nested+0x54/0x360 [ 4.416606] [<8049a800>] mv88e6xxx_ppu_access_get+0x28/0x100 [ 4.422906] [<8049b778>] mv88e6xxx_phy_read+0x90/0xdc [ 4.428599] [<806a4534>] dsa_slave_phy_read+0x3c/0x40 [ 4.434300] [<804943ec>] mdiobus_read+0x68/0x80 [ 4.439481] [<804939d4>] get_phy_device+0x58/0x1d8 [ 4.444914] [<80493ed0>] mdiobus_scan+0x24/0xf4 [ 4.450078] [<8049409c>] __mdiobus_register+0xfc/0x1ac [ 4.455857] [<806a40b0>] dsa_probe+0x860/0xca8 [ 4.460934] [<8043246c>] platform_drv_probe+0x5c/0xc0 [ 4.466627] [<804305a0>] driver_probe_device+0x118/0x450 [ 4.472589] [<80430b00>] __device_attach_driver+0xac/0x128 [ 4.478724] [<8042e350>] bus_for_each_drv+0x74/0xa8 [ 4.484235] [<804302d8>] __device_attach+0xc4/0x154 [ 4.489755] [<80430cec>] device_initial_probe+0x1c/0x20 [ 4.495612] [<8042f620>] bus_probe_device+0x98/0xa0 [ 4.501123] [<8042fbd0>] deferred_probe_work_func+0x4c/0xd4 [ 4.507328] [<8013a794>] process_one_work+0x1a8/0x604 [ 4.513030] [<8013ac54>] worker_thread+0x64/0x528 [ 4.518367] [<801409e8>] kthread+0xec/0x100 [ 4.523201] [<80108f30>] ret_from_fork+0x14/0x24 [ 4.528462] [ 4.528462] -> #0 (&ps->smi_mutex){+.+.+.}: [ 4.532895] [<8015ad5c>] lock_acquire+0xb4/0x1dc [ 4.538154] [<806d86bc>] mutex_lock_nested+0x54/0x360 [ 4.543856] [<8049c758>] mv88e6xxx_reg_read+0x30/0x54 [ 4.549549] [<8049cad8>] mv88e6xxx_ppu_reenable_work+0x40/0xd4 [ 4.556022] [<8013a794>] process_one_work+0x1a8/0x604 [ 4.561707] [<8013ac54>] worker_thread+0x64/0x528 [ 4.567053] [<801409e8>] kthread+0xec/0x100 [ 4.571878] [<80108f30>] ret_from_fork+0x14/0x24 [ 4.577139] [ 4.577139] other info that might help us debug this: [ 4.577139] [ 4.585159] Possible unsafe locking scenario: [ 4.585159] [ 4.591093] CPU0 CPU1 [ 4.595631] ---- ---- [ 4.600169] lock(&ps->ppu_mutex); [ 4.603693] lock(&ps->smi_mutex); [ 4.609742] lock(&ps->ppu_mutex); [ 4.615790] lock(&ps->smi_mutex); [ 4.619314] [ 4.619314] *** DEADLOCK *** [ 4.619314] [ 4.625256] 3 locks held by kworker/0:1/328: [ 4.629537] #0: ("events"){.+.+..}, at: [<8013a704>] process_one_work+0x118/0x604 [ 4.637288] #1: ((&ps->ppu_work)){+.+...}, at: [<8013a704>] process_one_work+0x118/0x604 [ 4.645653] #2: (&ps->ppu_mutex){+.+...}, at: [<8049cac0>] mv88e6xxx_ppu_reenable_work+0x28/0xd4 [ 4.654714] [ 4.654714] stack backtrace: [ 4.659098] CPU: 0 PID: 328 Comm: kworker/0:1 Not tainted 4.6.0 #4 [ 4.665286] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) [ 4.671748] Workqueue: events mv88e6xxx_ppu_reenable_work [ 4.677174] Backtrace: [ 4.679674] [<8010d354>] (dump_backtrace) from [<8010d5a0>] (show_stack+0x20/0x24) [ 4.687252] r6:80fb3c88 r5:80fb3c88 r4:80fb4728 r3:00000002 [ 4.693003] [<8010d580>] (show_stack) from [<803b45e8>] (dump_stack+0x24/0x28) [ 4.700246] [<803b45c4>] (dump_stack) from [<80157398>] (print_circular_bug+0x208/0x32c) [ 4.708361] [<80157190>] (print_circular_bug) from [<8015a630>] (__lock_acquire+0x185c/0x1b80) [ 4.716982] r10:9ec22a00 r9:00000060 r8:8164b6bc r7:00000040 r6:00000003 r5:8163a5b4 [ 4.724905] r4:00000003 r3:9ec22de8 [ 4.728537] [<80158dd4>] (__lock_acquire) from [<8015ad5c>] (lock_acquire+0xb4/0x1dc) [ 4.736378] r10:60000013 r9:00000000 r8:00000000 r7:00000000 r6:9e5e9c50 r5:80e618e0 [ 4.744301] r4:00000000 [ 4.746879] [<8015aca8>] (lock_acquire) from [<806d86bc>] (mutex_lock_nested+0x54/0x360) [ 4.754976] r10:9e5e9c1c r9:80e616c4 r8:9f685ea0 r7:0000001b r6:9ec22a00 r5:8163a5b4 [ 4.762899] r4:9e5e9c1c [ 4.765477] [<806d8668>] (mutex_lock_nested) from [<8049c758>] (mv88e6xxx_reg_read+0x30/0x54) [ 4.774008] r10:80e60c5b r9:80e616c4 r8:9f685ea0 r7:0000001b r6:00000004 r5:9e5e9c10 [ 4.781930] r4:9e5e9c1c [ 4.784507] [<8049c728>] (mv88e6xxx_reg_read) from [<8049cad8>] (mv88e6xxx_ppu_reenable_work+0x40/0xd4) [ 4.793907] r7:9ffd5400 r6:9e5e9c68 r5:9e5e9cb0 r4:9e5e9c10 [ 4.799659] [<8049ca98>] (mv88e6xxx_ppu_reenable_work) from [<8013a794>] (process_one_work+0x1a8/0x604) [ 4.809059] r9:80e616c4 r8:9f685ea0 r7:9ffd5400 r6:80e0a1c8 r5:9f5f2e80 r4:9e5e9cb0 [ 4.816910] [<8013a5ec>] (process_one_work) from [<8013ac54>] (worker_thread+0x64/0x528) [ 4.825010] r10:9f5f2e80 r9:00000008 r8:80e0dc80 r7:80e0a1fc r6:80e0a1c8 r5:9f5f2e98 [ 4.832933] r4:80e0a1c8 [ 4.835510] [<8013abf0>] (worker_thread) from [<801409e8>] (kthread+0xec/0x100) [ 4.842827] r10:00000000 r9:00000000 r8:00000000 r7:8013abf0 r6:9f5f2e80 r5:9ec15740 [ 4.850749] r4:00000000 [ 4.853327] [<801408fc>] (kthread) from [<80108f30>] (ret_from_fork+0x14/0x24) [ 4.860557] r7:00000000 r6:00000000 r5:801408fc r4:9ec15740 Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-16net: dsa: mv88e6xxx: remove bridge workVivien Didelot2-34/+8
Now that the bridge code defers the switchdev port state setting, there is no need to defer the port STP state change within the mv88e6xxx code. Thus get rid of the driver's bridge work code. This also fixes a race condition where the DSA layer assumes that the bridge code already set the unbridged port's STP state to Disabled before restoring the Forwarding state. As a consequence, this also fixes the FDB flush for the unbridged port which now correctly occurs during the Forwarding to Disabled transition. Fixes: 0bc05d585d38 ("switchdev: allow caller to explicitly request attr_set as deferred") Reported-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-12dsa: mv88e6xxx: Handle eeprom-length propertyAndrew Lunn2-0/+20
A switch can export an attached EEPROM using the standard ethtool API. However the switch itself cannot determine the size of the EEPROM, and multiple sizes are allowed. Thus a device tree property is supported to indicate the length of the EEPROM. Parse this property during device probe, and implement a callback function to retrieve it. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-12dsa: Rename switch chip data to cdAndrew Lunn2-4/+4
The dsa_switch structure contains a dsa_chip_data member called pd. However in the rest of the code, pd is used for dsa_platform_data. This is confusing. Rename it cd, which is already often used in dsa.c and slave.c for this data type. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-12dsa: Remove master_dev from switch structureAndrew Lunn1-0/+1
The switch drivers only use the master_dev member for dev_info() messages. Now that the device is passed to the old style probe, and new style drivers are probed as true linux drivers, this is no longer needed. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-12dsa: Move gpio reset into switch driverAndrew Lunn2-1/+20
Resetting the switch is something the driver does, not the framework. So move the parsing of this property into the driver. There are no in kernel users of this property, so moving it does not break anything. There is however a board which will make use of this property making its way into the kernel. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-12dsa: Add mdio device support to Marvell switchesAndrew Lunn1-18/+72
Allow Marvell switches to be mdio devices. Currently the driver just allocate the private structure and detects what device is on the bus. Later patches will make them register with the DSA framework. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-12dsa: mv88e6xxx: Rename probe function to fit the normal patternAndrew Lunn1-4/+4
All other DSA drivers use _drv_ in there DSA probe function name, thus allowing for a true linux driver probe function to use the conventional name. Make mv88e6xxx fit this pattern. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-12dsa: mv88e6xxx: Initialise the mutex as soon as it is createdAndrew Lunn1-2/+1
By initialising immediately it, we don't run the danger of using it before it is initialised. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-12net: dsa: mv88e6xxx: add STU capabilityVivien Didelot2-14/+16
Some switch models have a STU (per VLAN port state database). Add a new capability flag to switches info, instead of checking their family. Also if the 6165 family has an STU, it must have a VTU, so add the MV88E6XXX_FLAG_VTU to its family flags. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-12net: dsa: mv88e6xxx: abstract VTU/STU data accessVivien Didelot1-4/+28
Both VTU and STU operations use the same routine to access their (common) data registers, with a different offset. Add VTU and STU specific read and write functions to the data registers to abstract the required offset. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6xxx: factorize the switch driverVivien Didelot8-619/+297
Now that all drivers support the same set of functions and the same setup code, drop every model-specific DSA switch driver and replace them with a common mv88e6xxx driver. This merges the info tables into one, removes the function exports, the model-specific files, and update the defconfigs. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6131: use EDSA tag protocolVivien Didelot2-2/+2
6131 is the only driver to set the tag protocol to DSA_TAG_PROTO_DSA. Since it works fine with DSA_TAG_PROTO_EDSA, change its value, like all other mv88e6xxx drivers. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6xxx: factorize switch setupVivien Didelot6-98/+38
Provide a shared mv88e6xxx_setup function to the drivers. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6131: drop frames priorities setupVivien Didelot1-18/+0
6131 is the only driver which setups the priority of IGMP/MLD snoop frames and ARP frames to the highest setting. Drop such change until we figure out a common configuration for all switch models. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6xxx: factorize GLOBAL_CONTROL_2 setupVivien Didelot5-60/+7
All switch models setup the GLOBAL_CONTROL_2 register with slightly differences. Since the cascade mode is valid even in a single chip setup, factorize such configuration. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6xxx: factorize GLOBAL_MONITOR_CONTROL setupVivien Didelot5-56/+12
All switch drivers configure the GLOBAL_MONITOR_CONTROL register with slightly changes. Assume the setup of the upstream port, and configure it as the port to which ingress and egress and ARP monitor frames are to be sent. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6131: drop VLAN Ethertype setupVivien Didelot1-5/+0
The 6131 switch models have a Core Tag Type register. Their setup code is setting it to 0x8100, which is the reset default. Drop this specific part which is correctly configured on reset anyway. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6xxx: factorize GLOBAL_CONTROL setupVivien Didelot5-37/+13
All switch models configure the GLOBAL_CONTROL register with slightly differences. Discarding packets with excessive collisions (GLOBAL_CONTROL_DISCARD_EXCESS) is specific to 6352 and similar switches, and setting a maximum frame size (GLOBAL_CONTROL_MAX_FRAME_1632) is specific to 6185 and similar switches. As we are centralizing the chips setup, skip these settings and don't discard any frames yet, until we found out that such discarding by the hardware is necessary. Assume a common setup to enable the PHY Polling Unit if present, don't discard any packets, and mask all interrupt sources. Tested on 88E6352 and 88E6185. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6xxx: factorize global setupVivien Didelot6-70/+56
Every driver is calling mv88e6xxx_setup_global after mv88e6xxx_setup_common. Call the former in the latter. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6xxx: factorize switch resetVivien Didelot6-83/+76
Add a MV88E6XXX_FLAG_PPU_ACTIVE flag to describe how to reset the switch, and merge the reset call to the common setup code. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6xxx: factorize ATU accessVivien Didelot3-6/+36
Add a MV88E6XXX_FLAG_ATU flag to identify switch models with an Address Translation Unit. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6xxx: factorize VTU accessVivien Didelot3-6/+39
Add a MV88E6XXX_FLAG_VTU flag to indentify switch models with a VLAN Table Unit. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6xxx: factorize bridge supportVivien Didelot4-8/+43
Add MV88E6XXX_FLAG_PORTSTATE and MV88E6XXX_FLAG_VLANTABLE flags to identify switch models with required 802.1D operations. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6131: add registers accessVivien Didelot2-1/+7
Only 6131 was not supporting the port registers access yet. Assume such support and use the unlock access routines in the meantime. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6xxx: factorize EEE accessVivien Didelot5-2/+21
Add a MV88E6XXX_FLAG_EEE flag to describe switch models featuring Energy Efficient Ethernet. Use it to conditionally support such access in the common code. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6xxx: factorize MAC address settingVivien Didelot6-9/+30
Some switch models have a dedicated register for Switch MAC/WoF/WoL. This register, when present, is used to indirectly set the switch MAC address, instead of a direct write to 3 global registers. Identify this feature and share a common mv88e6xxx_set_addr function. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6xxx: factorize temperature accessVivien Didelot5-7/+36
Add MV88E6XXX_FLAG_TEMP and MV88E6XXX_FLAG_TEMP_LIMIT flags to describe switch models featuring a temperature access. Use them to centralize the access to the temperature feature. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6xxx: factorize EEPROM accessVivien Didelot6-211/+236
Add a MV88E6XXX_FLAG_EEPROM flag to describe switch models featuring an EEPROM and distribute the EEPROM access routines to all models. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6xxx: factorize PHY indirect accessVivien Didelot4-46/+21
Some switch has dedicated SMI PHY Command and Data registers, used to indirectly access the PHYs, instead of direct access. Identify these switch models and make mv88e6xxx_phy_{read,write} generic enough to support every models. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6xxx: factorize PHY access with PPUVivien Didelot4-66/+43
Add a MV88E6XXX_FLAG_PPU flag to describe switch models with a PHY Polling Unit. This allows to merge PPU specific PHY access code in the share code. Make the mv88e6xxx_ppu_disable and mv88e6xxx_phy_{read,write}_ppu functions use unlocked register accesses in order to call them in mv88e6xxx_phy_{read,write} in a locked context. Since the PPU code is shared, also remove NET_DSA_MV88E6XXX_NEED_PPU. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-09net: dsa: mv88e6xxx: add flags to infoVivien Didelot5-0/+38
Add a flags bitmap to the info structure in order to identify features supported or not by the different switch models. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>