- May 15, 2016
-
-
Michael Chan authored
The len value in the hwrm error message is wrong. Use the properly adjusted value in the variable len. Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Michael Chan authored
The current code has 2 problems: 1. The maximum wait time is not long enough. It is about 60% of the duration specified by the firmware. It is calling usleep_range(600, 800) for every 1 msec we are supposed to wait. 2. The granularity of the delay is too coarse. Many simple firmware commands finish in 25 usec or less. We fix these 2 issues by multiplying the original 1 msec loop counter by 40 and calling usleep_range(25, 40) for each iteration. There is also a second delay loop to wait for the last DMA word to complete. This delay loop should be a very short 5 usec wait. This change results in much faster bring-up/down time: Before the patch: time ip link set p4p1 up real 0m0.120s user 0m0.001s sys 0m0.009s After the patch: time ip link set p4p1 up real 0m0.030s user 0m0.000s sys 0m0.010s Signed-off-by:
-
Michael Chan authored
The chip supports 4K/8K/64K page sizes for the rings and we try to match it to the CPU PAGE_SIZE. The current page size limits for the rings are based on 4K/8K page size. If the page size is 64K, these limits are too large. Reduce them appropriately. Signed-off-by:
-
Ajit Khaparde authored
Add code to log a message during driver load indicating PCIe link speed and width. The log message will look like this: bnxt_en 0000:86:00.0 eth0: PCIe: Speed 8.0GT/s Width x8 Signed-off-by:
Ajit Khaparde <ajit.khaparde@broadcom.com> Signed-off-by:
-
Ajit Khaparde authored
Add support to fetch the SFP EEPROM settings from the firmware and display it via the ethtool -m command. We support SFP+ and QSFP modules. v2: Fixed a bug in bnxt_get_module_eeprom() found by Ben Hutchings. Signed-off-by:
-
Satish Baddipadige authored
When there is only 1 MSI-X vector or in INTA mode, tx and rx pre-set max channel parameters are shown incorrectly in ethtool -l. With only 1 vector, bnxt_get_max_rings() will return -ENOMEM. bnxt_get_channels should check this return value, and set max_rx/max_tx to 0 if it is non-zero. Signed-off-by:
Satish Baddipadige <sbaddipa@broadcom.com> Signed-off-by:
-
- May 14, 2016
-
-
Iyappan Subramanian authored
This patch fixes SG_RX_DV_GATE_REG_0_ADDR register offset and ring state field lengths. Signed-off-by:
Iyappan Subramanian <isubramanian@apm.com> Tested-by:
Toan Le <toanle@apm.com> Signed-off-by:
-
Iyappan Subramanian authored
This patch fixes the race condition on updating the statistics counters by moving the counters to the ring structure. Signed-off-by:
-
Iyappan Subramanian authored
This patch addresses ununiform latency across queues by adding more queues to match with, upto number of CPU cores. Also, number of interrupts are increased and the channel numbers are reordered. Signed-off-by:
-
Iyappan Subramanian authored
Since hardware doesn't allow sharing of interrupts, this patch fixes the same by removing IRQF_SHARED flag. Signed-off-by:
-
Iyappan Subramanian authored
This patch fixes the crash observed during IPv4 forward test by setting the drop field in the dbptr. Signed-off-by:
-
- May 13, 2016
-
-
Jacob Keller authored
The e1000e_config_hwtstamp function was incorrectly resetting the SYSTIM registers every time the ioctl was being run. If you happened to be running ptp4l and lost the PTP connect (removing cable, or blocking the UDP traffic for example), then ptp4l will eventually perform a restart which involves re-requesting timestamp settings. In e1000e this has the unfortunate and incorrect result of resetting SYSTIME to the kernel time. Since kernel time is usually in UTC, and PTP time is in TAI, this results in the leap second being re-applied. Fix this by extracting the SYSTIME reset out into its own function, e1000e_ptp_reset, which we call during reset to restore the hardware registers. This function will (a) restart the timecounter based on the new system time, (b) restore the previous PPB setting, and (c) restore the previous hwtstamp settings. In order to perform (b), I had to modify the adjfreq ptp function pointer to store the old delta each time it is called. This also has the side effect of restoring the correct base timinca register correctly. The driver does not need to explicitly zero the ptp_delta variable since the entire adapter structure comes zero-initialized. Reported-by:
Brian Walsh <brian@walsh.ws> Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Alexander Duyck authored
This patch adds support for partial GSO segmentation in the case of tunnels. Specifically with this change the driver an perform segmentation as long as the frame either has IPv6 inner headers, or we are allowed to mangle the IP IDs on the inner header. This is needed because we will not be modifying any fields from the start of the start of the outer transport header to the start of the inner transport header as we are treating them like they are just a block of IP options. Signed-off-by:
Alexander Duyck <aduyck@mirantis.com> Tested-by:
-
Jacob Keller authored
The E1000_ICH_NVM_SIG_MASK value is shifted, out to the 31st bit, which is the signed bit for signed constants. Mark these values as unsigned to prevent compiler warnings and issues on platforms which a different signed bit implementation. Signed-off-by:
-
Jacob Keller authored
This prevents signed bitshift issues when the shift would overwrite the signed bit, and prevents making this mistake in the future when copying and modifying code. Use GENMASK or the unsigned postfix for cases which aren't suitable for BIT() macro. Signed-off-by:
-
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 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:
-
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:
-
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:
-
Paul Durrant authored
Patch 562abd39 "xen-netback: support multiple extra info fragments passed from frontend" contained a mistake which can result in an in- correct number of responses being generated when handling errors encountered when processing packets containing extra info fragments. This patch fixes the problem. Signed-off-by:
Paul Durrant <paul.durrant@citrix.com> Reported-by:
Jan Beulich <JBeulich@suse.com> Cc: Wei Liu <wei.liu2@citrix.com> Acked-by:
Wei Liu <wei.liu2@citrix.com> Signed-off-by:
-
- May 12, 2016
-
-
Arnd Bergmann authored
I tried to fix this before, but my previous fix was incomplete and we can still get the same link error in randconfig builds because of the way that Kconfig treats the default y if MVNETA=y && MVNETA_BM_ENABLE line that does not actually trigger when MVNETA_BM_ENABLE=m, unlike I intended. Changing the line to use MVNETA_BM_ENABLE!=n however has the desired effect and hopefully makes all configurations work as expected. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 019ded3a ("net: mvneta: bm: clarify dependencies") Acked-by:
Gregory CLEMENT <gregory.clement@free-electrons.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:
-
Alex Deucher authored
Switch the order of the loops to walk the rates on the top so we exhaust all DP 1.1 rate/lane combinations before trying DP 1.2 rate/lane combos. This avoids selecting rates that are supported by the monitor, but not the connector leading to valid modes getting rejected. bug: https://bugs.freedesktop.org/show_bug.cgi?id=95206 Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Alex Deucher authored
Switch the order of the loops to walk the rates on the top so we exhaust all DP 1.1 rate/lane combinations before trying DP 1.2 rate/lane combos. This avoids selecting rates that are supported by the monitor, but not the connector leading to valid modes getting rejected. bug: https://bugs.freedesktop.org/show_bug.cgi?id=95206 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:
-
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:
-
