kernel/linux.git/drivers/net/dsa, branch v4.17.1

net: dsa: b53: Fix for brcm tag issue in Cygnus SoC

2018-06-11T20:43:19+00:00

[ Upstream commit 5040cc990cbac98733df4d58fdeac5bbdab15b49 ] In the Broadcom Cygnus SoC, the brcm tag needs to be inserted in between the mac address and the ether type (should use 'DSA_PROTO_TAG_BRCM') for the packets sent to the internal b53 switch. Since the Cygnus was added with the BCM58XX device id and the BCM58XX uses 'DSA_PROTO_TAG_BRCM_PREPEND', the data path is broken, due to the incorrect brcm tag location. Add a new b53 device id (BCM583XX) for Cygnus family to fix the issue. Add the new device id to the BCM58XX family as Cygnus is similar to the BCM58XX in most other functionalities. Fixes: 11606039604c ("net: dsa: b53: Support prepended Broadcom tags") Signed-off-by: Arun Parameswaran Acked-by: Scott Branden Reported-by: Clément Péron Reviewed-by: Florian Fainelli Tested-by: Clément Péron Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: dsa: b53: Add BCM5389 support

2018-06-01T15:15:42+00:00

This patch adds support for the BCM5389 switch connected through MDIO. Signed-off-by: Damien Thébault Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller

net: dsa: bcm_sf2: Fix IPv6 rule half deletion

2018-05-16T18:11:22+00:00

It was possible to delete only one half of an IPv6, which would leave the second half still programmed and possibly in use. Instead of checking for the unused bitmap, we need to check the unique bitmap, and refuse any deletion that does not match that criteria. We also need to move that check from bcm_sf2_cfp_rule_del_one() into its caller: bcm_sf2_cfp_rule_del() otherwise we would not be able to delete second halves anymore that would not pass the first test. Fixes: ba0696c22e7c ("net: dsa: bcm_sf2: Add support for IPv6 CFP rules") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller

net: dsa: bcm_sf2: Fix IPv6 rules and chain ID

2018-05-16T18:11:22+00:00

We had several issues that would make the programming of IPv6 rules both inconsistent and error prone: - the chain ID that we would be asking the hardware to put in the packet's Broadcom tag would be off by one, it would return one of the two indexes, but not the one user-space specified - when an user specified a particular location to insert a CFP rule at, we would not be returning the same index, which would be confusing if nothing else - finally, like IPv4, it would be possible to overflow the last entry by re-programming it Fix this by swapping the usage of rule_index[0] and rule_index[1] where relevant in order to return a consistent and correct user-space experience. Fixes: ba0696c22e7c ("net: dsa: bcm_sf2: Add support for IPv6 CFP rules") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller

net: dsa: bcm_sf2: Fix RX_CLS_LOC_ANY overwrite for last rule

2018-05-16T18:11:22+00:00

When we let the kernel pick up a rule location with RX_CLS_LOC_ANY, we would be able to overwrite the last rules because of a number of issues. The IPv4 code path would not be checking that rule_index is within bounds, and it would also only be allowed to pick up rules from range 0..126 instead of the full 0..127 range. This would lead us to allow overwriting the last rule when we let the kernel pick-up the location. Fixes: 3306145866b6 ("net: dsa: bcm_sf2: Move IPv4 CFP processing to specific functions") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller

net: dsa: mv88e6xxx: Fix PHY interrupts by parameterising PHY base address

2018-05-08T03:41:58+00:00

Most of the mv88e6xxx switches have the PHYs at address 0, 1, 2, ... The 6341 however has the PHYs at 0x10, 0x11, 0x12. Add a parameter to the info structure for this base address. Testing of 6f88284f3bd7 ("net: dsa: mv88e6xxx: Add MDIO interrupts for internal PHYs") was performed on the 6341. So it works only on the 6341. Use this base information to correctly set the interrupt. Fixes: 6f88284f3bd7 ("net: dsa: mv88e6xxx: Add MDIO interrupts for internal PHYs") Signed-off-by: Andrew Lunn Signed-off-by: David S. Miller

net: dsa: mv88e6xxx: Fix receive time stamp race condition.

2018-04-13T02:05:58+00:00

The DSA stack passes received PTP frames to this driver via mv88e6xxx_port_rxtstamp() for deferred delivery. The driver then queues the frame and kicks the worker thread. The work callback reads out the latched receive time stamp and then works through the queue, delivering any non-matching frames without a time stamp. If a new frame arrives after the worker thread has read out the time stamp register but enters the queue before the worker finishes processing the queue, that frame will be delivered without a time stamp. This patch fixes the race by moving the queue onto a list on the stack before reading out the latched time stamp value. Fixes: c6fe0ad2c3499 ("net: dsa: mv88e6xxx: add rx/tx timestamping support") Signed-off-by: Richard Cochran Signed-off-by: David S. Miller

net: dsa: mt7530: Use NULL instead of plain integer

2018-04-04T15:15:49+00:00

We would be passing 0 instead of NULL as the rsp argument to mt7530_fdb_cmd(), fix that. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: Florian Fainelli Acked-by: Sean Wang Signed-off-by: David S. Miller

net: dsa: b53: Fix sparse warnings in b53_mmap.c

2018-04-04T15:15:27+00:00

sparse complains about the following warnings: drivers/net/dsa/b53/b53_mmap.c:33:31: warning: incorrect type in initializer (different address spaces) drivers/net/dsa/b53/b53_mmap.c:33:31: expected unsigned char [noderef] [usertype] *regs drivers/net/dsa/b53/b53_mmap.c:33:31: got void *priv and indeed, while what we are doing is functional, we are dereferencing a void * pointer into a void __iomem * which is not great. Just use the defined b53_mmap_priv structure which holds our register base and use that. Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2018-04-01T23:49:34+00:00

Minor conflicts in drivers/net/ethernet/mellanox/mlx5/core/en_rep.c, we had some overlapping changes: 1) In 'net' MLX5E_PARAMS_LOG_{SQ,RQ}_SIZE --> MLX5E_REP_PARAMS_LOG_{SQ,RQ}_SIZE 2) In 'net-next' params->log_rq_size is renamed to be params->log_rq_mtu_frames. 3) In 'net-next' params->hard_mtu is added. Signed-off-by: David S. Miller