Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7 |
|
#
e9ad7a80 |
| 11-Dec-2023 |
Jacob Keller <jacob.e.keller@intel.com> |
e1000e: correct maximum frequency adjustment values
[ Upstream commit f1f6a6b1830a8f1dc92ee26fae76333f446b0663 ]
The e1000e driver supports hardware with a variety of different clock speeds, and th
e1000e: correct maximum frequency adjustment values
[ Upstream commit f1f6a6b1830a8f1dc92ee26fae76333f446b0663 ]
The e1000e driver supports hardware with a variety of different clock speeds, and thus a variety of different increment values used for programming its PTP hardware clock.
The values currently programmed in e1000e_ptp_init are incorrect. In particular, only two maximum adjustments are used: 24000000 - 1, and 600000000 - 1. These were originally intended to be used with the 96 MHz clock and the 25 MHz clock.
Both of these values are actually slightly too high. For the 96 MHz clock, the actual maximum value that can safely be programmed is 23,999,938. For the 25 MHz clock, the maximum value is 599,999,904.
Worse, several devices use a 24 MHz clock or a 38.4 MHz clock. These parts are incorrectly assigned one of either the 24million or 600million values. For the 24 MHz clock, this is not a significant issue: its current increment value can support an adjustment up to 7billion in the positive direction. However, the 38.4 KHz clock uses an increment value which can only support up to 230,769,157 before it starts overflowing.
To understand where these values come from, consider that frequency adjustments have the form of:
new_incval = base_incval + (base_incval * adjustment) / (unit of adjustment)
The maximum adjustment is reported in terms of parts per billion: new_incval = base_incval + (base_incval * adjustment) / 1 billion
The largest possible adjustment is thus given by the following: max_incval = base_incval + (base_incval * max_adj) / 1 billion
Re-arranging to solve for max_adj: max_adj = (max_incval - base_incval) * 1 billion / base_incval
We also need to ensure that negative adjustments cannot underflow. This can be achieved simply by ensuring max_adj is always less than 1 billion.
Introduce new macros in e1000.h codifying the maximum adjustment in PPB for each frequency given its associated increment values. Also clarify where these values come from by commenting about the above equations.
Replace the switch statement in e1000e_ptp_init with one which mirrors the increment value switch statement from e1000e_get_base_timinica. For each device, assign the appropriate maximum adjustment based on its frequency. Some parts can have one of two frequency modes as determined by E1000_TSYNCRXCTL_SYSCFI.
Since the new flow directly matches the assignments in e1000e_get_base_timinca, and uses well defined macro names, it is much easier to verify that the resulting maximum adjustments are correct. It also avoids difficult to parse construction such as the "hw->mac.type < e1000_phc_lpt", and the use of fallthrough which was especially confusing when combined with a conditional block.
Note that I believe the current increment value configuration used for 24MHz clocks is sub-par, as it leaves at least 3 extra bits available in the INCVALUE register. However, fixing that requires more careful review of the clock rate and associated values.
Reported-by: Trey Harrison <harrisondigitalmedia@gmail.com> Fixes: 68fe1d5da548 ("e1000e: Add Support for 38.4MHZ frequency") Fixes: d89777bf0e42 ("e1000e: add support for IEEE-1588 PTP") Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Naama Meir <naamax.meir@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58 |
|
#
db2d737d |
| 26-Jul-2022 |
Sasha Neftin <sasha.neftin@intel.com> |
e1000e: Separate MTP board type from ADP
We have the same LAN controller on different PCH's. Separate MTP board type from an ADP which will allow for specific fixes to be applied for MTP platforms.
e1000e: Separate MTP board type from ADP
We have the same LAN controller on different PCH's. Separate MTP board type from an ADP which will allow for specific fixes to be applied for MTP platforms.
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Naama Meir <naamax.meir@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
show more ...
|
Revision tags: v5.15.57 |
|
#
abab010f |
| 21-Jul-2022 |
Jacob Keller <jacob.e.keller@intel.com> |
e1000e: convert .adjfreq to .adjfine
The PTP implementation for the e1000e driver uses the older .adjfreq method. This method takes an adjustment in parts per billion. The newer .adjfine implementat
e1000e: convert .adjfreq to .adjfine
The PTP implementation for the e1000e driver uses the older .adjfreq method. This method takes an adjustment in parts per billion. The newer .adjfine implementation uses scaled_ppm. The use of scaled_ppm allows for finer grained adjustments and is preferred over using the older implementation.
Make use of mul_u64_u64_div_u64 in order to handle possible overflow of the multiplication used to calculate the desired adjustment to the hardware increment value.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Naama Meir <naamax.meir@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
show more ...
|
Revision tags: v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7 |
|
#
68defd52 |
| 07-Dec-2021 |
Sasha Neftin <sasha.neftin@intel.com> |
e1000e: Separate ADP board type from TGP
We have the same LAN controller on different PCH's. Separate ADP board type from a TGP which will allow for specific fixes to be applied for ADP platforms.
e1000e: Separate ADP board type from TGP
We have the same LAN controller on different PCH's. Separate ADP board type from a TGP which will allow for specific fixes to be applied for ADP platforms.
Suggested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com> Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Nechama Kraus <nechamax.kraus@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
show more ...
|
Revision tags: v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67 |
|
#
6042d434 |
| 17-Sep-2021 |
Hao Chen <chenhaoa@uniontech.com> |
net: e1000e: solve insmod 'Unknown symbol mutex_lock' error
After I turn on the CONFIG_LOCK_STAT=y, insmod e1000e.ko will report: [ 5.641579] e1000e: Unknown symbol mutex_lock (err -2) [ 90.775
net: e1000e: solve insmod 'Unknown symbol mutex_lock' error
After I turn on the CONFIG_LOCK_STAT=y, insmod e1000e.ko will report: [ 5.641579] e1000e: Unknown symbol mutex_lock (err -2) [ 90.775705] e1000e: Unknown symbol mutex_lock (err -2) [ 132.252339] e1000e: Unknown symbol mutex_lock (err -2)
This problem fixed after include <linux/mutex.h>.
Signed-off-by: Hao Chen <chenhaoa@uniontech.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
3b5fcdfa |
| 07-Dec-2021 |
Sasha Neftin <sasha.neftin@intel.com> |
e1000e: Separate ADP board type from TGP
commit 68defd528f94ed1cf11f49a75cc1875dccd781fa upstream.
We have the same LAN controller on different PCH's. Separate ADP board type from a TGP which will
e1000e: Separate ADP board type from TGP
commit 68defd528f94ed1cf11f49a75cc1875dccd781fa upstream.
We have the same LAN controller on different PCH's. Separate ADP board type from a TGP which will allow for specific fixes to be applied for ADP platforms.
Suggested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com> Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Nechama Kraus <nechamax.kraus@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
280db5d4 |
| 22-Sep-2021 |
Sasha Neftin <sasha.neftin@intel.com> |
e1000e: Separate TGP board type from SPT
We have the same LAN controller on different PCHs. Separate TGP board type from SPT which will allow for specific fixes to be applied for TGP platforms.
Sug
e1000e: Separate TGP board type from SPT
We have the same LAN controller on different PCHs. Separate TGP board type from SPT which will allow for specific fixes to be applied for TGP platforms.
Suggested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Mark Pearson <markpearson@lenovo.com> Tested-by: Nechama Kraus <nechamax.kraus@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
show more ...
|
Revision tags: v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
3c98cbf2 |
| 14-Dec-2020 |
Mario Limonciello <mario.limonciello@dell.com> |
e1000e: Export S0ix flags to ethtool
This flag can be used by an end user to disable S0ix flows on a buggy system or by an OEM for development purposes.
If you need this flag to be persisted across
e1000e: Export S0ix flags to ethtool
This flag can be used by an end user to disable S0ix flows on a buggy system or by an OEM for development purposes.
If you need this flag to be persisted across reboots, it's suggested to use a udev rule to call adjust it until the kernel could have your configuration in a disallow list.
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Yijun Shen <Yijun.shen@dell.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
show more ...
|
#
7c0681c2 |
| 14-Dec-2020 |
Mario Limonciello <mario.limonciello@dell.com> |
e1000e: Export S0ix flags to ethtool
[ Upstream commit 3c98cbf22a96c1b12f48c1b2a4680dfe5cb280f9 ]
This flag can be used by an end user to disable S0ix flows on a buggy system or by an OEM for devel
e1000e: Export S0ix flags to ethtool
[ Upstream commit 3c98cbf22a96c1b12f48c1b2a4680dfe5cb280f9 ]
This flag can be used by an end user to disable S0ix flows on a buggy system or by an OEM for development purposes.
If you need this flag to be persisted across reboots, it's suggested to use a udev rule to call adjust it until the kernel could have your configuration in a disallow list.
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Yijun Shen <Yijun.shen@dell.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7 |
|
#
34a2a3b8 |
| 29-May-2020 |
Jeff Kirsher <jeffrey.t.kirsher@intel.com> |
net/intel: remove driver versions from Intel drivers
As with other networking drivers, remove the unnecessary driver version from the Intel drivers. The ethtool driver information and module version
net/intel: remove driver versions from Intel drivers
As with other networking drivers, remove the unnecessary driver version from the Intel drivers. The ethtool driver information and module version will then report the kernel version instead.
For ixgbe, i40e and ice drivers, the driver passes the driver version to the firmware to confirm that we are up and running. So we now pass the value of UTS_RELEASE to the firmware. This adminq call is required per the HAS document. The Device then sends an indication to the BMC that the PF driver is present. This is done using Host NC Driver Status Indication in NC-SI Get Link command or via the Host Network Controller Driver Status Change AEN.
What the BMC may do with this information is implementation-dependent, but this is a standard NC-SI 1.1 command we honor per the HAS.
CC: Bruce Allan <bruce.w.allan@intel.com> CC: Jesse Brandeburg <jesse.brandeburg@intel.com> CC: Alek Loktionov <aleksandr.loktionov@intel.com> CC: Kevin Liedtke <kevin.d.liedtke@intel.com> CC: Aaron Rowden <aaron.f.rowden@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Co-developed-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
show more ...
|
Revision tags: v5.4.43, v5.4.42 |
|
#
d601afca |
| 14-May-2020 |
Punit Agrawal <punit1.agrawal@toshiba.co.jp> |
e1000e: Relax condition to trigger reset for ME workaround
It's an error if the value of the RX/TX tail descriptor does not match what was written. The error condition is true regardless the duratio
e1000e: Relax condition to trigger reset for ME workaround
It's an error if the value of the RX/TX tail descriptor does not match what was written. The error condition is true regardless the duration of the interference from ME. But the driver only performs the reset if E1000_ICH_FWSM_PCIM2PCI_COUNT (2000) iterations of 50us delay have transpired. The extra condition can lead to inconsistency between the state of hardware as expected by the driver.
Fix this by dropping the check for number of delay iterations.
While at it, also make __ew32_prepare() static as it's not used anywhere else.
CC: stable <stable@vger.kernel.org> Signed-off-by: Punit Agrawal <punit1.agrawal@toshiba.co.jp> Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
Revision tags: v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9 |
|
#
d5ad7a6a |
| 05-Jan-2020 |
Jeff Kirsher <jeffrey.t.kirsher@intel.com> |
e1000e: Revert "e1000e: Make watchdog use delayed work"
This reverts commit 59653e6497d16f7ac1d9db088f3959f57ee8c3db.
This is due to this commit causing driver crashes and connections to reset unex
e1000e: Revert "e1000e: Make watchdog use delayed work"
This reverts commit 59653e6497d16f7ac1d9db088f3959f57ee8c3db.
This is due to this commit causing driver crashes and connections to reset unexpectedly.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
show more ...
|
Revision tags: v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11 |
|
#
7ce2e76a |
| 27-Aug-2019 |
Krzysztof Wilczynski <kw@linux.com> |
PCI: Move ASPM declarations to linux/pci.h
Move ASPM definitions and function prototypes from include/linux/pci-aspm.h to include/linux/pci.h so users only need to include <linux/pci.h>:
PCIE_LIN
PCI: Move ASPM declarations to linux/pci.h
Move ASPM definitions and function prototypes from include/linux/pci-aspm.h to include/linux/pci.h so users only need to include <linux/pci.h>:
PCIE_LINK_STATE_L0S PCIE_LINK_STATE_L1 PCIE_LINK_STATE_CLKPM pci_disable_link_state() pci_disable_link_state_locked() pcie_no_aspm()
No functional changes intended.
Link: https://lore.kernel.org/r/20190827095620.11213-1-kw@linux.com Signed-off-by: Krzysztof Wilczynski <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
Revision tags: v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15 |
|
#
59653e64 |
| 22-Jun-2019 |
Detlev Casanova <detlev.casanova@gmail.com> |
e1000e: Make watchdog use delayed work
Use delayed work instead of timers to run the watchdog of the e1000e driver.
Simplify the code with one less middle function.
Signed-off-by: Detlev Casanova
e1000e: Make watchdog use delayed work
Use delayed work instead of timers to run the watchdog of the e1000e driver.
Simplify the code with one less middle function.
Signed-off-by: Detlev Casanova <detlev.casanova@gmail.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
Revision tags: v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18 |
|
#
98942d70 |
| 09-Nov-2018 |
Miroslav Lichvar <mlichvar@redhat.com> |
e1000e: extend PTP gettime function to read system clock
This adds support for the PTP_SYS_OFFSET_EXTENDED ioctl.
Cc: Richard Cochran <richardcochran@gmail.com> Cc: Jacob Keller <jacob.e.keller@int
e1000e: extend PTP gettime function to read system clock
This adds support for the PTP_SYS_OFFSET_EXTENDED ioctl.
Cc: Richard Cochran <richardcochran@gmail.com> Cc: Jacob Keller <jacob.e.keller@intel.com> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17 |
|
#
51dce24b |
| 26-Apr-2018 |
Jeff Kirsher <jeffrey.t.kirsher@intel.com> |
net: intel: Cleanup the copyright/license headers
After many years of having a ~30 line copyright and license header to our source files, we are finally able to reduce that to one line with the adve
net: intel: Cleanup the copyright/license headers
After many years of having a ~30 line copyright and license header to our source files, we are finally able to reduce that to one line with the advent of the SPDX identifier.
Also caught a few files missing the SPDX license identifier, so fixed them up.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Acked-by: Shannon Nelson <shannon.nelson@oracle.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v4.16 |
|
#
ae06c70b |
| 22-Mar-2018 |
Jeff Kirsher <jeffrey.t.kirsher@intel.com> |
intel: add SPDX identifiers to all the Intel drivers
Add the SPDX identifiers to all the Intel wired LAN driver files, as outlined in Documentation/process/license-rules.rst.
Signed-off-by: Jeff Ki
intel: add SPDX identifiers to all the Intel drivers
Add the SPDX identifiers to all the Intel wired LAN driver files, as outlined in Documentation/process/license-rules.rst.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v4.15, v4.13.16, v4.14, v4.13.5, v4.13 |
|
#
48072ae1 |
| 25-Aug-2017 |
Willem de Bruijn <willemb@google.com> |
e1000e: apply burst mode settings only on default
Devices that support FLAG2_DMA_BURST have different default values for RDTR and RADV. Apply burst mode default settings only when no explicit value
e1000e: apply burst mode settings only on default
Devices that support FLAG2_DMA_BURST have different default values for RDTR and RADV. Apply burst mode default settings only when no explicit value was passed at module load.
The RDTR default is zero. If the module is loaded for low latency operation with RxIntDelay=0, do not override this value with a burst default of 32.
Move the decision to apply burst values earlier, where explicitly initialized module variables can be distinguished from defaults.
Signed-off-by: Willem de Bruijn <willemb@google.com> Acked-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
Revision tags: v4.12, v4.10.17, v4.10.16, v4.10.15 |
|
#
cff57141 |
| 03-May-2017 |
Jacob Keller <jacob.e.keller@intel.com> |
e1000e: add statistic indicating number of skipped Tx timestamps
The e1000e driver can only handle one Tx timestamp request at a time. This means it is possible for an application timestamp request
e1000e: add statistic indicating number of skipped Tx timestamps
The e1000e driver can only handle one Tx timestamp request at a time. This means it is possible for an application timestamp request to be ignored.
There is no easy way for an administrator to determine if this occurred. Add a new statistic which tracks this, tx_hwtstamp_skipped.
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>
show more ...
|
Revision tags: v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9 |
|
#
68fe1d5d |
| 06-Apr-2017 |
Sasha Neftin <sasha.neftin@intel.com> |
e1000e: Add Support for 38.4MHZ frequency
Add support for 38.4MHz frequency is required for PTP on CannonLake. SYSTIM frequency adjustment attributes for TIMINCA are get/set dependent on the hardwar
e1000e: Add Support for 38.4MHZ frequency
Add support for 38.4MHz frequency is required for PTP on CannonLake. SYSTIM frequency adjustment attributes for TIMINCA are get/set dependent on the hardware clock frequency for a different types of adapters. 38.4MHz frequency supported by CannonLake and active once time synchronisation mechanism was enabled Changed abbreviation from Hz to HZ to be compliant checkpatch code style
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Reviewed-by: Raanan Avargil <raanan.avargil@intel.com> Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
#
3a3173b9 |
| 06-Apr-2017 |
Sasha Neftin <sasha.neftin@intel.com> |
e1000e: Initial Support for CannonLake
i219 (6) and i219 (7) are the next LOM generations that will be available on the nextIntel Client platform (CannonLake) This patch provides the initial support
e1000e: Initial Support for CannonLake
i219 (6) and i219 (7) are the next LOM generations that will be available on the nextIntel Client platform (CannonLake) This patch provides the initial support for these devices
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Reviewed-by: Raanan Avargil <raanan.avargil@intel.com> Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
Revision tags: v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10 |
|
#
bc1f4470 |
| 06-Jan-2017 |
stephen hemminger <stephen@networkplumber.org> |
net: make ndo_get_stats64 a void function
The network device operation for reading statistics is only called in one place, and it ignores the return value. Having a structure return value is potenti
net: make ndo_get_stats64 a void function
The network device operation for reading statistics is only called in one place, and it ignores the return value. Having a structure return value is potentially confusing because some future driver could incorrectly assume that the return value was used.
Fix all drivers with ndo_get_stats64 to have a void function.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6, v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16 |
|
#
0be5b96c |
| 26-Jul-2016 |
Jarod Wilson <jarod@redhat.com> |
e1000e: factor out systim sanitization
This is prepatory work for an expanding list of adapter families that have occasional ~10 hour clock jumps when being used for PTP. Factor out the sanitization
e1000e: factor out systim sanitization
This is prepatory work for an expanding list of adapter families that have occasional ~10 hour clock jumps when being used for PTP. Factor out the sanitization function and convert to using a feature (bug) flag, per suggestion from Jesse Brandeburg.
Littering functional code with device-specific checks is much messier than simply checking a flag, and having device-specific init set flags as needed. There are probably a number of other cases in the e1000e code that could/should be converted similarly.
Suggested-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jarod Wilson <jarod@redhat.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
Revision tags: v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4, v4.6.3, v4.4.14, v4.6.2, v4.4.13, openbmc-20160606-1, v4.6.1, v4.4.12, openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9 |
|
#
aa524b66 |
| 20-Apr-2016 |
Jacob Keller <jacob.e.keller@intel.com> |
e1000e: don't modify SYSTIM registers during SIOCSHWTSTAMP ioctl
The e1000e_config_hwtstamp function was incorrectly resetting the SYSTIM registers every time the ioctl was being run. If you happene
e1000e: don't modify SYSTIM registers during SIOCSHWTSTAMP ioctl
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: Brian Walsh <brian@walsh.ws> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|
Revision tags: v4.4.8 |
|
#
18dd2392 |
| 13-Apr-2016 |
Jacob Keller <jacob.e.keller@intel.com> |
e1000e: use BIT() macro for bit defines
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
e1000e: use BIT() macro for bit defines
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 <jacob.e.keller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
show more ...
|