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: 019ded3aa7 ("net: mvneta: bm: clarify dependencies")
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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: dc35a10f68 ("net: mvneta: bm: add support for hardware buffer management")
Signed-off-by: David S. Miller <davem@davemloft.net>
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>
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>
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: 898b2970e2 ("mvneta: implement SGMII-based in-band link state signaling")
Signed-off-by: David S. Miller <davem@davemloft.net>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
