aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/ethernet/marvell/Kconfig (follow)
AgeCommit message (Collapse)AuthorFilesLines
2016-05-12net: mvneta: bm: fix dependencies againArnd Bergmann1-1/+1
I tried to fix this before, but my previous fix was incomplete and we can still get the same link error in randconfig builds because of the way that Kconfig treats the default y if MVNETA=y && MVNETA_BM_ENABLE line that does not actually trigger when MVNETA_BM_ENABLE=m, unlike I intended. Changing the line to use MVNETA_BM_ENABLE!=n however has the desired effect and hopefully makes all configurations work as expected. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 019ded3aa7c9 ("net: mvneta: bm: clarify dependencies") Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-18net: mvneta: bm: clarify dependenciesArnd Bergmann1-2/+10
MVNETA_BM has a dependency on MVNETA, so we can only select the former if the latter is enabled. However, the code dependency is the reverse: The mvneta module can call into the mvneta_bm module, so mvneta cannot be a built-in if mvneta_bm is a module, or we get a link error: drivers/net/built-in.o: In function `mvneta_remove': drivers/net/ethernet/marvell/mvneta.c:4211: undefined reference to `mvneta_bm_pool_destroy' drivers/net/built-in.o: In function `mvneta_bm_update_mtu': drivers/net/ethernet/marvell/mvneta.c:1034: undefined reference to `mvneta_bm_bufs_free' This avoids the problem by further clarifying the dependency so that MVNETA_BM is a silent Kconfig option that gets turned on by the new MVNETA_BM_ENABLE option. This way both the core HWBM module and the MVNETA_BM code are always built-in when needed. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: dc35a10f68d3 ("net: mvneta: bm: add support for hardware buffer management") Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-14net: mvneta: Use the new hwbm frameworkGregory CLEMENT1-0/+1
Now that the hardware buffer management framework had been introduced, let's use it. Tested-by: Sebastian Careba <nitroshift@yahoo.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-14net: mvneta: bm: add support for hardware buffer managementMarcin Wojtas1-0/+13
Buffer manager (BM) is a dedicated hardware unit that can be used by all ethernet ports of Armada XP and 38x SoC's. It allows to offload CPU on RX path by sparing DRAM access on refilling buffer pool, hardware-based filling of descriptor ring data and better memory utilization due to HW arbitration for using 'short' pools for small packets. Tests performed with A388 SoC working as a network bridge between two packet generators showed increase of maximum processed 64B packets by ~20k (~555k packets with BM enabled vs ~535 packets without BM). Also when pushing 1500B-packets with a line rate achieved, CPU load decreased from around 25% without BM to 20% with BM. BM comprise up to 4 buffer pointers' (BP) rings kept in DRAM, which are called external BP pools - BPPE. Allocating and releasing buffer pointers (BP) to/from BPPE is performed indirectly by write/read access to a dedicated internal SRAM, where internal BP pools (BPPI) are placed. BM hardware controls status of BPPE automatically, as well as assigning proper buffers to RX descriptors. For more details please refer to Functional Specification of Armada XP or 38x SoC. In order to enable support for a separate hardware block, common for all ports, a new driver has to be implemented ('mvneta_bm'). It provides initialization sequence of address space, clocks, registers, SRAM, empty pools' structures and also obtaining optional configuration from DT (please refer to device tree binding documentation). mvneta_bm exposes also a necessary API to mvneta driver, as well as a dedicated structure with BM information (bm_priv), whose presence is used as a flag notifying of BM usage by port. It has to be ensured that mvneta_bm probe is executed prior to the ones in ports' driver. In case BM is not used or its probe fails, mvneta falls back to use software buffer management. A sequence executed in mvneta_probe function is modified in order to have an access to needed resources before possible port's BM initialization is done. According to port-pools mapping provided by DT appropriate registers are configured and the buffer pools are filled. RX path is modified accordingly. Becaues the hardware allows a wide variety of configuration options, following assumptions are made: * using BM mechanisms can be selectively disabled/enabled basing on DT configuration among the ports * 'long' pool's single buffer size is tied to port's MTU * using 'long' pool by port is obligatory and it cannot be shared * using 'short' pool for smaller packets is optional * one 'short' pool can be shared among all ports This commit enables hardware buffer management operation cooperating with existing mvneta driver. New device tree binding documentation is added and the one of mvneta is updated accordingly. [gregory.clement@free-electrons.com: removed the suspend/resume part] Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-09mvneta: add FIXED_PHY dependencyArnd Bergmann1-0/+1
The fixed_phy infrastructure is done in a way that is optional, by providing 'static inline' helper functions doing nothing in include/linux/phy_fixed.h for all its APIs. However, three out of the four users (DSA, BCMGENET, and SYSTEMPORT) always 'select FIXED_PHY', presumably because they need that. MVNETA is the fourth one, and if that is built-in but FIXED_PHY is configured as a loadable module, we get a link error: drivers/built-in.o: In function `mvneta_fixed_link_update': fpga-mgr.c:(.text+0x33ed80): undefined reference to `fixed_phy_update_state' Presumably this driver has the same dependency as the others, so this patch also uses 'select' to ensure that the fixed-phy support is built-in. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 898b2970e2c9 ("mvneta: implement SGMII-based in-band link state signaling") Signed-off-by: David S. Miller <davem@davemloft.net>
2015-06-23drivers/net: remove all references to obsolete Ethernet-HOWTOPaul Gortmaker1-3/+1
This howto made sense in the 1990s when users had to manually configure ISA cards with jumpers or vendor utilities, but with the implementation of PCI it became increasingly less and less relevant, to the point where it has been well over a decade since I last updated it. And there is no value in anyone else taking over updating it either. However the references to it continue to spread as boiler plate text from one Kconfig file into the next. We are not doing end users any favours by pointing them at this old document, so lets kill it with fire, once and for all, to hopefully stop any further spread. No code is changed in this commit, just Kconfig help text. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-10net: pxa168_eth: PXA168_ETH should depend on HAS_DMAGeert Uytterhoeven1-1/+2
If NO_DMA=y: drivers/built-in.o: In function `rxq_deinit': pxa168_eth.c:(.text+0x2a2f2e): undefined reference to `dma_free_coherent' drivers/built-in.o: In function `txq_reclaim': pxa168_eth.c:(.text+0x2a3044): undefined reference to `dma_unmap_single' drivers/built-in.o: In function `txq_deinit': pxa168_eth.c:(.text+0x2a310a): undefined reference to `dma_free_coherent' drivers/built-in.o: In function `txq_init': pxa168_eth.c:(.text+0x2a3226): undefined reference to `dma_alloc_coherent' drivers/built-in.o: In function `rxq_init': pxa168_eth.c:(.text+0x2a32d4): undefined reference to `dma_alloc_coherent' drivers/built-in.o: In function `init_hash_table': pxa168_eth.c:(.text+0x2a3354): undefined reference to `dma_alloc_coherent' drivers/built-in.o: In function `rxq_refill': pxa168_eth.c:(.text+0x2a345a): undefined reference to `dma_map_single' drivers/built-in.o: In function `rxq_process': pxa168_eth.c:(.text+0x2a39cc): undefined reference to `dma_unmap_single' drivers/built-in.o: In function `pxa168_eth_remove': pxa168_eth.c:(.text+0x2a3b84): undefined reference to `dma_free_coherent' drivers/built-in.o: In function `pxa168_eth_start_xmit': pxa168_eth.c:(.text+0x2a3e8a): undefined reference to `dma_map_single' Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-03drivers/net/ethernet/marvell/Kconfig: Let PXA168_ETH depend on HAS_IOMEMChen Gang1-1/+1
PXA168_ETH need HAS_IOMEM, so depend on it, the related error (with allmodconfig under um): CC [M] drivers/net/ethernet/marvell/pxa168_eth.o drivers/net/ethernet/marvell/pxa168_eth.c: In function ‘pxa168_eth_probe’: drivers/net/ethernet/marvell/pxa168_eth.c:1605:2: error: implicit declaration of function ‘iounmap’ [-Werror=implicit-function-declaration] iounmap(pep->base); ^ Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-30net: pxa168_eth: allow to compile the pxa168_eth driver for testsAntoine Ténart1-1/+1
Add a dependency to COMPILE_TEST so that the driver can be compiled for test purposes. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-30net: pxa168_eth: allow Berlin SoCs to use the pxa168_eth driverAntoine Ténart1-1/+1
Berlin SoCs have an Ethernet controller compatible with the pxa168. Allow these SoCs to use the pxa168_eth driver. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-10ethernet: Add new driver for Marvell Armada 375 network unitMarcin Wojtas1-0/+8
This commit adds a new network driver for the network controller in Marvell Armada 375 SoC. Given the controller is very different from the ones in the other Marvell SoCs that use the mv643xx_eth (Kirkwood, Orion, Discovery) and mvneta (Armada 370/38x/XP) drivers, a new driver is needed. Signed-off-by: Marcin Wojtas <mw@semihalf.com> [Ezequiel: coding style cleanup] Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-18net: ethernet: update dependency and help text of mvnetaThomas Petazzoni1-3/+3
With the introduction of the support for Armada 375 and Armada 38x, the hidden Kconfig option MACH_ARMADA_370_XP is being renamed to MACH_MVEBU_V7. Therefore, the dependency that was used for the mvneta driver can no longer work. This commit replaces this dependency by a dependency on PLAT_ORION, which is used similarly for the mv643xx_eth driver. In addition to this, it takes this opportunity to adjust the description and help text to indicate that the driver can is also used for Armada 38x. Note that Armada 375 cannot use this driver as it has a completely different networking unit, which will require a separate driver. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-01-15net,marvell: Add dependency on HAS_IOMEMRichard Weinberger1-0/+1
On archs like S390 or um this driver cannot build nor work. Make it depend on HAS_IOMEM to bypass build failures. drivers/built-in.o: In function `orion_mdio_probe': drivers/net/ethernet/marvell/mvmdio.c:228: undefined reference to `devm_ioremap' Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-22Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller1-1/+1
Conflicts: drivers/net/ethernet/emulex/benet/be_main.c drivers/net/ethernet/intel/igb/igb_main.c drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c include/net/scm.h net/batman-adv/routing.c net/ipv4/tcp_input.c The e{uid,gid} --> {uid,gid} credentials fix conflicted with the cleanup in net-next to now pass cred structs around. The be2net driver had a bug fix in 'net' that overlapped with the VLAN interface changes by Patrick McHardy in net-next. An IGB conflict existed because in 'net' the build_skb() support was reverted, and in 'net-next' there was a comment style fix within that code. Several batman-adv conflicts were resolved by making sure that all calls to batadv_is_my_mac() are changed to have a new bat_priv first argument. Eric Dumazet's TS ECR fix in TCP in 'net' conflicted with the F-RTO rewrite in 'net-next', mostly overlapping changes. Thanks to Stephen Rothwell and Antonio Quartulli for help with several of these merge resolutions. Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-13net: mvmdio: add select PHYLIBThomas Petazzoni1-1/+1
The mvmdio driver uses the phylib API, so it should select the PHYLIB symbol, otherwise, a build with mvmdio (but without mvneta) fails to build with undefined symbols such as mdiobus_unregister, mdiobus_free, etc. The mvneta driver does not use the phylib API directly, so it does not need to select PHYLIB. It already selects the mvmdio driver anyway. Historically, this problem is due to the fact that the PHY handling was originally part of mvneta, and was later moved to a separate driver, without updating the Kconfig select statements accordingly. And since there was no functional reason to use mvmdio without mvneta, this case was not tested. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-12net: mv643xx_eth: remove deprecated inet_lro supportSebastian Hesselbarth1-1/+0
With recent support for GRO, there is no need to keep both LRO and GRO. This patch therefore removes the deprecated inet_lro support from mv643xx_eth. This is work is based on an experimental patch provided by Eric Dumazet and Willy Tarreau. Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Based-on-patch-by: Eric Dumazet <eric.dumazet@gmail.com> Based-on-patch-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-03-22mv643xx_eth: convert to use the Marvell Orion MDIO driverFlorian Fainelli1-3/+2
This patch converts the Marvell MV643XX ethernet driver to use the Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms registering the Marvell MV643XX ethernet driver are also updated to register a Marvell Orion MDIO driver. This driver voluntarily overlaps with the Marvell Ethernet shared registers because it will use a subset of this shared register (shared_base + 0x4 to shared_base + 0x84). The Ethernet driver is also updated to look up for a PHY device using the Orion MDIO bus driver. For ARM and PowerPC we register a single instance of the "mvmdio" driver in the system like it used to be done with the use of the "shared_smi" platform_data cookie on ARM. Note that it is safe to register the mvmdio driver only for the "ge00" instance of the driver because this "ge00" interface is guaranteed to always be explicitely registered by consumers of arch/arm/plat-orion/common.c and other instances (ge01, ge10 and ge11) were all pointing their shared_smi to ge00. For PowerPC the in-tree Device Tree Source files mention only one MV643XX ethernet MAC instance so the MDIO bus driver is registered only when id == 0. Signed-off-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-11-16net: mvneta: driver for Marvell Armada 370/XP network unitThomas Petazzoni1-0/+13
This patch contains a new network driver for the network unit of the ARM Marvell Armada 370 and the Armada XP. Both SoCs use the PJ4B processor, a Marvell-developed ARM core that implements the ARMv7 instruction set. Compared to previous ARM Marvell SoCs (Kirkwood, Orion, Discovery), the network unit in Armada 370 and Armada XP is highly different. This is the reason why this new 'mvneta' driver is needed, while the older ARM Marvell SoCs use the 'mv643xx_eth' driver. Here is an overview of the most important hardware changes that require a new, specific, driver for the network unit of Armada 370/XP: - The new network unit has a completely different design and layout for the RX and TX descriptors. They are now organized as a simple array (each RX and TX queue has base address and size of this array) rather than a linked list as in the old SoCs. - The new network unit has a different RXQ and TXQ management: this management is done using special read/write counter registers, while in the Old SocS, it was done using the Ownership bit in RX and TX descriptors. - The new network unit has different interrupt registers - The new network unit way of cleaning of interrupts is not done by writing to the cause register, but by updating per-queue counters - The new network unit has different GMAC registers (link, speed, duplex configuration) and different WRR registers. - The new network unit has lots of new units like PnC (Parser and Classifier), PMT, BM (Memory Buffer Management), xPON, and more. The driver proposed in the current patch only handles the basic features. Additional hardware features will progressively be supported as needed. This code has originally been written by Rami Rosen <rosenr@marvell.com>, and then reviewed and cleaned up by Thomas Petazzoni <thomas.petazzoni@free-electrons.com>. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: David S. Miller <davem@davemloft.net>
2012-11-16net: mvmdio: new Marvell MDIO driverThomas Petazzoni1-0/+11
This patch adds a separate driver for the MDIO interface of the Marvell Ethernet controllers. There are two reasons to have a separate driver rather than including it inside the MAC driver itself: *) The MDIO interface is shared by all Ethernet ports, so a driver must guarantee non-concurrent accesses to this MDIO interface. The most logical way is to have a separate driver that handles this single MDIO interface, used by all Ethernet ports. *) The MDIO interface is the same between the existing mv643xx_eth driver and the new mvneta driver. Even though it is for now only used by the mvneta driver, it will in the future be used by the mv643xx_eth driver as well. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: David S. Miller <davem@davemloft.net>
2011-08-27drivers/net/ethernet/*: Enabled vendor Kconfig optionsJeff Kirsher1-0/+1
Based on finds for Stephen Rothwell, where current defconfig's enable a ethernet driver and it is not compiled due to the newly added NET_VENDOR_* component of Kconfig. This patch enables all the "new" Kconfig options so that current defconfig's will continue to compile the expected drivers. In addition, by enabling all the new Kconfig options does not add any un-expected options. CC: Stephen Rothwll <sfc@canb.auug.org.au> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2011-08-12skge/sky2/mv643xx/pxa168: Move the Marvell Ethernet driversJeff Kirsher1-0/+110
Move the Marvell Ethernet drivers into drivers/net/ethernet/marvell/ and make the necessary Kconfig and Makefile changes. CC: Sachin Sanap <ssanap@marvell.com> CC: Zhangfei Gao <zgao6@marvell.com> CC: Philip Rakity <prakity@marvell.com> CC: Mark Brown <markb@marvell.com> CC: Lennert Buytenhek <buytenh@marvell.com> CC: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>