aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2019-11-23net: phylink: rename mac_link_state() op to mac_pcs_get_state()Russell King1-11/+10
Rename the mac_link_state() method to mac_pcs_get_state() to make it clear that it should be returning the MACs PCS current state, which is used for inband negotiation rather than just reading back what the MAC has been configured for. Update the documentation to explicitly mention that this is for inband. We drop the return value as well; most of phylink doesn't check the return value and it is not clear what it should do on error - instead arrange for state->link to be false. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
2019-10-28mvpp2: prefetch frame headerMatteo Croce1-0/+1
When receiving traffic, eth_type_trans() is high up on the perf top list, because it's the first function which access the packet data. Move the DMA unmap a bit higher, and put a prefetch just after it, so we have more time to load the data into the cache. The packet rate increase is about 14% with a tc drop test: 1620 => 1853 kpps Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-28mvpp2: sync only the received frameMatteo Croce1-2/+7
In the RX path we always sync against the maximum frame size for that pool. Do the DMA sync and the unmap separately, so we can only sync by the size of the received frame. Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-28mvpp2: refactor frame drop routineMatteo Croce1-8/+9
Move some code down to remove a backward goto. Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-02mvpp2: remove misleading commentMatteo Croce1-2/+1
Recycling in mvpp2 has gone long time ago, but two comment still refers to it. Remove those two misleading comments as they generate confusion. Fixes: 7ef7e1d949cd ("net: mvpp2: drop useless fields in mvpp2_bm_pool and related code") Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-02mvpp2: percpu buffersMatteo Croce1-23/+218
Every mvpp2 unit can use up to 8 buffers mapped by the BM (the HW buffer manager). The HW will place the frames in the buffer pool depending on the frame size: short (< 128 bytes), long (< 1664) or jumbo (up to 9856). As any unit can have up to 4 ports, the driver allocates only 2 pools, one for small and one long frames, and share them between ports. When the first port MTU is set higher than 1664 bytes, a third pool is allocated for jumbo frames. This shared allocation makes impossible to use percpu allocators, and creates contention between HW queues. If possible, i.e. if the number of possible CPU are less than 8 and jumbo frames are not used, switch to a new scheme: allocate 8 per-cpu pools for short and long frames and bind every pool to an RXQ. When the first port MTU is set higher than 1664 bytes, the allocation scheme is reverted to the old behaviour (3 shared pools), and when all ports MTU are lowered, the per-cpu buffers are allocated again. Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-02mvpp2: refactor BM pool functionsMatteo Croce1-19/+16
Refactor mvpp2_bm_pool_create(), mvpp2_bm_pool_destroy() and mvpp2_bm_pools_init() so that they accept a struct device instead of a struct platform_device, as they just need platform_device->dev. Removing such dependency makes the BM code more reusable in context where we don't have a pointer to the platform_device. Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-14net/mvpp2: Replace tasklet with softirq hrtimerThomas Gleixner1-36/+22
The tx_done_tasklet tasklet is used in invoke the hrtimer (mvpp2_hr_timer_cb) in softirq context. This can be also achieved without the tasklet but with HRTIMER_MODE_SOFT as hrtimer mode. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-06Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller1-47/+40
Just minor overlapping changes in the conflicts here. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-01mvpp2: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-7/+3
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-01mvpp2: fix panic on module removalMatteo Croce1-3/+2
mvpp2 uses a delayed workqueue to gather traffic statistics. On module removal the workqueue can be destroyed before calling cancel_delayed_work_sync() on its works. Fix it by moving the destroy_workqueue() call after mvpp2_port_remove(). Also remove an unneeded call to flush_workqueue() # rmmod mvpp2 [ 2743.311722] mvpp2 f4000000.ethernet eth1: phy link down 10gbase-kr/10Gbps/Full [ 2743.320063] mvpp2 f4000000.ethernet eth1: Link is Down [ 2743.572263] mvpp2 f4000000.ethernet eth2: phy link down sgmii/1Gbps/Full [ 2743.580076] mvpp2 f4000000.ethernet eth2: Link is Down [ 2744.102169] mvpp2 f2000000.ethernet eth0: phy link down 10gbase-kr/10Gbps/Full [ 2744.110441] mvpp2 f2000000.ethernet eth0: Link is Down [ 2744.115614] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 2744.115615] Mem abort info: [ 2744.115616] ESR = 0x96000005 [ 2744.115617] Exception class = DABT (current EL), IL = 32 bits [ 2744.115618] SET = 0, FnV = 0 [ 2744.115619] EA = 0, S1PTW = 0 [ 2744.115620] Data abort info: [ 2744.115621] ISV = 0, ISS = 0x00000005 [ 2744.115622] CM = 0, WnR = 0 [ 2744.115624] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000422681000 [ 2744.115626] [0000000000000000] pgd=0000000000000000, pud=0000000000000000 [ 2744.115630] Internal error: Oops: 96000005 [#1] SMP [ 2744.115632] Modules linked in: mvpp2(-) algif_hash af_alg nls_iso8859_1 nls_cp437 vfat fat xhci_plat_hcd m25p80 spi_nor xhci_hcd mtd usbcore i2c_mv64xxx sfp usb_common marvell10g phy_generic spi_orion mdio_i2c i2c_core mvmdio phylink sbsa_gwdt ip_tables x_tables autofs4 [last unloaded: mvpp2] [ 2744.115654] CPU: 3 PID: 8357 Comm: kworker/3:2 Not tainted 5.3.0-rc2 #1 [ 2744.115655] Hardware name: Marvell 8040 MACCHIATOBin Double-shot (DT) [ 2744.115665] Workqueue: events_power_efficient phylink_resolve [phylink] [ 2744.115669] pstate: a0000085 (NzCv daIf -PAN -UAO) [ 2744.115675] pc : __queue_work+0x9c/0x4d8 [ 2744.115677] lr : __queue_work+0x170/0x4d8 [ 2744.115678] sp : ffffff801001bd50 [ 2744.115680] x29: ffffff801001bd50 x28: ffffffc422597600 [ 2744.115684] x27: ffffff80109ae6f0 x26: ffffff80108e4018 [ 2744.115688] x25: 0000000000000003 x24: 0000000000000004 [ 2744.115691] x23: ffffff80109ae6e0 x22: 0000000000000017 [ 2744.115694] x21: ffffffc42c030000 x20: ffffffc42209e8f8 [ 2744.115697] x19: 0000000000000000 x18: 0000000000000000 [ 2744.115699] x17: 0000000000000000 x16: 0000000000000000 [ 2744.115701] x15: 0000000000000010 x14: ffffffffffffffff [ 2744.115702] x13: ffffff8090e2b95f x12: ffffff8010e2b967 [ 2744.115704] x11: ffffff8010906000 x10: 0000000000000040 [ 2744.115706] x9 : ffffff80109223b8 x8 : ffffff80109223b0 [ 2744.115707] x7 : ffffffc42bc00068 x6 : 0000000000000000 [ 2744.115709] x5 : ffffffc42bc00000 x4 : 0000000000000000 [ 2744.115710] x3 : 0000000000000000 x2 : 0000000000000000 [ 2744.115712] x1 : 0000000000000008 x0 : ffffffc42c030000 [ 2744.115714] Call trace: [ 2744.115716] __queue_work+0x9c/0x4d8 [ 2744.115718] delayed_work_timer_fn+0x28/0x38 [ 2744.115722] call_timer_fn+0x3c/0x180 [ 2744.115723] expire_timers+0x60/0x168 [ 2744.115724] run_timer_softirq+0xbc/0x1e8 [ 2744.115727] __do_softirq+0x128/0x320 [ 2744.115731] irq_exit+0xa4/0xc0 [ 2744.115734] __handle_domain_irq+0x70/0xc0 [ 2744.115735] gic_handle_irq+0x58/0xa8 [ 2744.115737] el1_irq+0xb8/0x140 [ 2744.115738] console_unlock+0x3a0/0x568 [ 2744.115740] vprintk_emit+0x200/0x2a0 [ 2744.115744] dev_vprintk_emit+0x1c8/0x1e4 [ 2744.115747] dev_printk_emit+0x6c/0x7c [ 2744.115751] __netdev_printk+0x104/0x1d8 [ 2744.115752] netdev_printk+0x60/0x70 [ 2744.115756] phylink_resolve+0x38c/0x3c8 [phylink] [ 2744.115758] process_one_work+0x1f8/0x448 [ 2744.115760] worker_thread+0x54/0x500 [ 2744.115762] kthread+0x12c/0x130 [ 2744.115764] ret_from_fork+0x10/0x1c [ 2744.115768] Code: aa1403e0 97fffbbe aa0003f5 b4000700 (f9400261) Fixes: 118d6298f6f0 ("net: mvpp2: add ethtool GOP statistics") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Matteo Croce <mcroce@redhat.com> Acked-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-07-29mvpp2: refactor the HW checksum setupMatteo Croce1-13/+22
The hardware can only offload checksum calculation on first port due to the Tx FIFO size limitation, and has a maximum L3 offset of 128 bytes. Document this in a comment and move duplicated code in a function. Fixes: 576193f2d579 ("net: mvpp2: jumbo frames support") Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-07-29mvpp2: refactor MTU change codeMatteo Croce1-28/+13
The MTU change code can call napi_disable() with the device already down, leading to a deadlock. Also, lot of code is duplicated unnecessarily. Rework mvpp2_change_mtu() to avoid the deadlock and remove duplicated code. Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit") Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-07-22net: Use skb accessors in network driversMatthew Wilcox (Oracle)1-3/+4
In preparation for unifying the skb_frag and bio_vec, use the fine accessors which already exist and use skb_frag_t instead of struct skb_frag_struct. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-07-22net: mvpp2: Don't check for 3 consecutive Idle frames for 10G linksMaxime Chevallier1-3/+3
PPv2's XLGMAC can wait for 3 idle frames before triggering a link up event. This can cause the link to be stuck low when there's traffic on the interface, so disable this feature. Fixes: 4bb043262878 ("net: mvpp2: phylink support") Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-10net: mvpp2: Add support for more ethtool countersMaxime Chevallier1-18/+114
Besides the MIB counters, some other useful counters can be exposed to the user. This commit adds support for : - Per-port counters, that indicate FIFO drops and classifier drops, - Per-rxq counters, - Per-txq counters Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-10net: mvpp2: Rename mvpp2_ethtool_counters to mvpp2_ethtool_mib_countersMaxime Chevallier1-10/+11
Since we'll be adding support for other kind of internal counters, make clear that the currently supported counters are the MIB counters. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-10net: mvpp2: Only clear the stat counters at port initMaxime Chevallier1-6/+5
When first configuring a port on PPv2, we want to clear the internal counters so that we don't get values from previous boot stages. However, we can't really clear these counters when resetting the MAC, since there are valid reasons to do so while the port is being used, such as when reconfiguring the interface mode with the PHY. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-07Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller1-2/+2
Some ISDN files that got removed in net-next had some changes done in mainline, take the removals. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-06net: mvpp2: Use strscpy to handle stat stringsMaxime Chevallier1-2/+2
Use a safe strscpy call to copy the ethtool stat strings into the relevant buffers, instead of a memcpy that will be accessing out-of-bound data. Fixes: 118d6298f6f0 ("net: mvpp2: add ethtool GOP statistics") Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-31Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller1-6/+4
The phylink conflict was between a bug fix by Russell King to make sure we have a consistent PHY interface mode, and a change in net-next to pull some code in phylink_resolve() into the helper functions phylink_mac_link_{up,down}() On the dp83867 side it's mostly overlapping changes, with the 'net' side removing a condition that was supposed to trigger for RGMII but because of how it was coded never actually could trigger. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-30net: mvpp2: fix bad MVPP2_TXQ_SCHED_TOKEN_CNTR_REG queue valueAntoine Tenart1-6/+4
MVPP2_TXQ_SCHED_TOKEN_CNTR_REG() expects the logical queue id but the current code is passing the global tx queue offset, so it ends up writing to unknown registers (between 0x8280 and 0x82fc, which seemed to be unused by the hardware). This fixes the issue by using the logical queue id instead. Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit") Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-29net: phylink: Add struct phylink_config to PHYLINK APIIoana Ciornei1-17/+26
The phylink_config structure will encapsulate a pointer to a struct device and the operation type requested for this instance of PHYLINK. This patch does not make any functional changes, it just transitions the PHYLINK internals and all its users to the new API. A pointer to a phylink_config structure will be passed to phylink_create() instead of the net_device directly. Also, the same phylink_config pointer will be passed back to all phylink_mac_ops callbacks instead of the net_device. Using this mechanism, a PHYLINK user can get the original net_device using a structure such as 'to_net_dev(config->dev)' or directly the structure containing the phylink_config using a container_of call. At the moment, only the PHYLINK_NETDEV is defined as a valid operation type for PHYLINK. In this mode, a valid reference to a struct device linked to the original net_device should be passed to PHYLINK through the phylink_config structure. This API changes is mainly driven by the necessity of adding a new operation type in PHYLINK that disconnects the phy_device from the net_device and also works when the net_device is lacking. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-25net: mvpp2: cls: Use RSS contexts to handle RSS tablesMaxime Chevallier1-10/+55
The PPv2 controller has 8 RSS tables that are shared across all ports on a given PPv2 instance. The previous implementation allocated one table per port, leaving others unused. By using RSS contexts, we can make use of multiple RSS tables per port, one being the default table (always id 0), the other ones being used as destinations for flow steering, in the same way as rx rings. This commit introduces RSS contexts management in the PPv2 driver. We always reserve one table per port, allocated when the port is probed. The global table list is stored in the struct mvpp2, as it's a global resource. Each port then maintains a list of indices in that global table, that way each port can have it's own numbering scheme starting from 0. One limitation that seems unavoidable is that the hashing parameters are shared across all RSS contexts for a given port. Hashing parameters for ctx 0 will be applied to all contexts. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-25net: mvpp2: cls: Use the correct number of rules in various placesMaxime Chevallier1-1/+1
As of today, the classification offload implementation only supports 4 different rules to be offloaded. This number has been hardcoded in the rule insertion function, and the wrong define is being used elsewhere. Use the correct #define everywhere to make sure we always check for the correct number of rules. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-13net: mvpp2: cls: Add missing NETIF_F_NTUPLE flagMaxime Chevallier1-1/+3
Now that the mvpp2 driver supports classification offloading, we must add the NETIF_F_NTUPLE to the features list. Since the current code doesn't allow disabling the feature, we don't set the flag in dev->hw_features. Fixes: 90b509b39ac9 ("net: mvpp2: cls: Add Classification offload support") Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-01net: mvpp2: cls: Add Classification offload supportMaxime Chevallier1-1/+19
This commit introduces basic classification offloading support for the PPv2 controller. The PPv2 classifier has many classification engines, for now we only use the C2 TCAM match engine. This engine allows to perform ternary lookups on 64 bits keys (called Header Extracted Key), that are built by extracting fields from the packet header and concatenating them. At most 4 fields can be extracted for a single lookup. This basic implementation allows to build the HEK from the following fields : - L4 source and destination ports (for UDP and TCP) More fields are to be added in the future. Classification flows are added through the ethtool interface, using the newly introduced flow_rule infrastructure as an internal rule representation, allowing to more easily implement tc flower rules if need be. The internal design for now allocates one range of 4 rules per port due to the internal design of the flow table, which uses 22 sub-flows. When inserting a classification rule, the rule is created in every relevant sub-flow. This low rule-count is a very simple design which reaches quickly the limitations of the flow table ordering, but guarantees that the rule ordering will always be respected. This commit only introduces support for the "steer to rxq" action. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-27net: mvpp2: cls: Rename classifer per-port functionsMaxime Chevallier1-3/+3
This commit renames some of the classifier functions to follow the naming 'mvpp2_port_*' that's used for function that act on a given port. This commit is purely cosmetic. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-27net: mvpp2: Don't use an int to store netdev_features_tMaxime Chevallier1-1/+1
int is not long enough to store all netdev_features, use the correct dedicated type to store them when building the list of dev->features. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-01net: mvpp2: set the GMAC, XLG MAC, XPCS and MPCS in reset when a port is downAntoine Tenart1-0/+3
This patch adds calls in the stop() helper to ensure both MACs and both PCS blocks are set in reset when the user manually sets a port down. This is done so that we have the exact same block reset states at boot time and when a port is set down. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-01net: mvpp2: set the XPCS and MPCS in reset when not usedAntoine Tenart1-8/+58
This patch sets both the XPCS and MPCS blocks in reset when they aren't used. This is done both at boot time and when reconfiguring a port mode. The advantage now is that only the PCS used is set out of reset when the port is configured (10GKR uses the MCPS while RXAUI uses the XPCS). Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-01net: mvpp2: reset the MACs when reconfiguring a portAntoine Tenart1-0/+3
This patch makes sure both PPv2 MACs (GMAC + XLG MAC) are set in reset while a port is reconfigured. This is done so that we make sure a MAC is in a reset state when not used, as only one of the two will be set out of reset after the port is configured properly. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-01net: mvpp2: rework the XLG MAC reset handlingAntoine Tenart1-9/+18
This patch reworks the way the XLG MAC is set in reset: the XLG MAC is set in reset at probe time and taken out of this state only when used. The idea is to move forward a situation where only the blocks used are taken out of reset. This also has the effect to handle the GMAC and the XLG MAC in a similar way (the GMAC already is set in reset at boot time). Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-01net: mvpp2: force the XLG MAC link up or down when not using in-bandAntoine Tenart1-10/+25
This patch force the XLG MAC link state in the phylink link_up() and link_down() helpers when not using in-band auto-negotiation. This mimics what's already done for the GMAC and follows what's advised in the phylink documentation. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-01net: mvpp2: only update the XLG configuration when neededAntoine Tenart1-5/+8
This patch improves the XLG configuration function, to only update the XLG configuration register when a change is needed. This helps not writing over and over the same XLG configuration each time phylink request the MAC to be configured. This mimics the GMAC configuration function. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-01net: mvpp2: always disable both MACs when disabling a portAntoine Tenart1-4/+4
This patch modifies the port_disable() helper to always disable both the GMAC and the XLG MAC when called. At boot time we do not know of a port was enabled in the firmware/bootloader, and if so what mode was used (hence which of the two MACs was used). This also help in implementing a logic where all blocks are disabled when not used, and only enabled regarding the current mode used on a given port. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-01net: mvpp2: some AN fields require the link to be down when updatedAntoine Tenart1-1/+11
The GMAC configuration helper modifies values in the auto-negotiation register. Some of its values require the port to be forced down when modifying their values. This patches fixes the check made on the bit to be updated in this register, so that the port is forced down when needed. This fix cases where some of those parameters were updated, but not taken into account, such as when using RGMII interfaces. Fixes: d14e078f23cc ("net: marvell: mvpp2: only reprogram what is necessary on mac_config") Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-01net: mvpp2: fix the computation of the RXQsAntoine Tenart1-8/+15
The patch fixes the computation of RXQs being used by the PPv2 driver, which is set depending on the PPv2 engine version and the queue mode used. There are three cases: - PPv2.1: 1 RXQ per CPU. - PPV2.2 with MVPP2_QDIST_MULTI_MODE: 1 RXQ per CPU. - PPv2.2 with MVPP2_QDIST_SINGLE_MODE: 1 RXQ is shared between the CPUs. The PPv2 engine supports a maximum of 32 queues per port. This patch adds a check so that we do not overstep this maximum. It appeared the calculation was broken for PPv2.1 engines since f8c6ba8424b0, as PPv2.1 ports ended up with a single RXQ while they needed 4. This patch fixes it. Fixes: f8c6ba8424b0 ("net: mvpp2: use only one rx queue per port per CPU") Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-01net: mvpp2: fix validate for PPv2.1Antoine Tenart1-1/+1
The Phylink validate function is the Marvell PPv2 driver makes a check on the GoP id. This is valid an has to be done when using PPv2.2 engines but makes no sense when using PPv2.1. The check done when using an RGMII interface makes sure the GoP id is not 0, but this breaks PPv2.1. Fixes it. Fixes: 0fb628f0f250 ("net: mvpp2: fix phylink handling of invalid PHY modes") Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-01net: mvpp2: reconfiguring the port interface is PPv2.2 specificAntoine Tenart1-8/+6
This patch adds a check on the PPv2 version in-use not to reconfigure the port mode when an interface is updated when using PPv2.1 as the functions called are PPv2.2 specific. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-01net: mvpp2: a port can be disabled even if we use the link IRQAntoine Tenart1-7/+0
We had a check in the mvpp2_mac_link_down() function (called by phylink) to avoid disabling the port when link interrupts are used. It turned out the interrupt can still be used with the port disabled. We can thus remove this check. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-24net: mvpp2: Add 2.5GBaseT supportMaxime Chevallier1-0/+1
The PPv2 controller is able to support 2.5G speeds, allowing to use 2.5GBASET in conjunction with PHYs that use 2500BASEX as their MII interface when using this mode. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-12net: marvell: mvpp2: use mvpp2_is_xlg() helper elsewhereRussell King1-9/+6
There are several places which make the decision whether to access the XLGMAC vs GMAC that only check for PHY_INTERFACE_MODE_10GKR and not its XAUI variant. Switch these to use the new helper so that we have consistency through the driver. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-12net: marvell: mvpp2: add mvpp2_is_xlg() helperRussell King1-11/+9
Add a mvpp2_is_xlg() helper to identify whether the interface mode should be using the XLGMAC rather than the GMAC. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-09net: marvell: mvpp2: clear flow control modes in 10G modeRussell King1-0/+5
When mvpp2 configures the flow control modes in mvpp2_xlg_config() for 10G mode, it only ever set the flow control enable bits. There is no mechanism to clear these bits, which means that userspace is unable to use standard APIs to disable flow control (the only way is to poke the register directly.) Fix the missing bit clearance to allow flow control to be disabled. This means that, by default, as there is no negotiation in 10G modes with mvpp2, flow control is now disabled rather than being rx-only. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-08net: marvell: mvpp2: fix AN restartRussell King1-10/+5
phylink already limits which interface modes are able to call the MACs AN restart function, but in any case, the commentry seems incorrect: the AN restart bit does not automatically clear when set. This has been found via manual setting using devmem2, and we can observe that the AN does indeed restart and complete, yet the AN restart bit remains set. Explicitly clear the AN restart bit. Tested-by: Sven Auhagen <sven.auhagen@voleatech.de> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-08net: marvell: mvpp2: only reprogram what is necessary on mac_configRussell King1-23/+35
mac_config() can be called at any point, and the expected behaviour from MAC drivers is to only reprogram when necessary - and certainly avoid taking the link down on every call. Unfortunately, mvpp2 does exactly that - it takes the link down, and reprograms everything, and then releases the forced-link down. This is bad, it can cause the link to bounce: - SFP detects signal, disables LOS indication. - SFP code calls into phylink, calling phylink_sfp_link_up() which triggers a resolve. - phylink_resolve() calls phylink_get_mac_state() and finds the MAC reporting link up. - phylink wants to configure the pause mode on the MAC, so calls phylink_mac_config() - mvpp2 takes the link down temporarily, generating a MAC link down event followed by another MAC link event. - phylink calls mac_link_up() and then processes the MAC link down event. - phylink_resolve() gets called again, registers the link down, and calls mach_link_down() before re-running itself. - phylink_resolve() starts again at step 3 above. This sequence repeats. GMAC versions prior to mvpp2 do not require the link to be taken down except when certain link properties (eg, switching between SGMII and 1000base-X mode, or enabling/disabling in-band negotiation) are changed. Implement this for mvpp2. Tested-by: Sven Auhagen <sven.auhagen@voleatech.de> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-08net: marvell: mvpp2: fix stuck in-band SGMII negotiationRussell King1-6/+11
It appears that the mvpp22 can get stuck with SGMII negotiation. The symptoms are that in-band negotiation never completes and the partner (eg, PHY) never reports SGMII link up, or if it supports negotiation bypass, goes into negotiation bypass mode (which will happen when the PHY sees that the MAC is alive but gets no response.) Triggering the PHY end of the link to re-negotiate results in the bypass bit clearing on the PHY, and then re-setting - indicating that the problem is at the mvpp22 GMAC end. Asserting the GMAC reset and de-asserting it resolves the issue. Arrange to assert the GMAC reset at probe time, and deassert it only after we have configured the GMAC for the appropriate mode. This resolves the issue. Tested-by: Sven Auhagen <sven.auhagen@voleatech.de> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-08net: marvell: mvpp2: phylink compliance updatesRussell King1-36/+61
Sven Auhagen reported issues with negotiation on a couple of his platforms using a mixture of SFP and PHYs in various different modes. Debugging to root cause proved difficult, but essentially the problem comes down to the mvpp2 phylink implementation being slightly at odds with what is expected. phylink operates in three modes: phy, fixed-link, and in-band mode. In the first two modes, the expected behaviour from a MAC driver is that phylink resolves the operating mode and passes the mode to the MAC driver for it to program, including when the link should be brought up or taken down. This is basically the same as the libphy approach. This does not negate the requirement to advertise a correct control word for interface modes that have control words where that can be reasonably controlled. The second mode is in-band mode, where the MAC is expected to use the in-band control word to determine the operating mode. The mvneta driver implements the correct pattern required to support this: configure the port interface type separately from the in-band mode(s). This is now specified in the phylink documentation patches. mvpp2 was programming in-band mode for SGMII and the 802.3z modes no what, and avoided forcing the link up in fixed/phy modes. This caused a problem with some boards where the PHY is by default programmed to enter AN bypass mode, the PHY would report that the link was up, but the mvpp2 never completed the exchange of control word. Another issue that mvpp2 has is it sets SGMII AN format control word for both SGMII and 802.3z modes. The format of the control word is defined by MVPP2_GMAC_INBAND_AN_MASK, which should be set for SGMII and clear for 802.3z. Available Marvell documentation for earlier GMAC implementations does not make this clear, but this has been ascertained via extensive testing on earlier GMAC implementations, and then confirmed with a Macchiatobin Single Shot connected to a Clearfog: when MVPP2_GMAC_INBAND_AN_MASK is set, the clearfog does not receive the advertised pause mode settings. Lastly, there is no flow control in the in-band control word in Cisco SGMII, setting the flow control autonegotiation bit even with a PHY that has the Marvell extension to send this information does not result in the flow control being enabled at the MAC. We need to do this manually using the information provided via phylink. Re-code mvpp2's mac_config() and mac_link_up() to follow this pattern. This allows Sven Auhagen's board and Macchiatobin to reliably bring the link up with the 88e1512 PHY with phylink operating in PHY mode with COMPHY built as a module but the rest of the networking built-in, and u-boot having brought up the interface. in-band mode requires an additional patch to resolve another problem. Tested-by: Sven Auhagen <sven.auhagen@voleatech.de> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-05net: marvell: mvpp2: fix lack of link interruptsRussell King1-7/+14
Sven Auhagen reports that if he changes a SFP+ module for a SFP module on the Macchiatobin Single Shot, the link does not come back up. For Sven, it is as easy as: - Insert a SFP+ module connected, and use ping6 to verify link is up. - Remove SFP+ module - Insert SFP 1000base-X module use ping6 to verify link is up: Link up event did not trigger and the link is down but that doesn't show the problem for me. Locally, this has been reproduced by: - Boot with no modules. - Insert SFP+ module, confirm link is up. - Replace module with 25000base-X module. Confirm link is up. - Set remote end down, link is reported as dropped at both ends. - Set remote end up, link is reported up at remote end, but not local end due to lack of link interrupt. Fix this by setting up both GMAC and XLG interrupts for port 0, but only unmasking the appropriate interrupt according to the current mode set in the mac_config() method. However, only do the mask/unmask dance when we are really changing the link mode to avoid missing any link interrupts. Tested-by: Sven Auhagen <sven.auhagen@voleatech.de> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>