- 13 May, 2016 12 commits
-
-
Jacob Keller authored
To prevent signed bitshift issues, and improve code readability, use the BIT() macro. Also make use of GENMASK or the unsigned postfix where this is more appropriate than BIT() Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Jacob Keller authored
The variable rdlen is set but never used, and thus setting it is dead code. Remove it. Signed-off-by:
-
Nathan Sullivan authored
Table 7-62 on page 338 of the i210 datasheet lists TX and RX latencies for the various speeds the chip supports. To give better PTP timestamp accuracy, adjust the timestamps by the amounts Intel gives based on current link speed. Signed-off-by:
Nathan Sullivan <nathan.sullivan@ni.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
-
Denys Vlasenko authored
SYSTIMH:SYSTIML registers are incremented by 24-bit value TIMINCA[23..0] er32(SYSTIML) are probably moderately expensive (they are pci bus reads). Can we avoid one of them? Yes, we can. If the SYSTIML value we see is smaller than 0xff000000, the overflow into SYSTIMH would require at least two increments. We do two reads, er32(SYSTIML) and er32(SYSTIMH), in this order. Even if one increment happens between them, the overflow into SYSTIMH is impossible, and we can avoid doing another er32(SYSTIML) read and overflow check. Signed-off-by:
Denys Vlasenko <dvlasenk@redhat.com> Tested-by:
-
Denys Vlasenko authored
If two consecutive reads of the counter are the same, it is also not an overflow. "systimel_1 < systimel_2" should be "systimel_1 <= systimel_2". Before the patch, we could perform an *erroneous* correction: Let's say that systimel_1 == systimel_2 == 0xffffffff. "systimel_1 < systimel_2" is false, we think it's an overflow, we read "systimeh = er32(SYSTIMH)" which meanwhile had incremented, and use "(systimeh << 32) + systimel_2" value which is 2^32 too large. Signed-off-by:
-
Denys Vlasenko authored
"incvalue" variable holds a result of "er32(TIMINCA) & E1000_TIMINCA_INCVALUE_MASK" and used in "do_div(temp, incvalue)" as a divisor. Thus, "u64 incvalue" declaration is probably a mistake. Even though it seems to be a harmless one, let's fix it. Signed-off-by:
-
Jacob Keller authored
Signed-off-by:
-
Jacob Keller authored
For bitshifts, we should make use of the BIT macro when possible, and ensure that other bitshifts are marked as unsigned. This helps prevent signed bitshift errors, and ensures similar style. Make use of GENMASK and the unsigned postfix where BIT() isn't appropriate. Signed-off-by:
-
Brian Walsh authored
Fixed the file to use a consistent ret_val for return value checking. Signed-off-by:
Brian Walsh <brian@walsh.ws> Tested-by:
-
Steve Shih authored
This patch fixes the issues for disabling auto-negotiation and forcing speed and duplex settings for the non-copper media. For non-copper media, e1000_get_settings should return ETH_TP_MDI_INVALID for eth_tp_mdix_ctrl instead of ETH_TP_MDI_AUTO so subsequent e1000_set_settings call would not fail with -EOPNOTSUPP. e1000_set_spd_dplx should not automatically turn autoneg back on for forced 1000 Mbps full duplex settings for non-copper media. Cc: xe-kernel@external.cisco.com Cc: Daniel Walker <dwalker@fifo99.com> Signed-off-by:
Steve Shih <sshih@cisco.com> Tested-by:
-
Alexander Duyck authored
While testing an OpenStack configuration using VXLANs I saw the following call trace: RIP: 0010:[<ffffffff815fad49>] udp4_lib_lookup_skb+0x49/0x80 RSP: 0018:ffff88103867bc50 EFLAGS: 00010286 RAX: ffff88103269bf00 RBX: ffff88103269bf00 RCX: 00000000ffffffff RDX: 0000000000004300 RSI: 0000000000000000 RDI: ffff880f2932e780 RBP: ffff88103867bc60 R08: 0000000000000000 R09: 000000009001a8c0 R10: 0000000000004400 R11: ffffffff81333a58 R12: ffff880f2932e794 R13: 0000000000000014 R14: 0000000000000014 R15: ffffe8efbfd89ca0 FS: 0000000000000000(0000) GS:ffff88103fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000488 CR3: 0000000001c06000 CR4: 00000000001426e0 Stack: ffffffff81576515 ffffffff815733c0 ffff88103867bc98 ffffffff815fcc17 ffff88103269bf00 ffffe8efbfd89ca0 0000000000000014 0000000000000080 ffffe8efbfd89ca0 ffff88103867bcc8 ffffffff815fcf8b ffff880f2932e794 Call Trace: [<ffffffff81576515>] ? skb_checksum+0x35/0x50 [<ffffffff815733c0>] ? skb_push+0x40/0x40 [<ffffffff815fcc17>] udp_gro_receive+0x57/0x130 [<ffffffff815fcf8b>] udp4_gro_receive+0x10b/0x2c0 [<ffffffff81605863>] inet_gro_receive+0x1d3/0x270 [<ffffffff81589e59>] dev_gro_receive+0x269/0x3b0 [<ffffffff8158a1b8>] napi_gro_receive+0x38/0x120 [<ffffffffa0871297>] gro_cell_poll+0x57/0x80 [vxlan] [<ffffffff815899d0>] net_rx_action+0x160/0x380 [<ffffffff816965c7>] __do_softirq+0xd7/0x2c5 [<ffffffff8107d969>] run_ksoftirqd+0x29/0x50 [<ffffffff8109a50f>] smpboot_thread_fn+0x10f/0x160 [<ffffffff8109a400>] ? sort_range+0x30/0x30 [<ffffffff81096da8>] kthread+0xd8/0xf0 [<ffffffff81693c82>] ret_from_fork+0x22/0x40 [<ffffffff81096cd0>] ? kthread_park+0x60/0x60 The following trace is seen when receiving a DHCP request over a flow-based VXLAN tunnel. I believe this is caused by the metadata dst having a NULL dev value and as a result dev_net(dev) is causing a NULL pointer dereference. To resolve this I am replacing the check for skb_dst(skb)->dev with just skb->dev. This makes sense as the callers of this function are usually in the receive path and as such skb->dev should always be populated. In addition other functions in the area where these are called are already using dev_net(skb->dev) to determine the namespace the UDP packet belongs in. Fixes: 63058308 ("udp: Add udp6_lib_lookup_skb and udp4_lib_lookup_skb") Signed-off-by:
Alexander Duyck <aduyck@mirantis.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
sunrpc is using SOCKWQ_ASYNC_NOSPACE without setting SOCK_FASYNC, so the recent optimizations done in sk_set_bit() and sk_clear_bit() broke it. There is still the risk that a subsequent sock_fasync() call would clear SOCK_FASYNC, but sunrpc does not use this yet. Fixes: 9317bb69 ("net: SOCKWQ_ASYNC_NOSPACE optimizations") Signed-off-by:
Jiri Pirko <jiri@resnulli.us> Reported-by:
Huang, Ying <ying.huang@intel.com> Tested-by:
-
- 12 May, 2016 28 commits
-
-
Jon Paul Maloy authored
When an ACTIVATE or data packet is received in a link in state ESTABLISHING, the link does not immediately change state to ESTABLISHED, but does instead return a LINK_UP event to the caller, which will execute the state change in a different lock context. This non-atomic approach incurs a low risk that we may have two LINK_UP events pending simultaneously for the same link, resulting in the final part of the setup procedure being executed twice. The only potential harm caused by this it that we may see two LINK_UP events issued to subsribers of the topology server, something that may cause confusion. This commit eliminates this risk by checking if the link is already up before proceeding with the second half of the setup. Signed-off-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
Fabio Estevam authored
Replace the hardcoded mask 0x00fffff0 with MICREL_PHY_ID_MASK for better readability. Suggested-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Haishuang Yan authored
When dealing with WCCP in gre6 tunnel, it sets the wrong tpi->protocol, that is, ETH_P_IP instead of ETH_P_IPV6 for the encapuslated traffic. Signed-off-by:
Haishuang Yan <yanhaishuang@cmss.chinamobile.com> Signed-off-by:
-
Haishuang Yan authored
Do not include attribute IFLA_GRE_TOS. Signed-off-by:
-
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 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:
-
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 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: -
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:
-
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:
-
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:
-
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: -
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:
-
Yuval Mintz authored
Allows the user to view the VF configuration by observing the PF's device. Signed-off-by:
-
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 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 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 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 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 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 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 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 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 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 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 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:
-
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:
-
