RE: [Intel-wired-lan] [next-queue PATCH v1 2/2] Documentation: igb: Add a section about CBS

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Friday, November 16, 2018 4:19 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; jesus.s.palen...@gmail.com
> Subject: [Intel-wired-lan] [next-queue PATCH v1 2/2] Documentation: igb:
> Add a section about CBS
> 
> Add some pointers to the definition of the CBS algorithm, and some
> notes about the limits of its implementation in the i210 family of
> controllers.
> 
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  Documentation/networking/igb.rst | 19 +++
>  1 file changed, 19 insertions(+)
> 

Tested-by: Aaron Brown 

RE: [next-queue PATCH v1 1/2] igb: Change RXPBSIZE size when setting Qav mode

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> Sent: Friday, November 16, 2018 4:19 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: Sanchez-Palencia, Jesus ; Kirsher,
> Jeffrey T ; netdev@vger.kernel.org;
> jesus.s.palen...@gmail.com
> Subject: [next-queue PATCH v1 1/2] igb: Change RXPBSIZE size when setting
> Qav mode
> 
> From: Jesus Sanchez-Palencia 
> 
> Section 4.5.9 of the datasheet says that the total size of all packet
> buffers combined (TxPB 0 + 1 + 2 + 3 + RxPB + BMC2OS + OS2BMC) must not
> exceed 60KB. Today we are configuring a total of 62KB, so reduce the
> RxPB from 32KB to 30KB in order to respect that.
> 
> The choice of changing RxPBSIZE here is mainly because it seems more
> correct to give more priority to the transmit packet buffers over the
> receiver ones when running in Qav mode. Also, the BMC2OS and OS2BMC
> sizes are already too short.
> 
> Signed-off-by: Jesus Sanchez-Palencia 
> ---
>  drivers/net/ethernet/intel/igb/e1000_defines.h | 1 +
>  drivers/net/ethernet/intel/igb/igb_main.c  | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH net] igb: fix uninitialized variables

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of wangyunjian
> Sent: Tuesday, November 6, 2018 12:27 AM
> To: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org
> Cc: stone.z...@huawei.com; Yunjian Wang 
> Subject: [Intel-wired-lan] [PATCH net] igb: fix uninitialized variables
> 
> From: Yunjian Wang 
> 
> This patch fixes the variable 'phy_word' may be used uninitialized.
> 
> Signed-off-by: Yunjian Wang 
> ---
>  drivers/net/ethernet/intel/igb/e1000_i210.c | 1 +
>  1 file changed, 1 insertion(+)
> 

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH v2 net] igb: shorten maximum PHC timecounter update interval

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Miroslav Lichvar
> Sent: Friday, October 26, 2018 10:13 AM
> To: netdev@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Thomas Gleixner 
> Subject: [Intel-wired-lan] [PATCH v2 net] igb: shorten maximum PHC
> timecounter update interval
> 
> The timecounter needs to be updated at least once per ~550 seconds in
> order to avoid a 40-bit SYSTIM timestamp to be misinterpreted as an old
> timestamp.
> 
> Since commit 500462a9de65 ("timers: Switch to a non-cascading wheel"),
> scheduling of delayed work seems to be less accurate and a requested
> delay of 540 seconds may actually be longer than 550 seconds. Also, the
> PHC may be adjusted to run up to 6% faster than real time and the system
> clock up to 10% slower. Shorten the delay to 360 seconds to be sure the
> timecounter is updated in time.
> 
> This fixes an issue with HW timestamps on 82580/I350/I354 being off by
> ~1100 seconds for few seconds every ~9 minutes.
> 
> Cc: Jacob Keller 
> Cc: Richard Cochran 
> Cc: Thomas Gleixner 
> Signed-off-by: Miroslav Lichvar 
> ---
>  drivers/net/ethernet/intel/igb/igb_ptp.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH][next] igc: fix error return handling from call to netif_set_real_num_tx_queues

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Colin King
> Sent: Friday, October 19, 2018 11:16 AM
> To: Neftin, Sasha ; Kirsher, Jeffrey T
> ; David S . Miller ;
> intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; kernel-janit...@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH][next] igc: fix error return handling from
> call to netif_set_real_num_tx_queues
> 
> From: Colin Ian King 
> 
> The call to netif_set_real_num_tx_queues is not assigning the error
> return to variable err even though the next line checks err for an
> error.  Fix this by adding the missing err assignment.
> 
> Detected by CoverityScan, CID#1474551 ("Logically dead code")
> 
> Fixes: 3df25e4c1e66 ("igc: Add interrupt support")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/net/ethernet/intel/igc/igc_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Tested-by: Aaron Brown 

RE: [PATCH net-next] igc: Remove set but not used variable 'pci_using_dac'

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of YueHaibing
> Sent: Friday, October 19, 2018 5:48 AM
> To: Kirsher, Jeffrey T ; David S. Miller
> ; Neftin, Sasha 
> Cc: YueHaibing ; intel-wired-...@lists.osuosl.org;
> netdev@vger.kernel.org; kernel-janit...@vger.kernel.org
> Subject: [PATCH net-next] igc: Remove set but not used variable
> 'pci_using_dac'
> 
> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/net/ethernet/intel/igc/igc_main.c: In function 'igc_probe':
> drivers/net/ethernet/intel/igc/igc_main.c:3535:11: warning:
>  variable 'pci_using_dac' set but not used [-Wunused-but-set-variable]
> 
> It never used since introduction in commit
> d89f88419f99 ("igc: Add skeletal frame for Intel(R) 2.5G Ethernet Controller
> support")
> 
> Signed-off-by: YueHaibing 
> ---
>  drivers/net/ethernet/intel/igc/igc_main.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 

Tested-by: Aaron Brown 

RE: [PATCH net-next] igc: Remove set but not used variables 'ctrl_ext, link_mode'

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of YueHaibing
> Sent: Friday, October 19, 2018 5:41 AM
> To: Kirsher, Jeffrey T ; Neftin, Sasha
> 
> Cc: YueHaibing ; intel-wired-...@lists.osuosl.org;
> netdev@vger.kernel.org; kernel-janit...@vger.kernel.org
> Subject: [PATCH net-next] igc: Remove set but not used variables 'ctrl_ext,
> link_mode'
> 
> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/net/ethernet/intel/igc/igc_base.c: In function
> 'igc_init_phy_params_base':
> drivers/net/ethernet/intel/igc/igc_base.c:240:6: warning:
>  variable 'ctrl_ext' set but not used [-Wunused-but-set-variable]
>   u32 ctrl_ext;
> 
> drivers/net/ethernet/intel/igc/igc_base.c: In function
> 'igc_get_invariants_base':
> drivers/net/ethernet/intel/igc/igc_base.c:290:6: warning:
>  variable 'link_mode' set but not used [-Wunused-but-set-variable]
>   u32 link_mode = 0;
> 
> It never used since introduction in
> commit c0071c7aa5fe ("igc: Add HW initialization code")
> 
> Signed-off-by: YueHaibing 
> ---
> I'm not sure that reading IGC_CTRL_EXT is necessary.
> ---
>  drivers/net/ethernet/intel/igc/igc_base.c | 8 
>  1 file changed, 8 deletions(-)
> 

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH] igb: shorten maximum PHC timecounter update interval

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Miroslav Lichvar
> Sent: Friday, October 12, 2018 4:14 AM
> To: intel-wired-...@lists.osuosl.org; netdev@vger.kernel.org
> Cc: Thomas Gleixner ; Richard Cochran
> 
> Subject: [Intel-wired-lan] [PATCH] igb: shorten maximum PHC timecounter
> update interval
> 
> The timecounter needs to be updated at least once per ~550 seconds in
> order to avoid a 40-bit SYSTIM timestamp to be misinterpreted as an old
> timestamp.
> 
> Since commit 500462a9d ("timers: Switch to a non-cascading wheel"),
> scheduling of delayed work seems to be less accurate and a requested
> delay of 540 seconds may actually be longer than 550 seconds. Shorten
> the delay to 480 seconds to be sure the timecounter is updated in time.
> 
> This fixes an issue with HW timestamps on 82580/I350/I354 being off by
> ~1100 seconds for few seconds every ~9 minutes.
> 
> Cc: Jacob Keller 
> Cc: Richard Cochran 
> Cc: Thomas Gleixner 
> Signed-off-by: Miroslav Lichvar 
> ---
>  drivers/net/ethernet/intel/igb/igb_ptp.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH v1 net-next] igb: Use an advanced ctx descriptor for launchtime

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Jesus Sanchez-Palencia
> Sent: Thursday, July 26, 2018 10:21 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: [Intel-wired-lan] [PATCH v1 net-next] igb: Use an advanced ctx
> descriptor for launchtime
> 
> On i210, Launchtime (TxTime) requires the usage of an "Advanced
> Transmit Context Descriptor" for retrieving the timestamp of a packet.
> 
> The igb driver correctly builds such descriptor on the segmentation
> flow (i.e. igb_tso()) or on the checksum one (i.e. igb_tx_csum()), but the
> feature is broken for AF_PACKET if the IGB_TX_FLAGS_VLAN is not set,
> which happens due to an early return on igb_tx_csum().
> 
> This flag is only set by the kernel when a VLAN interface is used,
> thus we can't just rely on it. Here we are fixing this issue by checking
> if launchtime is enabled for the current tx_ring before performing the
> early return.
> 
> Signed-off-by: Jesus Sanchez-Palencia 
> ---
>  drivers/net/ethernet/intel/igb/igb_main.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH] e1000e: Ignore TSYNCRXCTL when getting I219 clock attributes

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Benjamin Poirier
> Sent: Thursday, May 10, 2018 12:29 AM
> To: Kirsher, Jeffrey T 
> Cc: ehabk...@redhat.com; netdev@vger.kernel.org; jaya...@goubiq.com;
> linux-ker...@vger.kernel.org; bart.vanass...@wdc.com;
> postmodern.m...@gmail.com; Achim Mildenberger
> ; intel-wired-...@lists.osuosl.org;
> olouvig...@gmail.com
> Subject: [Intel-wired-lan] [PATCH] e1000e: Ignore TSYNCRXCTL when getting
> I219 clock attributes
> 
> There have been multiple reports of crashes that look like
> kernel: RIP: 0010:[] timecounter_read+0xf/0x50
> [...]
> kernel: Call Trace:
> kernel:  [] e1000e_phc_gettime+0x2f/0x60 [e1000e]
> kernel:  [] e1000e_systim_overflow_work+0x1d/0x80
> [e1000e]
> kernel:  [] process_one_work+0x155/0x440
> kernel:  [] worker_thread+0x116/0x4b0
> kernel:  [] kthread+0xd2/0xf0
> kernel:  [] ret_from_fork+0x3f/0x70
> 
> These can be traced back to the fact that e1000e_systim_reset() skips the
> timecounter_init() call if e1000e_get_base_timinca() returns -EINVAL, which
> leads to a null deref in timecounter_read().
> 
> Commit 83129b37ef35 ("e1000e: fix systim issues", v4.2-rc1) reworked
> e1000e_get_base_timinca() in such a way that it can return -EINVAL for
> e1000_pch_spt if the SYSCFI bit is not set in TSYNCRXCTL.
> 
> Some experimentation has shown that on I219 (e1000_pch_spt, "MAC: 12")
> adapters, the E1000_TSYNCRXCTL_SYSCFI flag is unstable; TSYNCRXCTL reads
> sometimes don't have the SYSCFI bit set. Retrying the read shortly after
> finds the bit to be set. This was observed at boot (probe) but also link up
> and link down.
> 
> Moreover, the phc (PTP Hardware Clock) seems to operate normally even
> after
> reads where SYSCFI=0. Therefore, remove this register read and
> unconditionally set the clock parameters.
> 
> Reported-by: Achim Mildenberger 
> Message-Id: <20180425065243.g5mqewg5irkwgwgv@f2>
> Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1075876
> Fixes: 83129b37ef35 ("e1000e: fix systim issues")
> Signed-off-by: Benjamin Poirier 
> ---
>  drivers/net/ethernet/intel/e1000e/netdev.c | 15 ++-
>  1 file changed, 6 insertions(+), 9 deletions(-)

Tested-by: Aaron Brown 

RE: [next-queue PATCH] igb: Fix the transmission mode of queue 0 for Qav mode

[Brown, Aaron F]

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:28 PM
> To: 'Vinicius Costa Gomes' <vinicius.go...@intel.com>; intel-wired-
> l...@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.go...@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirs...@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palen...@intel.com>; Guedes, Andre
> <andre.gue...@intel.com>
> Subject: RE: [next-queue PATCH] igb: Fix the transmission mode of queue 0
> for Qav mode
> 
> > From: netdev-ow...@vger.kernel.org [mailto:netdev-
> > ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Friday, March 30, 2018 5:07 PM
> > To: intel-wired-...@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.go...@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirs...@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palen...@intel.com>; Guedes, Andre
> > <andre.gue...@intel.com>
> > Subject: [next-queue PATCH] igb: Fix the transmission mode of queue 0 for
> > Qav mode
> >
> > When Qav mode is enabled, queue 0 should be kept on Stream
> Reservation
> > mode. From the i210 datasheet, section 8.12.19:
> >
> > "Note: Queue0 QueueMode must be set to 1b when TransmitMode is set
> to
> > Qav." ("QueueMode 1b" represents the Stream Reservation mode)
> >
> > The solution is to give queue 0 the all the credits it might need, so
> > it has priority over queue 1.
> >
> > A situation where this can happen is when cbs is "installed" only on
> > queue 1, leaving queue 0 alone. For example:
> >
> > $ tc qdisc replace dev enp2s0 handle 100: parent root mqprio num_tc 3 \
> >map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@0 1@1 2@2 hw 0
> >
> > $ tc qdisc replace dev enp2s0 parent 100:2 cbs locredit -1470 \
> >hicredit 30 sendslope -98 idleslope 2 offload 1
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.go...@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_main.c | 17 -
> >  1 file changed, 16 insertions(+), 1 deletion(-)
> >
> 
> Tested by: Aaron Brown <aaron.f.br...@intel.com>
Tested-by: Aaron Brown <aaron.f.br...@intel.com>

RE: [next-queue PATCH v7 10/10] igb: Add support for adding offloaded clsflower filters

[Brown, Aaron F]

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:25 PM
> To: 'Vinicius Costa Gomes' <vinicius.go...@intel.com>; intel-wired-
> l...@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.go...@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirs...@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palen...@intel.com>
> Subject: RE: [next-queue PATCH v7 10/10] igb: Add support for adding
> offloaded clsflower filters
> 
> > From: netdev-ow...@vger.kernel.org [mailto:netdev-
> > ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-...@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.go...@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirs...@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palen...@intel.com>
> > Subject: [next-queue PATCH v7 10/10] igb: Add support for adding
> offloaded
> > clsflower filters
> >
> > This allows filters added by tc-flower and specifying MAC addresses,
> > Ethernet types, and the VLAN priority field, to be offloaded to the
> > controller.
> >
> > This reuses most of the infrastructure used by ethtool, but clsflower
> > filters are kept in a separated list, so they are invisible to
> > ethtool.
> >
> > To setup clsflower offloading:
> >
> > $ tc qdisc replace dev eth0 handle 100: parent root mqprio \
> >num_tc 3 map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \
> >queues 1@0 1@1 2@2 hw 0
> > (clsflower offloading depends on the netword driver to be configured
> > with multiple traffic classes, we use mqprio's 'num_tc' parameter to
> > set it to 3)
> >
> > $ tc qdisc add dev eth0 ingress
> >
> > Examples of filters:
> >
> > $ tc filter add dev eth0 parent : flower \
> > dst_mac aa:aa:aa:aa:aa:aa \
> > hw_tc 2 skip_sw
> > (just a simple filter filtering for the destination MAC address and
> > steering that traffic to queue 2)
> >
> > $ tc filter add dev enp2s0 parent : proto 0x22f0 flower \
> > src_mac cc:cc:cc:cc:cc:cc \
> > hw_tc 1 skip_sw
> > (as the i210 doesn't support steering traffic based on the source
> > address alone, we need to use another steering traffic, in this case
> > we are using the ethernet type (0x22f0) to steer traffic to queue 1)
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.go...@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb.h  |   2 +
> >  drivers/net/ethernet/intel/igb/igb_main.c | 188
> > +-
> >  2 files changed, 188 insertions(+), 2 deletions(-)
> 
> Tested by: Aaron Brown <aaron.f.br...@intel.com>
Tested-by: Aaron Brown <aaron.f.br...@intel.com>

RE: [Intel-wired-lan] [next-queue PATCH v7 09/10] igb: Add the skeletons for tc-flower offloading

[Brown, Aaron F]

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:23 PM
> To: 'Vinicius Costa Gomes' <vinicius.go...@intel.com>; intel-wired-
> l...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: RE: [Intel-wired-lan] [next-queue PATCH v7 09/10] igb: Add the
> skeletons for tc-flower offloading
> 
> > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> > Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-...@lists.osuosl.org
> > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  > palen...@intel.com>
> > Subject: [Intel-wired-lan] [next-queue PATCH v7 09/10] igb: Add the
> > skeletons for tc-flower offloading
> >
> > This adds basic functions needed to implement offloading for filters
> > created by tc-flower.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.go...@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_main.c | 66
> > +++
> >  1 file changed, 66 insertions(+)
> >
> 
> Tested by: Aaron Brown <aaron.f.br...@intel.com>
Tested-by: Aaron Brown <aaron.f.br...@intel.com>

RE: [next-queue PATCH v7 08/10] igb: Add MAC address support for ethtool nftuple filters

[Brown, Aaron F]

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:23 PM
> To: 'Vinicius Costa Gomes' <vinicius.go...@intel.com>; intel-wired-
> l...@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.go...@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirs...@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palen...@intel.com>
> Subject: RE: [next-queue PATCH v7 08/10] igb: Add MAC address support for
> ethtool nftuple filters
> 
> > From: netdev-ow...@vger.kernel.org [mailto:netdev-
> > ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-...@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.go...@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirs...@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palen...@intel.com>
> > Subject: [next-queue PATCH v7 08/10] igb: Add MAC address support for
> > ethtool nftuple filters
> >
> > This adds the capability of configuring the queue steering of arriving
> > packets based on their source and destination MAC addresses.
> >
> > Source address steering (i.e. driving traffic to a specific queue),
> > for the i210, does not work, but filtering does (i.e. accepting
> > traffic based on the source address). So, trying to add a filter
> > specifying only a source address will be an error.
> >
> > In practical terms this adds support for the following use cases,
> > characterized by these examples:
> >
> > $ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0
> > (this will direct packets with destination address "aa:aa:aa:aa:aa:aa"
> > to the RX queue 0)
> >
> > $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 \
> >   proto 0x22f0 action 3
> > (this will direct packets with source address "44:44:44:44:44:44" and
> > ethertype 0x22f0 to the RX queue 3)
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.go...@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_ethtool.c | 43 ++-
> -
> >  1 file changed, 39 insertions(+), 4 deletions(-)
> >
> 
> Tested by: Aaron Brown <aaron.f.br...@intel.com>
Tested-by: Aaron Brown <aaron.f.br...@intel.com>

RE: [next-queue PATCH v7 07/10] igb: Enable nfc filters to specify MAC addresses

[Brown, Aaron F]

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:22 PM
> To: 'Vinicius Costa Gomes' <vinicius.go...@intel.com>; intel-wired-
> l...@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.go...@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirs...@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palen...@intel.com>
> Subject: RE: [next-queue PATCH v7 07/10] igb: Enable nfc filters to specify
> MAC addresses
> 
> > From: netdev-ow...@vger.kernel.org [mailto:netdev-
> > ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-...@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.go...@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirs...@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palen...@intel.com>
> > Subject: [next-queue PATCH v7 07/10] igb: Enable nfc filters to specify MAC
> > addresses
> >
> > This allows igb_add_filter()/igb_erase_filter() to work on filters
> > that include MAC addresses (both source and destination).
> >
> > For now, this only exposes the functionality, the next commit glues
> > ethtool into this. Later in this series, these APIs are used to allow
> > offloading of cls_flower filters.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.go...@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb.h |  4 +++
> >  drivers/net/ethernet/intel/igb/igb_ethtool.c | 28
> 
> >  2 files changed, 32 insertions(+)
> 
> Tested by: Aaron Brown <aaron.f.br...@intel.com>
Tested-by: Aaron Brown <aaron.f.br...@intel.com>

RE: [Intel-wired-lan] [next-queue PATCH v7 06/10] igb: Allow filters to be added for the local MAC address

[Brown, Aaron F]

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:20 PM
> To: 'Vinicius Costa Gomes' <vinicius.go...@intel.com>; intel-wired-
> l...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: RE: [Intel-wired-lan] [next-queue PATCH v7 06/10] igb: Allow filters
> to be added for the local MAC address
> 
> > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> > Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-...@lists.osuosl.org
> > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  > palen...@intel.com>
> > Subject: [Intel-wired-lan] [next-queue PATCH v7 06/10] igb: Allow filters to
> > be added for the local MAC address
> >
> > Users expect that when adding a steering filter for the local MAC
> > address, that all the traffic directed to that address will go to some
> > queue.
> >
> > Currently, it's not possible to configure entries in the "in use"
> > state, which is the normal state of the local MAC address entry (it is
> > the default), this patch allows to override the steering configuration
> > of "in use" entries, if the filter to be added match the address and
> > address type (source or destination) of an existing entry.
> >
> > There is a bit of a special handling for entries referring to the
> > local MAC address, when they are removed, only the steering
> > configuration is reset.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.go...@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_main.c | 40 -
> --
> >  1 file changed, 36 insertions(+), 4 deletions(-)
> 
> Tested by: Aaron Brown <aaron.f.br...@intel.com>
Tested-by: Aaron Brown <aaron.f.br...@intel.com>

RE: [Intel-wired-lan] [next-queue PATCH v7 05/10] igb: Add support for enabling queue steering in filters

[Brown, Aaron F]

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:20 PM
> To: 'Vinicius Costa Gomes' <vinicius.go...@intel.com>; intel-wired-
> l...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: RE: [Intel-wired-lan] [next-queue PATCH v7 05/10] igb: Add support
> for enabling queue steering in filters
> 
> > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> > Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-...@lists.osuosl.org
> > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  > palen...@intel.com>
> > Subject: [Intel-wired-lan] [next-queue PATCH v7 05/10] igb: Add support
> for
> > enabling queue steering in filters
> >
> > On some igb models (82575 and i210) the MAC address filters can
> > control to which queue the packet will be assigned.
> >
> > This extends the 'state' with one more state to signify that queue
> > selection should be enabled for that filter.
> >
> > As 82575 parts are no longer easily obtained (and this was developed
> > against i210), only support for the i210 model is enabled.
> >
> > These functions are exported and will be used in the next patch.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.go...@intel.com>
> > ---
> >  .../net/ethernet/intel/igb/e1000_defines.h|  1 +
> >  drivers/net/ethernet/intel/igb/igb.h  |  6 +
> >  drivers/net/ethernet/intel/igb/igb_main.c | 26 +++
> >  3 files changed, 33 insertions(+)
> 
> Tested by: Aaron Brown <aaron.f.br...@intel.com>
Tested-by: Aaron Brown <aaron.f.br...@intel.com>

RE: [Intel-wired-lan] [next-queue PATCH v7 03/10] igb: Enable the hardware traffic class feature bit for igb models

[Brown, Aaron F]

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:18 PM
> To: 'Vinicius Costa Gomes' <vinicius.go...@intel.com>; intel-wired-
> l...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: RE: [Intel-wired-lan] [next-queue PATCH v7 03/10] igb: Enable the
> hardware traffic class feature bit for igb models
> 
> > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> > Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-...@lists.osuosl.org
> > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  > palen...@intel.com>
> > Subject: [Intel-wired-lan] [next-queue PATCH v7 03/10] igb: Enable the
> > hardware traffic class feature bit for igb models
> >
> > This will allow functionality depending on the hardware being traffic
> > class aware to work. In particular the tc-flower offloading checks
> > verifies that this bit is set.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.go...@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_main.c | 3 +++
> >  1 file changed, 3 insertions(+)
> 
> Tested by: Aaron Brown <aaron.f.br...@intel.com>
Tested-by: Aaron Brown <aaron.f.br...@intel.com>

RE: [next-queue PATCH v7 04/10] igb: Add support for MAC address filters specifying source addresses

[Brown, Aaron F]

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:19 PM
> To: 'Vinicius Costa Gomes' <vinicius.go...@intel.com>; intel-wired-
> l...@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.go...@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirs...@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palen...@intel.com>
> Subject: RE: [next-queue PATCH v7 04/10] igb: Add support for MAC address
> filters specifying source addresses
> 
> > From: netdev-ow...@vger.kernel.org [mailto:netdev-
> > ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-...@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.go...@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirs...@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palen...@intel.com>
> > Subject: [next-queue PATCH v7 04/10] igb: Add support for MAC address
> > filters specifying source addresses
> >
> > Makes it possible to direct packets to queues based on their source
> > address. Documents the expected usage of the 'flags' parameter.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.go...@intel.com>
> > ---
> >  .../net/ethernet/intel/igb/e1000_defines.h|  1 +
> >  drivers/net/ethernet/intel/igb/igb.h  |  1 +
> >  drivers/net/ethernet/intel/igb/igb_main.c | 40 ---
> >  3 files changed, 37 insertions(+), 5 deletions(-)
> 
> Tested by: Aaron Brown <aaron.f.br...@intel.com>
Tested-by: Aaron Brown <aaron.f.br...@intel.com>

RE: [next-queue PATCH v7 01/10] igb: Fix not adding filter elements to the list

[Brown, Aaron F]

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:17 PM
> To: 'Vinicius Costa Gomes' <vinicius.go...@intel.com>; intel-wired-
> l...@lists.osuosl.org
> Cc: Gomes, Vinicius <vinicius.go...@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirs...@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus <jesus.sanchez-palen...@intel.com>
> Subject: RE: [next-queue PATCH v7 01/10] igb: Fix not adding filter elements
> to the list
> 
> > From: netdev-ow...@vger.kernel.org [mailto:netdev-
> > ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-...@lists.osuosl.org
> > Cc: Gomes, Vinicius <vinicius.go...@intel.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirs...@intel.com>; netdev@vger.kernel.org; Sanchez-Palencia,
> > Jesus <jesus.sanchez-palen...@intel.com>
> > Subject: [next-queue PATCH v7 01/10] igb: Fix not adding filter elements to
> > the list
> >
> > Because the order of the parameters passes to 'hlist_add_behind()' was
> > inverted, the 'parent' node was added "behind" the 'input', as input
> > is not in the list, this causes the 'input' node to be lost.
> >
> > Fixes: 0e71def25281 ("igb: add support of RX network flow classification")
> > Signed-off-by: Vinicius Costa Gomes <vinicius.go...@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_ethtool.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Tested by: Aaron Brown <aaron.f.br...@intel.com>
Resending with "Tested-by..." rather then "Tested by..." so that patchwork 
actually picks it up.  What I get for signing off on the mails late Friday.
Tested-by: Aaron Brown <aaron.f.br...@intel.com>

RE: [Intel-wired-lan] [next-queue PATCH v7 02/10] igb: Fix queue selection on MAC filters on i210

[Brown, Aaron F]

> From: Brown, Aaron F
> Sent: Friday, April 13, 2018 7:18 PM
> To: 'Vinicius Costa Gomes' <vinicius.go...@intel.com>; intel-wired-
> l...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: RE: [Intel-wired-lan] [next-queue PATCH v7 02/10] igb: Fix queue
> selection on MAC filters on i210
> 
> > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> > Behalf Of Vinicius Costa Gomes
> > Sent: Tuesday, April 10, 2018 10:50 AM
> > To: intel-wired-...@lists.osuosl.org
> > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  > palen...@intel.com>
> > Subject: [Intel-wired-lan] [next-queue PATCH v7 02/10] igb: Fix queue
> > selection on MAC filters on i210
> >
> > On the RAH registers there are semantic differences on the meaning of
> > the "queue" parameter for traffic steering depending on the controller
> > model: there is the 82575 meaning, which "queue" means a RX Hardware
> > Queue, and the i350 meaning, where it is a reception pool.
> >
> > The previous behaviour was having no effect for i210 based controllers
> > because the QSEL bit of the RAH register wasn't being set.
> >
> > This patch separates the condition in discrete cases, so the different
> > handling is clearer.
> >
> > Fixes: 83c21335c876 ("igb: improve MAC filter handling")
> > Signed-off-by: Vinicius Costa Gomes <vinicius.go...@intel.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_main.c | 13 +
> >  1 file changed, 9 insertions(+), 4 deletions(-)
> >
> 
> Tested by: Aaron Brown <aaron.f.br...@intel.com>
Tested-by: Aaron Brown <aaron.f.br...@intel.com>

RE: [next-queue PATCH] igb: Fix the transmission mode of queue 0 for Qav mode

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> Sent: Friday, March 30, 2018 5:07 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: Gomes, Vinicius ; Kirsher, Jeffrey T
> ; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus ; Guedes, Andre
> 
> Subject: [next-queue PATCH] igb: Fix the transmission mode of queue 0 for
> Qav mode
> 
> When Qav mode is enabled, queue 0 should be kept on Stream Reservation
> mode. From the i210 datasheet, section 8.12.19:
> 
> "Note: Queue0 QueueMode must be set to 1b when TransmitMode is set to
> Qav." ("QueueMode 1b" represents the Stream Reservation mode)
> 
> The solution is to give queue 0 the all the credits it might need, so
> it has priority over queue 1.
> 
> A situation where this can happen is when cbs is "installed" only on
> queue 1, leaving queue 0 alone. For example:
> 
> $ tc qdisc replace dev enp2s0 handle 100: parent root mqprio num_tc 3 \
>  map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@0 1@1 2@2 hw 0
> 
> $ tc qdisc replace dev enp2s0 parent 100:2 cbs locredit -1470 \
>  hicredit 30 sendslope -98 idleslope 2 offload 1
> 
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  drivers/net/ethernet/intel/igb/igb_main.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 

Tested by: Aaron Brown 

RE: [next-queue PATCH v7 10/10] igb: Add support for adding offloaded clsflower filters

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: Gomes, Vinicius ; Kirsher, Jeffrey T
> ; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus 
> Subject: [next-queue PATCH v7 10/10] igb: Add support for adding offloaded
> clsflower filters
> 
> This allows filters added by tc-flower and specifying MAC addresses,
> Ethernet types, and the VLAN priority field, to be offloaded to the
> controller.
> 
> This reuses most of the infrastructure used by ethtool, but clsflower
> filters are kept in a separated list, so they are invisible to
> ethtool.
> 
> To setup clsflower offloading:
> 
> $ tc qdisc replace dev eth0 handle 100: parent root mqprio \
>  num_tc 3 map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \
>  queues 1@0 1@1 2@2 hw 0
> (clsflower offloading depends on the netword driver to be configured
> with multiple traffic classes, we use mqprio's 'num_tc' parameter to
> set it to 3)
> 
> $ tc qdisc add dev eth0 ingress
> 
> Examples of filters:
> 
> $ tc filter add dev eth0 parent : flower \
>   dst_mac aa:aa:aa:aa:aa:aa \
>   hw_tc 2 skip_sw
> (just a simple filter filtering for the destination MAC address and
> steering that traffic to queue 2)
> 
> $ tc filter add dev enp2s0 parent : proto 0x22f0 flower \
>   src_mac cc:cc:cc:cc:cc:cc \
>   hw_tc 1 skip_sw
> (as the i210 doesn't support steering traffic based on the source
> address alone, we need to use another steering traffic, in this case
> we are using the ethernet type (0x22f0) to steer traffic to queue 1)
> 
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  drivers/net/ethernet/intel/igb/igb.h  |   2 +
>  drivers/net/ethernet/intel/igb/igb_main.c | 188
> +-
>  2 files changed, 188 insertions(+), 2 deletions(-)

Tested by: Aaron Brown 

RE: [Intel-wired-lan] [next-queue PATCH v7 09/10] igb: Add the skeletons for tc-flower offloading

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: [Intel-wired-lan] [next-queue PATCH v7 09/10] igb: Add the
> skeletons for tc-flower offloading
> 
> This adds basic functions needed to implement offloading for filters
> created by tc-flower.
> 
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  drivers/net/ethernet/intel/igb/igb_main.c | 66
> +++
>  1 file changed, 66 insertions(+)
> 

Tested by: Aaron Brown 

RE: [next-queue PATCH v7 08/10] igb: Add MAC address support for ethtool nftuple filters

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: Gomes, Vinicius ; Kirsher, Jeffrey T
> ; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus 
> Subject: [next-queue PATCH v7 08/10] igb: Add MAC address support for
> ethtool nftuple filters
> 
> This adds the capability of configuring the queue steering of arriving
> packets based on their source and destination MAC addresses.
> 
> Source address steering (i.e. driving traffic to a specific queue),
> for the i210, does not work, but filtering does (i.e. accepting
> traffic based on the source address). So, trying to add a filter
> specifying only a source address will be an error.
> 
> In practical terms this adds support for the following use cases,
> characterized by these examples:
> 
> $ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0
> (this will direct packets with destination address "aa:aa:aa:aa:aa:aa"
> to the RX queue 0)
> 
> $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 \
> proto 0x22f0 action 3
> (this will direct packets with source address "44:44:44:44:44:44" and
> ethertype 0x22f0 to the RX queue 3)
> 
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  drivers/net/ethernet/intel/igb/igb_ethtool.c | 43 ++--
>  1 file changed, 39 insertions(+), 4 deletions(-)
> 

Tested by: Aaron Brown 

RE: [next-queue PATCH v7 07/10] igb: Enable nfc filters to specify MAC addresses

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: Gomes, Vinicius ; Kirsher, Jeffrey T
> ; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus 
> Subject: [next-queue PATCH v7 07/10] igb: Enable nfc filters to specify MAC
> addresses
> 
> This allows igb_add_filter()/igb_erase_filter() to work on filters
> that include MAC addresses (both source and destination).
> 
> For now, this only exposes the functionality, the next commit glues
> ethtool into this. Later in this series, these APIs are used to allow
> offloading of cls_flower filters.
> 
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  drivers/net/ethernet/intel/igb/igb.h |  4 +++
>  drivers/net/ethernet/intel/igb/igb_ethtool.c | 28 
>  2 files changed, 32 insertions(+)

Tested by: Aaron Brown 

RE: [Intel-wired-lan] [next-queue PATCH v7 06/10] igb: Allow filters to be added for the local MAC address

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: [Intel-wired-lan] [next-queue PATCH v7 06/10] igb: Allow filters to
> be added for the local MAC address
> 
> Users expect that when adding a steering filter for the local MAC
> address, that all the traffic directed to that address will go to some
> queue.
> 
> Currently, it's not possible to configure entries in the "in use"
> state, which is the normal state of the local MAC address entry (it is
> the default), this patch allows to override the steering configuration
> of "in use" entries, if the filter to be added match the address and
> address type (source or destination) of an existing entry.
> 
> There is a bit of a special handling for entries referring to the
> local MAC address, when they are removed, only the steering
> configuration is reset.
> 
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  drivers/net/ethernet/intel/igb/igb_main.c | 40 ---
>  1 file changed, 36 insertions(+), 4 deletions(-)

Tested by: Aaron Brown 

RE: [Intel-wired-lan] [next-queue PATCH v7 05/10] igb: Add support for enabling queue steering in filters

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: [Intel-wired-lan] [next-queue PATCH v7 05/10] igb: Add support for
> enabling queue steering in filters
> 
> On some igb models (82575 and i210) the MAC address filters can
> control to which queue the packet will be assigned.
> 
> This extends the 'state' with one more state to signify that queue
> selection should be enabled for that filter.
> 
> As 82575 parts are no longer easily obtained (and this was developed
> against i210), only support for the i210 model is enabled.
> 
> These functions are exported and will be used in the next patch.
> 
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  .../net/ethernet/intel/igb/e1000_defines.h|  1 +
>  drivers/net/ethernet/intel/igb/igb.h  |  6 +
>  drivers/net/ethernet/intel/igb/igb_main.c | 26 +++
>  3 files changed, 33 insertions(+)

Tested by: Aaron Brown 

RE: [next-queue PATCH v7 04/10] igb: Add support for MAC address filters specifying source addresses

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: Gomes, Vinicius ; Kirsher, Jeffrey T
> ; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus 
> Subject: [next-queue PATCH v7 04/10] igb: Add support for MAC address
> filters specifying source addresses
> 
> Makes it possible to direct packets to queues based on their source
> address. Documents the expected usage of the 'flags' parameter.
> 
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  .../net/ethernet/intel/igb/e1000_defines.h|  1 +
>  drivers/net/ethernet/intel/igb/igb.h  |  1 +
>  drivers/net/ethernet/intel/igb/igb_main.c | 40 ---
>  3 files changed, 37 insertions(+), 5 deletions(-)

Tested by: Aaron Brown 

RE: [Intel-wired-lan] [next-queue PATCH v7 03/10] igb: Enable the hardware traffic class feature bit for igb models

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: [Intel-wired-lan] [next-queue PATCH v7 03/10] igb: Enable the
> hardware traffic class feature bit for igb models
> 
> This will allow functionality depending on the hardware being traffic
> class aware to work. In particular the tc-flower offloading checks
> verifies that this bit is set.
> 
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  drivers/net/ethernet/intel/igb/igb_main.c | 3 +++
>  1 file changed, 3 insertions(+)

Tested by: Aaron Brown 

RE: [Intel-wired-lan] [next-queue PATCH v7 02/10] igb: Fix queue selection on MAC filters on i210

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: [Intel-wired-lan] [next-queue PATCH v7 02/10] igb: Fix queue
> selection on MAC filters on i210
> 
> On the RAH registers there are semantic differences on the meaning of
> the "queue" parameter for traffic steering depending on the controller
> model: there is the 82575 meaning, which "queue" means a RX Hardware
> Queue, and the i350 meaning, where it is a reception pool.
> 
> The previous behaviour was having no effect for i210 based controllers
> because the QSEL bit of the RAH register wasn't being set.
> 
> This patch separates the condition in discrete cases, so the different
> handling is clearer.
> 
> Fixes: 83c21335c876 ("igb: improve MAC filter handling")
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  drivers/net/ethernet/intel/igb/igb_main.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 

Tested by: Aaron Brown 

RE: [next-queue PATCH v7 01/10] igb: Fix not adding filter elements to the list

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, April 10, 2018 10:50 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: Gomes, Vinicius ; Kirsher, Jeffrey T
> ; netdev@vger.kernel.org; Sanchez-Palencia,
> Jesus 
> Subject: [next-queue PATCH v7 01/10] igb: Fix not adding filter elements to
> the list
> 
> Because the order of the parameters passes to 'hlist_add_behind()' was
> inverted, the 'parent' node was added "behind" the 'input', as input
> is not in the list, this causes the 'input' node to be lost.
> 
> Fixes: 0e71def25281 ("igb: add support of RX network flow classification")
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  drivers/net/ethernet/intel/igb/igb_ethtool.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Tested by: Aaron Brown 

RE: [Intel-wired-lan] [next-queue PATCH v6 10/10] igb: Add support for adding offloaded clsflower filters

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Thursday, March 29, 2018 2:08 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: [Intel-wired-lan] [next-queue PATCH v6 10/10] igb: Add support for
> adding offloaded clsflower filters
> 
> This allows filters added by tc-flower and specifying MAC addresses,
> Ethernet types, and the VLAN priority field, to be offloaded to the
> controller.

Can I get a brief explanation for enabling this?  I'm currently happy with this 
patch series from a regression perspective, but am personally a bit, umm, 
challenged with tc in general but would like to run it through the paces a bit. 
 If it can be done in a one or two liner I think it would be a good addition to 
the patch description.

> 
> This reuses most of the infrastructure used by ethtool, but clsflower
> filters are kept in a separated list, so they are invisible to
> ethtool.
> 
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  drivers/net/ethernet/intel/igb/igb.h  |   2 +
>  drivers/net/ethernet/intel/igb/igb_main.c | 188
> +-
>  2 files changed, 188 insertions(+), 2 deletions(-)

RE: [Intel-wired-lan] [next-queue PATCH v6 08/10] igb: Add MAC address support for ethtool nftuple filters

[Brown, Aaron F]

> From: Gomes, Vinicius
> Sent: Thursday, April 5, 2018 11:00 AM
> To: Brown, Aaron F <aaron.f.br...@intel.com>; intel-wired-
> l...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: RE: [Intel-wired-lan] [next-queue PATCH v6 08/10] igb: Add MAC
> address support for ethtool nftuple filters
> 
> Hi,
> 
> "Brown, Aaron F" <aaron.f.br...@intel.com> writes:
> 
> >> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> >> Behalf Of Vinicius Costa Gomes
> >> Sent: Thursday, March 29, 2018 2:08 PM
> >> To: intel-wired-...@lists.osuosl.org
> >> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  >> palen...@intel.com>
> >> Subject: [Intel-wired-lan] [next-queue PATCH v6 08/10] igb: Add MAC
> >> address support for ethtool nftuple filters
> >>
> >> This adds the capability of configuring the queue steering of arriving
> >> packets based on their source and destination MAC addresses.
> >>
> >> In practical terms this adds support for the following use cases,
> >> characterized by these examples:
> >>
> >> $ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0
> >> (this will direct packets with destination address "aa:aa:aa:aa:aa:aa"
> >> to the RX queue 0)
> >
> > This is now working for me, testing with the dst MAC being the MAC on the
> i210.  I set the filter and all the traffic to the destination MAC address 
> gets
> routed to the chosen RX queue.
> >
> >> $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 action 3
> >> (this will direct packets with source address "44:44:44:44:44:44" to
> >> the RX queue 3)

Since this apparently does not work without refining the filter down to an 
ethertype I would like to see this example touched up to include the proto 
keyword.

> >
> > However, I am still not getting the raw ethernet source filter to
> > work.  Even back to back with no other system to "confuse" the stream,
> > I set the filter so the source MAC is the same as the MAC on the link
> > partner, send traffic and the traffic bounces around the queues as if
> > the filter is not set.
> 
> It seems there is at least a documentation issue in the i210 datasheet,
> steering (placing traffic into a specific queue) by source address
> doesn't work, filtering (accepting the traffic based on some rule) does
> work. I pointed this out in the cover letter of v5 as a known issue, but
> forgot to repeat it for v6, sorry about the confusion.

Yes, I recall that now.  I don't think I quite understood the implication at 
the time, but after trying it out it that makes perfect sense with what I am 
seeing.

> 
> But only the filtering part is useful, I think, it enables cases like
> this:
> 
> $ ethtool -N enp2s0 flow-type ether src 68:05:ca:4a:c9:73 proto 0x22f0 action
> 3

Ok, yes, this works.  If I tack on the proto keyword I can filter on whatever 
ethertype I choose and it seems to direct to the queue as expected.

> 
> I added that note in the hope that someone else would have an stronger
> opinion about what to do.

I don't have a strong opinion beyond my preference for an ideal world where 
everything works :)  If the part simply cannot filter on the src address as a 
whole without the protocol I would ideally prefer an attempt in ethtool to set 
the filter on src address as a whole to return an error WHILE still allowing 
the filter to be set on an ethertype when the proto keyword is issued.  If 
ethtool does not allow that fine grain of control then I think the way it is 
now is good, I'd rather have the annoyance of being able to set a filter that 
does nothing then not be able to set the more specific filter at all.  

> 
> Anyway, my plan for now will be to document this better and turn the
> case that only the source address is specified into an error.
> 
> >
> >>
> >> Signed-off-by: Vinicius Costa Gomes <vinicius.go...@intel.com>
> >> ---
> >>  drivers/net/ethernet/intel/igb/igb_ethtool.c | 35
> >> 
> >>  1 file changed, 31 insertions(+), 4 deletions(-)
> 
> 
> Cheers,
> --
> Vinicius

RE: [Intel-wired-lan] [next-queue PATCH v6 08/10] igb: Add MAC address support for ethtool nftuple filters

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Thursday, March 29, 2018 2:08 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: [Intel-wired-lan] [next-queue PATCH v6 08/10] igb: Add MAC
> address support for ethtool nftuple filters
> 
> This adds the capability of configuring the queue steering of arriving
> packets based on their source and destination MAC addresses.
> 
> In practical terms this adds support for the following use cases,
> characterized by these examples:
> 
> $ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0
> (this will direct packets with destination address "aa:aa:aa:aa:aa:aa"
> to the RX queue 0)

This is now working for me, testing with the dst MAC being the MAC on the i210. 
 I set the filter and all the traffic to the destination MAC address gets 
routed to the chosen RX queue.

> $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 action 3
> (this will direct packets with source address "44:44:44:44:44:44" to
> the RX queue 3)

However, I am still not getting the raw ethernet source filter to work.  Even 
back to back with no other system to "confuse" the stream, I set the filter so 
the source MAC is the same as the MAC on the link partner, send traffic and the 
traffic bounces around the queues as if the filter is not set.

> 
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  drivers/net/ethernet/intel/igb/igb_ethtool.c | 35
> 
>  1 file changed, 31 insertions(+), 4 deletions(-)

RE: [Intel-wired-lan] [next-queue PATCH v5 7/9] igb: Add MAC address support for ethtool nftuple filters

[Brown, Aaron F]

> From: Gomes, Vinicius
> Sent: Monday, March 26, 2018 4:56 PM
> To: Brown, Aaron F <aaron.f.br...@intel.com>; intel-wired-
> l...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: RE: [Intel-wired-lan] [next-queue PATCH v5 7/9] igb: Add MAC
> address support for ethtool nftuple filters
> 
> Hi Aaron,
> 
> "Brown, Aaron F" <aaron.f.br...@intel.com> writes:
> 
> >
> > Maybe not "this" patch, but this is the one that enables the ethtool
> commands, so replying here.
> > The filters do not seem to take effect with this version (v5) of the
> > series.  The commands are accepted for i210 and rejected with
> > unsupported messages for the other adapters (as desired) and an
> > ethtool -n shows the filter, however, with either the src or dst
> > filter set I can run traffic (netperf) that should be caught by the
> > filter and rather than being directed to the single queue it is spread
> > across queues as would be expected without the filter set.
> >
> > The test system still has a kernel / driver with the v4 series of this
> > patch set and the exact same filter commands / system setup does
> > filter the traffic to the specified rx queue with the v4 series.
> 
> That's interesting. The only difference is that now non steering filters
> (filters added by 'ip (m)addr', PACKET_ADD_MEMBERSHIP and the local MAC
> address, for example) do not have the QSEL bit set.
> 
> On my tests I cannot detect any change in behaviour between those two
> versions of the series, for example. trying to add a filter for the
> local MAC address has no visible effect in both versions. (This raises a
> question: should this be an error, or should this override the default
> entry configuration, or this behaviour is fine?)
> 
> Can you share more information about your tests? so I can reproduce it here.

Sure, on I'm running a system the i210 is eth3 and it is linked back to back 
(crossover cable) to a link partner.  The i210 has a mac address of 
a0:36:9f:10:cc:d7 and the MAC address of the port it is connected to is 
00:1b:21:60:29:ea.  It should not matter, but eth0 is an older e1000 based 
adapter (82540EM) I use for connecting ssh sessions, eth1 and eth2 are other 
igb ports (a dual port 82575EB adapter.)

I tried both an ethtool src and ethtool dst filter with these addresses and 
with the older version they both seemed to work and with the latest patch in 
place neither seemed to work.  My steps were to set the filter, check that 
ethtool shows the filter in place then run some netperf traffic (using a script 
we have called netperf_stress that cycles through a number of sessions to 
provide constant traffic) and from another login session I watched the rx_queue 
counters.

For the src filter I used the MAC address of the link partner eth3 interface, 
00:1b:21:60:29:ea :
-
u1485:[0]/root> ethtool -N eth3 flow-type ether src 00:1b:21:60:29:ea action 0
Added rule with ID 15
u1485:[0]/root> ethtool -n eth3
4 RX rings available
Total 1 rules

Filter: 15
Flow Type: Raw Ethernet
Src MAC addr: 00:1B:21:60:29:EA mask: 00:00:00:00:00:00
Dest MAC addr: 00:00:00:00:00:00 mask: FF:FF:FF:FF:FF:FF
Ethertype: 0x0 mask: 0x
Action: Direct to VF 0 queue 0

u1485:[0]/root>netperf_stress u0485-3
Test limit is NONE
Found netperf support
u0485:[0]/root

Contacted u0485-3

-> Testing with u0485-3 - Testing since Mon Mar 26 17:35:32 PDT 2018
...
...
-
Then on another login I watch on an ethtool stat dump grepping for rx_queue.  I 
threw a -d to get a better visual of the differences.

-
1485:[1]/root> watch -d 'ethtool -S eth3|grep rx_queue'
Every 2.0s: ethtool -S eth3|grep rx_queue   Mon Mar 26 18:19:21 2018

 rx_queue_0_packets: 13
 rx_queue_0_bytes: 2204
 rx_queue_0_drops: 0
 rx_queue_0_csum_err: 0
 rx_queue_0_alloc_failed: 0
 rx_queue_1_packets: 330677
 rx_queue_1_bytes: 500632203
 rx_queue_1_drops: 0
 rx_queue_1_csum_err: 0
 rx_queue_1_alloc_failed: 0
 rx_queue_2_packets: 141902
 rx_queue_2_bytes: 214787953
 rx_queue_2_drops: 0
 rx_queue_2_csum_err: 0
 rx_queue_2_alloc_failed: 0
 rx_queue_3_packets: 234377
 rx_queue_3_bytes: 347172517
 rx_queue_3_drops: 0
 rx_queue_3_csum_err: 0
 rx_queue_3_alloc_failed: 0
-
After a few moments I can tell the counters are all over the place.  I do 
pretty much the exact same thing for the dst filter, except I use the i210'

RE: [Intel-wired-lan] [next-queue PATCH v5 7/9] igb: Add MAC address support for ethtool nftuple filters

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Wednesday, March 21, 2018 5:34 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: [Intel-wired-lan] [next-queue PATCH v5 7/9] igb: Add MAC address
> support for ethtool nftuple filters
> 
> This adds the capability of configuring the queue steering of arriving
> packets based on their source and destination MAC addresses.
> 
> In practical terms this adds support for the following use cases,
> characterized by these examples:
> 
> $ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0
> (this will direct packets with destination address "aa:aa:aa:aa:aa:aa"
> to the RX queue 0)
> 
> $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 action 3
> (this will direct packets with source address "44:44:44:44:44:44" to
> the RX queue 3)
> 
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  drivers/net/ethernet/intel/igb/igb_ethtool.c | 35
> 
>  1 file changed, 31 insertions(+), 4 deletions(-)

Maybe not "this" patch, but this is the one that enables the ethtool commands, 
so replying here.
The filters do not seem to take effect with this version (v5) of the series.  
The commands are accepted for i210 and rejected with unsupported messages for 
the other adapters (as desired) and an ethtool -n shows the filter, however, 
with either the src or dst filter set I can run traffic (netperf) that should 
be caught by the filter and rather than being directed to the single queue it 
is spread across queues as would be expected without the filter set.

The test system still has a kernel / driver with the v4 series of this patch 
set and the exact same filter commands / system setup does filter the traffic 
to the specified rx queue with the v4 series.

RE: [Intel-wired-lan] [next-queue PATCH v4 6/8] igb: Add MAC address support for ethtool nftuple filters

[Brown, Aaron F]

> From: Alexander Duyck [mailto:alexander.du...@gmail.com]
> Sent: Friday, March 16, 2018 11:07 AM
> To: Gomes, Vinicius <vinicius.go...@intel.com>
> Cc: Brown, Aaron F <aaron.f.br...@intel.com>; intel-wired-
> l...@lists.osuosl.org; netdev@vger.kernel.org; Sanchez-Palencia, Jesus
> <jesus.sanchez-palen...@intel.com>
> Subject: Re: [Intel-wired-lan] [next-queue PATCH v4 6/8] igb: Add MAC
> address support for ethtool nftuple filters
> 
> On Fri, Mar 16, 2018 at 10:59 AM, Vinicius Costa Gomes
> <vinicius.go...@intel.com> wrote:
> > Hi,
> >
> > Alexander Duyck <alexander.du...@gmail.com> writes:
> >
> >> On Tue, Mar 13, 2018 at 8:04 PM, Brown, Aaron F
> <aaron.f.br...@intel.com> wrote:
> >>>> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> >>>> Behalf Of Vinicius Costa Gomes
> >>>> Sent: Wednesday, March 7, 2018 4:37 PM
> >>>> To: intel-wired-...@lists.osuosl.org
> >>>> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  >>>> palen...@intel.com>
> >>>> Subject: [Intel-wired-lan] [next-queue PATCH v4 6/8] igb: Add MAC
> address
> >>>> support for ethtool nftuple filters
> >>>>
> >>>> This adds the capability of configuring the queue steering of arriving
> >>>> packets based on their source and destination MAC addresses.
> >>>>
> >>>> In practical terms this adds support for the following use cases,
> >>>> characterized by these examples:
> >>>>
> >>>> $ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0
> >>>> (this will direct packets with destination address "aa:aa:aa:aa:aa:aa"
> >>>> to the RX queue 0)
> >>>>
> >>>> $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 action 3
> >>>> (this will direct packets with source address "44:44:44:44:44:44" to
> >>>> the RX queue 3)
> >>>
> >>> This seems to work fine on i210, and the patch series allows me to set
> the rx filters on the i350, i354 and i211, but it is not directing the 
> packets to
> the queue I request.
> >>>
> >>> With the exception of i210 the rx_queues number does not seem to be
> effected by setting the filter.  In the case of i211 the rx packets stay on
> rx_queue 0 with or without an ether src or dst filter.  The first example one
> seems to work at first since it's directing to queue 0, but changing the 
> filter to
> "action 1" does not change the behavior.  With the i350 and i354 ports the
> packets are spread across the rx_queues with or without the filter set.
> >>
> >> Do any of the other parts actually support this functionality? I don't
> >> think they do.
> >
> > From what I can see, the only other part that supports queue steering (by
> MAC
> > addresses) is the 82575. But as I don't have any of those handy, making
> > it work only for the i210 seems more reasonable, to avoid getting into
> > this situation again.
> 
> That sounds good to me. What you might do is add a comment explaining
> that this is only supported on 82575 and i210 wherever you put the
> check that limits this. Then if we have time for the
> development/validation efforts, or someone in the community does they
> could take it upon themselves to enable and test it for 82575.
> 
> I have done similar things in the past. As long as it is clear that
> the reason why we limited it to i210 is mostly because of
> development/validation resources somebody else can come along and
> enable it if they have the resources and time to invest in doing so.

I do have a few of 82575 NICs in my lab and am perfectly willing to test them 
on whatever you come up with.  But I don't believe it is a common part at all 
so have no qualms with limiting it to i210.

RE: [Intel-wired-lan] [next-queue PATCH v4 2/8] igb: Fix queue selection on MAC filters on i210 and i211

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Wednesday, March 7, 2018 4:37 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: [Intel-wired-lan] [next-queue PATCH v4 2/8] igb: Fix queue selection
> on MAC filters on i210 and i211
> 
> On the RAH registers there are semantic differences on the meaning of
> the "queue" parameter for traffic steering depending on the controller
> model: there is the 82575 meaning, which "queue" means a RX Hardware
> Queue, and the i350 meaning, where it is a reception pool.
> 
> The previous behaviour was having no effect for i210 and i211 based
> controllers because the QSEL bit of the RAH register wasn't being set.
> 
> This patch separates the condition in discrete cases, so the different
> handling is clearer.
> 
> Fixes: 83c21335c876 ("igb: improve MAC filter handling")
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  drivers/net/ethernet/intel/igb/e1000_defines.h |  1 +
>  drivers/net/ethernet/intel/igb/igb_main.c  | 15 +++
>  2 files changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/igb/e1000_defines.h
> b/drivers/net/ethernet/intel/igb/e1000_defines.h
> index 83cabff1e0ab..573bf177fd08 100644
> --- a/drivers/net/ethernet/intel/igb/e1000_defines.h
> +++ b/drivers/net/ethernet/intel/igb/e1000_defines.h
> @@ -490,6 +490,7 @@
>   * manageability enabled, allowing us room for 15 multicast addresses.
>   */
>  #define E1000_RAH_AV  0x8000/* Receive descriptor valid */
> +#define E1000_RAH_QSEL_ENABLE 0x1000
>  #define E1000_RAL_MAC_ADDR_LEN 4
>  #define E1000_RAH_MAC_ADDR_LEN 2
>  #define E1000_RAH_POOL_MASK 0x03FC
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
> b/drivers/net/ethernet/intel/igb/igb_main.c
> index 715bb32e6901..eabedc6b6518 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -8747,12 +8747,19 @@ static void igb_rar_set_index(struct igb_adapter
> *adapter, u32 index)
>   if (is_valid_ether_addr(addr))
>   rar_high |= E1000_RAH_AV;
> 
> - if (hw->mac.type == e1000_82575)
> + switch (hw->mac.type) {
> + case e1000_82575:
> + case e1000_i210:
> + case e1000_i211:
> + rar_high |= E1000_RAH_QSEL_ENABLE;
>   rar_high |= E1000_RAH_POOL_1 *
> - adapter->mac_table[index].queue;
> - else
> +   adapter->mac_table[index].queue;
> + break;
> + default:
>   rar_high |= E1000_RAH_POOL_1 <<
> - adapter->mac_table[index].queue;
> + adapter->mac_table[index].queue;

Small nit.  Shouldn't this line be indented more to be a few spaces past the 
"|=" operator as above?

> + break;
> + }
>   }
> 
>   wr32(E1000_RAL(index), rar_low);
> --
> 2.16.2
> 
> ___
> Intel-wired-lan mailing list
> intel-wired-...@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

RE: [Intel-wired-lan] [next-queue PATCH v4 6/8] igb: Add MAC address support for ethtool nftuple filters

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Wednesday, March 7, 2018 4:37 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: [Intel-wired-lan] [next-queue PATCH v4 6/8] igb: Add MAC address
> support for ethtool nftuple filters
> 
> This adds the capability of configuring the queue steering of arriving
> packets based on their source and destination MAC addresses.
> 
> In practical terms this adds support for the following use cases,
> characterized by these examples:
> 
> $ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0
> (this will direct packets with destination address "aa:aa:aa:aa:aa:aa"
> to the RX queue 0)
> 
> $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 action 3
> (this will direct packets with source address "44:44:44:44:44:44" to
> the RX queue 3)

This seems to work fine on i210, and the patch series allows me to set the rx 
filters on the i350, i354 and i211, but it is not directing the packets to the 
queue I request.

With the exception of i210 the rx_queues number does not seem to be effected by 
setting the filter.  In the case of i211 the rx packets stay on rx_queue 0 with 
or without an ether src or dst filter.  The first example one seems to work at 
first since it's directing to queue 0, but changing the filter to "action 1" 
does not change the behavior.  With the i350 and i354 ports the packets are 
spread across the rx_queues with or without the filter set.

> 
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  drivers/net/ethernet/intel/igb/igb_ethtool.c | 35
> 
>  1 file changed, 31 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c
> b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> index 94fc9a4bed8b..3f98299d4cd0 100644
> --- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
> +++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> @@ -2494,6 +2494,23 @@ static int igb_get_ethtool_nfc_entry(struct
> igb_adapter *adapter,
>   fsp->h_ext.vlan_tci = rule->filter.vlan_tci;
>   fsp->m_ext.vlan_tci = htons(VLAN_PRIO_MASK);
>   }
> + if (rule->filter.match_flags &
> IGB_FILTER_FLAG_DST_MAC_ADDR) {
> + ether_addr_copy(fsp->h_u.ether_spec.h_dest,
> + rule->filter.dst_addr);
> + /* As we only support matching by the full
> +  * mask, return the mask to userspace
> +  */
> + eth_broadcast_addr(fsp->m_u.ether_spec.h_dest);
> + }
> + if (rule->filter.match_flags &
> IGB_FILTER_FLAG_SRC_MAC_ADDR) {
> + ether_addr_copy(fsp->h_u.ether_spec.h_source,
> + rule->filter.src_addr);
> + /* As we only support matching by the full
> +  * mask, return the mask to userspace
> +  */
> + eth_broadcast_addr(fsp-
> >m_u.ether_spec.h_source);
> + }
> +
>   return 0;
>   }
>   return -EINVAL;
> @@ -2932,10 +2949,6 @@ static int igb_add_ethtool_nfc_entry(struct
> igb_adapter *adapter,
>   if ((fsp->flow_type & ~FLOW_EXT) != ETHER_FLOW)
>   return -EINVAL;
> 
> - if (fsp->m_u.ether_spec.h_proto != ETHER_TYPE_FULL_MASK &&
> - fsp->m_ext.vlan_tci != htons(VLAN_PRIO_MASK))
> - return -EINVAL;
> -
>   input = kzalloc(sizeof(*input), GFP_KERNEL);
>   if (!input)
>   return -ENOMEM;
> @@ -2945,6 +2958,20 @@ static int igb_add_ethtool_nfc_entry(struct
> igb_adapter *adapter,
>   input->filter.match_flags = IGB_FILTER_FLAG_ETHER_TYPE;
>   }
> 
> + /* Only support matching addresses by the full mask */
> + if (is_broadcast_ether_addr(fsp->m_u.ether_spec.h_source)) {
> + input->filter.match_flags |=
> IGB_FILTER_FLAG_SRC_MAC_ADDR;
> + ether_addr_copy(input->filter.src_addr,
> + fsp->h_u.ether_spec.h_source);
> + }
> +
> + /* Only support matching addresses by the full mask */
> + if (is_broadcast_ether_addr(fsp->m_u.ether_spec.h_dest)) {
> + input->filter.match_flags |=
> IGB_FILTER_FLAG_DST_MAC_ADDR;
> + ether_addr_copy(input->filter.dst_addr,
> + fsp->h_u.ether_spec.h_dest);
> + }
> +
>   if ((fsp->flow_type & FLOW_EXT) && fsp->m_ext.vlan_tci) {
>   if (fsp->m_ext.vlan_tci != htons(VLAN_PRIO_MASK)) {
>   err = -EINVAL;
> --
> 2.16.2
> 
> ___
> Intel-wired-lan mailing list
> intel-wired-...@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

RE: [PATCH 2/2] e1000e: Fix link check race condition

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Benjamin Poirier
> Sent: Monday, March 5, 2018 5:56 PM
> To: Kirsher, Jeffrey T 
> Cc: Alexander Duyck ; Lennart Sorensen
> ; intel-wired-...@lists.osuosl.org;
> netdev@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: [PATCH 2/2] e1000e: Fix link check race condition
> 
> Alex reported the following race condition:
> 
> /* link goes up... interrupt... schedule watchdog */
> \ e1000_watchdog_task
>   \ e1000e_has_link
>   \ hw->mac.ops.check_for_link() ===
> e1000e_check_for_copper_link
>   \ e1000e_phy_has_link_generic(..., )
>   link = true
> 
>/* link goes down... interrupt */
>\ e1000_msix_other
>hw->mac.get_link_status =
> true
> 
>   /* link is up */
>   mac->get_link_status = false
> 
>   link_active = true
>   /* link_active is true, wrongly, and stays so because
>* get_link_status is false */
> 
> Avoid this problem by making sure that we don't set get_link_status = false
> after having checked the link.
> 
> It seems this problem has been present since the introduction of e1000e.
> 
> Link: https://lkml.org/lkml/2018/1/29/338
> Reported-by: Alexander Duyck 
> Signed-off-by: Benjamin Poirier 
> ---
>  drivers/net/ethernet/intel/e1000e/ich8lan.c | 31 ---
> --
>  drivers/net/ethernet/intel/e1000e/mac.c | 14 ++---
>  2 files changed, 24 insertions(+), 21 deletions(-)

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH 1/2] Revert "e1000e: Separate signaling for link check/link up"

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Benjamin Poirier
> Sent: Monday, March 5, 2018 5:56 PM
> To: Kirsher, Jeffrey T 
> Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org; Lennart Sorensen 
> Subject: [Intel-wired-lan] [PATCH 1/2] Revert "e1000e: Separate signaling for
> link check/link up"
> 
> This reverts commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013.
> This reverts commit 4110e02eb45ea447ec6f5459c9934de0a273fb91.
> This reverts commit d3604515c9eda464a92e8e67aae82dfe07fe3c98.
> 
> Commit 19110cfbb34d ("e1000e: Separate signaling for link check/link up")
> changed what happens to the link status when there is an error which
> happens after "get_link_status = false" in the copper check_for_link
> callbacks. Previously, such an error would be ignored and the link
> considered up. After that commit, any error implies that the link is down.
> 
> Revert commit 19110cfbb34d ("e1000e: Separate signaling for link check/link
> up") and its followups. After reverting, the race condition described in
> the log of commit 19110cfbb34d is reintroduced. It may still be triggered
> by LSC events but this should keep the link down in case the link is
> electrically unstable, as discussed. The race may no longer be
> triggered by RXO events because commit 4aea7a5c5e94 ("e1000e: Avoid
> receiver overrun interrupt bursts") restored reading icr in the Other
> handler.
> 
> Link: https://lkml.org/lkml/2018/3/1/789
> Signed-off-by: Benjamin Poirier 
> ---
>  drivers/net/ethernet/intel/e1000e/ich8lan.c | 13 -
>  drivers/net/ethernet/intel/e1000e/mac.c | 13 -
>  drivers/net/ethernet/intel/e1000e/netdev.c  |  2 +-
>  3 files changed, 9 insertions(+), 19 deletions(-)
> 

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [next-queue PATCH v3 6/8] igb: Add MAC address support for ethtool nftuple filters

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Tuesday, March 6, 2018 5:30 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: [Intel-wired-lan] [next-queue PATCH v3 6/8] igb: Add MAC address
> support for ethtool nftuple filters
> 
> This adds the capability of configuring the queue steering of arriving
> packets based on their source and destination MAC addresses.
> 
> In practical terms this adds support for the following use cases,
> characterized by these examples:
> 
> $ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0
> (this will direct packets with destination address "aa:aa:aa:aa:aa:aa"
> to the RX queue 0)
> 
> $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 action 3
> (this will direct packets with destination address "44:44:44:44:44:44"
> to the RX queue 3)

I assume this example should read "... source address"  rather than 
"...destination".

> 
> Signed-off-by: Vinicius Costa Gomes 
> ---
>  drivers/net/ethernet/intel/igb/igb_ethtool.c | 35
> 
>  1 file changed, 31 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c
> b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> index 94fc9a4bed8b..3f98299d4cd0 100644
> --- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
> +++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> @@ -2494,6 +2494,23 @@ static int igb_get_ethtool_nfc_entry(struct
> igb_adapter *adapter,
>   fsp->h_ext.vlan_tci = rule->filter.vlan_tci;
>   fsp->m_ext.vlan_tci = htons(VLAN_PRIO_MASK);
>   }
> + if (rule->filter.match_flags &
> IGB_FILTER_FLAG_DST_MAC_ADDR) {
> + ether_addr_copy(fsp->h_u.ether_spec.h_dest,
> + rule->filter.dst_addr);
> + /* As we only support matching by the full
> +  * mask, return the mask to userspace
> +  */
> + eth_broadcast_addr(fsp->m_u.ether_spec.h_dest);
> + }
> + if (rule->filter.match_flags &
> IGB_FILTER_FLAG_SRC_MAC_ADDR) {
> + ether_addr_copy(fsp->h_u.ether_spec.h_source,
> + rule->filter.src_addr);
> + /* As we only support matching by the full
> +  * mask, return the mask to userspace
> +  */
> + eth_broadcast_addr(fsp-
> >m_u.ether_spec.h_source);
> + }
> +
>   return 0;
>   }
>   return -EINVAL;
> @@ -2932,10 +2949,6 @@ static int igb_add_ethtool_nfc_entry(struct
> igb_adapter *adapter,
>   if ((fsp->flow_type & ~FLOW_EXT) != ETHER_FLOW)
>   return -EINVAL;
> 
> - if (fsp->m_u.ether_spec.h_proto != ETHER_TYPE_FULL_MASK &&
> - fsp->m_ext.vlan_tci != htons(VLAN_PRIO_MASK))
> - return -EINVAL;
> -
>   input = kzalloc(sizeof(*input), GFP_KERNEL);
>   if (!input)
>   return -ENOMEM;
> @@ -2945,6 +2958,20 @@ static int igb_add_ethtool_nfc_entry(struct
> igb_adapter *adapter,
>   input->filter.match_flags = IGB_FILTER_FLAG_ETHER_TYPE;
>   }
> 
> + /* Only support matching addresses by the full mask */
> + if (is_broadcast_ether_addr(fsp->m_u.ether_spec.h_source)) {
> + input->filter.match_flags |=
> IGB_FILTER_FLAG_SRC_MAC_ADDR;
> + ether_addr_copy(input->filter.src_addr,
> + fsp->h_u.ether_spec.h_source);
> + }
> +
> + /* Only support matching addresses by the full mask */
> + if (is_broadcast_ether_addr(fsp->m_u.ether_spec.h_dest)) {
> + input->filter.match_flags |=
> IGB_FILTER_FLAG_DST_MAC_ADDR;
> + ether_addr_copy(input->filter.dst_addr,
> + fsp->h_u.ether_spec.h_dest);
> + }
> +
>   if ((fsp->flow_type & FLOW_EXT) && fsp->m_ext.vlan_tci) {
>   if (fsp->m_ext.vlan_tci != htons(VLAN_PRIO_MASK)) {
>   err = -EINVAL;
> --
> 2.16.2
> 
> ___
> Intel-wired-lan mailing list
> intel-wired-...@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

RE: [Intel-wired-lan] [PATCH net-queue] e1000e: Fix check_for_link return value with autoneg off.

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Benjamin Poirier
> Sent: Monday, February 19, 2018 10:12 PM
> To: Kirsher, Jeffrey T 
> Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH net-queue] e1000e: Fix check_for_link
> return value with autoneg off.
> 
> When autoneg is off, the .check_for_link callback functions clear the
> get_link_status flag and systematically return a "pseudo-error". This means
> that the link is not detected as up until the next execution of the
> e1000_watchdog_task() 2 seconds later.
> 
> Fixes: 19110cfbb34d ("e1000e: Separate signaling for link check/link up")
> Signed-off-by: Benjamin Poirier 
> ---
>  drivers/net/ethernet/intel/e1000e/ich8lan.c | 2 +-
>  drivers/net/ethernet/intel/e1000e/mac.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH net-queue 3/3] e1000e: Avoid missed interrupts following ICR read.

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Benjamin Poirier
> Sent: Wednesday, February 7, 2018 10:47 PM
> To: Kirsher, Jeffrey T 
> Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH net-queue 3/3] e1000e: Avoid missed
> interrupts following ICR read.
> 
> The 82574 specification update errata 12 states that interrupts may be
> missed if ICR is read while INT_ASSERTED is not set. Avoid that problem by
> setting all bits related to events that can trigger the Other interrupt in
> IMS.
> 
> The Other interrupt is raised for such events regardless of whether or not
> they are set in IMS. However, only when they are set is the INT_ASSERTED
> bit also set in ICR.
> 
> By doing this, we ensure that INT_ASSERTED is always set when we read ICR
> in e1000_msix_other() and steer clear of the errata. This also ensures that
> ICR will automatically be cleared on read, therefore we no longer need to
> clear bits explicitly.
> 
> Signed-off-by: Benjamin Poirier 
> ---
>  drivers/net/ethernet/intel/e1000e/defines.h | 21
> -
>  drivers/net/ethernet/intel/e1000e/netdev.c  | 11 ---
>  2 files changed, 24 insertions(+), 8 deletions(-)
> 

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH net-queue 1/3] Partial revert "e1000e: Avoid receiver overrun interrupt bursts"

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Benjamin Poirier
> Sent: Wednesday, February 7, 2018 10:47 PM
> To: Kirsher, Jeffrey T 
> Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH net-queue 1/3] Partial revert "e1000e:
> Avoid receiver overrun interrupt bursts"
> 
> This partially reverts commit 4aea7a5c5e940c1723add439f4088844cd26196d.
> 
> We keep the fix for the first part of the problem (1) described in the log
> of that commit, that is to read ICR in the other interrupt handler. We
> remove the fix for the second part of the problem (2), Other interrupt
> throttling.
> 
> Bursts of "Other" interrupts may once again occur during rxo (receive
> overflow) traffic conditions. This is deemed acceptable in the interest of
> avoiding unforeseen fallout from changes that are not strictly necessary.
> As discussed, the e1000e driver should be in "maintenance mode".
> 
> Link: https://www.spinics.net/lists/netdev/msg480675.html
> Signed-off-by: Benjamin Poirier 
> ---
>  drivers/net/ethernet/intel/e1000e/netdev.c | 16 ++--
>  1 file changed, 2 insertions(+), 14 deletions(-)

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH net-queue 2/3] e1000e: Fix queue interrupt re-raising in Other interrupt.

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Benjamin Poirier
> Sent: Wednesday, February 7, 2018 10:47 PM
> To: Kirsher, Jeffrey T 
> Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH net-queue 2/3] e1000e: Fix queue
> interrupt re-raising in Other interrupt.
> 
> restores the ICS write for rx/tx queue interrupts which was present before
> commit 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt",
> v4.5-rc1) but was not restored in commit 4aea7a5c5e94 ("e1000e: Avoid
> receiver overrun interrupt bursts", v4.15-rc1).
> 
> This re-raises the queue interrupts in case the txq or rxq bits were set in
> ICR and the Other interrupt handler read and cleared ICR before the queue
> interrupt was raised.
> 
> Fixes: 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt bursts")
> Signed-off-by: Benjamin Poirier 
> ---
>  drivers/net/ethernet/intel/e1000e/netdev.c | 3 +++
>  1 file changed, 3 insertions(+)

Tested-by: Aaron Brown 

RE: [PATCH] igb: Fix a test with HWTSTAMP_TX_ON

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Christophe JAILLET
> Sent: Tuesday, February 6, 2018 11:48 AM
> To: Kirsher, Jeffrey T 
> Cc: intel-wired-...@lists.osuosl.org; netdev@vger.kernel.org; linux-
> ker...@vger.kernel.org; kernel-janit...@vger.kernel.org; Christophe
> JAILLET 
> Subject: [PATCH] igb: Fix a test with HWTSTAMP_TX_ON
> 
> 'HWTSTAMP_TX_ON' should be handled as a value, not as a bit mask.
> The modified code should behave the same, because HWTSTAMP_TX_ON is
> 1
> and no other possible values of 'tx_type' would match the test.
> However, this is more future-proof, should other values be allowed one day.
> 
> See 'struct hwtstamp_config' in 'include/uapi/linux/net_tstamp.h'
> 
> This fixes a warning reported by smatch:
>igb_xmit_frame_ring() warn: bit shifter 'HWTSTAMP_TX_ON' used for
> logical '&'
> 
> Fixes: 26bd4e2db06be ("igb: protect TX timestamping from API misuse")
> Signed-off-by: Christophe JAILLET 
> ---
>  drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Tested-by: Aaron Brown 

RE: [PATCH] e1000e: allocate ring descriptors with dma_zalloc_coherent

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Pierre-Yves Kerbrat
> Sent: Friday, January 26, 2018 2:24 AM
> To: Kirsher, Jeffrey T ; intel-wired-
> l...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Marius Gligor 
> Subject: [PATCH] e1000e: allocate ring descriptors with dma_zalloc_coherent
> 
> Descriptor rings were not initialized at zero when allocated
> When area contained garbage data, it caused skb_over_panic in
> e1000_clean_rx_irq (if data had E1000_RXD_STAT_DD bit set)
> 
> This patch makes use of dma_zalloc_coherent to make sure the
> ring is memset at 0 to prevent the area from containing garbage.
> 
> Following is the signature of the panic:
> IODDR0@0.0: skbuff: skb_over_panic: text:80407b20 len:64010 put:64010
> head:ab46d800 data:ab46d842 tail:0xab47d24c end:0xab46df40 dev:eth0
> IODDR0@0.0: BUG: failure at net/core/skbuff.c:105/skb_panic()!
> IODDR0@0.0: Kernel panic - not syncing: BUG!
> IODDR0@0.0:
> IODDR0@0.0: Process swapper/0 (pid: 0, threadinfo=81728000,
> task=8173cc00 ,cpu: 0)
> IODDR0@0.0: SP = <815a1c0c>
> IODDR0@0.0: Stack:  0001
> IODDR0@0.0: b2d89800 815e33ac
> IODDR0@0.0: ea73c040 0001
> IODDR0@0.0: 60040003 fa0a
> IODDR0@0.0: 0002
> IODDR0@0.0:
> IODDR0@0.0: 804540c0 815a1c70
> IODDR0@0.0: b2744000 602ac070
> IODDR0@0.0: 815a1c44 b2d89800
> IODDR0@0.0: 8173cc00 815a1c08
> IODDR0@0.0:
> IODDR0@0.0: 0006
> IODDR0@0.0: 815a1b50 
> IODDR0@0.0: 80079434 0001
> IODDR0@0.0: ab46df40 b2744000
> IODDR0@0.0: b2d89800
> IODDR0@0.0:
> IODDR0@0.0: fa0a 8045745c
> IODDR0@0.0: 815a1c88 fa0a
> IODDR0@0.0: 80407b20 b2789f80
> IODDR0@0.0: 0005 80407b20
> IODDR0@0.0:
> IODDR0@0.0:
> IODDR0@0.0: Call Trace:
> IODDR0@0.0: [<804540bc>] skb_panic+0xa4/0xa8
> IODDR0@0.0: [<80079430>] console_unlock+0x2f8/0x6d0
> IODDR0@0.0: [<80457458>] skb_put+0xa0/0xc0
> IODDR0@0.0: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
> IODDR0@0.0: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
> IODDR0@0.0: [<804079c8>] e1000_clean_rx_irq+0x188/0x3e8
> IODDR0@0.0: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
> IODDR0@0.0: [<80468b48>] __dev_kfree_skb_any+0x88/0xa8
> IODDR0@0.0: [<804101ac>] e1000e_poll+0x94/0x288
> IODDR0@0.0: [<8046e9d4>] net_rx_action+0x19c/0x4e8
> IODDR0@0.0:   ...
> IODDR0@0.0: Maximum depth to print reached. Use
> kstack= To specify a custom value (where 0
> means to display the full backtrace)
> IODDR0@0.0: ---[ end Kernel panic - not syncing: BUG!
> 
> Signed-off-by: Pierre-Yves Kerbrat 
> Signed-off-by: Marius Gligor 
> ---
>  drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Tested-by: Aaron Brown 

RE: [PATCH] igb: Do not call netif_device_detach() when PCIe link goes missing

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Mika Westerberg
> Sent: Tuesday, January 23, 2018 2:29 AM
> To: Kirsher, Jeffrey T 
> Cc: Ferenc Boldog ; Nikolay Bogoychev
> ; Mika Westerberg
> ; intel-wired-...@lists.osuosl.org;
> netdev@vger.kernel.org
> Subject: [PATCH] igb: Do not call netif_device_detach() when PCIe link goes
> missing
> 
> When the driver notices that PCIe link is gone by reading 0x
> from a register it clears hw->hw_addr and then calls netif_device_detach().
> This happens when the PCIe device is physically unplugged for example
> the user disconnected the Thunderbolt cable.
> 
> However, netif_device_detach() prevents netif_unregister() from bringing
> the device down properly including tearing down MSI-X vectors. This
> triggers following crash during the driver removal:
> 
>   igb :0b:00.0 enp11s0f0: PCIe link lost, device now detached
>   [ cut here ]
>   kernel BUG at drivers/pci/msi.c:352!
>   invalid opcode:  [#1] PREEMPT SMP PTI
>   ...
>   Call Trace:
>pci_disable_msix+0xc9/0xf0
>igb_reset_interrupt_capability+0x58/0x60 [igb]
>igb_remove+0x90/0x100 [igb]
>pci_device_remove+0x31/0xa0
>device_release_driver_internal+0x152/0x210
>pci_stop_bus_device+0x78/0xa0
>pci_stop_bus_device+0x38/0xa0
>pci_stop_bus_device+0x38/0xa0
>pci_stop_bus_device+0x26/0xa0
>pci_stop_bus_device+0x38/0xa0
>pci_stop_and_remove_bus_device+0x9/0x20
>trim_stale_devices+0xee/0x130
>? _raw_spin_unlock_irqrestore+0xf/0x30
>trim_stale_devices+0x8f/0x130
>? _raw_spin_unlock_irqrestore+0xf/0x30
>trim_stale_devices+0xa1/0x130
>? get_slot_status+0x8b/0xc0
>acpiphp_check_bridge.part.7+0xf9/0x140
>acpiphp_hotplug_notify+0x170/0x1f0
>...
> 
> To prevent the crash do not call netif_device_detach() in igb_rd32().
> This should be fine because hw->hw_addr is set to NULL preventing future
> hardware access of the now missing device.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=198181
> Reported-by: Ferenc Boldog 
> Reported-by: Nikolay Bogoychev 
> Signed-off-by: Mika Westerberg 
> ---
>  drivers/net/ethernet/intel/igb/igb_main.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [RFC PATCH] e1000e: Remove Other from EIAC.

[Brown, Aaron F]

> From: Brown, Aaron F
> Sent: Thursday, February 1, 2018 8:30 PM
> To: 'Benjamin Poirier' <bpoir...@suse.com>; Alexander Duyck
> <alexander.du...@gmail.com>
> Cc: Netdev <netdev@vger.kernel.org>; intel-wired-lan  l...@lists.osuosl.org>; linux-ker...@vger.kernel.org
> Subject: RE: [Intel-wired-lan] [RFC PATCH] e1000e: Remove Other from EIAC.
> 
> > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> > Behalf Of Benjamin Poirier
> > Sent: Tuesday, January 30, 2018 11:31 PM
> > To: Alexander Duyck <alexander.du...@gmail.com>
> > Cc: Netdev <netdev@vger.kernel.org>; intel-wired-lan  > l...@lists.osuosl.org>; linux-ker...@vger.kernel.org
> > Subject: Re: [Intel-wired-lan] [RFC PATCH] e1000e: Remove Other from
> EIAC.
> >
> > On 2018/01/30 11:46, Alexander Duyck wrote:
> > > On Wed, Jan 17, 2018 at 10:50 PM, Benjamin Poirier
> <bpoir...@suse.com>
> > wrote:
> > > > It was reported that emulated e1000e devices in vmware esxi 6.5 Build
> > > > 7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid
> > receiver
> > > > overrun interrupt bursts", v4.15-rc1). Some tracing shows that after
> > > > e1000e_trigger_lsc() is called, ICR reads out as 0x0 in
> e1000_msix_other()
> > > > on emulated e1000e devices. In comparison, on real e1000e 82574
> > hardware,
> > > > icr=0x8004 (_INT_ASSERTED | _OTHER) in the same situation.
> > > >
> > > > Some experimentation showed that this flaw in vmware e1000e
> > emulation can
> > > > be worked around by not setting Other in EIAC. This is how it was
> before
> > > > 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt", v4.5-rc1).
> > > >
> > > > Fixes: 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt
> bursts")
> > > > Signed-off-by: Benjamin Poirier <bpoir...@suse.com>
> > > > ---
> > >
> > > Hi Benjamin,
> > >
> > > How would you feel about resubmitting this patch for net?
> > >
> > > We have some issues that have come up and it would be useful to have
> > > this fixed in the kernel sooner rather than later. I would be okay
> > > with us applying it for now while we work on coming up with a more
> > > complete solution.
> >
> > Ok, I've resent it in its original form. Once it's in mainline I'll
> > rebase the cleanups.
> 
> Tested-by: Aaron Brown
> <aaron.f.br...@intel.com>
Stupid line wrap ... been that kind of day.

Tested-by: Aaron Brown <aaron.f.br...@intel.com>

> 
> > ___
> > Intel-wired-lan mailing list
> > intel-wired-...@osuosl.org
> > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

RE: [Intel-wired-lan] [RFC PATCH] e1000e: Remove Other from EIAC.

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Benjamin Poirier
> Sent: Tuesday, January 30, 2018 11:31 PM
> To: Alexander Duyck 
> Cc: Netdev ; intel-wired-lan  l...@lists.osuosl.org>; linux-ker...@vger.kernel.org
> Subject: Re: [Intel-wired-lan] [RFC PATCH] e1000e: Remove Other from EIAC.
> 
> On 2018/01/30 11:46, Alexander Duyck wrote:
> > On Wed, Jan 17, 2018 at 10:50 PM, Benjamin Poirier 
> wrote:
> > > It was reported that emulated e1000e devices in vmware esxi 6.5 Build
> > > 7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid
> receiver
> > > overrun interrupt bursts", v4.15-rc1). Some tracing shows that after
> > > e1000e_trigger_lsc() is called, ICR reads out as 0x0 in e1000_msix_other()
> > > on emulated e1000e devices. In comparison, on real e1000e 82574
> hardware,
> > > icr=0x8004 (_INT_ASSERTED | _OTHER) in the same situation.
> > >
> > > Some experimentation showed that this flaw in vmware e1000e
> emulation can
> > > be worked around by not setting Other in EIAC. This is how it was before
> > > 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt", v4.5-rc1).
> > >
> > > Fixes: 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt bursts")
> > > Signed-off-by: Benjamin Poirier 
> > > ---
> >
> > Hi Benjamin,
> >
> > How would you feel about resubmitting this patch for net?
> >
> > We have some issues that have come up and it would be useful to have
> > this fixed in the kernel sooner rather than later. I would be okay
> > with us applying it for now while we work on coming up with a more
> > complete solution.
> 
> Ok, I've resent it in its original form. Once it's in mainline I'll
> rebase the cleanups.

Tested-by: Aaron Brown


> ___
> Intel-wired-lan mailing list
> intel-wired-...@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

RE: [Intel-wired-lan] [PATCH] igb: add VF trust infrastructure

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Alexander Duyck
> Sent: Monday, January 22, 2018 2:58 PM
> To: intel-wired-lan ; Netdev
> 
> Cc: Corinna Vinschen 
> Subject: Re: [Intel-wired-lan] [PATCH] igb: add VF trust infrastructure
> 
> Hi Corinna,
> 
> I've looked over the patch and didn't see any issues. My understanding
> is that Jeff has pulled it into his tree and it should be going
> through testing shortly.

Indeed it is / was ;)

> 
> Thanks.
> 
> - Alex
> 
> On Mon, Jan 22, 2018 at 12:54 AM, Corinna Vinschen
>  wrote:
> > Hi,
> >
> > Could somebody please review this patch?
> >
> >
> > Thanks,
> > Corinna
> >
> >
> > On Jan 17 11:53, Corinna Vinschen wrote:
> >> * Add a per-VF value to know if a VF is trusted, by default don't
> >>   trust VFs.
> >>
> >> * Implement netdev op to trust VFs (igb_ndo_set_vf_trust) and add
> >>   trust status to ndo_get_vf_config output.
> >>
> >> * Allow a trusted VF to change MAC and MAC filters even if MAC
> >>   has been administratively set.
> >>
> >> Signed-off-by: Corinna Vinschen 
> >> ---
> >>  drivers/net/ethernet/intel/igb/igb.h  |  1 +
> >>  drivers/net/ethernet/intel/igb/igb_main.c | 30
> +++---
> >>  2 files changed, 28 insertions(+), 3 deletions(-)

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH 01/27] timecounter: Make cyclecounter struct part of timecounter struct

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Sagar Arun Kamble
> Sent: Thursday, December 14, 2017 11:38 PM
> To: linux-ker...@vger.kernel.org
> Cc: alsa-de...@alsa-project.org; linux-r...@vger.kernel.org;
> netdev@vger.kernel.org; Richard Cochran ;
> Stephen Boyd ; Chris Wilson  wilson.co.uk>; John Stultz ; intel-wired-
> l...@lists.osuosl.org; Thomas Gleixner ; Kamble, Sagar A
> ; kvm...@lists.cs.columbia.edu; linux-arm-
> ker...@lists.infradead.org
> Subject: [Intel-wired-lan] [PATCH 01/27] timecounter: Make cyclecounter
> struct part of timecounter struct
> 
> There is no real need for the users of timecounters to define cyclecounter
> and timecounter variables separately. Since timecounter will always be
> based on cyclecounter, have cyclecounter struct as member of timecounter
> struct.
> 
> v2: Rebase.
> 
> Suggested-by: Chris Wilson 
> Signed-off-by: Sagar Arun Kamble 
> Cc: Chris Wilson 
> Cc: Richard Cochran 
> Cc: John Stultz 
> Cc: Thomas Gleixner 
> Cc: Stephen Boyd 
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: netdev@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org
> Cc: linux-r...@vger.kernel.org
> Cc: alsa-de...@alsa-project.org
> Cc: kvm...@lists.cs.columbia.edu
> Acked-by: Jeff Kirsher  (Intel drivers)
> ---
>  arch/microblaze/kernel/timer.c | 20 ++--
>  drivers/clocksource/arm_arch_timer.c   | 19 ++--
>  drivers/net/ethernet/amd/xgbe/xgbe-dev.c   |  3 +-
>  drivers/net/ethernet/amd/xgbe/xgbe-ptp.c   |  9 +++---
>  drivers/net/ethernet/amd/xgbe/xgbe.h   |  1 -
>  drivers/net/ethernet/broadcom/bnx2x/bnx2x.h|  1 -
>  drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c   | 20 ++--
>  drivers/net/ethernet/freescale/fec.h   |  1 -
>  drivers/net/ethernet/freescale/fec_ptp.c   | 30 +-
>  drivers/net/ethernet/intel/e1000e/e1000.h  |  1 -
>  drivers/net/ethernet/intel/e1000e/netdev.c | 27 
>  drivers/net/ethernet/intel/e1000e/ptp.c|  2 +-
>  drivers/net/ethernet/intel/igb/igb.h   |  1 -
>  drivers/net/ethernet/intel/igb/igb_ptp.c   | 25 ---
>  drivers/net/ethernet/intel/ixgbe/ixgbe.h   |  1 -
>  drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c   | 17 +-
>  drivers/net/ethernet/mellanox/mlx4/en_clock.c  | 28 -
>  drivers/net/ethernet/mellanox/mlx4/mlx4_en.h   |  1 -
>  .../net/ethernet/mellanox/mlx5/core/lib/clock.c| 34 ++--
>  drivers/net/ethernet/qlogic/qede/qede_ptp.c| 20 ++--
>  drivers/net/ethernet/ti/cpts.c | 36 
> --
>  drivers/net/ethernet/ti/cpts.h |  1 -
>  include/linux/mlx5/driver.h|  1 -
>  include/linux/timecounter.h|  4 +--
>  include/sound/hdaudio.h|  1 -
>  kernel/time/timecounter.c  | 28 -
>  sound/hda/hdac_stream.c|  7 +++--
>  virt/kvm/arm/arch_timer.c  |  6 ++--
>  28 files changed, 163 insertions(+), 182 deletions(-)
> 

For Intel e1000e and igb drivers:
Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH 09/27] igb: Use timecounter_initialize interface

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Sagar Arun Kamble
> Sent: Thursday, December 14, 2017 11:38 PM
> To: linux-ker...@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Kamble, Sagar A
> ; netdev@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH 09/27] igb: Use timecounter_initialize
> interface
> 
> With new interface timecounter_initialize we can initialize timecounter
> fields and underlying cyclecounter together. Update igb ptp timecounter
> init with this new function.
> 
> Signed-off-by: Sagar Arun Kamble 
> Cc: Richard Cochran 
> Cc: Jeff Kirsher 
> Cc: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
>  drivers/net/ethernet/intel/igb/igb.h |  4 
>  drivers/net/ethernet/intel/igb/igb_ptp.c | 23 ++-
>  2 files changed, 18 insertions(+), 9 deletions(-)
> 

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH 22/27] ixgbe: Use timecounter_reset interface

[Brown, Aaron F]

> -Original Message-
> From: Brown, Aaron F
> Sent: Friday, January 5, 2018 8:34 PM
> To: 'Sagar Arun Kamble' <sagar.a.kam...@intel.com>; linux-
> ker...@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> <richardcoch...@gmail.com>; Kamble, Sagar A
> <sagar.a.kam...@intel.com>; netdev@vger.kernel.org
> Subject: RE: [Intel-wired-lan] [PATCH 22/27] ixgbe: Use timecounter_reset
> interface
> 
> > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> > Behalf Of Sagar Arun Kamble
> > Sent: Thursday, December 14, 2017 11:39 PM
> > To: linux-ker...@vger.kernel.org
> > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> > <richardcoch...@gmail.com>; Kamble, Sagar A
> > <sagar.a.kam...@intel.com>; netdev@vger.kernel.org
> > Subject: [Intel-wired-lan] [PATCH 22/27] ixgbe: Use timecounter_reset
> > interface
> >
> > With new interface timecounter_reset we can update the start time for
> > timecounter. Update ixgbe_ptp_settime with this new function.
> >
> > Signed-off-by: Sagar Arun Kamble <sagar.a.kam...@intel.com>
> > Cc: Richard Cochran <richardcoch...@gmail.com>
> > Cc: Jeff Kirsher <jeffrey.t.kirs...@intel.com>
> > Cc: intel-wired-...@lists.osuosl.org
> > Cc: netdev@vger.kernel.org
> > Cc: linux-ker...@vger.kernel.org
> > ---
> >  drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> 
> Tested-by: Aaron Brown <aaron.f.br...@intel.com>
Strike my Tested-by: for this (ixgbe) instance.  It was meant for igb.

RE: [Intel-wired-lan] [PATCH 22/27] ixgbe: Use timecounter_reset interface

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Sagar Arun Kamble
> Sent: Thursday, December 14, 2017 11:39 PM
> To: linux-ker...@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Kamble, Sagar A
> ; netdev@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH 22/27] ixgbe: Use timecounter_reset
> interface
> 
> With new interface timecounter_reset we can update the start time for
> timecounter. Update ixgbe_ptp_settime with this new function.
> 
> Signed-off-by: Sagar Arun Kamble 
> Cc: Richard Cochran 
> Cc: Jeff Kirsher 
> Cc: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
>  drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH 21/27] igb: Use timecounter_reset interface

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Sagar Arun Kamble
> Sent: Thursday, December 14, 2017 11:39 PM
> To: linux-ker...@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Kamble, Sagar A
> ; netdev@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH 21/27] igb: Use timecounter_reset
> interface
> 
> With new interface timecounter_reset we can update the start time for
> timecounter. Update igb_ptp_settime_82576 with this new function.
> 
> Signed-off-by: Sagar Arun Kamble 
> Cc: Richard Cochran 
> Cc: Jeff Kirsher 
> Cc: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
>  drivers/net/ethernet/intel/igb/igb_ptp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH 08/27] e1000e: Use timecounter_initialize interface

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Sagar Arun Kamble
> Sent: Thursday, December 14, 2017 11:38 PM
> To: linux-ker...@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Kamble, Sagar A
> ; netdev@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH 08/27] e1000e: Use timecounter_initialize
> interface
> 
> With new interface timecounter_initialize we can initialize timecounter
> fields and underlying cyclecounter together. Update e1000e timecounter
> init with this new function.
> 
> Signed-off-by: Sagar Arun Kamble 
> Cc: Richard Cochran 
> Cc: Jeff Kirsher 
> Cc: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
>  drivers/net/ethernet/intel/e1000e/e1000.h  |  4 
>  drivers/net/ethernet/intel/e1000e/netdev.c | 31 +-
> 
>  2 files changed, 22 insertions(+), 13 deletions(-)
> 

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH 20/27] e1000e: Use timecounter_reset interface

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Sagar Arun Kamble
> Sent: Thursday, December 14, 2017 11:39 PM
> To: linux-ker...@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Kamble, Sagar A
> ; netdev@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH 20/27] e1000e: Use timecounter_reset
> interface
> 
> With new interface timecounter_reset we can update the start time for
> timecounter. Update e1000e_phc_settime with this new function.
> 
> Signed-off-by: Sagar Arun Kamble 
> Cc: Richard Cochran 
> Cc: Jeff Kirsher 
> Cc: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
>  drivers/net/ethernet/intel/e1000e/ptp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH 1/1] timecounter: Make cyclecounter struct part of timecounter struct

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Jeff Kirsher
> Sent: Wednesday, December 6, 2017 8:25 AM
> To: Kamble, Sagar A ; linux-
> ker...@vger.kernel.org
> Cc: alsa-de...@alsa-project.org; linux-r...@vger.kernel.org;
> netdev@vger.kernel.org; Richard Cochran ;
> Stephen Boyd ; Chris Wilson  wilson.co.uk>; John Stultz ; intel-wired-
> l...@lists.osuosl.org; Thomas Gleixner ;
> kvm...@lists.cs.columbia.edu; linux-arm-ker...@lists.infradead.org
> Subject: Re: [Intel-wired-lan] [PATCH 1/1] timecounter: Make cyclecounter
> struct part of timecounter struct
> 
> On Sat, 2017-12-02 at 10:01 +0530, Sagar Arun Kamble wrote:
> > There is no real need for the users of timecounters to define
> > cyclecounter
> > and timecounter variables separately. Since timecounter will always
> > be
> > based on cyclecounter, have cyclecounter struct as member of
> > timecounter
> > struct.
> >
> > Suggested-by: Chris Wilson 
> > Signed-off-by: Sagar Arun Kamble 
> > Cc: Chris Wilson 
> > Cc: Richard Cochran 
> > Cc: John Stultz 
> > Cc: Thomas Gleixner 
> > Cc: Stephen Boyd 
> > Cc: linux-ker...@vger.kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: netdev@vger.kernel.org
> > Cc: intel-wired-...@lists.osuosl.org
> > Cc: linux-r...@vger.kernel.org
> > Cc: alsa-de...@alsa-project.org
> > Cc: kvm...@lists.cs.columbia.edu
> 
> Acked-by: Jeff Kirsher 
> 

Tested-by: Aaron Brown 

> For the changes to the Intel drivers.
> 
> > ---
> >  arch/microblaze/kernel/timer.c | 20 ++--
> >  drivers/clocksource/arm_arch_timer.c   | 19 ++--
> >  drivers/net/ethernet/amd/xgbe/xgbe-dev.c   |  3 +-
> >  drivers/net/ethernet/amd/xgbe/xgbe-ptp.c   |  9 +++---
> >  drivers/net/ethernet/amd/xgbe/xgbe.h   |  1 -
> >  drivers/net/ethernet/broadcom/bnx2x/bnx2x.h|  1 -
> >  drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c   | 20 ++--
> >  drivers/net/ethernet/freescale/fec.h   |  1 -
> >  drivers/net/ethernet/freescale/fec_ptp.c   | 30 +---
> > --
> >  drivers/net/ethernet/intel/e1000e/e1000.h  |  1 -
> >  drivers/net/ethernet/intel/e1000e/netdev.c | 27 --
> > --
> >  drivers/net/ethernet/intel/e1000e/ptp.c|  2 +-
> >  drivers/net/ethernet/intel/igb/igb.h   |  1 -
> >  drivers/net/ethernet/intel/igb/igb_ptp.c   | 25 --
> > -
> >  drivers/net/ethernet/intel/ixgbe/ixgbe.h   |  1 -
> >  drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c   | 17 +-
> >  drivers/net/ethernet/mellanox/mlx4/en_clock.c  | 28 --
> > ---
> >  drivers/net/ethernet/mellanox/mlx4/mlx4_en.h   |  1 -
> >  .../net/ethernet/mellanox/mlx5/core/lib/clock.c| 34 ++
> > --
> >  drivers/net/ethernet/qlogic/qede/qede_ptp.c| 20 ++--
> >  drivers/net/ethernet/ti/cpts.c | 36
> > --
> >  drivers/net/ethernet/ti/cpts.h |  1 -
> >  include/linux/mlx5/driver.h|  1 -
> >  include/linux/timecounter.h|  4 +--
> >  include/sound/hdaudio.h|  1 -
> >  kernel/time/timecounter.c  | 28 --
> > ---
> >  sound/hda/hdac_stream.c|  7 +++--
> >  virt/kvm/arm/arch_timer.c  |  6 ++--
> >  28 files changed, 163 insertions(+), 182 deletions(-)

RE: [Intel-wired-lan] [PATCH] igb: Delete an error message for a failed memory allocation in igb_enable_sriov()

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of SF Markus Elfring
> Sent: Monday, January 1, 2018 11:57 AM
> To: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; Kirsher,
> Jeffrey T 
> Cc: kernel-janit...@vger.kernel.org; LKML 
> Subject: [Intel-wired-lan] [PATCH] igb: Delete an error message for a failed
> memory allocation in igb_enable_sriov()
> 
> From: Markus Elfring 
> Date: Mon, 1 Jan 2018 20:53:10 +0100
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/net/ethernet/intel/igb/igb_main.c | 2 --
>  1 file changed, 2 deletions(-)
> 

Tested-by: Aaron Brown 

RE: [PATCH v3] igb: Free IRQs when device is hotplugged

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Lyude Paul
> Sent: Tuesday, December 12, 2017 11:32 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: Fujinaka, Todd ; Stephen Hemminger
> ; sta...@vger.kernel.org; Kirsher, Jeffrey T
> ; netdev@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH v3] igb: Free IRQs when device is hotplugged
> 
> Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon
> hotplugging my kernel would immediately crash due to igb:
> 
> [  680.825801] kernel BUG at drivers/pci/msi.c:352!
> [  680.828388] invalid opcode:  [#1] SMP
> [  680.829194] Modules linked in: igb(O) thunderbolt i2c_algo_bit joydev vfat
> fat btusb btrtl btbcm btintel bluetooth ecdh_generic hp_wmi
> sparse_keymap rfkill wmi_bmof iTCO_wdt intel_rapl
> x86_pkg_temp_thermal coretemp crc32_pclmul snd_pcm rtsx_pci_ms
> mei_me snd_timer memstick snd pcspkr mei soundcore i2c_i801 tpm_tis
> psmouse shpchp wmi tpm_tis_core tpm video hp_wireless acpi_pad
> rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci mfd_core
> xhci_pci xhci_hcd i2c_hid i2c_core [last unloaded: igb]
> [  680.831085] CPU: 1 PID: 78 Comm: kworker/u16:1 Tainted: G   O
> 4.15.0-rc3Lyude-Test+ #6
> [  680.831596] Hardware name: HP HP ZBook Studio G4/826B, BIOS P71 Ver.
> 01.03 06/09/2017
> [  680.832168] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
> [  680.832687] RIP: 0010:free_msi_irqs+0x180/0x1b0
> [  680.833271] RSP: 0018:c930fbf0 EFLAGS: 00010286
> [  680.833761] RAX: 8803405f9c00 RBX: 88033e3d2e40 RCX:
> 002c
> [  680.834278] RDX:  RSI: 00ac RDI:
> 880340be2178
> [  680.834832] RBP:  R08: 880340be1ff0 R09:
> 8803405f9c00
> [  680.835342] R10:  R11: 0040 R12:
> 88033d63a298
> [  680.835822] R13: 88033d63a000 R14: 0060 R15:
> 880341959000
> [  680.836332] FS:  () GS:88034f44()
> knlGS:
> [  680.836817] CS:  0010 DS:  ES:  CR0: 80050033
> [  680.837360] CR2: 55e64044afdf CR3: 01c09002 CR4:
> 003606e0
> [  680.837954] Call Trace:
> [  680.838853]  pci_disable_msix+0xce/0xf0
> [  680.839616]  igb_reset_interrupt_capability+0x5d/0x60 [igb]
> [  680.840278]  igb_remove+0x9d/0x110 [igb]
> [  680.840764]  pci_device_remove+0x36/0xb0
> [  680.841279]  device_release_driver_internal+0x157/0x220
> [  680.841739]  pci_stop_bus_device+0x7d/0xa0
> [  680.842255]  pci_stop_bus_device+0x2b/0xa0
> [  680.842722]  pci_stop_bus_device+0x3d/0xa0
> [  680.843189]  pci_stop_and_remove_bus_device+0xe/0x20
> [  680.843627]  trim_stale_devices+0xf3/0x140
> [  680.844086]  trim_stale_devices+0x94/0x140
> [  680.844532]  trim_stale_devices+0xa6/0x140
> [  680.845031]  ? get_slot_status+0x90/0xc0
> [  680.845536]  acpiphp_check_bridge.part.5+0xfe/0x140
> [  680.846021]  acpiphp_hotplug_notify+0x175/0x200
> [  680.846581]  ? free_bridge+0x100/0x100
> [  680.847113]  acpi_device_hotplug+0x8a/0x490
> [  680.847535]  acpi_hotplug_work_fn+0x1a/0x30
> [  680.848076]  process_one_work+0x182/0x3a0
> [  680.848543]  worker_thread+0x2e/0x380
> [  680.848963]  ? process_one_work+0x3a0/0x3a0
> [  680.849373]  kthread+0x111/0x130
> [  680.849776]  ? kthread_create_worker_on_cpu+0x50/0x50
> [  680.850188]  ret_from_fork+0x1f/0x30
> [  680.850601] Code: 43 14 85 c0 0f 84 d5 fe ff ff 31 ed eb 0f 83 c5 01 39 6b 
> 14 0f
> 86 c5 fe ff ff 8b 7b 10 01 ef e8 b7 e4 d2 ff 48 83 78 70 00 74 e3 <0f> 0b 49 
> 8d b5
> a0 00 00 00 e8 62 6f d3 ff e9 c7 fe ff ff 48 8b
> [  680.851497] RIP: free_msi_irqs+0x180/0x1b0 RSP: c930fbf0
> 
> As it turns out, normally the freeing of IRQs that would fix this is called
> inside of the scope of __igb_close(). However, since the device is
> already gone by the point we try to unregister the netdevice from the
> driver due to a hotplug we end up seeing that the netif isn't present
> and thus, forget to free any of the device IRQs.
> 
> So: make sure that if we're in the process of dismantling the netdev, we
> always allow __igb_close() to be called so that IRQs may be freed
> normally. Additionally, only allow igb_close() to be called from
> __igb_close() if it hasn't already been called for the given adapter.
> 
> Signed-off-by: Lyude Paul 
> Fixes: 9474933caf21 ("igb: close/suspend race in netif_device_detach")
> Cc: Todd Fujinaka 
> Cc: Stephen Hemminger 
> Cc: sta...@vger.kernel.org
> ---
> Changes since v2:
>   - Remove hunk in __igb_close() that was left over by accident, it's
> not needed
> 
>  drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH] e1000e: Fix e1000_check_for_copper_link_ich8lan return value.

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Neftin, Sasha
> Sent: Wednesday, December 20, 2017 10:57 PM
> To: Benjamin Poirier ; Kirsher, Jeffrey T
> 
> Cc: Ben Hutchings ; Gabriel C
> ; netdev@vger.kernel.org; Christian Hesse
> ; sta...@vger.kernel.org; linux-ker...@vger.kernel.org;
> intel-wired-...@lists.osuosl.org
> Subject: Re: [Intel-wired-lan] [PATCH] e1000e: Fix
> e1000_check_for_copper_link_ich8lan return value.
> 
> On 11/12/2017 9:26, Benjamin Poirier wrote:
> > e1000e_check_for_copper_link() and
> e1000_check_for_copper_link_ich8lan()
> > are the two functions that may be assigned to mac.ops.check_for_link
> when
> > phy.media_type == e1000_media_type_copper. Commit 19110cfbb34d
> ("e1000e:
> > Separate signaling for link check/link up") changed the meaning of the
> > return value of check_for_link for copper media but only adjusted the first
> > function. This patch adjusts the second function likewise.
> >
> > Reported-by: Christian Hesse 
> > Reported-by: Gabriel C 
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=198047
> > Fixes: 19110cfbb34d ("e1000e: Separate signaling for link check/link up")
> > Tested-by: Christian Hesse 
> > Signed-off-by: Benjamin Poirier 
> > ---
> >   drivers/net/ethernet/intel/e1000e/ich8lan.c | 11 ---
> >   1 file changed, 8 insertions(+), 3 deletions(-)
> >

Tested-by: Aaron Brown 

> Acked by sasha.nef...@intel.com
> 
> ___
> Intel-wired-lan mailing list
> intel-wired-...@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

RE: [PATCH] e1000: Fix off-by-one in debug message

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Ahmad Fatoum
> Sent: Saturday, November 18, 2017 12:54 PM
> To: Kirsher, Jeffrey T 
> Cc: intel-wired-...@lists.osuosl.org; netdev@vger.kernel.org; Ahmad
> Fatoum 
> Subject: [PATCH] e1000: Fix off-by-one in debug message
> 
> Signed-off-by: Ahmad Fatoum 
> ---
>  drivers/net/ethernet/intel/e1000/e1000_hw.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH] i40e: remove redundant initialization of read_size

[Brown, Aaron F]

> From: Brown, Aaron F
> Sent: Thursday, November 9, 2017 7:16 PM
> To: 'Colin King' <colin.k...@canonical.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirs...@intel.com>; intel-wired-...@lists.osuosl.org;
> netdev@vger.kernel.org
> Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: RE: [Intel-wired-lan] [PATCH] i40e: remove redundant initialization
> of read_size
> 
> > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf
> > Of Colin King
> > Sent: Sunday, November 5, 2017 5:04 AM
> > To: Kirsher, Jeffrey T <jeffrey.t.kirs...@intel.com>; intel-wired-
> > l...@lists.osuosl.org; netdev@vger.kernel.org
> > Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org
> > Subject: [Intel-wired-lan] [PATCH] i40e: remove redundant initialization of
> > read_size
> >
> > From: Colin Ian King <colin.k...@canonical.com>
> >
> > Variable read_size is initialized and this value is never read, it is
> > instead set inside the do-loop, hence the intialization is redundant
> > and can be removed. Cleans up clang warning:
> >
> > drivers/net/ethernet/intel/i40e/i40e_nvm.c:390:6: warning: Value stored
> > to 'read_size' during its initialization is never read
> >
> > Signed-off-by: Colin Ian King <colin.k...@canonical.com>
> 
> s/intialization/initialization/g

Other than that typo, looks fine:
Tested-by: Aaron Brown <aaron.f.br...@intel.com>

RE: [Intel-wired-lan] [PATCH] i40e: remove redundant initialization of read_size

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of Colin King
> Sent: Sunday, November 5, 2017 5:04 AM
> To: Kirsher, Jeffrey T ; intel-wired-
> l...@lists.osuosl.org; netdev@vger.kernel.org
> Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH] i40e: remove redundant initialization of
> read_size
> 
> From: Colin Ian King 
> 
> Variable read_size is initialized and this value is never read, it is
> instead set inside the do-loop, hence the intialization is redundant
> and can be removed. Cleans up clang warning:
> 
> drivers/net/ethernet/intel/i40e/i40e_nvm.c:390:6: warning: Value stored
> to 'read_size' during its initialization is never read
> 
> Signed-off-by: Colin Ian King 

s/intialization/initialization/g

RE: [Intel-wired-lan] [next-queue PATCH v9 6/6] igb: Add support for CBS offload

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of Vinicius Costa Gomes
> Sent: Monday, October 16, 2017 6:01 PM
> To: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org
> Cc: rodney.cummi...@ni.com; Guedes, Andre ;
> j...@resnulli.us; Briano, Ivan ;
> richardcoch...@gmail.com; hen...@austad.us; j...@mojatatu.com;
> levipear...@gmail.com; Ong, Boon Leong ;
> xiyou.wangc...@gmail.com; Sanchez-Palencia, Jesus  palen...@intel.com>
> Subject: [Intel-wired-lan] [next-queue PATCH v9 6/6] igb: Add support for
> CBS offload
> 
> From: Andre Guedes 
> 
> This patch adds support for Credit-Based Shaper (CBS) qdisc offload
> from Traffic Control system. This support enable us to leverage the
> Forwarding and Queuing for Time-Sensitive Streams (FQTSS) features
> from Intel i210 Ethernet Controller. FQTSS is the former 802.1Qav
> standard which was merged into 802.1Q in 2014. It enables traffic
> prioritization and bandwidth reservation via the Credit-Based Shaper
> which is implemented in hardware by i210 controller.
> 
> The patch introduces the igb_setup_tc() function which implements the
> support for CBS qdisc hardware offload in the IGB driver. CBS offload
> is the only traffic control offload supported by the driver at the
> moment.
> 
> FQTSS transmission mode from i210 controller is automatically enabled
> by the IGB driver when the CBS is enabled for the first hardware
> queue. Likewise, FQTSS mode is automatically disabled when CBS is
> disabled for the last hardware queue. Changing FQTSS mode requires NIC
> reset.
> 
> FQTSS feature is supported by i210 controller only.
> 
> Signed-off-by: Andre Guedes 
> ---
>  drivers/net/ethernet/intel/igb/e1000_defines.h |  23 ++
>  drivers/net/ethernet/intel/igb/e1000_regs.h|   8 +
>  drivers/net/ethernet/intel/igb/igb.h   |   6 +
>  drivers/net/ethernet/intel/igb/igb_main.c  | 347
> +
>  4 files changed, 384 insertions(+)

>From a regression standpoint:
Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH][V3] e1000: avoid null pointer dereference on invalid stat type

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of Colin King
> Sent: Friday, September 22, 2017 10:14 AM
> To: Kirsher, Jeffrey T ; intel-wired-
> l...@lists.osuosl.org; netdev@vger.kernel.org
> Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH][V3] e1000: avoid null pointer dereference
> on invalid stat type
> 
> From: Colin Ian King 
> 
> Currently if the stat type is invalid then data[i] is being set
> either by dereferencing a null pointer p, or it is reading from
> an incorrect previous location if we had a valid stat type
> previously.  Fix this by skipping over the read of p on an invalid
> stat type.
> 
> Detected by CoverityScan, CID#113385 ("Explicit null dereferenced")
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)

Tested-by: Aaron Brown 

RE: [net-next,RESEND] igb: add function to get maximum RSS queues

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Zhang Shengju
> Sent: Tuesday, September 19, 2017 6:41 AM
> To: Kirsher, Jeffrey T ; intel-wired-
> l...@lists.osuosl.org; netdev@vger.kernel.org
> Subject: [net-next,RESEND] igb: add function to get maximum RSS queues
> 
> This patch adds a new function igb_get_max_rss_queues() to get maximum
> RSS queues, this will reduce duplicate code and facilitate future
> maintenance.
> 
> Signed-off-by: Zhang Shengju 
> ---
>  drivers/net/ethernet/intel/igb/igb.h |  1 +
>  drivers/net/ethernet/intel/igb/igb_ethtool.c | 32 
> +---
>  drivers/net/ethernet/intel/igb/igb_main.c| 12 +--
>  3 files changed, 12 insertions(+), 33 deletions(-)
> 

Tested-by: Aaron Brown 

RE: [PATCH net] driver: e1000: fix race condition between e1000_down() and e1000_watchdog

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Vincenzo Maffione
> Sent: Saturday, September 16, 2017 9:00 AM
> To: Kirsher, Jeffrey T 
> Cc: intel-wired-...@lists.osuosl.org; netdev@vger.kernel.org; linux-
> ker...@vger.kernel.org; Vincenzo Maffione 
> Subject: [PATCH net] driver: e1000: fix race condition between e1000_down()
> and e1000_watchdog
> 
> This patch fixes a race condition that can result into the interface being
> up and carrier on, but with transmits disabled in the hardware.
> The bug may show up by repeatedly IFF_DOWN+IFF_UP the interface, which
> allows e1000_watchdog() interleave with e1000_down().
> 
> CPU x   CPU y
> 
> e1000_down():
> netif_carrier_off()
> e1000_watchdog():
> if (carrier == off) {
> netif_carrier_on();
> enable_hw_transmit();
> }
> disable_hw_transmit();
> e1000_watchdog():
> /* carrier on, do nothing */
> 
> Signed-off-by: Vincenzo Maffione 
> ---
>  drivers/net/ethernet/intel/e1000/e1000_main.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH 2/5] e1000e: Fix wrong comment related to link detection

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of Benjamin Poirier
> Sent: Friday, July 21, 2017 11:36 AM
> To: Kirsher, Jeffrey T 
> Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org; Lennart Sorensen 
> Subject: [Intel-wired-lan] [PATCH 2/5] e1000e: Fix wrong comment related to
> link detection
> 
> Reading e1000e_check_for_copper_link() shows that get_link_status is set to
> false after link has been detected. Therefore, it stays TRUE until then.
> 
> Signed-off-by: Benjamin Poirier 
> ---
>  drivers/net/ethernet/intel/e1000e/netdev.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH 5/5] e1000e: Avoid receiver overrun interrupt bursts

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of Benjamin Poirier
> Sent: Friday, July 21, 2017 11:36 AM
> To: Kirsher, Jeffrey T 
> Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org; Lennart Sorensen 
> Subject: [Intel-wired-lan] [PATCH 5/5] e1000e: Avoid receiver overrun
> interrupt bursts
> 
> When e1000e_poll() is not fast enough to keep up with incoming traffic, the
> adapter (when operating in msix mode) raises the Other interrupt to signal
> Receiver Overrun.
> 
> This is a double problem because 1) at the moment e1000_msix_other()
> assumes that it is only called in case of Link Status Change and 2) if the
> condition persists, the interrupt is repeatedly raised again in quick
> succession.
> 
> Ideally we would configure the Other interrupt to not be raised in case of
> receiver overrun but this doesn't seem possible on this adapter. Instead,
> we handle the first part of the problem by reverting to the practice of
> reading ICR in the other interrupt handler, like before commit 16ecba59bc33
> ("e1000e: Do not read ICR in Other interrupt"). Thanks to commit
> 0a8047ac68e5 ("e1000e: Fix msi-x interrupt automask") which cleared IAME
> from CTRL_EXT, reading ICR doesn't interfere with RxQ0, TxQ0 interrupts
> anymore. We handle the second part of the problem by not re-enabling the
> Other interrupt right away when there is overrun. Instead, we wait until
> traffic subsides, napi polling mode is exited and interrupts are
> re-enabled.
> 
> Reported-by: Lennart Sorensen 
> Fixes: 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt")
> Signed-off-by: Benjamin Poirier 
> ---
>  drivers/net/ethernet/intel/e1000e/defines.h |  1 +
>  drivers/net/ethernet/intel/e1000e/netdev.c  | 33
> +++--
>  2 files changed, 27 insertions(+), 7 deletions(-)
> 

I get an error and a few warnings out of checkpatch from this, but I think the 
error is false (thinking the reference to a commit in the description is this 
commit, a fixes commit or something like that) and I'm more concerned with the 
fix than the warnings, so...

Tested-by: Aaron Brown 

Here is the checkpatch output in case anyone has a different opinion on the 
severity:
-
u1484:[0]/usr/src/kernels/next-queue> git format-patch d81d1e6 -1 
--stdout|./scripts/checkpatch.pl -
ERROR: Please use git commit description style 'commit <12+ chars of sha1> 
("")' - ie: 'commit 0a8047ac68e5 ("e1000e: Fix msi-x interrupt 
automask")'
#20:
0a8047ac68e5 ("e1000e: Fix msi-x interrupt automask") which cleared IAME

WARNING: braces {} are not necessary for single statement blocks
#73: FILE: drivers/net/ethernet/intel/e1000e/netdev.c:1931:
+   if (!test_bit(__E1000_DOWN, >state)) {
+   mod_timer(>watchdog_timer, jiffies + 1);
+   }

WARNING: braces {} are not necessary for single statement blocks
#83: FILE: drivers/net/ethernet/intel/e1000e/netdev.c:1936:
+   if (enable && !test_bit(__E1000_DOWN, >state)) {
ew32(IMS, E1000_IMS_OTHER);
}

total: 1 errors, 2 warnings, 0 checks, 59 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
  mechanically convert to the typical style using --fix or --fix-inplace.

Your patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
  them to the maintainer, see CHECKPATCH in MAINTAINERS.
u1484:[0]/usr/src/kernels/next-queue>

RE: [Intel-wired-lan] [PATCH 4/5] e1000e: Separate signaling for link check/link up

[Brown, Aaron F]

On 7/21/2017 21:36, Benjamin Poirier wrote:
> Lennart reported the following race condition:
>
> \ e1000_watchdog_task
>  \ e1000e_has_link
>  \ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link
>  /* link is up */
>  mac->get_link_status = false;
>
>  /* interrupt */
>  \ e1000_msix_other
>  hw->mac.get_link_status = true;
>
>  link_active = !hw->mac.get_link_status
>  /* link_active is false, wrongly */
>
> This problem arises because the single flag get_link_status is used to
> signal two different states: link status needs checking and link status is
> down.
>
> Avoid the problem by using the return value of .check_for_link to signal
> the link status to e1000e_has_link().
>
> Reported-by: Lennart Sorensen 
> Signed-off-by: Benjamin Poirier 
> ---
>   drivers/net/ethernet/intel/e1000e/mac.c| 11 ---
>   drivers/net/ethernet/intel/e1000e/netdev.c |  2 +-
>   2 files changed, 9 insertions(+), 4 deletions(-)

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH 3/5] e1000e: Fix return value test

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of Benjamin Poirier
> Sent: Friday, July 21, 2017 11:36 AM
> To: Kirsher, Jeffrey T 
> Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org; Lennart Sorensen 
> Subject: [Intel-wired-lan] [PATCH 3/5] e1000e: Fix return value test
> 
> All the helpers return -E1000_ERR_PHY.
> 
> Signed-off-by: Benjamin Poirier 
> ---
>  drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH 1/5] e1000e: Fix error path in link detection

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of Benjamin Poirier
> Sent: Friday, July 21, 2017 11:36 AM
> To: Kirsher, Jeffrey T 
> Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org; Lennart Sorensen 
> Subject: [Intel-wired-lan] [PATCH 1/5] e1000e: Fix error path in link 
> detection
> 
> In case of error from e1e_rphy(), the loop will exit early and "success"
> will be set to true erroneously.
> 
> Signed-off-by: Benjamin Poirier 
> ---
>  drivers/net/ethernet/intel/e1000e/phy.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH net-next v3] e1000e: Be drop monitor friendly

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of Florian Fainelli
> Sent: Friday, August 25, 2017 6:14 PM
> To: netdev@vger.kernel.org
> Cc: eduma...@gmail.com; Florian Fainelli ; open list
> ; moderated list:INTEL ETHERNET DRIVERS
> ; da...@davemloft.net
> Subject: [Intel-wired-lan] [PATCH net-next v3] e1000e: Be drop monitor
> friendly
> 
> e1000e_put_txbuf() can be called from normal reclamation path as well as
> when a DMA mapping failure, so we need to differentiate these two cases
> when freeing SKBs to be drop monitor friendly. e1000e_tx_hwtstamp_work()
> and e1000_remove() are processing TX timestamped SKBs and those should
> not be accounted as drops either.
> 
> Signed-off-by: Florian Fainelli 
> ---
> Changes in v3:
> 
> - differentiate normal reclamation from TX DMA fragment mapping errors
> - removed a few invalid dev_kfree_skb() replacements (those are already
>   drop monitor friendly)
> 
> Changes in v2:
> 
> - make it compile
> 
>  drivers/net/ethernet/intel/e1000e/netdev.c | 18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)

Tested-by: Aaron Brown 

RE: [PATCH] e1000e: apply burst mode settings only on default

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Willem de Bruijn
> Sent: Friday, August 25, 2017 8:06 AM
> To: Kirsher, Jeffrey T 
> Cc: intel-wired-...@lists.osuosl.org; netdev@vger.kernel.org; Brandeburg,
> Jesse ; Willem de Bruijn
> 
> Subject: [PATCH] e1000e: apply burst mode settings only on default
> 
> From: Willem de Bruijn 
> 
> 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 
> ---
>  drivers/net/ethernet/intel/e1000e/e1000.h  |  4 
>  drivers/net/ethernet/intel/e1000e/netdev.c |  8 
>  drivers/net/ethernet/intel/e1000e/param.c  | 16 +++-
>  3 files changed, 15 insertions(+), 13 deletions(-)

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH] igb: check memory allocation failure

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of Christophe JAILLET
> Sent: Monday, August 28, 2017 10:13 AM
> To: Waskiewicz Jr, Peter ; Kirsher, Jeffrey T
> 
> Cc: netdev@vger.kernel.org; kernel-janit...@vger.kernel.org; intel-wired-
> l...@lists.osuosl.org; linux-ker...@vger.kernel.org
> Subject: Re: [Intel-wired-lan] [PATCH] igb: check memory allocation failure
> 
> Le 28/08/2017 à 01:09, Waskiewicz Jr, Peter a écrit :
> > On 8/27/17 2:42 AM, Christophe JAILLET wrote:
> >> Check memory allocation failures and return -ENOMEM in such cases, as
> >> already done for other memory allocations in this function.
> >>
> >> This avoids NULL pointers dereference.
> >>
> >> Signed-off-by: Christophe JAILLET 
> >> ---
> >>drivers/net/ethernet/intel/igb/igb_main.c | 2 ++
> >>1 file changed, 2 insertions(+)
> >>

This seems to be fine from a "it does not break in testing" perspective, so...

Tested-by: Aaron Brown  > -PJ
> >
> Hi,
> 
> in fact, there is no leak because the only caller of 'igb_sw_init()'
> (i.e. 'igb_probe()'), already frees these resources in case of error,
> see [1]
> 
> These resources are also freed  in 'igb_remove()'.
> 
> Best reagrds,
> CJ
> 
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
> next.git/tree/drivers/net/ethernet/intel/igb/igb_main.c#n2775

But is PJ's comment saying that it is not really necessary?  If so I tend to 
lean towards the don't touch it if it's not broken perspective.
 

RE: [PATCH] e1000e: changed some expensive calls of udelay to usleep_range

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Kardonik Michael
> Sent: Tuesday, September 5, 2017 1:27 PM
> To: leoyang...@nxp.com; michael.kardo...@nxp.com; Kirsher, Jeffrey T
> ; Brandeburg, Jesse
> ; Shannon Nelson
> ; Wyborny, Carolyn
> ; Skidmore, Donald C
> ; Vick, Matthew ;
> John Ronciak ; Williams, Mitch A
> ; intel-wired-...@lists.osuosl.org;
> netdev@vger.kernel.org; linux-ker...@vger.kernel.org
> Cc: Matthew Tan 
> Subject: [PATCH] e1000e: changed some expensive calls of udelay to
> usleep_range
> 
> Calls to udelay are not preemtable by userspace so userspace
> applications experience a large (~200us) latency when running on core0.
> Instead usleep_range can be used to be more friendly to userspace
> since it is preemtable. This is due to udelay using busy-wait loops
> while usleep_rang uses hrtimers instead. It is recommended to use
> udelay when the delay is <10us since at that precision overhead of
> usleep_range hrtimer setup causes issues. However, the replaced calls
> are for 50us and 100us so this should not be not an issue.
> There is no open bug that this patch is fixing, but we see a good
> boost in zero loss performance of specific user space application
> (dpdk l3fwd) when this patch is applied: we get from 32% of 10Gb line
> to 49%.
> 
> Signed-off-by: Matthew Tan 
> Signed-off-by: Michael Kardonik 
> 
> ---
>  drivers/net/ethernet/intel/e1000e/phy.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 

This version continues to crash the same systems as the last (an 82577 and an 
i218.)  As before, when link partner is a lower speed (autoneg set for 100 half 
for this instance) and I simply bring up the interface I start getting stuck 
CPU messages:

Message from syslogd@u1459 at Sep 11 17:16:25 ...
 kernel:watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [kworker/2:0:4204]

Message from syslogd@u1459 at Sep 11 17:16:53 ...
 kernel:watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [kworker/2:0:4204]


System becomes unresponsive and on a reboot I am able to pull out  a trace file:

Sep 11 17:16:00 u1459 kernel: INFO: rcu_sched self-detected stall on CPU
Sep 11 17:16:00 u1459 kernel:   2-...: (20999 ticks this GP) 
idle=a5a/141/0 softirq=8232/8232 fqs=5250
Sep 11 17:16:00 u1459 kernel:(t=21000 jiffies g=4013 c=4012 q=616)
Sep 11 17:16:00 u1459 kernel: NMI backtrace for cpu 2
Sep 11 17:16:00 u1459 kernel: CPU: 2 PID: 4204 Comm: kworker/2:0 Tainted: G 
   E   4.13.0_next-queue_dev-queue_41b1c97 #39
Sep 11 17:16:00 u1459 kernel: Hardware name:  /NUC5i5MYBE, BIOS 
MYBDWi5v.86A.0030.2016.0527.1657 05/27/2016
Sep 11 17:16:00 u1459 kernel: Workqueue: events linkwatch_event
Sep 11 17:16:00 u1459 kernel: Call Trace:
Sep 11 17:16:00 u1459 kernel: 
Sep 11 17:16:00 u1459 kernel: dump_stack+0x51/0x78
Sep 11 17:16:00 u1459 kernel: nmi_cpu_backtrace+0xd3/0xe0
Sep 11 17:16:00 u1459 kernel: ? hw_nmi_get_sample_period+0x20/0x20
Sep 11 17:16:00 u1459 kernel: nmi_trigger_cpumask_backtrace+0xf5/0x130
Sep 11 17:16:00 u1459 kernel: arch_trigger_cpumask_backtrace+0x19/0x20
Sep 11 17:16:00 u1459 kernel: rcu_dump_cpu_stacks+0xb7/0xe0
Sep 11 17:16:00 u1459 kernel: print_cpu_stall+0xfa/0x170
Sep 11 17:16:00 u1459 kernel: ? __update_load_avg_cfs_rq+0x183/0x190
Sep 11 17:16:00 u1459 kernel: ? sched_slice+0x55/0xa0
Sep 11 17:16:00 u1459 kernel: check_cpu_stall+0x110/0x120
Sep 11 17:16:00 u1459 kernel: ? check_preempt_curr+0x73/0x90
Sep 11 17:16:00 u1459 kernel: ? ttwu_do_wakeup+0x2b/0x170
Sep 11 17:16:00 u1459 kernel: ? cpu_needs_another_gp+0x7b/0x80
Sep 11 17:16:00 u1459 kernel: ? notifier_call_chain+0x56/0x80
Sep 11 17:16:00 u1459 kernel: rcu_pending+0x5f/0x180
Sep 11 17:16:00 u1459 kernel: ? raw_notifier_call_chain+0x16/0x20
Sep 11 17:16:00 u1459 kernel: ? timekeeping_update+0xd9/0x130
Sep 11 17:16:00 u1459 kernel: rcu_check_callbacks+0x8a/0x1b0
Sep 11 17:16:00 u1459 kernel: ? account_system_index_time+0x6b/0x80
Sep 11 17:16:00 u1459 kernel: update_process_times+0x39/0x70
Sep 11 17:16:00 u1459 kernel: tick_sched_handle+0x37/0x70
Sep 11 17:16:00 u1459 kernel: tick_sched_timer+0x52/0xa0
Sep 11 17:16:00 u1459 kernel: __run_hrtimer+0x77/0x1b0
Sep 11 17:16:00 u1459 kernel: ? tick_nohz_handler+0xc0/0xc0
Sep 11 17:16:00 u1459 kernel: ? ktime_get+0x5a/0xd0
Sep 11 17:16:00 u1459 kernel: __hrtimer_run_queues+0x67/0x90
Sep 11 17:16:00 u1459 kernel: hrtimer_interrupt+0xa4/0x1d0
Sep 11 17:16:00 u1459 kernel: 

RE: [Intel-wired-lan] [PATCH] e1000e: changed some expensive calls of udelay to usleep_range

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Pavel Machek
> Sent: Monday, September 4, 2017 9:26 AM
> To: Matthew Tan 
> Cc: michael.kardo...@nxp.com; Williams, Mitch A
> ; linux-ker...@vger.kernel.org;
> john.ronc...@intel.com; intel-wired-...@lists.osuosl.org;
> netdev@vger.kernel.org
> Subject: Re: [Intel-wired-lan] [PATCH] e1000e: changed some expensive calls
> of udelay to usleep_range
> 
> Hi!
> 
> > @@ -183,7 +183,7 @@ s32 e1000e_read_phy_reg_mdic(struct e1000_hw
> *hw, u32 offset, u16 *data)
> >  * reading duplicate data in the next MDIC transaction.
> >  */
> > if (hw->mac.type == e1000_pch2lan)
> > -   udelay(100);
> > +   usleep_range(90, 100);
> >
> > return 0;
> >  }
> 
> Can you explain why shortening the delay is acceptable here?

Maybe it's not.

This patch is causing speed / duplex tests to fail on several of my test 
systems.  Specifically a Lenova laptop with an 82577 and a NUC with an i218 
(though that does not mean it is limited to those or that it's not related to 
the individual link partner.)

In both cases they "blow up" when attempting to link at 10 Mb with a Call Trace 
on the console / log and a watchdog: BUG: soft lockup - CPU#X stuck appearing 
in the current login session.  The simplest way to produce the crash is simply 
load the interface and attempt to bring it up with the link partner configured 
to 10 Mb half (force or autoneg) or forced to 10 Mb full (autoneg to 10 Mb full 
did not blow up.)  The problem is also appearing at some, but not all 100 Mb 
speeds and duplexes.  100 Mb also crashes, apparently with the same pattern.  
With the link partner set to 100 Mb half Autoneg on, 100 Mb half forced and 100 
Mb full forced the system crashes, 100 Full autoneg seems to work fine.

The call trace repeats every 30 seconds, is captured in the log and looks a lot 
like this:

Sep  7 14:17:10 u1459 kernel: watchdog: BUG: soft lockup - CPU#2 stuck for 22s! 
[kworker/2:0:23]
Sep  7 14:17:10 u1459 kernel: Modules linked in: e1000e ptp pps_core 
ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 
nf_defrag_ipv4 xt_state nf_conntrack libcrc32c ipt_REJECT nf_reject_ipv4 
xt_CHECKSUM iptable_mangle iptable_filter ip_tables bridge stp llc nfsd lockd 
grace nfs_acl auth_rpcgss sunrpc autofs4 ipv6 crc_ccitt dm_mirror 
dm_region_hash dm_log vhost_net vhost tap tun kvm_intel kvm irqbypass uinput 
joydev ax88179_178a usbnet mii iTCO_wdt iTCO_vendor_support sg i2c_i801 lpc_ich 
mfd_core xhci_pci snd_hda_codec_realtek xhci_hcd snd_hda_codec_hdmi 
snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep 
snd_seq snd_seq_device snd_pcm snd_timer snd soundcore dm_mod(E) dax(E) ext4(E) 
jbd2(E) mbcache(E) sd_mod(E) ahci(E) libahci(E) i915(E) drm_kms_helper(E) 
drm(E) fb_sys_fops(E)
Sep  7 14:17:10 u1459 kernel: sysimgblt(E) sysfillrect(E) syscopyarea(E) 
i2c_algo_bit(E) i2c_core(E) iosf_mbi(E) video(E)
Sep  7 14:17:10 u1459 kernel: CPU: 2 PID: 23 Comm: kworker/2:0 Tainted: G   
 EL  4.13.0-rc6_next-queue_dev-queue_regress #38
Sep  7 14:17:10 u1459 kernel: Hardware name:  /NUC5i5MYBE, BIOS 
MYBDWi5v.86A.0030.2016.0527.1657 05/27/2016
Sep  7 14:17:10 u1459 kernel: Workqueue: events linkwatch_event
Sep  7 14:17:10 u1459 kernel: task: 88024cf84680 task.stack: 
c9d44000
Sep  7 14:17:10 u1459 kernel: RIP: 0010:queued_spin_lock_slowpath+0x56/0x1d0
Sep  7 14:17:10 u1459 kernel: RSP: 0018:c9d478c8 EFLAGS: 0202 
ORIG_RAX: ff10
Sep  7 14:17:10 u1459 kernel: RAX: 0101 RBX: 880239fe8000 RCX: 
0101
Sep  7 14:17:10 u1459 kernel: RDX: c9d47948 RSI: 0001 RDI: 
880239feb1a0
Sep  7 14:17:10 u1459 kernel: RBP: c9d47968 R08: 0001 R09: 
88024ce181a4
Sep  7 14:17:10 u1459 kernel: R10:  R11:  R12: 
880239fe8840
Sep  7 14:17:10 u1459 kernel: R13: 88024ce180e4 R14: 88024ce180e4 R15: 
c9d47a48
Sep  7 14:17:10 u1459 kernel: FS:  () 
GS:880255d0() knlGS:
Sep  7 14:17:10 u1459 kernel: CS:  0010 DS:  ES:  CR0: 80050033
Sep  7 14:17:10 u1459 kernel: CR2: 7ffd4c3579b8 CR3: 01c09000 CR4: 
003406e0
Sep  7 14:17:10 u1459 kernel: DR0:  DR1:  DR2: 

Sep  7 14:17:10 u1459 kernel: DR3:  DR6: fffe0ff0 DR7: 
0400
Sep  7 14:17:10 u1459 kernel: Call Trace:
Sep  7 14:17:10 u1459 kernel: ? netlink_broadcast_filtered+0x15f/0x1a0
Sep  7 14:17:10 u1459 kernel: _raw_spin_lock+0x21/0x30
Sep  7 14:17:10 u1459 kernel: e1000e_get_stats64+0x2b/0x140 [e1000e]
Sep  7 14:17:10 u1459 kernel: dev_get_stats+0x3d/0xc0
Sep  7 14:17:10 u1459 kernel: ? __nla_reserve+0x53/0x70
Sep  7 14:17:10 u1459 kernel: 

RE: [Intel-wired-lan] [PATCH] igb: support BCM54616 PHY

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of John W. Linville
> Sent: Friday, July 21, 2017 11:12 AM
> To: netdev@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; John W. Linville
> 
> Subject: [Intel-wired-lan] [PATCH] igb: support BCM54616 PHY
> 
> The management port on an Edgecore AS7712-32 switch uses an igb MAC,
> but
> it uses a BCM54616 PHY. Without a patch like this, loading the igb
> module produces dmesg output like this:
> 
> [3.439125] igb: Copyright (c) 2007-2014 Intel Corporation.
> [3.439866] igb: probe of :00:14.0 failed with error -2
> 
> Signed-off-by: John W. Linville 
> Cc: Jeff Kirsher 
> ---
>  drivers/net/ethernet/intel/igb/e1000_82575.c   | 6 ++
>  drivers/net/ethernet/intel/igb/e1000_defines.h | 1 +
>  drivers/net/ethernet/intel/igb/e1000_hw.h  | 1 +
>  3 files changed, 8 insertions(+)

I do not have the specific hardware (Edgecore switch) but as far as regression 
tests go this works fine.
Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH] net: intel: e1000e: add check on e1e_wphy() return value

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of Gustavo A. R. Silva
> Sent: Tuesday, June 20, 2017 2:23 PM
> To: Kirsher, Jeffrey T 
> Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org; Gustavo A. R. Silva 
> Subject: [Intel-wired-lan] [PATCH] net: intel: e1000e: add check on
> e1e_wphy() return value
> 
> Check return value from call to e1e_wphy(). This value is being
> checked during previous calls to function e1e_wphy() and it seems
> a check was missing here.
> 
> Addresses-Coverity-ID: 1226905
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/net/ethernet/intel/e1000e/ich8lan.c | 2 ++
>  1 file changed, 2 insertions(+)

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
> Of Jeff Kirsher
> Sent: Tuesday, June 6, 2017 1:46 PM
> To: David Miller ; Nikula, Jani
> 
> Cc: Ursulin, Tvrtko ; daniel.vet...@ffwll.ch; intel-
> g...@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> jani.nik...@linux.intel.com; ch...@chris-wilson.co.uk; Ertman, David M
> ; intel-wired-...@lists.osuosl.org; dri-
> de...@lists.freedesktop.org; netdev@vger.kernel.org; airl...@gmail.com
> Subject: Re: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo
> e1000e_pm_freeze if __e1000_shutdown fails
> 
> On Fri, 2017-06-02 at 14:14 -0400, David Miller wrote:
> > From: Jani Nikula 
> > Date: Wed, 31 May 2017 18:50:43 +0300
> >
> > > From: Chris Wilson 
> > >
> > > An error during suspend (e100e_pm_suspend),
> >
> >  ...
> > > lead to complete failure:
> >
> >  ...
> > > The unwind failures stems from commit 2800209994f8 ("e1000e:
> > > Refactor PM
> > > flows"), but it may be a later patch that introduced the non-
> > > recoverable
> > > behaviour.
> > >
> > > Fixes: 2800209994f8 ("e1000e: Refactor PM flows")
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847
> > > Cc: Tvrtko Ursulin 
> > > Cc: Jeff Kirsher 
> > > Cc: Dave Ertman 
> > > Cc: Bruce Allan 
> > > Cc: intel-wired-...@lists.osuosl.org
> > > Cc: netdev@vger.kernel.org
> > > Signed-off-by: Chris Wilson 
> > > [Jani: bikeshed repainted]
> > > Signed-off-by: Jani Nikula 
> >
> > Jeff, please make sure this gets submitted to me soon.
> 
> Expect it later tonight, just finishing up testing.

Tested-by: Aaron Brown 

RE: [PATCH] e1000e: use disable_hardirq() also for MSIX vectors in e1000_netpoll()

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Konstantin Khlebnikov
> Sent: Friday, May 19, 2017 12:19 AM
> To: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey
> T 
> Cc: Dave Jones ; WANG Cong
> ; David S. Miller ;
> Sabrina Dubroca 
> Subject: [PATCH] e1000e: use disable_hardirq() also for MSIX vectors in
> e1000_netpoll()
> 
> Replace disable_irq() which waits for threaded irq handlers with
> disable_hardirq() which waits only for hardirq part.
> 
> Signed-off-by: Konstantin Khlebnikov 
> Fixes: 311191297125 ("e1000: use disable_hardirq() for e1000_netpoll()")
> ---
>  drivers/net/ethernet/intel/e1000e/netdev.c |   12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)

Tested-by: Aaron Brown 

RE: [PATCH v2] e1000e: Don't return uninitialized stats

[Brown, Aaron F]

> From: Kirsher, Jeffrey T
> Sent: Friday, May 19, 2017 1:17 AM
> To: David Miller <da...@davemloft.net>; bpoir...@suse.com
> Cc: s.pri...@profihost.ag; intel-wired-...@lists.osuosl.org;
> netdev@vger.kernel.org; pmen...@molgen.mpg.de; Neftin, Sasha
> <sasha.nef...@intel.com>; Brown, Aaron F <aaron.f.br...@intel.com>;
> step...@networkplumber.org
> Subject: Re: [PATCH v2] e1000e: Don't return uninitialized stats
> 
> On Thu, 2017-05-18 at 10:46 -0400, David Miller wrote:
> > From: Benjamin Poirier <bpoir...@suse.com>
> > Date: Wed, 17 May 2017 16:24:13 -0400
> >
> > > Some statistics passed to ethtool are garbage because
> > > e1000e_get_stats64()
> > > doesn't write them, for example: tx_heartbeat_errors. This leaks kernel
> > > memory to userspace and confuses users.
> > >
> > > Do like ixgbe and use dev_get_stats() which first zeroes out
> > > rtnl_link_stats64.
> > >
> > > Fixes: 5944701df90d ("net: remove useless memset's in drivers
> > > get_stats64")
> > > Reported-by: Stefan Priebe <s.pri...@profihost.ag>
> > > Signed-off-by: Benjamin Poirier <bpoir...@suse.com>

Tested-by: Aaron Brown <aaron.f.br...@intel.com>

RE: [Intel-wired-lan] [PATCH] igb: make a few local functions static

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Colin King
> Sent: Thursday, April 27, 2017 10:59 AM
> To: Kirsher, Jeffrey T ; intel-wired-
> l...@lists.osuosl.org; netdev@vger.kernel.org
> Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH] igb: make a few local functions static
> 
> From: Colin Ian King 
> 
> clean up a few sparse warnings, these following
> functions can be made static:
> 
> drivers/net/ethernet/intel/igb/igb_main.c: warning: symbol
>   'igb_add_mac_filter' was not declared. Should it be static?
> drivers/net/ethernet/intel/igb/igb_main.c: warning: symbol
>   'igb_del_mac_filter' was not declared. Should it be static?
> drivers/net/ethernet/intel/igb/igb_main.c: warning: symbol
>   'igb_set_vf_mac_filter' was not declared. Should it be static?
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/net/ethernet/intel/igb/igb_main.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH net-next] igb: mark PM functions as __maybe_unused

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Arnd Bergmann
> Sent: Thursday, April 27, 2017 12:10 PM
> To: Kirsher, Jeffrey T 
> Cc: Arnd Bergmann ; netdev@vger.kernel.org; linux-
> ker...@vger.kernel.org; intel-wired-...@lists.osuosl.org; David S. Miller
> 
> Subject: [Intel-wired-lan] [PATCH net-next] igb: mark PM functions as
> __maybe_unused
> 
> The new wake function is only used by the suspend/resume handlers that
> are defined in inside of an #ifdef, which can cause this harmless
> warning:
> 
> drivers/net/ethernet/intel/igb/igb_main.c:7988:13: warning:
> 'igb_deliver_wake_packet' defined but not used [-Wunused-function]
> 
> Removing the #ifdef, instead using a __maybe_unused annotation
> simplifies the code and avoids the warning.
> 
> Fixes: b90fa8763560 ("igb: Enable reading of wake up packet")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/net/ethernet/intel/igb/igb_main.c | 18 +-
>  1 file changed, 5 insertions(+), 13 deletions(-)

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH 1/2] e1000e: Don't return uninitialized stats

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Benjamin Poirier
> Sent: Monday, April 24, 2017 12:10 PM
> To: Neftin, Sasha 
> Cc: kirs...@f1.synalogic.ca; Stefan Priebe ;
> netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org
> Subject: Re: [Intel-wired-lan] [PATCH 1/2] e1000e: Don't return uninitialized
> stats
> 
> Sasha, please use reply-all to keep everyone in cc (including me...).
> 
> On 2017/04/24 11:17, Neftin, Sasha wrote:
> > On 4/23/2017 15:53, Neftin, Sasha wrote:
> > > -Original Message-
> > > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org]
> On Behalf Of Benjamin Poirier
> > > Sent: Saturday, April 22, 2017 00:20
> > > To: Kirsher, Jeffrey T 
> > > Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; Stefan
> Priebe 
> > > Subject: [Intel-wired-lan] [PATCH 1/2] e1000e: Don't return uninitialized
> stats
> > >
> > > Some statistics passed to ethtool are garbage because
> e1000e_get_stats64() doesn't write them, for example: tx_heartbeat_errors.
> This leaks kernel memory to userspace and confuses users.
> > >
> > > Do like ixgbe and use dev_get_stats() which first zeroes out
> rtnl_link_stats64.
> > >
> > > Reported-by: Stefan Priebe 
> > > Signed-off-by: Benjamin Poirier 
> > > ---
> > >   drivers/net/ethernet/intel/e1000e/ethtool.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c
> b/drivers/net/ethernet/intel/e1000e/ethtool.c
> > > index 7aff68a4a4df..f117b90cdc2f 100644
> > > --- a/drivers/net/ethernet/intel/e1000e/ethtool.c
> > > +++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
> > > @@ -2063,7 +2063,7 @@ static void e1000_get_ethtool_stats(struct
> net_device *netdev,
> > >   pm_runtime_get_sync(netdev->dev.parent);
> > > - e1000e_get_stats64(netdev, _stats);
> > > + dev_get_stats(netdev, _stats);
> > >   pm_runtime_put_sync(netdev->dev.parent);
> > > --
> > > 2.12.2
> > >
> > > ___
> > > Intel-wired-lan mailing list
> > > intel-wired-...@lists.osuosl.org
> > > http://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> >
> > Hello,
> >
> > We would like to not accept this patch. Suggested generic method
> > '*dev_get_stats' (net/core/dev.c) calls 'ops->ndo_get_stats64' method
> which
> > eventually calls e1000e_get_stats64 (netdev.c) - so there is same
> > functionality. Also, see that 'e1000e_get_stats64' method in netdev.c (line
> 
> No, it's not the same functionality because dev_get_stats() does a
> memset on the rtnl_link_stats64 struct.
> 
> > 5928) calls 'memset' with 0's before update statistics.  Local sanity check
> 
> I don't see any memset in e1000e_get_stats64(). What kernel version are
> you looking at?

The call to memset was removed from the upstream kernel with:

commit 5944701df90d9577658e2354cc27c4ceaeca30fe
Author: stephen hemminger 
Date:   Fri Jan 6 19:12:53 2017 -0800

net: remove useless memset's in drivers get_stats64

In dev_get_stats() the statistic structure storage has already been
zeroed. Therefore network drivers do not need to call memset() again.
...
< changes to other drivers snipped out >
...
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/int
index 723025b..79651eb 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5925,7 +5925,6 @@ void e1000e_get_stats64(struct net_device *netdev,
 {
struct e1000_adapter *adapter = netdev_priv(netdev);

-   memset(stats, 0, sizeof(struct rtnl_link_stats64));
spin_lock(>stats64_lock);
e1000e_update_stats(adapter);
/* Fill out the OS statistics structure */


This also is where the bad counters start to show up for e1000e for my test 
systems.  From this driver on I see (very) large values for tx_dropped, 
rx_over_errors and tx_fifo_errors on driver load (even before bringing the 
interface up.  It seems the memset is not so useless for this driver after all. 
 Would simply reverting the e1000e portion of this patch resolve the issue?

> 
> > in our lab shows 'tx_heartbeat_errors' counter reported as 0.
> >
> 
> Please see the mail I just sent to Paul Menzel 
> for more information about the issue and how to reproduce it.
> ___
> Intel-wired-lan mailing list
> intel-wired-...@lists.osuosl.org
> http://lists.osuosl.org/mailman/listinfo/intel-wired-lan

RE: [Intel-wired-lan] [PATCH] net: igbvf: Use net_device_stats from struct net_device

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Tobias Klauser
> Sent: Wednesday, April 5, 2017 11:45 PM
> To: Kirsher, Jeffrey T 
> Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org
> Subject: [Intel-wired-lan] [PATCH] net: igbvf: Use net_device_stats from
> struct net_device
> 
> Instead of using a private copy of struct net_device_stats in
> struct igbvf_adapter, use stats from struct net_device. Also remove the
> now unnecessary .ndo_get_stats function.
> 
> Signed-off-by: Tobias Klauser 
> ---
>  drivers/net/ethernet/intel/igbvf/igbvf.h  |  1 -
>  drivers/net/ethernet/intel/igbvf/netdev.c | 26 +-
>  2 files changed, 5 insertions(+), 22 deletions(-)

Tested-by: Aaron Brown 

RE: [PATCH net-next] ixgb: Omit private ndo_get_stats function

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Tobias Klauser
> Sent: Wednesday, February 15, 2017 3:08 AM
> To: netdev@vger.kernel.org
> Cc: Kirsher, Jeffrey T ; intel-wired-
> l...@lists.osuosl.org; Joe Perches 
> Subject: [PATCH net-next] ixgb: Omit private ndo_get_stats function
> 
> ixgb_get_stats() just returns dev->stats so we can leave it
> out altogether and let dev_get_stats() do the job.
> 
> Suggested-by: Joe Perches 
> Signed-off-by: Tobias Klauser 
> ---
>  drivers/net/ethernet/intel/ixgb/ixgb_main.c | 16 
>  1 file changed, 16 deletions(-)

Well, well.  I managed to locate one of my ixgb based adapters as well as a 
system with a working PCI-X bus to host it.

Tested-by: Aaron Brown 

RE: [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Bernd Faust
> Sent: Thursday, February 16, 2017 10:42 AM
> To: Kirsher, Jeffrey T ; Lubetkin, YanirX
> ; intel-wired-...@lists.osuosl.org;
> netdev@vger.kernel.org; linux-ker...@vger.kernel.org
> Cc: Bernd Faust 
> Subject: [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller
> 
> After an upgrade to Linux kernel v4.x the hardware timestamps of the
> 82579 Gigabit Ethernet Controller are different than expected.
> The values that are being read are almost four times as big as before
> the kernel upgrade.
> 
> The difference is that after the upgrade the driver sets the clock
> frequency to 25MHz, where before the upgrade it was set to 96MHz. Intel
> confirmed that the correct frequency for this network adapter is 96MHz.
> 
> Signed-off-by: Bernd Faust 
> ---
>  drivers/net/ethernet/intel/e1000e/netdev.c | 6 ++
>  1 file changed, 6 insertions(+)

Tested-by: Aaron Brown 

RE: [PATCH net-next] e1000: Omit private ndo_get_stats function

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Tobias Klauser
> Sent: Wednesday, February 15, 2017 3:08 AM
> To: netdev@vger.kernel.org
> Cc: Kirsher, Jeffrey T ; intel-wired-
> l...@lists.osuosl.org; Joe Perches 
> Subject: [PATCH net-next] e1000: Omit private ndo_get_stats function
> 
> e1000_get_stats() just returns dev->stats so we can leave it
> out altogether and let dev_get_stats() do the job.
> 
> Suggested-by: Joe Perches 
> Signed-off-by: Tobias Klauser 
> ---
>  drivers/net/ethernet/intel/e1000/e1000_main.c | 15 ---
>  1 file changed, 15 deletions(-)

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH] net: intel: ixgb: use new api ethtool_{get|set}_link_ksettings

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Philippe Reynes
> Sent: Sunday, February 5, 2017 3:11 PM
> To: Kirsher, Jeffrey T ; da...@davemloft.net
> Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org; Philippe Reynes 
> Subject: [Intel-wired-lan] [PATCH] net: intel: ixgb: use new api
> ethtool_{get|set}_link_ksettings
> 
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
> 
> Signed-off-by: Philippe Reynes 
> ---
>  drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c |   39 ++-
> -
>  1 files changed, 23 insertions(+), 16 deletions(-)
> 

Tested-by: Aaron Brown 
Well, compile / static tested by:  I probably have an ixgb adapter somewhere as 
well as a PCI-X slot that might work for it, but am not sure I can find them or 
that they still function.  If I stumble upon one I'll fire it up and run it 
through some paces, but the variant of this patch for other drivers seem good 
and I don't want to hold this patch up any longer.

RE: [Intel-wired-lan] [PATCH] net: intel: igbvf: use new api ethtool_{get|set}_link_ksettings

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Philippe Reynes
> Sent: Sunday, February 5, 2017 2:55 PM
> To: Kirsher, Jeffrey T ; da...@davemloft.net
> Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org; Philippe Reynes 
> Subject: [Intel-wired-lan] [PATCH] net: intel: igbvf: use new api
> ethtool_{get|set}_link_ksettings
> 
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
> 
> Signed-off-by: Philippe Reynes 
> ---
>  drivers/net/ethernet/intel/igbvf/ethtool.c |   38 
> ++--
>  1 files changed, 19 insertions(+), 19 deletions(-)

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH] net: intel: igb: use new api ethtool_{get|set}_link_ksettings

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Philippe Reynes
> Sent: Sunday, February 5, 2017 9:56 AM
> To: Kirsher, Jeffrey T ; da...@davemloft.net
> Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org; Philippe Reynes 
> Subject: [Intel-wired-lan] [PATCH] net: intel: igb: use new api
> ethtool_{get|set}_link_ksettings
> 
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
> 
> Signed-off-by: Philippe Reynes 
> ---
>  drivers/net/ethernet/intel/igb/igb_ethtool.c |  108 ++---
> -
>  1 files changed, 59 insertions(+), 49 deletions(-)
> 

Tested-by: Aaron Brown 

RE: [PATCH] net: intel: e1000: use new api ethtool_{get|set}_link_ksettings

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Philippe Reynes
> Sent: Saturday, January 21, 2017 7:06 AM
> To: Kirsher, Jeffrey T ; da...@davemloft.net
> Cc: intel-wired-...@lists.osuosl.org; netdev@vger.kernel.org; linux-
> ker...@vger.kernel.org; Philippe Reynes 
> Subject: [PATCH] net: intel: e1000: use new api
> ethtool_{get|set}_link_ksettings
> 
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
> 
> Signed-off-by: Philippe Reynes 
> ---
>  drivers/net/ethernet/intel/e1000/e1000_ethtool.c |   93 +++-
> --
>  1 files changed, 46 insertions(+), 47 deletions(-)

Tested-by: Aaron Brown 

RE: [PATCH] net: intel: e1000e: use new api ethtool_{get|set}_link_ksettings

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Philippe Reynes
> Sent: Thursday, January 26, 2017 1:20 PM
> To: Kirsher, Jeffrey T ; da...@davemloft.net
> Cc: intel-wired-...@lists.osuosl.org; netdev@vger.kernel.org; linux-
> ker...@vger.kernel.org; Philippe Reynes 
> Subject: [PATCH] net: intel: e1000e: use new api
> ethtool_{get|set}_link_ksettings
> 
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
> 
> Signed-off-by: Philippe Reynes 
> ---
>  drivers/net/ethernet/intel/e1000e/ethtool.c |   91 ++-
> ---
>  1 files changed, 49 insertions(+), 42 deletions(-)

Tested-by: Aaron Brown 

RE: [PATCH 1/1] igb: Fix hw_dbg logging in igb_update_flash_i210

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Peter Senna Tschudin
> Sent: Monday, January 2, 2017 9:26 AM
> Cc: Hannu Lounento ; Peter Senna Tschudin
> ; Kirsher, Jeffrey T
> ; moderated list:INTEL ETHERNET DRIVERS
> ; open list:NETWORKING DRIVERS
> ; open list 
> Subject: [PATCH 1/1] igb: Fix hw_dbg logging in igb_update_flash_i210
> 
> From: Hannu Lounento 
> 
> Fix an if statement with hw_dbg lines where the logic was inverted with
> regards to the corresponding return value used in the if statement.
> 
> Signed-off-by: Hannu Lounento 
> Signed-off-by: Peter Senna Tschudin 
> ---
>  drivers/net/ethernet/intel/igb/e1000_i210.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Tested-by: Aaron Brown 

RE: [Intel-wired-lan] [PATCH net v2] igb: re-assign hw address pointer on reset after PCI error

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Guilherme G. Piccoli
> Sent: Thursday, November 10, 2016 10:47 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; gpicc...@linux.vnet.ibm.com
> Subject: [Intel-wired-lan] [PATCH net v2] igb: re-assign hw address pointer on
> reset after PCI error
> 
> Whenever the igb driver detects the result of a read operation returns
> a value composed only by F's (like 0x), it will detach the
> net_device, clear the hw_addr pointer and warn to the user that adapter's
> link is lost - those steps happen on igb_rd32().
> 
> In case a PCI error happens on Power architecture, there's a recovery
> mechanism called EEH, that will reset the PCI slot and call driver's
> handlers to reset the adapter and network functionality as well.
> 
> We observed that once hw_addr is NULL after the error is detected on
> igb_rd32(), it's never assigned back, so in the process of resetting
> the network functionality we got a NULL pointer dereference in both
> igb_configure_tx_ring() and igb_configure_rx_ring(). In order to avoid
> such bug, this patch re-assigns the hw_addr value in the slot_reset
> handler.
> 
> Reported-by: Anthony H. Thai 
> Reported-by: Harsha Thyagaraja 
> Signed-off-by: Guilherme G. Piccoli 
> ---
>  drivers/net/ethernet/intel/igb/igb_main.c | 5 +
>  1 file changed, 5 insertions(+)

Tested-by: Aaron Brown