summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/marvell/Kconfig
AgeCommit message (Collapse)AuthorFilesLines
2020-09-18net: marvell: prestera: Add driver for Prestera family ASIC devicesVadym Kochan1-0/+1
Marvell Prestera 98DX326x integrates up to 24 ports of 1GbE with 8 ports of 10GbE uplinks or 2 ports of 40Gbps stacking for a largely wireless SMB deployment. The current implementation supports only boards designed for the Marvell Switchdev solution and requires special firmware. The core Prestera switching logic is implemented in prestera_main.c, there is an intermediate hw layer between core logic and firmware. It is implemented in prestera_hw.c, the purpose of it is to encapsulate hw related logic, in future there is a plan to support more devices with different HW related configurations. This patch contains only basic switch initialization and RX/TX support over SDMA mechanism. Currently supported devices have DMA access range <= 32bit and require ZONE_DMA to be enabled, for such cases SDMA driver checks if the skb allocated in proper range supported by the Prestera device. Also meanwhile there is no TX interrupt support in current firmware version so recycling work is scheduled on each xmit. Port's mac address is generated from the switch base mac which may be provided via device-tree (static one or as nvme cell), or randomly generated. This is required by the firmware. Co-developed-by: Andrii Savka <andrii.savka@plvision.eu> Signed-off-by: Andrii Savka <andrii.savka@plvision.eu> Co-developed-by: Oleksandr Mazur <oleksandr.mazur@plvision.eu> Signed-off-by: Oleksandr Mazur <oleksandr.mazur@plvision.eu> Co-developed-by: Serhiy Boiko <serhiy.boiko@plvision.eu> Signed-off-by: Serhiy Boiko <serhiy.boiko@plvision.eu> Co-developed-by: Serhiy Pshyk <serhiy.pshyk@plvision.eu> Signed-off-by: Serhiy Pshyk <serhiy.pshyk@plvision.eu> Co-developed-by: Taras Chornyi <taras.chornyi@plvision.eu> Signed-off-by: Taras Chornyi <taras.chornyi@plvision.eu> Co-developed-by: Volodymyr Mytnyk <volodymyr.mytnyk@plvision.eu> Signed-off-by: Volodymyr Mytnyk <volodymyr.mytnyk@plvision.eu> Signed-off-by: Vadym Kochan <vadym.kochan@plvision.eu> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-10net: mvpp2: ptp: add TAI supportRussell King1-0/+6
Add support for the TAI block in the mvpp2.2 hardware. Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-04mvpp2: use page_pool allocatorMatteo Croce1-0/+1
Use the page_pool API for memory management. This is a prerequisite for native XDP support. Tested-by: Sven Auhagen <sven.auhagen@voleatech.de> Signed-off-by: Matteo Croce <mcroce@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-13treewide: replace '---help---' in Kconfig files with 'help'Masahiro Yamada1-12/+12
Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over '---help---'"), the number of '---help---' has been gradually decreasing, but there are still more than 2400 instances. This commit finishes the conversion. While I touched the lines, I also fixed the indentation. There are a variety of indentation styles found. a) 4 spaces + '---help---' b) 7 spaces + '---help---' c) 8 spaces + '---help---' d) 1 space + 1 tab + '---help---' e) 1 tab + '---help---' (correct indentation) f) 1 tab + 1 space + '---help---' g) 1 tab + 2 spaces + '---help---' In order to convert all of them to 1 tab + 'help', I ran the following commend: $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/' Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2019-10-21net: mvneta: introduce page pool API for sw buffer managerLorenzo Bianconi1-0/+1
Use the page_pool api for allocations and DMA handling instead of __dev_alloc_page()/dma_map_page() and free_page()/dma_unmap_page(). Pages are unmapped using page_pool_release_page before packets go into the network stack. The page_pool API offers buffer recycling capabilities for XDP but allocates one page per packet, unless the driver splits and manages the allocated page. This is a preliminary patch to add XDP support to mvneta driver Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-21treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner1-0/+1
Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-10-10octeontx2-af: Add Marvell OcteonTX2 RVU AF driverSunil Goutham1-0/+3
This patch adds basic template for Marvell OcteonTX2's resource virtualization unit (RVU) admin function (AF) driver. Just the driver registration and probe. Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-06-23net: Remove depends on HAS_DMA in case of platform dependencyGeert Uytterhoeven1-5/+3
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their dependencies on HAS_DMA, to prevent compiling subsystems or drivers that cannot work anyway. This simplifies the dependencies, and allows to improve compile-testing. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Mark Brown <broonie@kernel.org> Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-05-17net: mvpp2: phylink supportAntoine Tenart1-0/+1
Convert the PPv2 driver to implement phylink helpers, and use phylink in DT mode. The other mode supported is ACPI, which will need further work in order to be entirely compatible with phylink. The MAC and GoP configuration functions were completely moved to fit into the phylink helpers. When a PHY is always present between the MAC and the physical port, phylink only is used, but when this is not the case (the MAC directly is connected to the physical port) the link IRQ is used to detect changes in the link state and call phylink_mac_change. The ACPI mode do not uses phylink as of now, and the changes shouldn't impact its use. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-03net: mvneta: convert to phylinkRussell King1-1/+1
Convert mvneta to use phylink, which models the MAC to PHY link in a generic, reusable form. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> - remove unused sync status Signed-off-by: David S. Miller <davem@davemloft.net>
2017-03-09net: mvpp2: finally add the PPv2.2 compatible stringThomas Petazzoni1-2/+2
Now that the mvpp2 driver has been modified to accommodate the support for PPv2.2, we can finally advertise this support by adding the appropriate compatible string. At the same time, we update the Kconfig description of the MVPP2 driver. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-21net: mvpp2: enable building on 64-bit platformsThomas Petazzoni1-2/+1
The mvpp2 is going to be extended to support the Marvell Armada 7K/8K platform, which is ARM64. As a preparation to this work, this commit enables building the mvpp2 driver on ARM64, by: - Adjusting the Kconfig dependency - Fixing the types used in the driver so that they are 32/64-bits compliant. We use dma_addr_t for DMA addresses, and unsigned long for virtual addresses. It is worth mentioning that after this commit, the driver is for now still only used on 32-bits platforms, and will only work on 32-bits platforms. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-11net: mvneta: select GENERIC_ALLOCATORArnd Bergmann1-0/+1
We previously relied on GENERIC_ALLOCATOR to be selected by CONFIG_ARM, but now we can compile-test the driver on other architectures that don't select it: drivers/net/built-in.o: In function `mvneta_bm_remove': mvneta_bm.c:(.text+0x4ee35): undefined reference to `gen_pool_free' This adds an explicit select for the part of the driver that has the dependency. Fixes: a0627f776a45 ("net: marvell: Allow drivers to be built with COMPILE_TEST") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-02net: mvneta: Add network support for Armada 3700 SoCMarcin Wojtas1-3/+4
Armada 3700 is a new ARMv8 SoC from Marvell using same network controller as older Armada 370/38x/XP. There are however some differences that needed taking into account when adding support for it: * open default MBUS window to 4GB of DRAM - Armada 3700 SoC's Mbus configuration for network controller has to be done on two levels: global and per-port. The first one is inherited from the bootloader. The latter can be opened in a default way, leaving arbitration to the bus controller. Hence filled mbus_dram_target_info structure is not needed * make per-CPU operation optional - Recent patches adding RSS and XPS support for Armada 38x/XP enabled per-CPU operation of the controller by default. Contrary to older SoC's Armada 3700 SoC's network controller is not capable of per-CPU processing due to interrupt lines' connectivity. This patch restores non-per-CPU operation, which is now optional and depends on neta_armada3700 flag value in mvneta_port structure. In order not to complicate the code, separate interrupt subroutine is implemented. For now, on the Armada 3700, RSS is disabled as the current implementation depend on the per cpu interrupts. [gregory.clement@free-electrons.com: extract from a larger patch, replace some ifdef and port to net-next for v4.10] Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Tested-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-02net: mvneta: Only disable mvneta_bm for 64-bitsGregory CLEMENT1-1/+2
Actually only the mvneta_bm support is not 64-bits compatible. The mvneta code itself can run on 64-bits architecture. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Tested-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-22marvell: mark mvneta and mvpp2 32-bit onlyArnd Bergmann1-0/+2
Both of these drivers won't work on 64-bit architectures unless they are redesigned, since they store a virtual address pointer in a 32-bit field of the descriptors: drivers/net/ethernet/marvell/mvneta_bm.c: In function 'mvneta_bm_construct': drivers/net/ethernet/marvell/mvneta_bm.c:103:16: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_vlan_init': drivers/net/ethernet/marvell/mvpp2.c:2563:32: error: large integer implicitly truncated to unsigned type [-Werror=overflow] This limits the COMPILE_TEST option for the two drivers again to only build them on 32-bit. This seems nicer than shutting up the warnings, in case we ever actually want to use them on 64-bit, as the warnings indicate which parts of the driver are currently broken there. Fixes: a0627f776a45 ("net: marvell: Allow drivers to be built with COMPILE_TEST") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-18net: marvell: Allow drivers to be built with COMPILE_TESTFlorian Fainelli1-4/+7
All Marvell Ethernet drivers actually build fine with COMPILE_TEST with a few warnings. We need to add a few HAS_DMA dependencies to fix linking failures on problematic architectures like m32r. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
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-19net: 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-04drivers/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-10-01net: 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-10-01net: 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-11ethernet: 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-19net: 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-16net,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-23Merge 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-14net: 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>