- 05 Jan, 2020 34 commits
-
-
Vladimir Oltean authored
I finally found out how the 4 management route slots are supposed to be used, but.. it's not worth it. The description from the comment I've just deleted in this commit is still true: when more than 1 management slot is active at the same time, the switch will match frames incoming [from the CPU port] on the lowest numbered management slot that matches the frame's DMAC. My issue was that one was not supposed to statically assign each port a slot. Yes, there are 4 slots and also 4 non-CPU ports, but that is a mere coincidence. Instead, the switch can be used like this: every management frame gets a slot at the right of the most recently assigned slot: Send mgmt frame 1 through S0: S0 x x x Send mgmt frame 2 through S1: S0 S1 x x Send mgmt frame 3 through S2: S0 S1 S2 x Send mgmt frame 4 through S3: S0 S1 S2 S3 The difference compared to the old usage is that the transmission of frames 1-4 doesn't need to wait until the completion of the management route. It is safe to use a slot to the right of the most recently used one, because by protocol nobody will program a slot to your left and "steal" your route towards the correct egress port. So there is a potential throughput benefit here. But mgmt frame 5 has no more free slot to use, so it has to wait until _all_ of S0, S1, S2, S3 are full, in order to use S0 again. And that's actually exactly the problem: I was looking for something that would bring more predictable transmission latency, but this is exactly the opposite: 3 out of 4 frames would be transmitted quicker, but the 4th would draw the short straw and have a worse worst-case latency than before. Useless. Things are made even worse by PTP TX timestamping, which is something I won't go deeply into here. Suffice to say that the fact there is a driver-level lock on the SPI bus offsets any potential throughput gains that parallelism might bring. So there's no going back to the multi-slot scheme, remove the "mgmt_slot" variable from sja1105_port and the dummy static assignment made at probe time. While passing by, also remove the assignment to casc_port altogether. Don't pretend that we support cascaded setups. Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Russell King says: ==================== Fix 10G PHY interface types Recent discussion has revealed that our current usage of the 10GKR phy_interface_t is not correct. This is based on a misunderstanding caused in part by the various specifications being difficult to obtain. Now that a better understanding has been reached, we ought to correct this. This series introduce PHY_INTERFACE_MODE_10GBASER to replace the existing usage of 10GKR mode, and document their differences in the phylib documentation. Then switch PHY, SFP/phylink, the Marvell PP2 network driver, and its associated comphy driver over to use the correct interface mode. None of the existing platform usage was actually using 10GBASE-KR. In order to maintain compatibility with existing DT files, arrange for the Marvell PP2 driver to rewrite the phy interface mode; this allows other drivers to adopt correct behaviour w.r.t whether the 10G connection conforms to the backplane 10GBASE-KR protocol vs normal 10GBASE-R protocol. After applying these locally to net-next I've validated that the only places which mention the old PHY_INTERFACE_MODE_10GKR definition are: Documentation/networking/phy.rst:``PHY_INTERFACE_MODE_10GKR`` drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c: if (phy_mode == PHY_INTERFACE_MODE_10GKR) drivers/net/phy/aquantia_main.c: phydev->interface = PHY_INTERFACE_MODE_10GKR; drivers/net/phy/aquantia_main.c: phydev->interface != PHY_INTERFACE_MODE_10GKR && include/linux/phy.h: PHY_INTERFACE_MODE_10GKR, include/linux/phy.h: case PHY_INTERFACE_MODE_10GKR: which is as expected. The only users of "10gbase-kr" in DT are: arch/arm64/boot/dts/marvell/armada-7040-db.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/armada-8040-db.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/armada-8040-db.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/armada-8040-mcbin-singleshot.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/armada-8040-mcbin-singleshot.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts: phy-mode = "10gbase-kr";arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts: phy-mode = "10gbase-kr";arch/arm64/boot/dts/marvell/cn9130-db.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/cn9131-db.dts: phy-mode = "10gbase-kr"; arch/arm64/boot/dts/marvell/cn9132-db.dts: phy-mode = "10gbase-kr"; which all use the mvpp2 driver, and these will be updated in a separate patch to be submitted in the following kernel cycle. v2: add comment to mvpp2 driver. ==================== Signed-off-by: -
Russell King authored
Switch network drivers, phy drivers, and SFP/phylink over to use the more correct 10GBASE-R, rather than 10GBASE-KR. 10GBASE-KR is backplane ethernet, which is 10GBASE-R with autonegotiation on top, which our current usage on the affected platforms does not have. The only remaining user of PHY_INTERFACE_MODE_10GKR is the Aquantia PHY, which has a separate mode for 10GBASE-KR. For Marvell mvpp2, we detect 10GBASE-KR, and rewrite it to 10GBASE-R for compatibility with existing DT - this is the only network driver at present that makes use of PHY_INTERFACE_MODE_10GKR. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Russell King authored
Recent discussion has revealed that the use of PHY_INTERFACE_MODE_10GKR is incorrect. Add a 10GBASE-R definition, document both the -R and -KR versions, and the fact that 10GKR was used incorrectly. Reviewed-by:
-
David S. Miller authored
Shannon Nelson says: ==================== ionic: add sriov support Set up the basic support for enabling SR-IOV devices in the ionic driver. Since most of the management work happens in the NIC firmware, the driver becomes mostly a pass-through for the network stack commands that want to control and configure the VFs. v4: changed "vf too big" checks to use pci_num_vf() changed from vf[] array of pointers of individually allocated vf structs to single allocated vfs[] array of vf structs added clean up of vfs[] on probe fail added setup for vf stats dma v3: added check in probe for pre-existing VFs split out the alloc and dealloc of vf structs to better deal with pre-existing VFs (left enabled on remove) restored the checks for vf too big because of a potential case where VFs are already enabled but driver failed to alloc the vf structs v2: use pci_num_vf() and kcalloc() remove checks for vf too big add locking for the VF operations disable VFs in ionic_remove() if they are still running ==================== Signed-off-by: -
Shannon Nelson authored
Add the netdev ops for managing VFs. Since most of the management work happens in the NIC firmware, the driver becomes mostly a pass-through for the network stack commands that want to control and configure the VFs. We also tweak ionic_station_set() a little to allow for the VFs that start off with a zero'd mac address. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
-
Shannon Nelson authored
Adds new AdminQ calls and their related structs for supporting PF controls on VFs: CMD_OPCODE_VF_GETATTR CMD_OPCODE_VF_SETATTR Signed-off-by: -
Krzysztof Kozlowski authored
Fix up inconsistent usage of upper and lowercase letters in "Samsung" name. "SAMSUNG" is not an abbreviation but a regular trademarked name. Therefore it should be written with lowercase letters starting with capital letter. Although advertisement materials usually use uppercase "SAMSUNG", the lowercase version is used in all legal aspects (e.g. on Wikipedia and in privacy/legal statements on https://www.samsung.com/semiconductor/privacy-global/). Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
David S. Miller authored
Dmitry Torokhov says: ==================== net: phy: switch to using fwnode_gpiod_get_index This series switches phy drivers form using fwnode_get_named_gpiod() and gpiod_get_from_of_node() that are scheduled to be removed in favor of fwnode_gpiod_get_index() that behaves more like standard gpiod_get_index() and will potentially handle secondary software nodes in cases we need to augment platform firmware. Now that the dependencies have been merged into networking tree the patches can be applied there as well. v3: - rebased on top of net-next v2: - rebased on top of Linus' W devel branch - added David's ACKs ==================== Signed-off-by: -
Dmitry Torokhov authored
gpiod_get_from_of_node() is being retired in favor of [devm_]fwnode_gpiod_get_index(), that behaves similar to [devm_]gpiod_get_index(), but can work with arbitrary firmware node. It will also be able to support secondary software nodes. Let's switch this driver over. Acked-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Dmitry Torokhov authored
If we fail to locate GPIO for any reason other than deferral or not-found-GPIO, we try to print device tree node info, however if might be freed already as we called of_node_put() on it. Acked-by:
-
Dmitry Torokhov authored
Instead of fwnode_get_named_gpiod() that I plan to hide away, let's use the new fwnode_gpiod_get_index() that mimics gpiod_get_index(), but works with arbitrary firmware node. Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
-
Florian Fainelli authored
There is no build time dependency on CONFIG_OF, but we do need to make sure we gate the initialization of the gpio_chip::of_node member with a proper check on CONFIG_OF_GPIO. This enables the driver to build on platforms that do not have CONFIG_OF enabled. Signed-off-by:
-
David S. Miller authored
Jason A. Donenfeld says: ==================== WireGuard bug fixes and cleanups I've been working through some personal notes and also the whole git repo history of the out-of-tree module, looking for places where tradeoffs were made (and subsequently forgotten about) for old kernels. The first two patches in this series clean up those. The first one does so in the self-tests and self-test harness, where we're now able to expand test coverage by a bit, and we're now cooking away tests on every commit to both the wireguard-linux repo and to net-next. The second one removes a workaround for a skbuff.h bug that was fixed long ago. Finally, the last patch in the series fixes in a bug unearthed by newer Qualcomm chipsets running the rmnet_perf driver, which does UDP GRO. ==================== Signed-off-by: -
Jason A. Donenfeld authored
Certain drivers will pass gro skbs to udp, at which point the udp driver simply iterates through them and passes them off to encap_rcv, which is where we pick up. At the moment, we're not attempting to coalesce these into bundles, but we also don't want to wind up having cascaded lists of skbs treated separately. The right behavior here, then, is to just mark each incoming one as not on a list. This can be seen in practice, for example, with Qualcomm's rmnet_perf driver. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Tested-by:
Yaroslav Furman <yaro330@gmail.com> Signed-off-by:
-
Jason A. Donenfeld authored
Before 8b700862 ("net: Don't copy pfmemalloc flag in __copy_skb_ header()"), the pfmemalloc flag used to be between headers_start and headers_end, which is a region we clear when preparing the packet for encryption/decryption. This is a parameter we certainly want to preserve, which is why 8b700862 moved it out of there. The code here was written in a world before 8b700862, though, where we had to manually account for it. This commit brings things up to speed. Signed-off-by:
-
Jason A. Donenfeld authored
Quite a bit of the test suite was designed to work with ancient kernels. Thankfully we no longer have to deal with this. This commit updates things that we can finally update and removes things that we can finally remove, to avoid the build-up of the last several years as a result of having to support ancient kernels. We can finally rely on suppress_ prefixlength being available. On the build side of things, the no-PIE hack is no longer required, and we can bump some of the tools, repair our m68k and i686-kvm support, and get better coverage of the static branches used in the crypto lib and in udp_tunnel. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 1GbE Intel Wired LAN Driver Updates 2020-01-04 This series contains updates to the igc driver only. Sasha does some housekeeping on the igc driver to remove forward declarations that are not needed after re-arranging several functions. ==================== Signed-off-by: -
Sasha Neftin authored
We want to avoid forward-declarations of function if possible. Rearrange the igc_sw_init function implementation. Signed-off-by:
Sasha Neftin <sasha.neftin@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Sasha Neftin authored
We want to avoid forward-declarations of function if possible. Rearrange the igc_write_itr function implementation. Signed-off-by:
-
Sasha Neftin authored
We want to avoid forward-declarations of function if possible. Rearrange the igc_assign_vector function implementation. Signed-off-by:
-
Sasha Neftin authored
We want to avoid forward-declarations of function if possible. Rearrange the igc_free_q_vector function implementation. Signed-off-by:
-
Sasha Neftin authored
We want to avoid forward-declarations of function if possible. Rearrange the igc_free_q_vectors function implementation. Signed-off-by:
-
Sasha Neftin authored
We want to avoid forward-declarations of function if possible. Rearrange the igc_irq_disable function implementation. Signed-off-by:
-
Sasha Neftin authored
We want to avoid forward-declarations of function if possible. Rearrange the igc_irq_enable function implementation. Signed-off-by:
-
Sasha Neftin authored
We want to avoid forward-declarations of function if possible. Rearrange the igc_configure_msix function implementation. Signed-off-by:
-
Sasha Neftin authored
We want to avoid forward-declarations of function if possible. Rearrange the igc_set_rx_mode function implementation. Signed-off-by:
-
Sasha Neftin authored
We want to avoid forward-declarations of function if possible. Rearrange the igc_set_interrupt_capability function implementation. Signed-off-by:
-
Sasha Neftin authored
We want to avoid forward-declarations of function if possible. Rearrange the igc_alloc_mapped_page function implementation. Signed-off-by:
-
Sasha Neftin authored
We want to avoid forward-declarations of function if possible. Rearrange the igc_configure function implementation. Signed-off-by:
-
Sasha Neftin authored
We want to avoid forward-declarations of function if possible. Rearrange the igc_set_default_mac_filter function implementation. Signed-off-by:
-
Sasha Neftin authored
We want to avoid forward-declarations of function if possible. Rearrange the igc_power_down_link function implementation. Signed-off-by:
-
Sasha Neftin authored
We want to avoid forward-declarations of function if possible. Rearrange the igc_clean_tx_ring function implementation. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 100GbE Intel Wired LAN Driver Updates 2020-01-03 This series contains updates to the ice driver only. Brett adds support for UDP segmentation offload (USO) based on the work Alex Duyck did for other Intel drivers. Refactored how the VF sets spoof checking to resolve a couple of issues found in ice_set_vf_spoofchk(). Adds the ability to track of the dflt_vsI (default VSI), since we cannot have more than one default VSI. Add a macro for commonly used "for loop" used repeatedly in the code. Cleaned up and made the VF link flows all similar. Refactor the flows of adding and deleting MAC addresses in order to simplify the logic for error conditions and setting/clearing the VF's default MAC address field. Michal moves the setting of the default ITR value from ice_cfg_itr() to the function we allocate queue vectors. Adds support for saving and restoring the ITR value for each queue. Adds a check for all invalid or unused parameters to log the information and return an error. Vignesh cleans up the driver where we were trying to write to read-only registers for the receive flex descriptors. Tony changes a netdev_info() to netdev_dbg() when the MTU value is changed. Bruce suppresses a coverity reported error that was not really an error by adding a code comment. Mitch adds a check for a NULL receive descriptor to resolve a coverity reported issue. Krzysztof prevents a potential general protection fault by adding a boundary check to see if the queue id is greater than the size of a UMEM array. Adds additional code comments to assist coverity in its scans to prevent false positives. Jake adds support for E822 devices to the driver. ==================== Signed-off-by:
-
- 04 Jan, 2020 6 commits
-
-
Jacob Keller authored
Add support for E822 devices Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
Bruce Allan <bruce.w.allan@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
-
Krzysztof Kazimierczak authored
Coverity reports some of the calls to xdp_rxq_info_reg() as potential issues, because the driver does not check its return value. However, those calls are wrapped with "if (!xdp_rxq_info_is_reg(&ring->xdp_rxq))" and this check alone is enough to be sure that the function will never fail. All possible states of xdp_rxq_info are: - NEW, - REGISTERED, - UNREGISTERED, - UNUSED. The driver won't mark a queue as UNUSED under no circumstance, so the return value can be ignored safely. Add comments for Coverity right above calls to xdp_rxq_info_reg() to suppress the warnings. Signed-off-by:
Krzysztof Kazimierczak <krzysztof.kazimierczak@intel.com> Tested-by:
-
Krzysztof Kazimierczak authored
In ice_xsk_umem(), variable qid which is later used as an array index, is not validated for a possible boundary exceedance. Because of that, a calling function might receive an invalid address, which causes general protection fault when dereferenced. To address this, add a boundary check to see if qid is greater than the size of a UMEM array. Also, don't let user change vsi->num_xsk_umems just by trying to setup a second UMEM if its value is already set up (i.e. UMEM region has already been allocated for this VSI). While at it, make sure that ring->zca.free pointer is always zeroed out if there is no UMEM on a specified ring. Signed-off-by:
-
Mitch Williams authored
In the case where the hardware gives us a null Rx descriptor, it is theoretically possible that we could call one of our skb-construction functions with no data pointer, which would cause a panic. In real life, this will never happen - we only get null RX descriptors as the final descriptor in a chain of otherwise-valid descriptors. When this happens, the skb will be extant and we'll just call ice_add_rx_frag(), which can deal with empty data buffers. Unfortunately, Coverity does not have intimate knowledge of our hardware, so we must add a check here. Signed-off-by:
Mitch Williams <mitch.a.williams@intel.com> Tested-by:
-
Bruce Allan authored
Coverity reports an error that is not really an error; suppress it. Signed-off-by:
-
Tony Nguyen authored
Following the changes of commit 12299132 ("net: ethernet: intel: Demote MTU change prints to debug"), change the MTU change message to netdev_dbg() Signed-off-by:
-
