- 01 Jun, 2017 40 commits
-
-
Jesse Brandeburg authored
This moves a header for i40evf to include/linux/avf/virtchnl.h. The directory name AVF is an acronym for the Intel(R) Adaptive Virtual Function. This first step creates the new file, which is a rename of drivers/net/ethernet/intel/i40evf/i40e_virtchnl.h to include/linux/avf/virtchnl.h, and should show up in git as a rename when using git log --follow. To keep things building after the move, the changes to the i40evf driver are made to point to the new include file location. Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Jesse Brandeburg authored
This drops the i40e_type.h include in anticipation of the next patch which moves this file to a location where type.h doesn't exist, and all the places this file is included already include i40e_type.h before this file. Signed-off-by:
-
Ido Schimmel authored
When BRIDGE is a loadable module, MLXSW_SPECTRUM mustn't be built-in: drivers/built-in.o: In function `mlxsw_sp_bridge_device_create': drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c:145: undefined reference to `br_vlan_enabled' drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c:158: undefined reference to `br_multicast_enabled' drivers/built-in.o: In function `mlxsw_sp_dev_rif_type': drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:2972: undefined reference to `br_vlan_enabled' drivers/built-in.o: In function `mlxsw_sp_inetaddr_vlan_event': drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3310: undefined reference to `br_vlan_enabled' Add Kconfig dependency to enforce usable configurations. Fixes: c57529e1 ("mlxsw: spectrum: Replace vPorts with Port-VLAN") Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Reported-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Tested-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Corentin Labbe says: ==================== net-next: stmmac: add dwmac-sun8i ethernet driver This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC present on Allwinner H3/H5/A83T/A64 SoCs. This driver is the continuation of the sun8i-emac driver. During the development, it appeared that in fact the hardware was a modified version of some dwmac. So the driver is now written as a glue driver for stmmac. It supports 10/100/1000 Mbit/s speed with half/full duplex. It can use an internal PHY (MII 10/100) or an external PHY via RGMII/RMII. This patch series enable the driver only for the H3/A64/H5 SoC since A83T doesn't have the necessary clocks present in mainline. The driver have been tested on the following boards: - H3 Orange PI PC, BananaPI-M2+ - A64 Pine64, BananaPi-M64 - A83T BananaPI-M3 The first two patchs are some mandatory changes for letting dwmac-sun8i be used. The following three patchs add the driver and its documentation. The remaining are DT patch enabling it. Regards Corentin Labbe Changes since v5: - Added DT patch for NanoPi neo - Use the new adjust_link variables (speedxxx/speedmask) - Made the timeout of readl_poll_timeout from 10 to 100ms - Fix sun8i_unpower_phy that could be called twice - Replace phy by phy-handle in doc/dwmac-sun8i.txt Changes since v4: - Re-ordered by alphabetical order some DT nodes - Simplified power/unpower_phy functions by testing the use of internal_phy - Added a patch for adding dwmac-sun8i to arm64 defconfig - Fix a typo in sun50i-a64-system-controller (wrongly used sun8i) - Reworked uc/mc filter address setting Changes since v3: - Renamed tx-delay/rx-delay to tx-delay-ps/rx-delay-ps - fix syscon compatible example - Changed parameter type for setup() function - Dropped some DT patchs for boards which I could not test further Changes since v2: - corrected order of syscon compatible - added compatible = "ethernet-phy-ieee802.3-c22 to PHY - added set_mac function Changes since v1: - added TX/RX delay units - splitted syscon documentation in its own patch - regulator is now disabled after clk_prepare_enable(gmac->tx_clk) error - Fixed a memory leak on mac_device_info - Use now generic pin config for all DT stuff - CONFIG_DWMAC_SUN8I is now set to y in defconfigs ==================== Signed-off-by: -
LABBE Corentin authored
Enable the dwmac-sun8i ethernet driver as a module in the ARM64 defconfig. Signed-off-by:
Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by:
-
LABBE Corentin authored
Enable the dwmac-sun8i driver in the multi_v7 default configuration Signed-off-by:
-
LABBE Corentin authored
Enable the dwmac-sun8i driver in the sunxi default configuration Signed-off-by:
-
LABBE Corentin authored
The dwmac-sun8i hardware is present on the BananaPi M64. It uses an external PHY rtl8211e via RGMII. Signed-off-by:
-
LABBE Corentin authored
The dwmac-sun8i hardware is present on the pine64 plus. It uses an external PHY rtl8211e via RGMII. Signed-off-by:
-
LABBE Corentin authored
The dwmac-sun8i hardware is present on the pine64 It uses an external PHY via RMII. Signed-off-by:
-
LABBE Corentin authored
The dwmac-sun8i is an Ethernet MAC that supports 10/100/1000 Mbit connections. It is very similar to the device found in the Allwinner H3, but lacks the internal 100 Mbit PHY and its associated control bits. This adds the necessary bits to the Allwinner A64 SoC .dtsi, but keeps it disabled at this level. Signed-off-by:
-
LABBE Corentin authored
This patch add the dt node for the syscon register present on the Allwinner A64. Only two register are present in this syscon and the only one useful is the one dedicated to EMAC clock. Signed-off-by:
-
LABBE Corentin authored
The dwmac-sun8i hardware is present on the NanoPi Neo. It uses the internal PHY. This patch create the needed emac node. Signed-off-by:
-
LABBE Corentin authored
On the Orange Pi PC Plus, the polarity of the LEDs on the RJ45 Ethernet port were changed from active low to active high. Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
LABBE Corentin authored
The dwmac-sun8i hardware is present on the Orange PI 2. It uses the internal PHY. This patch create the needed emac node. Signed-off-by:
-
LABBE Corentin authored
The dwmac-sun8i hardware is present on the Orange PI One. It uses the internal PHY. This patch create the needed emac node. Signed-off-by:
-
LABBE Corentin authored
The dwmac-sun8i hardware is present on the Orange PI Zero. It uses the internal PHY. This patch create the needed emac node. Signed-off-by:
-
LABBE Corentin authored
The dwmac-sun8i hardware is present on the Orange PI PC. It uses the internal PHY. This patch create the needed emac node. Signed-off-by:
-
LABBE Corentin authored
The dwmac-sun8i is an ethernet MAC hardware that support 10/100/1000 speed. This patch enable the dwmac-sun8i on Allwinner H3/H5 SoC Device-tree. SoC H3/H5 have an internal PHY, so optionals syscon and ephy are set. Signed-off-by:
-
LABBE Corentin authored
This patch add the dt node for the syscon register present on the Allwinner H3/H5 Only two register are present in this syscon and the only one useful is the one dedicated to EMAC clock.. Signed-off-by:
-
LABBE Corentin authored
The dwmac-sun8i is a heavy hacked version of stmmac hardware by allwinner. In fact the only common part is the descriptor management and the first register function. Signed-off-by:
-
LABBE Corentin authored
This patch adds documentation for Device-Tree bindings for the syscon present in allwinner devices. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
LABBE Corentin authored
This patch adds documentation for Device-Tree bindings for the Allwinner dwmac-sun8i driver. Signed-off-by:
-
LABBE Corentin authored
Instead of adding more ifthen logic for adding a new mac_device_info setup function, it is easier to add a function pointer to the function needed. Signed-off-by:
-
LABBE Corentin authored
Thoses symbol will be needed for the dwmac-sun8i ethernet driver. For letting it to be build as module, they need to be exported. Signed-off-by:
-
Stephen Rothwell authored
asm-generic/socket.h already has an exception for the differences that powerpc needs, so just include it after defining the differences. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Yotam Gigi authored
Add callback to the ethtool flash_device op. This callback uses the mlxfw module to flash the new firmware file to the device. As the firmware flash process takes about 20 seconds and ethtool takes the rtnl lock during the flash_device callback, release the rtnl lock at the beginning of the flash process and take it again before leaving the callback. This way, the rtnl is not held during the process. To make sure the device does not get deleted during the flash process, take a reference to it before releasing the rtnl lock. Signed-off-by:
Yotam Gigi <yotamg@mellanox.com> Reviewed-by:
-
David S. Miller authored
Yuval Mintz says: ==================== qed: Status block changes The device maintains a CAM mapping of the internal status blocks and the various PF/VF MSI-x vector mappings. During initialization, the driver reads the HW memory and constructs a shadow SW implementation which it would later use for manipulation of interrupts. E.g., when enabling VFs and setting their MSI-x tables. The driver currently has some very strict assumptions on the order the entries are placed in the CAM. Specifically, it assumes that all entries belonging to a PF would be consecutive and in-order in the CAM, and that the VF entries would then follow. But there's no actual HW constraint enforcing this assumption [although management firmware does set it accordingly to same assumption initially]. Since the CAM is re-configurable, there are now SW flows employeed by other OSes that might cause the assumption to be invalid. Such flows allow the PF to forfeit some of it's available interrupts in favor of its VFs or vice versa. While those are not employeed today by qed, we want to relax the assumptions as much as we can - both to allow functionality after PDA as well as allowing future compatibility where the driver would be loaded after a newer one has 'dirtied' the CAM configuration. In addition to patches meant for the above relaxation, the series also contains various cleanups & refactoring for interrupt logic [most of which is !semantic]. ==================== Signed-off-by: -
Mintz, Yuval authored
Since we're resetting the IGU CAM each time we initialize the PF device, there's no need to reset the VF SBs again when initializing IOV. Signed-off-by:
Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by:
-
Mintz, Yuval authored
The IGU CAM contains an assocaition between hardware SBs and interrupt lines, and it can be dynamically configured to allow more interrupts in one entity over another, specifically for Re-distibution of SBs between a PF and its child VFs. While we don't yet use this functionality, there are other clients that do and as such its possible the information passed from management firmware during initialization in regard to the possible number of SBs doesn't accurately reflect the current HW configuration. The following changes are going to apply to the driver init sequence: a. PF is going to re-configure all entries belonging to itself and its child VFs in IGU CAM based on the management firmware info regarding the number of SBs that are supposed to exist there. b. PF is going to stop using the SB resource [management firmware provided information] for anything but the initialization. Instead, it would use the live-time counters it maintains for the numbers. Signed-off-by: -
Mintz, Yuval authored
A PF today holds 2 different arrays - one holding information about the HW configuration and one holding information about the SBs that are used by the protocol drivers. These arrays aren't really connected - e.g., protocol driver initializing a given SB would not mark the same SB as occupied in the HW shadow array. Move into a single array [at least for PFs] - hold the mapping of the driver-protocol SBs on the HW entry which they configure. Signed-off-by:
-
Mintz, Yuval authored
IOV code is very intrusive in its manipulation of the status block database. Add a new auxiliary function to allow the PF to find an available unused status block to configure for a specific VF's MSI-x vector. Signed-off-by:
-
Mintz, Yuval authored
Current code assumes there's a known layout for SBs in the IGU, where all the SBs of a single entity would be laid in consecutive order of vectors. While the assumption is still kept by management firmware, we already have the necessary information to eliminate it, so no reason to keep it in code. Signed-off-by:
-
Mintz, Yuval authored
We already have an API struct that contains interrupt-related numbers. Use it to encapsulate all information relating to the status of SBs as (used|free). Signed-off-by:
-
Mintz, Yuval authored
An additional step for relaxing the IGU order assumption, we now add an auxiliary function that can be used for finding the HW status block that's associated with a given MSI-x vector. Signed-off-by:
-
Mintz, Yuval authored
In qed code, sb_id means 2 different things: - An interrupt vector [usually when received as a parameter from a protocol driver, but not only] that's associated with a status block. - An index to a status block entity existing in HW. This patch renames the references to the HW entity, adding an 'igu_' prefix to allow an easier distinction. Signed-off-by: -
Mintz, Yuval authored
As a first step for relaxing various assumptions done by driver about the IGU mapping, the driver is now going to read the entire IGU into a shadow copy, and mark in its database each status block that's relevant for it. Signed-off-by:
-
Mintz, Yuval authored
Separate the portions controlling interrupt enablement form those controlling the ability of HW to generate attentions. Signed-off-by:
-
Mintz, Yuval authored
Signed-off-by:
-
Colin Ian King authored
function ksz_rcv can be made static as it does not need to be in global scope. Reformat arguments to make it checkpatch warning free too. Cleans up sparse warning: "symbol 'ksz_rcv' was not declared. Should it be static?" Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Woojung Huh <Woojung.Huh@microchip.com> Signed-off-by:
-
