summaryrefslogtreecommitdiff
path: root/drivers/net/dsa/b53/b53_mmap.c
AgeCommit message (Collapse)Author
2018-04-04net: dsa: b53: Fix sparse warnings in b53_mmap.cFlorian Fainelli
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] <asn:2>*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 <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-10-17net: dsa: b53: Fix module autoloadJavier Martinez Canillas
If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo drivers/net/dsa/b53/b53_mmap.ko | grep alias $ After this patch: $ modinfo drivers/net/dsa/b53/b53_mmap.ko | grep alias alias: of:N*T*Cbrcm,bcm63xx-switchC* alias: of:N*T*Cbrcm,bcm63xx-switch alias: of:N*T*Cbrcm,bcm6368-switchC* alias: of:N*T*Cbrcm,bcm6368-switch alias: of:N*T*Cbrcm,bcm6328-switchC* alias: of:N*T*Cbrcm,bcm6328-switch alias: of:N*T*Cbrcm,bcm3384-switchC* alias: of:N*T*Cbrcm,bcm3384-switch Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-10-11treewide: remove redundant #include <linux/kconfig.h>Masahiro Yamada
Kernel source files need not include <linux/kconfig.h> explicitly because the top Makefile forces to include it with: -include $(srctree)/include/linux/kconfig.h This commit removes explicit includes except the following: * arch/s390/include/asm/facilities_src.h * tools/testing/radix-tree/linux/kernel.h These two are used for host programs. Link: http://lkml.kernel.org/r/1473656164-11929-1-git-send-email-yamada.masahiro@socionext.com Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-08-09net: dsa: b53: constify b53_io_ops structuresJulia Lawall
The b53_io_ops structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-01dsa: b53: remove redundant ifxypron.glpk@gmx.de
For pdata == null the code leaves with an error. There is no need to check the condition again. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-29dsa: b53: avoid 'maybe-uninitialized' warningArnd Bergmann
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 <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-16dsa: b53: fix big-endian register accessArnd Bergmann
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-09net: dsa: b53: Add support for Broadcom RoboSwitchFlorian Fainelli
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>