- 12 May, 2016 24 commits
-
-
Pablo Neira authored
This patch fixes a netns leak. Fixes: 93edb8c7 ("gtp: reload GTPv1 header after pskb_may_pull()") Reported-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Merge tag 'mac80211-next-for-davem-2016-05-12' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== Some more work for 4.7, notably: * completion and fixups of nla_put_64_64bit() work * remove a/b/g/n from wext nickname to avoid confusion with 11ac (which wouldn't even fit fully there due to string length restrictions) along with some other minor changes/cleanups. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Johannes Berg authored
When using RSS, frames might not be processed in the correct order, and thus AP_LINK_PS must be used; most likely with firmware keeping track of the powersave state, this is the case in iwlwifi now. In this case, the driver can use ieee80211_sta_ps_transition() to still have mac80211 manage powersave buffering. However, for U-APSD and PS-Poll this isn't sufficient. If the device can't manage that entirely on its own, mac80211's code should be used. To allow this, export two functions: ieee80211_sta_uapsd_trigger() and ieee80211_sta_pspoll(). Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
There's no harm in having drivers read the list, since they can use RCU protection or RTNL locking; allow this to not require each and every driver to also implement its own bookkeeping. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The devlist_mtx mutex was removed about two years ago, in favour of just using RTNL/RCU protection. Remove the comment still referencing it. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
This allows finding vendor IE from a specific vendor. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Sara Sharon authored
Some hardware (iwlwifi an example) de-aggregate AMSDUs and copy the IV as is to the generated MPDUs, so the same PN appears in multiple packets without being a replay attack. Allow driver to explicitly indicate that a frame is allowed to have the same PN as the previous frame. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
David Spinadel authored
In some cases, after a sudden AP disappearing and reconnection to another AP in the same ESS, user space gets the old AP in scan results (cached). User space may decide to roam to that old AP which will cause a disconnection and longer recovery. Remove APs that are probably out of range from BSS table. Signed-off-by: David Spinadel <david.spinadel@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
David S. Miller authored
Yuval Mintz says: ==================== qed*: Add SR-IOV support This patch adds SR-IOV support to qed/qede drivers, adding a new PCI device ID for a VF that is shared between all the various PFs that support IOV. This is quite a massive series - the first 7 parts of the series add the infrastructure of supporting vfs in qed - mainly adding support in a HW-based vf<->pf channel, as well as diverging all existing configuration flows based on the pf/vf decision. I.e., while PF-originated requests head directly to HW/FW, the VF requests first have to traverse to the PF which will perform the configuration. The 8th patch is the one that adds the support for the VF device in qede. The remaining 6 patches each adds some user-based API support related to VFs that can be used over the PF - forcing mac/vlan, changing speed, etc. Dave, Sorry in advance for the length of the series. Most of the bulk here is in the infrastructure patches that have to go together [or at least, it makes little sense to try splitting them up]. Please consider applying this to `net-next'. Thanks, Yuval Changes from previous revision: ------------------------------ - V2 - Replace aligned_u64 with regular u64; This was possible as the shared structures [between PF and VF] were already sufficiently padded as-is in the API, making this redundant. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
Device should be configured by default to VEB once VFs are active. This changes the configuration of both PFs' and VFs' vports into enabling tx-switching once sriov is enabled. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
Allows the user to view the VF configuration by observing the PF's device. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
Add support in `ndo_set_vf_spoofchk' for allowing PF control over its VF spoof-checking configuration. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
This adds support in 2 ndo that allow PF to tweak the VF's view of the link - `ndo_set_vf_link_state' to allow it a view independent of the PF's, and `ndo_set_vf_rate' which would allow the PF to limit the VF speed. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
Allows the PF to enforce the VF's mac. i.e., by using `ip link ... vf <x> mac <value>'. While a MAC is forced, PF would prevent the VF from configuring any other MAC. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
This adds support for PF control over the VF vlan configuration. I.e., `ip link ... vf <x> vlan <vid>' should now be supported. 1. <vid> != 0 => VF receives [unknowingly] only traffic tagged by <vid> and tags all outgoing traffic sent by VF with <vid>. 2. <vid> == 0 ==> Remove the pvid configuration, reverting to previous. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
Adding a PCI callback for `sriov_configure' and a new PCI device id for the VF [+ Some minor changes to accomodate differences between PF and VF at the qede]. Following this, VF creation should be possible and the entire subset of existing PF functionality that's allow to VFs should be supported. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
As the VF infrastructure is supposed to offer backward/forward compatibility, the various types associated with VF<->PF communication should be aligned across all various platforms that support IOV on our family of adapters. This adds a couple of currently missing values, specifically aligning the enum for the various TLVs possible in the communication between them. It then adds the PF implementation for some of those missing VF requests. This support isn't really necessary for the Linux VF as those VFs aren't requiring it [at least today], but are required by VFs running on other OSes. LRO is an example of one such configuration. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
Up to this point, VF and PF communication always originates from VF. As a result, VF cannot be notified of any async changes, and specifically cannot be informed of the current link state. This introduces the bulletin board, the mechanism through which the PF is going to communicate async notifications back to the VF. basically, it's a well-defined structure agreed by both PF and VF which the VF would continuously poll and into which the PF would DMA messages when needed. [Bulletin board is actually allocated and communicated in previous patches but never before used] Based on the bulletin infrastructure, the VF can query its link status and receive said async carrier changes. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
While previous patches have already added the necessary logic to probe VFs as well as enabling them in the HW, this patch adds the ability to support VF FLR & SRIOV disable. It then wraps both flows together into the first IOV callback to be provided to the protocol driver - `configure'. This would later to be used to enable and disable SRIOV in the adapter. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
Communication between VF and PF is based on a dedicated HW channel; VF will prepare a messge, and by signaling the HW the PF would get a notification of that message existance. The PF would then copy the message, process it and DMA an answer back to the VF as a response. The messages themselves are TLV-based - allowing easier backward/forward compatibility. This patch adds the infrastructure of the channel on the PF side - starting with the arrival of the notification and ending with DMAing the response back to the VF. It also adds a dummy-response as reference, as it only lays the groundwork of the communication; it doesn't really add support of any actual messages. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yuval Mintz authored
Add support for a new Kconfig option for qed* driver which would allow [eventually] the support in VFs. This patch adds the necessary logic in the PF to learn about the possible VFs it will have to support [Based on PCI configuration space and HW], and prepare a database with an entry per-VF as infrastructure for future interaction with said VFs. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-nextDavid S. Miller authored
Samuel Ortiz says: ==================== NFC 4.7 pull request This is the first NFC pull request for 4.7. With this one we mainly have: - Support for NXP's pn532 NFC chipset. The pn532 is based on the same microcontroller as the pn533, but it talks to the host through i2c instead of USB. By separating the pn533 driver into core and PHY parts, we can not add the i2c layer and support the pn532 chipset. - Support for NCI's loopback mode. This is a testing mode where each packet received by the NFCC is sent back to the DH, allowing the host to test that the controller can receive and send data. - A few ACPI related fixes for the STMicro drivers, in order to match the device tree naming scheme. - A bunch of cleanups for the st-nci and the st21nfca STMicro drivers. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 11 May, 2016 16 commits
-
-
David S. Miller authored
Saeed Mahameed says: ==================== Mellanox 100G mlx5 CQE compression Introducing ConnectX-4 CQE (Completion Queue Entry) compression feature for mlx5 etherent driver. CQE Compressing reduces PCI overhead by coalescing and compressing multiple CQEs into a single merged CQE. Successful compressing improves message rate especially for small packet traffic. CQE Compressing in details: Instead of writing full CQEs to memory, multiple almost identical CQEs are merged and compressed. Information that is shared between the CQEs is written once, regardless of the number of compressed CQEs. In addition, only the unique information (small amount of bytes compared to full CQE size) is written per CQE. CQE Compression Block: This block contains multiple compressed CQEs. CQE Compression Block contains a single copy of CQEs properties which are shared between all the compressed CQEs (called Title, see below) and multiple mini CQEs (CQEs in compressed form). Title: The Title holds information which is shared between all the compressed CQEs in the CQE Compression Block. In each Compression Block there is only a single Title regardless of the number of compressed CQEs. Mini CQE: A CQE in compressed form that holds some data needed to extract a single full CQE, for example 8 Bytes instead of 64 Bytes. The shared information between all compressed CQEs, which belong to the same CQE Compression Block called Title, is written once, and only the unique information in each compressed CQE, for example 8 bytes, is written per compressed CQE, called mini CQE. Since CQE Compression can add overhead to the software (CPU), it will be only enabled on "weak/slow" PCI slots, where it can actually help. Applied on top: c047c3b1 ('netfilter: conntrack: remove uninitialized shadow variable') ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Saeed Mahameed authored
We turn the feature ON, only for servers with PCI BW < MAX LINK BW, as it helps reducing PCI pressure on weak PCI slots, but it adds some software overhead. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tariq Toukan authored
Make the MPWQE/Striding RQ default configuration dynamic and not statically set at compile time. Now at driver load we set stride size and num strides dynamically. By default we use same values as before, but when CQE compression is enabled, we set larger stride size to benefit from CQE compression for larger packets. Signed-off-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tariq Toukan authored
CQE compression feature is meant to save PCIe bandwidth by compressing few CQEs into smaller amount of bytes on PCIe. CQE compression can be selectively enabled per CQ. By default is disabled for now and will be enabled later on. Signed-off-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Andrew Lunn says: ==================== More enabler patches for DSA probing The complete set of patches for the reworked DSA probing is too big to post as once. These subset contains some enablers which are easy to review. Eventually, the Marvell driver will instantiate its own internal MDIO bus, rather than have the framework do it, thus allows devices on the bus to be listed in the device tree. Initialize the main mutex as soon as it is created, to avoid lifetime issues with the mdio bus. A previous patch renamed all the DSA probe functions to make room for a true device probe. However the recent merging of all the Marvell switch drivers resulted in mv88e6xxx going back to the old probe name. Rename it again, so we can have a driver probe function. Add minimum support for the Marvell switch driver to probe as an MDIO device, as well as an DSA driver. Later patches will then register this device with the new DSA core framework. Move the GPIO reset code out of the DSA code. Different drivers may need different reset mechanisms, e.g. via a reset controller for memory mapped devices. Don't clutter up the core with this. Let each driver implement what it needs. master_dev is no longer needed in the switch drivers, since they have access to a device pointer from the probe function. Remove it. Let the switch parse the eeprom length from its one device tree node. This is required with the new binding when the central DSA platform device no longer exists. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
A switch can export an attached EEPROM using the standard ethtool API. However the switch itself cannot determine the size of the EEPROM, and multiple sizes are allowed. Thus a device tree property is supported to indicate the length of the EEPROM. Parse this property during device probe, and implement a callback function to retrieve it. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
The dsa_switch structure contains a dsa_chip_data member called pd. However in the rest of the code, pd is used for dsa_platform_data. This is confusing. Rename it cd, which is already often used in dsa.c and slave.c for this data type. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
The switch drivers only use the master_dev member for dev_info() messages. Now that the device is passed to the old style probe, and new style drivers are probed as true linux drivers, this is no longer needed. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
Resetting the switch is something the driver does, not the framework. So move the parsing of this property into the driver. There are no in kernel users of this property, so moving it does not break anything. There is however a board which will make use of this property making its way into the kernel. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
Allow Marvell switches to be mdio devices. Currently the driver just allocate the private structure and detects what device is on the bus. Later patches will make them register with the DSA framework. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
All other DSA drivers use _drv_ in there DSA probe function name, thus allowing for a true linux driver probe function to use the conventional name. Make mv88e6xxx fit this pattern. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
By initialising immediately it, we don't run the danger of using it before it is initialised. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vivien Didelot authored
Some switch models have a STU (per VLAN port state database). Add a new capability flag to switches info, instead of checking their family. Also if the 6165 family has an STU, it must have a VTU, so add the MV88E6XXX_FLAG_VTU to its family flags. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vivien Didelot authored
Both VTU and STU operations use the same routine to access their (common) data registers, with a different offset. Add VTU and STU specific read and write functions to the data registers to abstract the required offset. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
David Ahern says: ==================== net: vrf: Fixup PKTINFO to return enslaved device index Applications such as OSPF and BFD need the original ingress device not the VRF device; the latter can be derived from the former. To that end move the packet intercept from an rx handler that is invoked by __netif_receive_skb_core to the ipv4 and ipv6 receive processing. IPv6 already saves the skb_iif to the control buffer in ipv6_rcv. Since the skb->dev has not been switched the cb has the enslaved device. Make the same happen for IPv4 by adding the skb_iif to inet_skb_parm and set it in ipv4 code after clearing the skb control buffer similar to IPv6. From there the pktinfo can just pull it from cb with the PKTINFO_SKB_CB cast. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
David Ahern authored
Applications such as OSPF and BFD need the original ingress device not the VRF device; the latter can be derived from the former. To that end add the skb_iif to inet_skb_parm and set it in ipv4 code after clearing the skb control buffer similar to IPv6. From there the pktinfo can just pull it from cb with the PKTINFO_SKB_CB cast. The previous patch moving the skb->dev change to L3 means nothing else is needed for IPv6; it just works. Signed-off-by: David Ahern <dsa@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-