Re: [Intel-wired-lan] [PATCH iwl-next v7 01/12] virtchnl: add support for enabling PTP on iAVF
On Tue, Jun 04, 2024 at 09:13:49AM -0400, Mateusz Polchlopek wrote: > From: Jacob Keller > > Add support for allowing a VF to enable PTP feature - Rx timestamps > > The new capability is gated by VIRTCHNL_VF_CAP_PTP, which must be > set by the VF to request access to the new operations. In addition, the > VIRTCHNL_OP_1588_PTP_CAPS command is used to determine the specific > capabilities available to the VF. > > This support includes the following additional capabilities: > > * Rx timestamps enabled in the Rx queues (when using flexible advanced > descriptors) > * Read access to PHC time over virtchnl using > VIRTCHNL_OP_1588_PTP_GET_TIME > > Extra space is reserved in most structures to allow for future > extension (like set clock, Tx timestamps). Additional opcode numbers > are reserved and space in the virtchnl_ptp_caps structure is > specifically set aside for this. > Additionally, each structure has some space reserved for future > extensions to allow some flexibility. > > Signed-off-by: Jacob Keller > Reviewed-by: Wojciech Drewek > Reviewed-by: Rahul Rameshbabu > Signed-off-by: Mateusz Polchlopek Hi Mateusz, Jacob, all, If you need to respin this for some reason, please consider updating the Kernel doc for the following to include a short description. Else, please consider doing so as a follow-up * struct virtchnl_ptp_caps * struct virtchnl_phc_time Likewise as a follow-up, as it was not introduced by this patch, for: * virtchnl_vc_validate_vf_msg Flagged by kernel-doc -none -Wall The above not withstanding, this looks good to me. Reviewed-by: Simon Horman ...
Re: [Intel-wired-lan] [PATCH iwl-next v7 04/12] iavf: add support for negotiating flexible RXDID format
On Tue, Jun 04, 2024 at 09:13:52AM -0400, Mateusz Polchlopek wrote:
> From: Jacob Keller
>
> Enable support for VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC, to enable the VF
> driver the ability to determine what Rx descriptor formats are
> available. This requires sending an additional message during
> initialization and reset, the VIRTCHNL_OP_GET_SUPPORTED_RXDIDS. This
> operation requests the supported Rx descriptor IDs available from the
> PF.
>
> This is treated the same way that VLAN V2 capabilities are handled. Add
> a new set of extended capability flags, used to process send and receipt
> of the VIRTCHNL_OP_GET_SUPPORTED_RXDIDS message.
>
> This ensures we finish negotiating for the supported descriptor formats
> prior to beginning configuration of receive queues.
>
> This change stores the supported format bitmap into the iavf_adapter
> structure. Additionally, if VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC is enabled
> by the PF, we need to make sure that the Rx queue configuration
> specifies the format.
>
> Signed-off-by: Jacob Keller
> Reviewed-by: Wojciech Drewek
> Co-developed-by: Mateusz Polchlopek
> Signed-off-by: Mateusz Polchlopek
Hi Mateusz, Jacob, all,
The nit below notwithstanding, this looks good to me.
Reviewed-by: Simon Horman
...
> @@ -262,6 +276,45 @@ int iavf_get_vf_vlan_v2_caps(struct iavf_adapter
> *adapter)
> return err;
> }
>
> +int iavf_get_vf_supported_rxdids(struct iavf_adapter *adapter)
> +{
> + struct iavf_hw *hw = &adapter->hw;
> + struct iavf_arq_event_info event;
> + enum virtchnl_ops op;
> + enum iavf_status err;
> + u16 len;
> +
> + len = sizeof(struct virtchnl_supported_rxdids);
> + event.buf_len = len;
> + event.msg_buf = kzalloc(event.buf_len, GFP_KERNEL);
> + if (!event.msg_buf) {
> + err = -ENOMEM;
> + goto out;
> + }
> +
> + while (1) {
> + /* When the AQ is empty, iavf_clean_arq_element will return
> + * nonzero and this loop will terminate.
> + */
> + err = iavf_clean_arq_element(hw, &event, NULL);
> + if (err != IAVF_SUCCESS)
> + goto out_alloc;
> + op = (enum virtchnl_ops)le32_to_cpu(event.desc.cookie_high);
> + if (op == VIRTCHNL_OP_GET_SUPPORTED_RXDIDS)
> + break;
> + }
> +
> + err = (enum iavf_status)le32_to_cpu(event.desc.cookie_low);
> + if (err)
> + goto out_alloc;
> +
> + memcpy(&adapter->supported_rxdids, event.msg_buf, min(event.msg_len,
> len));
If you need to respin for some other reason,
please consider wrapping the above to <= 80 columns wide.
Likewise for the 2nd call to iavf_ptp_cap_supported() in
iavf_ptp_process_caps() in
[PATCH v7 06/12] iavf: add initial framework for registering PTP clock
Flagged by: checkpatch.pl --max-line-length=80
> +out_alloc:
> + kfree(event.msg_buf);
> +out:
> + return err;
> +}
> +
> /**
> * iavf_configure_queues
> * @adapter: adapter structure
...
Re: [Intel-wired-lan] [PATCH iwl-next v7 02/12] ice: support Rx timestamp on flex descriptor
On Tue, Jun 04, 2024 at 09:13:50AM -0400, Mateusz Polchlopek wrote: > From: Simei Su > > To support Rx timestamp offload, VIRTCHNL_OP_1588_PTP_CAPS is sent by > the VF to request PTP capability and responded by the PF what capability > is enabled for that VF. > > Hardware captures timestamps which contain only 32 bits of nominal > nanoseconds, as opposed to the 64bit timestamps that the stack expects. > To convert 32b to 64b, we need a current PHC time. > VIRTCHNL_OP_1588_PTP_GET_TIME is sent by the VF and responded by the > PF with the current PHC time. > > Signed-off-by: Simei Su > Reviewed-by: Wojciech Drewek > Co-developed-by: Mateusz Polchlopek > Signed-off-by: Mateusz Polchlopek Reviewed-by: Simon Horman
Re: [Intel-wired-lan] [PATCH iwl-next v7 03/12] virtchnl: add enumeration for the rxdid format
On Tue, Jun 04, 2024 at 09:13:51AM -0400, Mateusz Polchlopek wrote: > From: Jacob Keller > > Support for allowing VF to negotiate the descriptor format requires that > the VF specify which descriptor format to use when requesting Rx queues. > The VF is supposed to request the set of supported formats via the new > VIRTCHNL_OP_GET_SUPPORTED_RXDIDS, and then set one of the supported > formats in the rxdid field of the virtchnl_rxq_info structure. > > The virtchnl.h header does not provide an enumeration of the format > values. The existing implementations in the PF directly use the values > from the DDP package. > > Make the formats explicit by defining an enumeration of the RXDIDs. > Provide an enumeration for the values as well as the bit positions as > returned by the supported_rxdids data from the > VIRTCHNL_OP_GET_SUPPORTED_RXDIDS. > > Signed-off-by: Jacob Keller > Reviewed-by: Wojciech Drewek > Reviewed-by: Rahul Rameshbabu > Signed-off-by: Mateusz Polchlopek Reviewed-by: Simon Horman
Re: [Intel-wired-lan] [PATCH iwl-next v7 04/12] iavf: add support for negotiating flexible RXDID format
On Tue, Jun 04, 2024 at 09:13:52AM -0400, Mateusz Polchlopek wrote: > From: Jacob Keller > > Enable support for VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC, to enable the VF > driver the ability to determine what Rx descriptor formats are > available. This requires sending an additional message during > initialization and reset, the VIRTCHNL_OP_GET_SUPPORTED_RXDIDS. This > operation requests the supported Rx descriptor IDs available from the > PF. > > This is treated the same way that VLAN V2 capabilities are handled. Add > a new set of extended capability flags, used to process send and receipt > of the VIRTCHNL_OP_GET_SUPPORTED_RXDIDS message. > > This ensures we finish negotiating for the supported descriptor formats > prior to beginning configuration of receive queues. > > This change stores the supported format bitmap into the iavf_adapter > structure. Additionally, if VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC is enabled > by the PF, we need to make sure that the Rx queue configuration > specifies the format. > > Signed-off-by: Jacob Keller > Reviewed-by: Wojciech Drewek > Co-developed-by: Mateusz Polchlopek > Signed-off-by: Mateusz Polchlopek Reviewed-by: Simon Horman
Re: [Intel-wired-lan] [PATCH iwl-next v7 05/12] iavf: negotiate PTP capabilities
On Tue, Jun 04, 2024 at 09:13:53AM -0400, Mateusz Polchlopek wrote: > From: Jacob Keller > > Add a new extended capabilities negotiation to exchange information from > the PF about what PTP capabilities are supported by this VF. This > requires sending a VIRTCHNL_OP_1588_PTP_GET_CAPS message, and waiting > for the response from the PF. Handle this early on during the VF > initialization. > > Signed-off-by: Jacob Keller > Reviewed-by: Wojciech Drewek > Co-developed-by: Mateusz Polchlopek > Signed-off-by: Mateusz Polchlopek Reviewed-by: Simon Horman
Re: [Intel-wired-lan] [PATCH iwl-next v7 06/12] iavf: add initial framework for registering PTP clock
On Tue, Jun 04, 2024 at 09:13:54AM -0400, Mateusz Polchlopek wrote: > From: Jacob Keller > > Add the iavf_ptp.c file and fill it in with a skeleton framework to > allow registering the PTP clock device. > Add implementation of helper functions to check if a PTP capability > is supported and handle change in PTP capabilities. > Enabling virtual clock would be possible, though it would probably > perform poorly due to the lack of direct time access. > > Signed-off-by: Jacob Keller > Reviewed-by: Wojciech Drewek > Reviewed-by: Sai Krishna > Co-developed-by: Ahmed Zaki > Signed-off-by: Ahmed Zaki > Co-developed-by: Mateusz Polchlopek > Signed-off-by: Mateusz Polchlopek Reviewed-by: Simon Horman
Re: [Intel-wired-lan] [PATCH iwl-next v7 07/12] iavf: add support for indirect access to PHC time
On Tue, Jun 04, 2024 at 09:13:55AM -0400, Mateusz Polchlopek wrote: > From: Jacob Keller > > Implement support for reading the PHC time indirectly via the > VIRTCHNL_OP_1588_PTP_GET_TIME operation. > > Based on some simple tests with ftrace, the latency of the indirect > clock access appears to be about ~110 microseconds. This is due to the > cost of preparing a message to send over the virtchnl queue. > > This is expected, due to the increased jitter caused by sending messages > over virtchnl. It is not easy to control the precise time that the > message is sent by the VF, or the time that the message is responded to > by the PF, or the time that the message sent from the PF is received by > the VF. > > For sending the request, note that many PTP related operations will > require sending of VIRTCHNL messages. Instead of adding a separate AQ > flag and storage for each operation, setup a simple queue mechanism for > queuing up virtchnl messages. > > Each message will be converted to a iavf_ptp_aq_cmd structure which ends > with a flexible array member. A single AQ flag is added for processing > messages from this queue. In principle this could be extended to handle > arbitrary virtchnl messages. For now it is kept to PTP-specific as the > need is primarily for handling PTP-related commands. > > Use this to implement .gettimex64 using the indirect method via the > virtchnl command. The response from the PF is processed and stored into > the cached_phc_time. A wait queue is used to allow the PTP clock gettime > request to sleep until the message is sent from the PF. > > Signed-off-by: Jacob Keller > Reviewed-by: Wojciech Drewek > Reviewed-by: Rahul Rameshbabu > Signed-off-by: Mateusz Polchlopek Reviewed-by: Simon Horman
Re: [Intel-wired-lan] [PATCH iwl-next v7 08/12] iavf: periodically cache PHC time
On Tue, Jun 04, 2024 at 09:13:56AM -0400, Mateusz Polchlopek wrote: > From: Jacob Keller > > The Rx timestamps reported by hardware may only have 32 bits of storage > for nanosecond time. These timestamps cannot be directly reported to the > Linux stack, as it expects 64bits of time. > > To handle this, the timestamps must be extended using an algorithm that > calculates the corrected 64bit timestamp by comparison between the PHC > time and the timestamp. This algorithm requires the PHC time to be > captured within ~2 seconds of when the timestamp was captured. > > Instead of trying to read the PHC time in the Rx hotpath, the algorithm > relies on a cached value that is periodically updated. > > Keep this cached time up to date by using the PTP .do_aux_work kthread > function. > > The iavf_ptp_do_aux_work will reschedule itself about twice a second, > and will check whether or not the cached PTP time needs to be updated. > If so, it issues a VIRTCHNL_OP_1588_PTP_GET_TIME to request the time > from the PF. The jitter and latency involved with this command aren't > important, because the cached time just needs to be kept up to date > within about ~2 seconds. > > Signed-off-by: Jacob Keller > Reviewed-by: Wojciech Drewek > Co-developed-by: Mateusz Polchlopek > Signed-off-by: Mateusz Polchlopek Reviewed-by: Simon Horman
Re: [Intel-wired-lan] [PATCH iwl-next v7 09/12] iavf: refactor iavf_clean_rx_irq to support legacy and flex descriptors
On Tue, Jun 04, 2024 at 09:13:57AM -0400, Mateusz Polchlopek wrote: > From: Jacob Keller > > Using VIRTCHNL_VF_OFFLOAD_FLEX_DESC, the iAVF driver is capable of > negotiating to enable the advanced flexible descriptor layout. Add the > flexible NIC layout (RXDID=2) as a member of the Rx descriptor union. > > Also add bit position definitions for the status and error indications > that are needed. > > The iavf_clean_rx_irq function needs to extract a few fields from the Rx > descriptor, including the size, rx_ptype, and vlan_tag. > Move the extraction to a separate function that decodes the fields into > a structure. This will reduce the burden for handling multiple > descriptor types by keeping the relevant extraction logic in one place. > > To support handling an additional descriptor format with minimal code > duplication, refactor Rx checksum handling so that the general logic > is separated from the bit calculations. Introduce an iavf_rx_desc_decoded > structure which holds the relevant bits decoded from the Rx descriptor. > This will enable implementing flexible descriptor handling without > duplicating the general logic twice. > > Introduce an iavf_extract_flex_rx_fields, iavf_flex_rx_hash, and > iavf_flex_rx_csum functions which operate on the flexible NIC descriptor > format instead of the legacy 32 byte format. Based on the negotiated > RXDID, select the correct function for processing the Rx descriptors. > > With this change, the Rx hot path should be functional when using either > the default legacy 32byte format or when we switch to the flexible NIC > layout. > > Modify the Rx hot path to add support for the flexible descriptor > format and add request enabling Rx timestamps for all queues. > > As in ice, make sure we bump the checksum level if the hardware detected > a packet type which could have an outer checksum. This is important > because hardware only verifies the inner checksum. > > Signed-off-by: Jacob Keller > Reviewed-by: Wojciech Drewek > Co-developed-by: Mateusz Polchlopek > Signed-off-by: Mateusz Polchlopek Reviewed-by: Simon Horman
Re: [Intel-wired-lan] [PATCH iwl-next v7 10/12] iavf: Implement checking DD desc field
On Tue, Jun 04, 2024 at 09:13:58AM -0400, Mateusz Polchlopek wrote: > Rx timestamping introduced in PF driver caused the need of refactoring > the VF driver mechanism to check packet fields. > > The function to check errors in descriptor has been removed and from > now only previously set struct fields are being checked. The field DD > (descriptor done) needs to be checked at the very beginning, before > extracting other fields. > > Signed-off-by: Mateusz Polchlopek > Reviewed-by: Wojciech Drewek > Reviewed-by: Rahul Rameshbabu Reviewed-by: Simon Horman
Re: [Intel-wired-lan] [PATCH iwl-next v7 11/12] iavf: handle set and get timestamps ops
On Tue, Jun 04, 2024 at 09:13:59AM -0400, Mateusz Polchlopek wrote: > From: Jacob Keller > > Add handlers for the .ndo_hwtstamp_get and .ndo_hwtstamp_set ops which allow > userspace to request timestamp enablement for the device. This support allows > standard Linux applications to request the timestamping desired. > > As with other devices that support timestamping all packets, the driver > will upgrade any request for timestamping of a specific type of packet > to HWTSTAMP_FILTER_ALL. > > The current configuration is stored, so that it can be retrieved by > calling .ndo_hwtstamp_get > > The Tx timestamps are not implemented yet so calling set ops for > Tx path will end with EOPNOTSUPP error code. > > Signed-off-by: Jacob Keller > Reviewed-by: Wojciech Drewek > Reviewed-by: Rahul Rameshbabu > Co-developed-by: Mateusz Polchlopek > Signed-off-by: Mateusz Polchlopek Reviewed-by: Simon Horman
Re: [Intel-wired-lan] [PATCH iwl-next v7 12/12] iavf: add support for Rx timestamps to hotpath
On Tue, Jun 04, 2024 at 09:14:00AM -0400, Mateusz Polchlopek wrote: > From: Jacob Keller > > Add support for receive timestamps to the Rx hotpath. This support only > works when using the flexible descriptor format, so make sure that we > request this format by default if we have receive timestamp support > available in the PTP capabilities. > > In order to report the timestamps to userspace, we need to perform > timestamp extension. The Rx descriptor does actually contain the "40 > bit" timestamp. However, upper 32 bits which contain nanoseconds are > conveniently stored separately in the descriptor. We could extract the > 32bits and lower 8 bits, then perform a bitwise OR to calculate the > 40bit value. This makes no sense, because the timestamp extension > algorithm would simply discard the lower 8 bits anyways. > > Thus, implement timestamp extension as iavf_ptp_extend_32b_timestamp(), > and extract and forward only the 32bits of nominal nanoseconds. > > Signed-off-by: Jacob Keller > Reviewed-by: Wojciech Drewek > Reviewed-by: Rahul Rameshbabu > Reviewed-by: Sunil Goutham > Signed-off-by: Mateusz Polchlopek Reviewed-by: Simon Horman
Re: [Intel-wired-lan] [PATCH iwl-next v3 0/3] ice:Support to dump PHY config, FEC
Hi Jacob, Can you please help me with the branch name that I should rebase? Last time I rebased to "dev-queue" branch of "git clone git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git". Let me know, if I should use a different branch for rebasing. Thanks Anil -Original Message- From: Keller, Jacob E Sent: Friday, May 24, 2024 2:11 PM To: Samal, Anil ; intel-wired-...@lists.osuosl.org Cc: net...@vger.kernel.org; Pepiak, Leszek ; Kitszel, Przemyslaw ; Czapnik, Lukasz ; Nguyen, Anthony L Subject: Re: [PATCH iwl-next v3 0/3] ice:Support to dump PHY config, FEC On 5/24/2024 6:51 AM, Anil Samal wrote: > Implementation to dump PHY configuration and FEC statistics to > facilitate link level debugging of customer issues. Implementation > has two parts > What commit is this based off of? I believe we have slightly conflicting work already queued in IWL next-queue, and the NIPA automation is unable to apply this series for testing: > [IWL-NIPA] Patch: https://patchwork.ozlabs.org/patch/1939088 > Pass: 1 Warn: 0 Fail: 1 > > Patch: https://patchwork.ozlabs.org/patch/1939088 > results path: results/408098/1939088 > > Test: apply > Fail - Patch does not apply to next-queue > > Test: tree_selection > Okay - Clearly marked for next-queue Normally, basing directly on net-next is fine. Unfortunately, I am having trouble properly resolving the conflicts with the work on the queue already. If you could rebase this on top of dev-queue [1] that would be appreciated. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git/commit/?h=dev-queue
[Intel-wired-lan] [tnguy-next-queue:dev-queue] BUILD SUCCESS 2746dc17cbf54ef20cc09a7ec6862477a326fae1
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git dev-queue branch HEAD: 2746dc17cbf54ef20cc09a7ec6862477a326fae1 igb: Add MII write support elapsed time: 1454m configs tested: 91 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc arc allnoconfig gcc arc defconfig gcc arm mxs_defconfig clang arm nhk8815_defconfig clang arm64allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc csky allnoconfig gcc cskydefconfig gcc i386 allmodconfig gcc i386 allnoconfig gcc i386 allyesconfig gcc i386 buildonly-randconfig-002-20240608 clang i386 buildonly-randconfig-005-20240608 clang i386 randconfig-001-20240608 clang i386 randconfig-004-20240608 clang i386 randconfig-011-20240608 clang i386 randconfig-012-20240608 clang i386 randconfig-013-20240608 clang i386 randconfig-015-20240608 clang i386 randconfig-016-20240608 clang loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchallyesconfig gcc loongarch defconfig gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68kdefconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc mips allmodconfig gcc mips allnoconfig gcc mips allyesconfig gcc mips jazz_defconfig clang mips maltaaprp_defconfig clang mips rt305x_defconfig clang nios2allmodconfig gcc nios2 allnoconfig gcc nios2allyesconfig gcc nios2 defconfig gcc openrisc allmodconfig gcc openrisc allnoconfig gcc openriscdefconfig gcc pariscallnoconfig gcc parisc defconfig gcc parisc64defconfig gcc powerpc allnoconfig gcc powerpc allyesconfig clang powerpc linkstation_defconfig clang powerpc mpc834x_itx_defconfig clang riscvallmodconfig clang riscv allnoconfig gcc riscvallyesconfig clang riscv defconfig clang s390 allnoconfig clang s390 allyesconfig gcc s390defconfig clang sh allmodconfig gcc shallnoconfig gcc sh allyesconfig gcc sh defconfig gcc sparcallmodconfig gcc sparc allnoconfig gcc sparcallyesconfig gcc sparc defconfig gcc sparc64 allmodconfig gcc sparc64 allyesconfig gcc sparc64 defconfig gcc umallnoconfig clang um allyesconfig gcc um defconfig clang um i386_defconfig gcc um x86_64_defconfig clang x86_64 buildonly-randconfig-001-20240608 clang x86_64 buildonly-randconfig-003-20240608 clang x86_64 defconfig gcc x86_64randconfig-001-20240608 clang x86_64randconfig-005-20240608 clang x86_64randconfig-012-20240608 clang x86_64randconfig-015-20240608
[Intel-wired-lan] [tnguy-net-queue:dev-queue] BUILD SUCCESS 3480b86d0ad6df1f7fd4978557bc016ad1ed8c64
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git dev-queue branch HEAD: 3480b86d0ad6df1f7fd4978557bc016ad1ed8c64 ice: Do not get coalesce settings while in reset elapsed time: 1621m configs tested: 22 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: i386 buildonly-randconfig-001-20240609 gcc openrisc allnoconfig gcc openriscdefconfig gcc pariscallnoconfig gcc parisc defconfig gcc parisc64defconfig gcc powerpc allnoconfig gcc riscv allnoconfig gcc riscv defconfig clang s390 allnoconfig clang s390defconfig clang shallnoconfig gcc sh defconfig gcc sparc allnoconfig gcc sparc defconfig gcc sparc64 defconfig gcc um allmodconfig clang umallnoconfig clang um defconfig clang um i386_defconfig gcc um x86_64_defconfig clang xtensaallnoconfig gcc -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
[Intel-wired-lan] [iwl-next v1 1/1] igc: Remove the internal 'eee_advert' field
Since kernels 'ethtool_keee' structure is in use, the internal 'eee_advert'
a field becomes pointless and can be removed.
This patch comes to clean up this redundant code.
Signed-off-by: Sasha Neftin
---
drivers/net/ethernet/intel/igc/igc.h | 1 -
drivers/net/ethernet/intel/igc/igc_ethtool.c | 6 --
drivers/net/ethernet/intel/igc/igc_main.c| 3 ---
3 files changed, 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/igc/igc.h
b/drivers/net/ethernet/intel/igc/igc.h
index 8b14c029eda1..c38b4d0f00ce 100644
--- a/drivers/net/ethernet/intel/igc/igc.h
+++ b/drivers/net/ethernet/intel/igc/igc.h
@@ -202,7 +202,6 @@ struct igc_adapter {
struct net_device *netdev;
struct ethtool_keee eee;
- u16 eee_advert;
unsigned long state;
unsigned int flags;
diff --git a/drivers/net/ethernet/intel/igc/igc_ethtool.c
b/drivers/net/ethernet/intel/igc/igc_ethtool.c
index a80ac148b402..1e9241103aa9 100644
--- a/drivers/net/ethernet/intel/igc/igc_ethtool.c
+++ b/drivers/net/ethernet/intel/igc/igc_ethtool.c
@@ -1636,10 +1636,6 @@ static int igc_ethtool_get_eee(struct net_device *netdev,
linkmode_set_bit(ETHTOOL_LINK_MODE_100baseT_Full_BIT,
edata->supported);
- if (hw->dev_spec._base.eee_enable)
- mii_eee_cap1_mod_linkmode_t(edata->advertised,
- adapter->eee_advert);
-
eeer = rd32(IGC_EEER);
/* EEE status on negotiated link */
@@ -1700,8 +1696,6 @@ static int igc_ethtool_set_eee(struct net_device *netdev,
return -EINVAL;
}
- adapter->eee_advert = linkmode_to_mii_eee_cap1_t(edata->advertised);
-
if (hw->dev_spec._base.eee_enable != edata->eee_enabled) {
hw->dev_spec._base.eee_enable = edata->eee_enabled;
adapter->flags |= IGC_FLAG_EEE;
diff --git a/drivers/net/ethernet/intel/igc/igc_main.c
b/drivers/net/ethernet/intel/igc/igc_main.c
index c057d0afaf9a..772f425b1a24 100644
--- a/drivers/net/ethernet/intel/igc/igc_main.c
+++ b/drivers/net/ethernet/intel/igc/igc_main.c
@@ -4976,9 +4976,6 @@ void igc_up(struct igc_adapter *adapter)
/* start the watchdog. */
hw->mac.get_link_status = true;
schedule_work(&adapter->watchdog_task);
-
- adapter->eee_advert = MDIO_EEE_100TX | MDIO_EEE_1000T |
- MDIO_EEE_2_5GT;
}
/**
--
2.34.1
