- 10 Mar, 2017 12 commits
-
-
Mahesh Bandewar authored
In preparation to move the work-queue initialization to port creation from current port_open phase. Work-queue initialization does not make sense every time we do 'ifup/ifdown'. So moving to port creation phase. Arp monitoring work depends on the bonding mode and that is not tied to the port creation and can change anytime during the life after port creation. So this restructuring allows us to move the initialization at creation without losing the ability to arm the correct work for the mode user has selected. Signed-off-by:
Mahesh Bandewar <maheshb@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jakub Kicinski says: ==================== nfp: CRC32 RSS hash, port name reporting and misc fastpath cleanups This series adds support for CRC32 RSS hash function to kernel API of which NFP driver immediately makes use. There is also a .ndo_get_phys_port_name() implementation conforming to switchdev name format. Small patch takes advantage of napi_complete_done()'s return code. Simon provides a fix for potentially trusting values returned from FW too much. A handful of unassuming fast path adjustments is also thrown in to make the upcoming xdp_adjust_head() series easier to review. ==================== Signed-off-by: -
Simon Horman authored
Prevent theoretical buffer overrun by returning an error if the number of entries returned by the firmware does not match those present. Also use a common handling error path. Found by inspection. Signed-off-by:
Simon Horman <simon.horman@netronome.com> Tested-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
Jakub Kicinski authored
We only need FW version in the first cache line of adapter struct because we need to know the metadata format. To save space add a metadata format bit. Signed-off-by:
-
Jakub Kicinski authored
Make use of return code from napi_complete_done() to avoid rearming interrupts when busy polling is on. Signed-off-by:
-
Jakub Kicinski authored
We really only need the device pointer on the fast path, stash it at the beginning of the adapter structure and move pci_dev pointer down. This saves up a few lines of code. Signed-off-by:
-
Jakub Kicinski authored
Reorder variables longest to shortest to comply with netdev coding style. Signed-off-by:
-
Jakub Kicinski authored
We already print most of ring configuration including descriptors in debugfs, add the few missing pieces and remove debug prints. Signed-off-by:
-
Jakub Kicinski authored
NSP reports to us port labels. First id is the id of the physical port, the other one tells us which logical interface is it within a split port. Instead of printing them as string keep them in integer format. Compute which interfaces are part of port split. On netdev side use port labels and split information to provide a .ndo_get_phys_port_name() implementation. We follow the name format of mlxsw which is also suggested in "Port Netdev Naming" section of Documentation/networking/switchdev.txt. Signed-off-by:
-
Jakub Kicinski authored
Some firmware images may reuse CRC32 hardware to compute RXHASH. Make sure we report the correct hash function. Note that we don't support changing functions at runtime. That would also require a few more additions to the way the key is set because different functions have different key sizes. Signed-off-by:
-
Jakub Kicinski authored
CRC32 engines are usually easily available in hardware and generate OK spread for RSS hash. Add CRC32 RSS hash function to ethtool API. Signed-off-by:
-
Paolo Abeni authored
Currently the sock queue's spin locks get their lockdep classes by the default init_spin_lock() initializer: all socket families get - usually, see below - a single class for rx, another specific class for tx, etc. This can lead to false positive lockdep splat, as reported by Andrey. Moreover there are two separate initialization points for the sock queues, one in sk_clone_lock() and one in sock_init_data(), so that e.g. the rx queue lock can get one of two possible, different classes, depending on the socket being cloned or not. This change tries to address the above, setting explicitly a per address family lockdep class for each queue's spinlock. Also, move the duplicated initialization code to a single location. v1 -> v2: - renamed the init helper rfc -> v1: - no changes, tested with several different workload Suggested-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
- 09 Mar, 2017 28 commits
-
-
Jie Deng authored
Synopsys provides a new DesignWare Core Enterprise Ethernet MAC IP (DWC-XLGMAC) for Ethernet designs. It is compliant with the IEEE 802.3-2012 specifications, including IEEE 802.3ba and consortium specifications. This patch provides the initial 25G/40G/50G/100G Ethernet driver for Synopsys XLGMAC IP Prototyping Kit. Signed-off-by:
Jie Deng <jiedeng@synopsys.com> Signed-off-by:
-
David S. Miller authored
Iyappan Subramanian says: ==================== drivers: net: xgene-v2: Add RGMII based 1G driver This patch set adds support for RGMII based 1GbE hardware which uses a linked list of DMA descriptor architecture (v2) for APM X-Gene SoCs. v4: Address review comments from v3 - fixed local variable declarations to reverse christmas tree order v3: Address review comments from v2 - fixed kbuild warnings (this 'if' clause does not guard) v2: Address review comments from v1 - moved create_desc_ring and delete_desc_ring to open() and close() respectively - changed to use dma_zalloc APIs - fixed tx_timeout() - removed tx completion polling upper bound - added error checking on rx packets - added netif_stop_queue() and netif_wake_queue() v1: - Initial version ==================== Signed-off-by:
Iyappan Subramanian <isubramanian@apm.com> Signed-off-by:
-
Iyappan Subramanian authored
This patch adds a MAINTAINERS entry for the ethernet driver for the on-chip ethernet interface which uses a linked list of DMA descriptor architecture (v2) for APM X-Gene SoCs. Signed-off-by:
Keyur Chudgar <kchudgar@apm.com> Signed-off-by:
-
Iyappan Subramanian authored
This patch adds, - Transmit - Transmit completion poll - Receive poll - NAPI handler and enables the driver. Signed-off-by: -
Iyappan Subramanian authored
This patch adds, - probe, remove, shutdown - open, close and stats - create and delete ring - request and delete irq Signed-off-by: -
Iyappan Subramanian authored
This patch adds functions to configure ethernet hardware. Signed-off-by:
-
Iyappan Subramanian authored
This patch adds functions to configure and control mac. This patch also adds helper functions to get/set registers. Signed-off-by:
-
Iyappan Subramanian authored
This patch adds DMA descriptor setup and interrupt enable/disable functions. Signed-off-by:
-
Rick Farrington authored
Add support for XPS. Signed-off-by:
Rick Farrington <ricardo.farrington@cavium.com> Signed-off-by:
Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by:
Derek Chickles <derek.chickles@cavium.com> Signed-off-by:
Satanand Burla <satananda.burla@cavium.com> Signed-off-by:
-
Joao Pinto authored
The axi variable was not being freed upon device removal. With devm_kzalloc it ensures that it is properly freed. Signed-off-by:
Joao Pinto <jpinto@synopsys.com> Signed-off-by:
-
Tobias Klauser authored
Use eth_hw_addr_random() to set a random dev_addr and update addr_assign_type instead of open-coding it. Signed-off-by:
Tobias Klauser <tklauser@distanz.ch> Signed-off-by:
-
Florian Fainelli authored
Introduce a Kconfig option: CONFIG_TIGON3_HWMON which allows to build in/out support for thermal sensors reported by Tigon3 NICs. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
David S. Miller authored
Thomas Petazzoni says: ==================== net: mvpp2: add initial support for PPv2.2 The goal of this patch series is to add basic support for PPv2.2 in the existing mvpp2 driver. mvpp2 currently supported the PPv2.1 version of the IP, used in the 32 bits Marvell Armada 375 SoC. PPv2.2 is an evolution of this IP block, used in the 64 bits Marvell Armada 7K/8K SoCs. In order to ease the review, the introduction of PPv2.2 support has been made into multiple small commits, with the final commit adding the compatible string that makes the PPv2.2 support actually usable. The series remain fully bisectable. People interested in testing the code will find the full series (plus a few Device Tree patches) at: https://github.com/MISL-EBU-System-SW/mainline-public/tree/4.11/mvpp2.2-support-v3 I'd like to thank Stefan Chulski and Marcin Wojtas, who helped me a lot in the development of this patch series, by reviewing the patches, and giving lots of useful hints to debug the driver on PPv2.2. Thanks as well to Russell King for reviewing previous iterations of this series, and providing suggestions and fixes. Changes between v2 and v3: - Rebased on v4.11-rc1. - Add patch "net: mvpp2: fix DMA address calculation in mvpp2_txq_inc_put()", to properly take into account the "packet offset" field of the TX descriptors. Without this, we were getting DMA_API_DEBUG warnings that we are unmapping DMA mappings with a non-mapped DMA address. - In patch "net: mvpp2: add and use accessors for TX/RX descriptors", add a function named mvpp2_txdesc_offset_get(), which is needed for the DMA address calculation fix. - In patch "net: mvpp2: add and use accessors for TX/RX descriptors", fix the calculation of tx_desc physical address and packet offset in mvpp2_tx_frag_process(). The offset was assigned into the buffer physical address, and the physical address to the packet offset, which meant the fragment process was completely broken. - In patch "net: mvpp2: adjust the allocation/free of BM pools for PPv2.2" fix how MVPP22_BM_ADDR_HIGH_VIRT_RLS_MASK is used. This mask is already shifted. So the value should be shifted before being masked and not the opposite. - Add a new patch "net: mvpp2: set dma mask and coherent dma mask on PPv2.2", to set the DMA mask and DMA coherent mask. By setting the DMA mask to 40 bits we avoid using bounce buffers when network packets are above the 4 GB limit. The coherent mask remains set to 32 bits, because the BM pools must all have the same high 32 bits in their addresses. - Use "dma" instead of "phys" where appropriate, as suggested by Russell King. - Use the "cookie" field of the RX descriptor to store the physical address instead of the virtual address, and then use phys_to_virt() to get the virtual address. This allows to work around the limit that the "cookie" field only has 40 bits, which is not sufficient to store a virtual address on 64 bits platforms. This was suggested by Russell King. As part of this change, also got rid of all the compile time conditionals on CONFIG_ARCH_DMA_ADDR_T_64BIT, to get better compile-time coverage. - In patch "net: mvpp2: handle misc PPv2.1/PPv2.2 differences": * Instead of calling mvpp21_port_power_up(port) only on PPv2.1, remove this function, and call its relevant parts directly from ->probe(). Only mvpp2_port_fc_adv_enable() is PPv2.1 specific. Reported by Russell King. * Add a mvpp22_port_mii_set() function that properly initializes SGMII support on PPv2.2. Code provided by Russell King. - In patch "net: mvpp2: handle register mapping and access for PPv2.2": * Adjust the code to match the change of the DT binding in terms of mapping the second register area on PPv2.2. * Rework the register accessors to remove the get_cpu()/put_cpu(), and instead use separate accessors for global registers vs. per-CPU registers. - Add a few new patches removing dead/unused/useless code: net: mvpp2: remove support for buffer header net: mvpp2: remove unused register definition MVPP2_TXQ_THRESH_REG net: mvpp2: remove mvpp2_txq_pend_desc_num_get() function - Fix a number of checkpatch warnings. Changes between v1 and v2: - Made a separate series from the set of patches doing preparation changes/fixes to the mvpp2 driver. - Rebased on top of v4.10-rc1. - Update Kconfig text of the mvpp2 driver to mention the support for Armada 7K and 8K (PPv2.2). ==================== Signed-off-by:
-
Thomas Petazzoni authored
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:
-
Thomas Petazzoni authored
On PPv2.2, the streaming mappings can be anywhere in the first 40 bits of the physical address space. However, for the coherent mappings, we still need them to be in the first 32 bits of the address space, because all BM pools share a single register to store the high 32 bits of the BM pool address, which means all BM pools must be allocated in the same 4GB memory area. Signed-off-by:
-
Thomas Petazzoni authored
The PPv2.2 variant of the network controller needs an additional clock, the "MG clock" in order for the IP block to operate properly. This commit adds support for this additional clock to the driver, reworking as needed the error handling path. Signed-off-by:
-
Thomas Petazzoni authored
In PPv2.1, we have a maximum of 8 RXQs per port, with a default of 4 RXQs per port, and we were assigning RXQs 0->3 to the first port, 4->7 to the second port, 8->11 to the third port, etc. In PPv2.2, we have a maximum of 32 RXQs per port, and we must allocate RXQs from the range of 32 RXQs available for each port. So port 0 must use RXQs in the range 0->31, port 1 in the range 32->63, etc. This commit adapts the mvpp2 to this difference between PPv2.1 and PPv2.2: - The constant definition MVPP2_MAX_RXQ is replaced by a new field 'max_port_rxqs' in 'struct mvpp2', which stores the maximum number of RXQs per port. This field is initialized during ->probe() depending on the IP version. - MVPP2_RXQ_TOTAL_NUM is removed, and instead we calculate the total number of RXQs by multiplying the number of ports by the maximum of RXQs per port. This was anyway used in only one place. - In mvpp2_port_probe(), the calculation of port->first_rxq is adjusted to cope with the different allocation strategy between PPv2.1 and PPv2.2. Due to this change, the 'next_first_rxq' argument of this function is no longer needed and is removed. Signed-off-by:
-
Thomas Petazzoni authored
This commit adjusts how the MVPP2_ISR_RXQ_GROUP_REG register is configured, since it changed between PPv2.1 and PPv2.2. Signed-off-by:
-
Thomas Petazzoni authored
The PPv2.2 unit is connected to an AXI bus on Armada 7K/8K, so this commit adds the necessary initialization of the AXI bridge. Signed-off-by:
-
Thomas Petazzoni authored
This commit handles a few miscellaneous differences between PPv2.1 and PPv2.2 in different areas, where code done for PPv2.1 doesn't apply for PPv2.2 or needs to be adjusted (getting the MAC address, disabling PHY polling, etc.). Thanks to Russell King for providing the initial implementation of mvpp22_port_mii_set(). Signed-off-by:
-
Thomas Petazzoni authored
This commit adjusts the mvpp2 driver register mapping and access logic to support PPv2.2, to handle a number of differences. Due to how the registers are laid out in memory, the Device Tree binding for the "reg" property is different: - On PPv2.1, we had a first area for the packet processor registers (common to all ports), and then one area per port. - On PPv2.2, we have a first area for the packet processor registers (common to all ports), and a second area for numerous other registers, including a large number of per-port registers In addition, on PPv2.2, the area for the common registers is split into so-called "address spaces" of 64 KB each. They allow to access per-CPU registers, where each CPU has its own copy of some registers. A few other registers, which have a single copy, also need to be accessed from those per-CPU windows if they are related to a per-CPU register. For example: - Writing to MVPP2_TXQ_NUM_REG selects a TX queue. This register is a per-CPU register, it must be accessed from the current CPU register window. - Then a write to MVPP2_TXQ_PENDING_REG, MVPP2_TXQ_DESC_ADDR_REG (and a few others) will affect the TX queue that was selected by the write to MVPP2_TXQ_NUM_REG. It must be accessed from the same CPU window as the write to the TXQ_NUM_REG. Therefore, the ->base member of 'struct mvpp2' is replaced with a ->cpu_base[] array, each entry pointing to a mapping of the per-CPU area. Since PPv2.1 doesn't have this concept of per-CPU windows, all entries in ->cpu_base[] point to the same io-remapped area. The existing mvpp2_read() and mvpp2_write() accessors use cpu_base[0], they are used for registers for which the CPU window doesn't matter. mvpp2_percpu_read() and mvpp2_percpu_write() are new accessors added to access the registers for which the CPU window does matter, which is why they take a "cpu" as argument. The driver is then changed to use mvpp2_percpu_read() and mvpp2_percpu_write() where it matters. Signed-off-by: -
Thomas Petazzoni authored
In PPv2.2, the MVPP2_RXQ_DESC_ADDR_REG and MVPP2_TXQ_DESC_ADDR_REG registers have a slightly different layout, because they need to contain a 64-bit address for the RX and TX descriptor arrays. This commit adjusts those functions accordingly. Signed-off-by:
-
Thomas Petazzoni authored
This commit modifies the mvpp2_defaults_set() function to not do the loopback and FIFO threshold initialization, which are not needed for PPv2.2. Signed-off-by:
-
Thomas Petazzoni authored
The MVPP2_RXQ_CONFIG_REG register has a slightly different layout between PPv2.1 and PPv2.2, so this commit adapts the functions modifying this register to accommodate for both the PPv2.1 and PPv2.2 cases. Signed-off-by:
-
Thomas Petazzoni authored
This commit adjusts the allocation and freeing of BM pools to support PPv2.2. This involves: - Checking that the number of buffer pointers is a multiple of 16, as required by the hardware. - Adjusting the size of the DMA coherent area allocated for buffer pointers. Indeed, PPv2.2 needs space for 2 pointers of 64-bits per buffer, as opposed to 2 pointers of 32-bits per buffer in PPv2.1. The size in bytes is now stored in a new field of the mvpp2_bm_pool structure. - On PPv2.2, getting the DMA address and cookie (used for the physical address) of each buffer requires reading the MVPP22_BM_ADDR_HIGH_ALLOC to get the high order bits of those addresses. A new utility function mvpp2_bm_bufs_get_addrs() is introduced to handle this. - On PPv2.2, releasing a buffer requires writing the high order 32 bits of the DMA address and cookie to MVPP22_BM_PHY_VIRT_HIGH_RLS_REG. Signed-off-by:
-
Thomas Petazzoni authored
This commit adds the definition of the PPv2.2 HW descriptors, adjusts the mvpp2_tx_desc and mvpp2_rx_desc structures accordingly, and adapts the accessors to work on both PPv2.1 and PPv2.2. Signed-off-by:
-
Thomas Petazzoni authored
Since the format of the HW descriptors is different between PPv2.1 and PPv2.2, this commit introduces an intermediate union, with for now only the PPv2.1 descriptors. The bulk of the driver code only manipulates opaque mvpp2_tx_desc and mvpp2_rx_desc pointers, and the descriptors can only be accessed and modified through the accessor functions. A follow-up commit will add the descriptor definitions for PPv2.2. Signed-off-by:
-
Thomas Petazzoni authored
In preparation to the introduction for the support of PPv2.2 in the mvpp2 driver, this commit adds a hw_version field to the struct mvpp2, and uses the .data field of the DT match table to fill it in. Having the MVPP21 and MVPP22 definitions available will allow to start adding the necessary conditional code to support PPv2.2. Signed-off-by:
-
