summaryrefslogtreecommitdiff
path: root/drivers/net/dsa
AgeCommit message (Collapse)Author
2019-03-21net: dsa: bcm_sf2: Remove print of base addressFlorian Fainelli
Since commit ad67b74d2469 ("printk: hash addresses printed with %p") pointers are being hashed when printed. Displaying the virtual memory at bootup time is not helpful, we use a dev_info() print which already displays the platform device's address. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-08net: dsa: mv88e6xxx: Set correct interface mode for CPU/DSA portsAndrew Lunn
By default, the switch driver is expected to configure CPU and DSA ports to their maximum speed. For the 6341 and 6390 families, the ports interface mode has to be configured as well. The 6390X range support 10G ports using XAUI, while the 6341 and 6390 supports 2500BaseX, as their maximum speed. Fixes: 787799a9d555 ("net: dsa: mv88e6xxx: Default ports 9/10 6390X CMODE to 1000BaseX") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-04Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
2019-03-04net: dsa: mv88e6xxx: add call to mv88e6xxx_ports_cmode_init to probe for new ↵Heiner Kallweit
DSA framework In the original patch I missed to add mv88e6xxx_ports_cmode_init() to the second probe function, the one for the new DSA framework. Fixes: ed8fe20205ac ("net: dsa: mv88e6xxx: prevent interrupt storm caused by mv88e6390x_port_set_cmode") Reported-by: Shaokun Zhang <zhangshaokun@hisilicon.com> Suggested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-04net: dsa: mv88e6xxx: support in-band signalling on SGMII ports with external ↵Heiner Kallweit
PHYs If an external PHY is connected via SGMII and uses in-band signalling then the auto-negotiated values aren't propagated to the port, resulting in a broken link. See discussion in [0]. This patch adds this propagation. We need to call mv88e6xxx_port_setup_mac(), therefore export it from chip.c. Successfully tested on a ZII DTU with 88E6390 switch and an Aquantia AQCS109 PHY connected via SGMII to port 9. [0] https://marc.info/?t=155130287200001&r=1&w=2 Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-03net: dsa: mv8e6xxx: fix number of internal PHYs for 88E6x90 familyHeiner Kallweit
Ports 9 and 10 don't have internal PHY's but are (dependent on the version) SERDES/SGMII/XAUI/RXAUI ports. v2: - fix it for all 88E6x90 family members Fixes: bc3931557d1d ("net: dsa: mv88e6xxx: Add number of internal PHYs") Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-03net: dsa: mv88e6xxx: handle unknown duplex modes gracefully in ↵Heiner Kallweit
mv88e6xxx_port_set_duplex When testing another issue I faced the problem that mv88e6xxx_port_setup_mac() failed due to DUPLEX_UNKNOWN being passed as argument to mv88e6xxx_port_set_duplex(). We should handle this case gracefully and return -EOPNOTSUPP, like e.g. mv88e6xxx_port_set_speed() is doing it. Fixes: 7f1ae07b51e8 ("net: dsa: mv88e6xxx: add port duplex setter") Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-03net: dsa: microchip: add KSZ9893 switch supportTristram Ha
Add KSZ9893 switch support in KSZ9477 driver. This switch is similar to KSZ9477 except the ingress tail tag has 1 byte instead of 2 bytes, so KSZ9893 tagging will be used. The XMII register that governs how the host port communicates with the MAC also has different register definitions. Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-02Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
2019-03-02net: dsa: mv88e6xxx: Fix statistics on mv88e6161Andrew Lunn
Despite what the datesheet says, the silicon implements the older way of snapshoting the statistics. Change the op. Reported-by: Chris.Healy@zii.aero Tested-by: Chris.Healy@zii.aero Fixes: 0ac64c394900 ("net: dsa: mv88e6xxx: mv88e6161 uses mv88e6320 stats snapshot") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-01drivers: net: Remove unnecessary semicolonYueHaibing
drivers/net/dsa/mt7530.c:649:3-4: Unneeded semicolon drivers/net/ethernet/cisco/enic/enic_clsf.c:35:2-3: Unneeded semicolon drivers/net/ethernet/faraday/ftgmac100.c:1640:2-3: Unneeded semicolon drivers/net/ethernet/mediatek/mtk_eth_soc.c:229:2-3: Unneeded semicolon drivers/net/usb/sr9700.c:437:2-3: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Sean Wang <sean.wang@mediatek.com> for mt7530 and mtk_eth_soc Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-01net: dsa: mv88e6xxx: prevent interrupt storm caused by mv88e6390x_port_set_cmodeHeiner Kallweit
When debugging another issue I faced an interrupt storm in this driver (88E6390, port 9 in SGMII mode), consisting of alternating link-up / link-down interrupts. Analysis showed that the driver wanted to set a cmode that was set already. But so far mv88e6390x_port_set_cmode() doesn't check this and powers down SERDES, what causes the link to break, and eventually results in the described interrupt storm. Fix this by checking whether the cmode actually changes. We want that the very first call to mv88e6390x_port_set_cmode() always configures the registers, therefore initialize port.cmode with a value that is different from any supported cmode value. We have to take care that we only init the ports cmode once chip->info->num_ports is set. v2: - add small helper and init the number of actual ports only Fixes: 364e9d7776a3 ("net: dsa: mv88e6xxx: Power on/off SERDES on cmode change") Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-28net: dsa: mv88e6xxx: power serdes on/off for 10G interfaces on 6390XMaxime Chevallier
Upon setting the cmode on 6390 and 6390X, the associated serdes interfaces must be powered off/on. Both 6390X and 6390 share code to do so, but it currently uses the 6390 specific helper mv88e6390_serdes_power() to disable and enable the serdes interface. This call will fail silently on 6390X when trying so set a 10G interface such as XAUI or RXAUI, since mv88e6390_serdes_power() internally grabs the lane number based on modes supported by the 6390, and returns 0 when getting -ENODEV as a lane number. Using mv88e6390x_serdes_power() should be safe here, since we explicitly rule-out all ports but the 9 and 10, and because modes supported by 6390 ports 9 and 10 are a subset of those supported on 6390X. This was tested on 6390X using RXAUI mode. Fixes: 364e9d7776a3 ("net: dsa: mv88e6xxx: Power on/off SERDES on cmode change") Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-28net: dsa: mv88e6xxx: Fix u64 statisticsAndrew Lunn
The switch maintains u64 counters for the number of octets sent and received. These are kept as two u32's which need to be combined. Fix the combing, which wrongly worked on u16's. Fixes: 80c4627b2719 ("dsa: mv88x6xxx: Refactor getting a single statistic") Reported-by: Chris Healy <Chris.Healy@zii.aero> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-25net: dsa: mv88e6xxx: Fix phylink_validate for Topaz familyMarek Behún
The Topaz family should have different phylink_validate method from the Peridot, since on Topaz the port supporting 2500BaseX mode is port 5, not 9 and 10. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-25net: dsa: mv88e6xxx: Default CMODE to 1000BaseX only on 6390XMarek Behún
Commit 787799a9d555 sets the SERDES interfaces of 6390 and 6390X to 1000BaseX, but this is only needed on 6390X, since there are SERDES interfaces which can be used on lower ports on 6390. This commit fixes this by returning to previous behaviour on 6390. (Previous behaviour means that CMODE is not set at all if requested mode is NA). This is needed on Turris MOX, where the 88e6190 is connected to CPU in 2500BaseX mode. Fixes: 787799a9d555 ("net: dsa: mv88e6xxx: Default ports 9/10 6390X CMODE to 1000BaseX") Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-24dsa: Remove phydev parameter from disable_port callAndrew Lunn
No current DSA driver makes use of the phydev parameter passed to the disable_port call. Remove it. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-24net: dsa: mv88e6xxx: Release lock while requesting IRQAndrew Lunn
There is no need to hold the register lock while requesting the GPIO interrupt. By not holding it we can also avoid a false positive lockdep splat. Reported-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-24net: dsa: mv88e6xxx: Add lockdep classes to fix false positive splatAndrew Lunn
The following false positive lockdep splat has been observed. ====================================================== WARNING: possible circular locking dependency detected 4.20.0+ #302 Not tainted ------------------------------------------------------ systemd-udevd/160 is trying to acquire lock: edea6080 (&chip->reg_lock){+.+.}, at: __setup_irq+0x640/0x704 but task is already holding lock: edff0340 (&desc->request_mutex){+.+.}, at: __setup_irq+0xa0/0x704 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&desc->request_mutex){+.+.}: mutex_lock_nested+0x1c/0x24 __setup_irq+0xa0/0x704 request_threaded_irq+0xd0/0x150 mv88e6xxx_probe+0x41c/0x694 [mv88e6xxx] mdio_probe+0x2c/0x54 really_probe+0x200/0x2c4 driver_probe_device+0x5c/0x174 __driver_attach+0xd8/0xdc bus_for_each_dev+0x58/0x7c bus_add_driver+0xe4/0x1f0 driver_register+0x7c/0x110 mdio_driver_register+0x24/0x58 do_one_initcall+0x74/0x2e8 do_init_module+0x60/0x1d0 load_module+0x1968/0x1ff4 sys_finit_module+0x8c/0x98 ret_fast_syscall+0x0/0x28 0xbedf2ae8 -> #0 (&chip->reg_lock){+.+.}: __mutex_lock+0x50/0x8b8 mutex_lock_nested+0x1c/0x24 __setup_irq+0x640/0x704 request_threaded_irq+0xd0/0x150 mv88e6xxx_g2_irq_setup+0xcc/0x1b4 [mv88e6xxx] mv88e6xxx_probe+0x44c/0x694 [mv88e6xxx] mdio_probe+0x2c/0x54 really_probe+0x200/0x2c4 driver_probe_device+0x5c/0x174 __driver_attach+0xd8/0xdc bus_for_each_dev+0x58/0x7c bus_add_driver+0xe4/0x1f0 driver_register+0x7c/0x110 mdio_driver_register+0x24/0x58 do_one_initcall+0x74/0x2e8 do_init_module+0x60/0x1d0 load_module+0x1968/0x1ff4 sys_finit_module+0x8c/0x98 ret_fast_syscall+0x0/0x28 0xbedf2ae8 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&desc->request_mutex); lock(&chip->reg_lock); lock(&desc->request_mutex); lock(&chip->reg_lock); &desc->request_mutex refer to two different mutex. #1 is the GPIO for the chip interrupt. #2 is the chained interrupt between global 1 and global 2. Add lockdep classes to the GPIO interrupt to avoid this. Reported-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-24net: dsa: microchip: add port_cleanup functionTristram Ha
Add port_cleanup function to reset some device variables when the port is disabled. Add a mutex to make sure changing those variables is thread-safe. Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-24net: dsa: microchip: remove unnecessary include headersTristram Ha
Remove unnecessary header include. Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-24net: dsa: microchip: get port link statusTristram Ha
Get port link status to know whether to read MIB counters when the link is going down. Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-24net: dsa: microchip: add MIB counter reading supportTristram Ha
Add background MIB counter reading support. Port MIB counters should only be read when there is link. Otherwise it is a waste of time as hardware never increases those counters. There are exceptions as some switches keep track of dropped counts no matter what. Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-24net: dsa: microchip: prepare PHY for proper advertisementTristram Ha
Prepare PHY for proper advertisement as sometimes the PHY in the switch has its own problems even though it may share the PHY id from regular PHY but the fixes in the PHY driver do not apply. Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-24net: dsa: lantiq: Add GPHY firmware filesHauke Mehrtens
This adds the file names of the FW files which this driver handles into the module description. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-23net: dsa: mv88e6xxx: Fix -Wformat-security warningsFlorian Fainelli
We are not specifying an explicit format argument but instead passing a string litteral which causes these two warnings to show up: drivers/net/dsa/mv88e6xxx/chip.c: In function 'mv88e6xxx_irq_poll_setup': drivers/net/dsa/mv88e6xxx/chip.c:483:2: warning: format not a string literal and no format arguments [-Wformat-security] chip->kworker = kthread_create_worker(0, dev_name(chip->dev)); ^~~~ drivers/net/dsa/mv88e6xxx/ptp.c: In function 'mv88e6xxx_ptp_setup': drivers/net/dsa/mv88e6xxx/ptp.c:403:4: warning: format not a string literal and no format arguments [-Wformat-security] dev_name(chip->dev)); ^~~~~~~~ LD [M] drivers/net/dsa/mv88e6xxx/mv88e6xxx.o Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-21net: dsa: mv88e6xxx: add support for bridge flagsRussell King
Add support for the bridge flags to Marvell 88e6xxx bridges, allowing the multicast and unicast flood properties to be controlled. These can be controlled on a per-port basis via commands such as: bridge link set dev lan1 flood on|off bridge link set dev lan1 mcast_flood on|off Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-20Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
Two easily resolvable overlapping change conflicts, one in TCP and one in the eBPF verifier. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-19net: dsa: qca8k: Enable delay for RGMII_ID modeVinod Koul
RGMII_ID specifies that we should have internal delay, so resurrect the delay addition routine but under the RGMII_ID mode. Fixes: 40269aa9f40a ("net: dsa: qca8k: disable delay for RGMII mode") Tested-by: Michal Vokáč <michal.vokac@ysoft.com> Signed-off-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-17net: dsa: bcm_sf2: Remove set but not used variables 'v6_spec, v6_m_spec'YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/dsa/bcm_sf2_cfp.c: In function 'bcm_sf2_cfp_ipv6_rule_set': drivers/net/dsa/bcm_sf2_cfp.c:606:40: warning: variable 'v6_m_spec' set but not used [-Wunused-but-set-variable] drivers/net/dsa/bcm_sf2_cfp.c:606:30: warning: variable 'v6_spec' set but not used [-Wunused-but-set-variable] It not used any more after commit e4f7ef54cbd8 ("dsa: bcm_sf2: use flow_rule infrastructure") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-15net: dsa: b53: Do not program CPU port's PVIDFlorian Fainelli
The CPU port is special and does not need to obey VLAN restrictions as far as untagged traffic goes, also, having the CPU port be part of a particular PVID is against the idea of keeping it tagged in all VLANs. Fixes: ca8931948344 ("net: dsa: b53: Keep CPU port as tagged in all VLANs") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-15net: dsa: bcm_sf2: Do not assume DSA master supports WoLFlorian Fainelli
We assume in the bcm_sf2 driver that the DSA master network device supports ethtool_ops::{get,set}_wol operations, which is not a given. Avoid de-referencing potentially non-existent function pointers and check them as we should. Fixes: 96e65d7f3f88 ("net: dsa: bcm_sf2: add support for Wake-on-LAN") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-15net: dsa: b53: Properly account for VLAN filteringFlorian Fainelli
VLAN filtering can be built into the kernel, and also dynamically turned on/off through the bridge master device. Allow re-configuring the switch appropriately to account for that by deciding whether VLAN table (v_table) misses should lead to a drop or forward. Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-15net: dsa: b53: Fix default VLAN IDFlorian Fainelli
We were not consistent in how the default VID of a given port was defined, b53_br_leave() would make sure the VLAN ID would be either 0/1 depending on the switch generation, but b53_configure_vlan(), which is the default configuration would unconditionally set it to 1. The correct value is 1 for 5325/5365 series and 0 otherwise. To avoid repeating that mistake ever again, introduce a helper function: b53_default_pvid() to factor that out. Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-15Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
The netfilter conflicts were rather simple overlapping changes. However, the cls_tcindex.c stuff was a bit more complex. On the 'net' side, Cong is fixing several races and memory leaks. Whilst on the 'net-next' side we have Vlad adding the rtnl-ness support. What I've decided to do, in order to resolve this, is revert the conversion over to using a workqueue that Cong did, bringing us back to pure RCU. I did it this way because I believe that either Cong's races don't apply with have Vlad did things, or Cong will have to implement the race fix slightly differently. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-13net: dsa: bcm_sf2: potential array overflow in bcm_sf2_sw_suspend()Dan Carpenter
The value of ->num_ports comes from bcm_sf2_sw_probe() and it is less than or equal to DSA_MAX_PORTS. The ds->ports[] array is used inside the dsa_is_user_port() and dsa_is_cpu_port() functions. The ds->ports[] array is allocated in dsa_switch_alloc() and it has ds->num_ports elements so this leads to a static checker warning about a potential out of bounds read. Fixes: 8cfa94984c9c ("net: dsa: bcm_sf2: add suspend/resume callbacks") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-13dsa: mv88e6xxx: Ensure all pending interrupts are handled prior to exitJohn David Anglin
The GPIO interrupt controller on the espressobin board only supports edge interrupts. If one enables the use of hardware interrupts in the device tree for the 88E6341, it is possible to miss an edge. When this happens, the INTn pin on the Marvell switch is stuck low and no further interrupts occur. I found after adding debug statements to mv88e6xxx_g1_irq_thread_work() that there is a race in handling device interrupts (e.g. PHY link interrupts). Some interrupts are directly cleared by reading the Global 1 status register. However, the device interrupt flag, for example, is not cleared until all the unmasked SERDES and PHY ports are serviced. This is done by reading the relevant SERDES and PHY status register. The code only services interrupts whose status bit is set at the time of reading its status register. If an interrupt event occurs after its status is read and before all interrupts are serviced, then this event will not be serviced and the INTn output pin will remain low. This is not a problem with polling or level interrupts since the handler will be called again to process the event. However, it's a big problem when using level interrupts. The fix presented here is to add a loop around the code servicing switch interrupts. If any pending interrupts remain after the current set has been handled, we loop and process the new set. If there are no pending interrupts after servicing, we are sure that INTn has gone high and we will get an edge when a new event occurs. Tested on espressobin board. Fixes: dc30c35be720 ("net: dsa: mv88e6xxx: Implement interrupt support.") Signed-off-by: John David Anglin <dave.anglin@bell.net> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-11net: dsa: microchip: add switch offload forwarding supportTristram Ha
The flag offload_fwd_mark is set as the switch can forward frames by itself. This can be considered a fix to a problem introduced in commit c2e866911e254067 where the port membership are not set in sync. The flag offload_fwd_mark just needs to be set in tag_ksz.c to prevent the software bridge from forwarding duplicate multicast frames. Fixes: c2e866911e254067 ("microchip: break KSZ9477 DSA driver into two files") Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-09net: dsa: mv88e6xxx: SERDES support 2500BaseT via external PHYAndrew Lunn
By using an external PHY, ports 9 and 10 can support 2500BaseT. So set this link mode in the mask when validating. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-08net: dsa: bcm_sf2: Allow looping back CFP rulesFlorian Fainelli
When the source and destination port of a CFP rule match, we must set the loopback bit enable to allow that, otherwise the frame is discarded. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-08net: dsa: bcm_sf2: Add support for CFP statisticsFlorian Fainelli
Return CFP policer statistics (Green, Yellow or Red) as part of the standard ethtool statistics. This helps debug when CFP rules may not be hit (0 counter). Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-08net: dsa: bcm_sf2: Prepare for adding CFP statisticsFlorian Fainelli
In preparation for adding CFP statistics, we will need to overlay the standard B53 statistics, so create specific bcm_sf2_sw_* functions to call into their b53_common.c counterpart. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-08net: dsa: bcm_sf2: Remove stats mutexFlorian Fainelli
We no longer need a dedicated statistics mutex since we leverage b53_common for statistics now. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-08Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
An ipvlan bug fix in 'net' conflicted with the abstraction away of the IPV6 specific support in 'net-next'. Similarly, a bug fix for mlx5 in 'net' conflicted with the flow action conversion in 'net-next'. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-07net: dsa: b53: Fix for failure when irq is not defined in dtArun Parameswaran
Fixes the issues with non BCM58XX chips in the b53 driver failing, when the irq is not specified in the device tree. Removed the check for BCM58XX in b53_srab_prepare_irq(), so the 'port->irq' will be set to '-EXIO' if the irq is not specified in the device tree. Fixes: 16994374a6fc ("net: dsa: b53: Make SRAB driver manage port interrupts") Fixes: b2ddc48a81b5 ("net: dsa: b53: Do not fail when IRQ are not initialized") Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-06net: dsa: mv88e6xxx: Prevent suspend to RAMMiquel Raynal
On one hand, the mv88e6xxx driver has a work queue called in loop which will attempt register accesses after MDIO bus suspension, that entirely freezes the platform during suspend. On the other hand, the DSA core is not ready yet to support suspend to RAM operation because so far there is no way to recover reliably the switch configuration. To avoid the kernel to freeze when suspending with a switch driven by the mv88e6xxx driver, we choose to prevent the driver suspension and in the same way, the whole platform. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-06dsa: bcm_sf2: use flow_rule infrastructurePablo Neira Ayuso
Update this driver to use the flow_rule infrastructure, hence we can use the same code to populate hardware IR from ethtool_rx_flow and the cls_flower interfaces. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-05net: dsa: mv88e6xxx: Fix counting of ATU violationsAndrew Lunn
The ATU port vector contains a bit per port of the switch. The code wrongly used it as a port number, and incremented a port counter. This resulted in the wrong interfaces counter being incremented, and potentially going off the end of the array of ports. Fix this by using the source port ID for the violation, which really is a port number. Reported-by: Chris Healy <Chris.Healy@zii.aero> Tested-by: Chris Healy <Chris.Healy@zii.aero> Fixes: 65f60e4582bd ("net: dsa: mv88e6xxx: Keep ATU/VTU violation statistics") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-04net: phy: fixed-phy: Drop GPIO from fixed_phy_add()Linus Walleij
All users of the fixed_phy_add() pass -1 as GPIO number to the fixed phy driver, and all users of fixed_phy_register() pass -1 as GPIO number as well, except for the device tree MDIO bus. Any new users should create a proper device and pass the GPIO as a descriptor associated with the device so delete the GPIO argument from the calls and drop the code looking requesting a GPIO in fixed_phy_add(). In fixed phy_register(), investigate the "fixed-link" node and pick the GPIO descriptor from "link-gpios" if this property exists. Move the corresponding code out of of_mdio.c as the fixed phy code anyways requires OF to be in use. Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-01-30net: dsa: mt7530: support the 7530 switch on the Mediatek MT7621 SoCGreg Ungerer
The MediaTek MT7621 SoC device contains a 7530 switch, and the existing linux kernel 7530 DSA switch driver can be used with it. The bulk of the changes required stem from the 7621 having different regulator and pad setup. The existing setup of these in the 7530 driver appears to be very specific to its implemtation in the Mediatek 7623 SoC. (Not entirely surprising given the 7623 is a quad core ARM based SoC, and the 7621 is a dual core, dual thread MIPS based SoC). Create a new devicetree type, "mediatek,mt7621", to support the 7530 switch in the 7621 SoC. There appears to be no usable ID register to distinguish it from a 7530 in other hardware at runtime. This is used to carry out the appropriate configuration and setup. Signed-off-by: Greg Ungerer <gerg@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Sean Wang <sean.wang@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>