kernel.git/drivers/net/dsa/b53, branch linux-4.8.y

net: dsa: b53: Fix VLAN usage and how we treat CPU port

2016-12-10T18:09:37Z

[ Upstream commit e47112d9d6009bf6b7438cedc0270316d6b0370d ] We currently have a fundamental problem in how we treat the CPU port and its VLAN membership. As soon as a second VLAN is configured to be untagged, the CPU automatically becomes untagged for that VLAN as well, and yet, we don't gracefully make sure that the CPU becomes tagged in the other VLANs it could be a member of. This results in only one VLAN being effectively usable from the CPU's perspective. Instead of having some pretty complex logic which tries to maintain the CPU port's default VLAN and its untagged properties, just do something very simple which consists in neither altering the CPU port's PVID settings, nor its untagged settings: - whenever a VLAN is added, the CPU is automatically a member of this VLAN group, as a tagged member - PVID settings for downstream ports do not alter the CPU port's PVID since it now is part of all VLANs in the system This means that a typical example where e.g: LAN ports are in VLAN1, and WAN port is in VLAN2, now require having two VLAN interfaces for the host to properly terminate and send traffic from/to. Fixes: Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support") Reported-by: Hartmut Knaack Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: dsa: b53: Add missing ULL suffix for 64-bit constant

2016-08-06T04:11:08Z

On 32-bit (e.g. with m68k-linux-gnu-gcc-4.1): drivers/net/dsa/b53/b53_common.c: In function ‘b53_arl_read’: drivers/net/dsa/b53/b53_common.c:1072: warning: integer constant is too large for ‘long’ type Fixes: 1da6df85c6fbed8f ("net: dsa: b53: Implement ARL add/del/dump operations") Signed-off-by: Geert Uytterhoeven Signed-off-by: David S. Miller

dsa: b53: remove redundant if

2016-08-01T20:32:53Z

For pdata == null the code leaves with an error. There is no need to check the condition again. Signed-off-by: Heinrich Schuchardt Signed-off-by: David S. Miller

b53: Fix build warning.

2016-07-11T21:30:52Z

drivers/net/dsa/b53/b53_srab.c: In function 'b53_srab_probe': >> drivers/net/dsa/b53/b53_srab.c:388:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] pdata->chip_id = (u32)of_id->data; ^ Reported-by: kbuild test robot Signed-off-by: David S. Miller

net: dsa: b53: Add support for BCM585xx/586xx/88312 integrated switch

2016-07-11T19:52:03Z

Update the SRAB, core driver and binding document to support the BCM585xx/586xx/88312 integrated switch (Northstar Plus SoCs family). Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller

net: dsa: b53: Allow SRAB driver to specify platform data

2016-07-11T19:52:03Z

For Northstart Plus SoCs, we cannot detect the switch because only the revision information is provied in the Management page, instead, rely on Device Tree to tell us the chip id, and pass it down using the b53_platform_data structure. Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller

dsa: b53: avoid 'maybe-uninitialized' warning

2016-06-29T09:07:12Z

In some configurations, gcc produces a warning for correct code in this driver: drivers/net/dsa/b53/b53_mmap.c: In function 'b53_mmap_read64': drivers/net/dsa/b53/b53_mmap.c:107:10: error: 'hi' may be used uninitialized in this function [-Werror=maybe-uninitialized] *val = ((u64)hi << 32) | lo; ^~~~~~~ drivers/net/dsa/b53/b53_mmap.c: In function 'b53_mmap_read48': drivers/net/dsa/b53/b53_mmap.c:91:11: error: 'hi' may be used uninitialized in this function [-Werror=maybe-uninitialized] *val = ((u64)hi << 32) | lo; ^~~~~~~ drivers/net/dsa/b53/b53_mmap.c:83:11: error: 'hi' may be used uninitialized in this function [-Werror=maybe-uninitialized] *val = ((u64)hi << 16) | lo; I have seen the warning before and at the time thought I had fixed it with 55e7f6abe131 ("dsa: b53: fix big-endian register access"), however it now came back in a different randconfig build that happens to have different inlining decisions in the compiler. The mistake that gcc makes here is that it thinks the second call to readl() might fail because the address 'reg + 4' is not a multiple of four despite having knowing that 'reg' itself is a multiple of four. By open-coding the two reads without the redundant alignment check, we can avoid the warning and produce slightly better object code, but get slightly longer source code instead. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller

net: dsa: b53: Fix statistics readings

2016-06-23T19:13:48Z

Due to a typo we would always be using the MIB counter width of the first element of the counter array instead of the current element, and we would always be accessing the register statistics with a 64-bits read, while some could be 32-bits. This got unnoticed in testing with MDIO and SRAB which tolerate doing this, but testing with the SPI bus revealed bogus values being returned. Fix this by using the proper iterator here. Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch") Reported-by: Jonas Gorski Signed-off-by: Florian Fainelli Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller

dsa: b53: fix big-endian register access

2016-06-17T00:15:28Z

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 Acked-by: Florian Fainelli Signed-off-by: David S. Miller

net: dsa: b53: Plug in VLAN support

2016-06-10T05:21:29Z

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 Signed-off-by: David S. Miller