<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers/net/ethernet/intel, branch dev-4.17</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.17</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.17'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2018-08-03T05:47:58+00:00</updated>
<entry>
<title>igb: Fix queue selection on MAC filters on i210</title>
<updated>2018-08-03T05:47:58+00:00</updated>
<author>
<name>Vinicius Costa Gomes</name>
<email>vinicius.gomes@intel.com</email>
</author>
<published>2018-04-10T17:49:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=62de12170fdc846623394ab5791fd74c548f2a26'/>
<id>urn:sha1:62de12170fdc846623394ab5791fd74c548f2a26</id>
<content type='text'>
[ Upstream commit 4dc93fcf0b95dc3fda4db917effae31fbb8ad2a8 ]

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 &lt;vinicius.gomes@intel.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>i40e: avoid overflow in i40e_ptp_adjfreq()</title>
<updated>2018-08-03T05:47:57+00:00</updated>
<author>
<name>Jacob Keller</name>
<email>jacob.e.keller@intel.com</email>
</author>
<published>2018-04-20T08:41:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=1bcca8a39076c40754513db93b812f4d9526921c'/>
<id>urn:sha1:1bcca8a39076c40754513db93b812f4d9526921c</id>
<content type='text'>
[ Upstream commit 830e0dd9996c4644e42412aa6c46ed8f8eab0cca ]

When operating at 1GbE, the base incval for the PTP clock is so large
that multiplying it by numbers close to the max_adj can overflow the
u64.

Rather than attempting to limit the max_adj to a value small enough to
avoid overflow, instead calculate the incvalue adjustment based on the
40GbE incvalue, and then multiply that by the scaling factor for the
link speed.

This sacrifices a small amount of precision in the adjustment but we
avoid erratic behavior of the clock due to the overflow caused if ppb is
very near the maximum adjustment.

Signed-off-by: Jacob Keller &lt;jacob.e.keller@intel.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>i40e: Add advertising 10G LR mode</title>
<updated>2018-08-03T05:47:57+00:00</updated>
<author>
<name>Jakub Pawlak</name>
<email>jakub.pawlak@intel.com</email>
</author>
<published>2018-04-20T08:41:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=d8fb5d37a9b8c4fd1e54de61b11f798a8b1c016f'/>
<id>urn:sha1:d8fb5d37a9b8c4fd1e54de61b11f798a8b1c016f</id>
<content type='text'>
[ Upstream commit 6ee4d32255865fc4b383355a8354603d60ab9f8a ]

The advertising 10G LR mode should be possible to set
but in the function i40e_set_link_ksettings() check for this
is missed. This patch adds check for 10000baseLR_Full
flag for 10G modes.

Signed-off-by: Jakub Pawlak &lt;jakub.pawlak@intel.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>i40e: free the skb after clearing the bitlock</title>
<updated>2018-08-03T05:47:52+00:00</updated>
<author>
<name>Jacob Keller</name>
<email>jacob.e.keller@intel.com</email>
</author>
<published>2018-05-10T12:59:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=69596fc961e0fc66342fe7c663f98b5bc40f926c'/>
<id>urn:sha1:69596fc961e0fc66342fe7c663f98b5bc40f926c</id>
<content type='text'>
[ Upstream commit c79756cb5f084736b138da9319a02f7c72644548 ]

In commit bbc4e7d273b5 ("i40e: fix race condition with PTP_TX_IN_PROGRESS
bits") we modified the code which handles Tx timestamps so that we would
clear the progress bit as soon as possible.

A later commit 0bc0706b46cd ("i40e: check for Tx timestamp timeouts during
watchdog") introduced similar code for detecting and handling cleanup of
a blocked Tx timestamp. This code did not use the same pattern for cleaning
up the skb.

Update this code to wait to free the skb until after the bit lock is
free, by first setting the ptp_tx_skb to NULL and clearing the lock.

Signed-off-by: Jacob Keller &lt;jacob.e.keller@intel.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ixgbevf: fix MAC address changes through ixgbevf_set_mac()</title>
<updated>2018-08-03T05:47:49+00:00</updated>
<author>
<name>Emil Tantilov</name>
<email>emil.s.tantilov@intel.com</email>
</author>
<published>2018-05-14T18:16:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=e775c2bc95000ccb3fbdb6e404caf205859e360e'/>
<id>urn:sha1:e775c2bc95000ccb3fbdb6e404caf205859e360e</id>
<content type='text'>
[ Upstream commit 6e7d0ba1e59b1a306761a731e67634c0f2efea2a ]

Set hw-&gt;mac.perm_addr in ixgbevf_set_mac() in order to avoid losing the
custom MAC on reset. This can happen in the following case:

&gt;ip link set $vf address $mac
&gt;ethtool -r $vf

Signed-off-by: Emil Tantilov &lt;emil.s.tantilov@intel.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>e1000e: Ignore TSYNCRXCTL when getting I219 clock attributes</title>
<updated>2018-08-03T05:47:37+00:00</updated>
<author>
<name>Benjamin Poirier</name>
<email>bpoirier@suse.com</email>
</author>
<published>2018-05-10T07:28:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a1a6cfeea67fffc73589f3195dd7aec7ac2ea583'/>
<id>urn:sha1:a1a6cfeea67fffc73589f3195dd7aec7ac2ea583</id>
<content type='text'>
[ Upstream commit fff200caf6f9179dd9a7fc67acd659e614c3f72f ]

There have been multiple reports of crashes that look like
kernel: RIP: 0010:[&lt;ffffffff8110303f&gt;] timecounter_read+0xf/0x50
[...]
kernel: Call Trace:
kernel:  [&lt;ffffffffa0806b0f&gt;] e1000e_phc_gettime+0x2f/0x60 [e1000e]
kernel:  [&lt;ffffffffa0806c5d&gt;] e1000e_systim_overflow_work+0x1d/0x80 [e1000e]
kernel:  [&lt;ffffffff810992c5&gt;] process_one_work+0x155/0x440
kernel:  [&lt;ffffffff81099e16&gt;] worker_thread+0x116/0x4b0
kernel:  [&lt;ffffffff8109f422&gt;] kthread+0xd2/0xf0
kernel:  [&lt;ffffffff8163184f&gt;] 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 &lt;admin@fph.physik.uni-karlsruhe.de&gt;
Message-Id: &lt;20180425065243.g5mqewg5irkwgwgv@f2&gt;
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1075876
Fixes: 83129b37ef35 ("e1000e: fix systim issues")
Signed-off-by: Benjamin Poirier &lt;bpoirier@suse.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ixgbe: Fix setting of TC configuration for macvlan case</title>
<updated>2018-08-03T05:47:34+00:00</updated>
<author>
<name>Alexander Duyck</name>
<email>alexander.h.duyck@intel.com</email>
</author>
<published>2018-06-04T15:07:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=e2bed54f0e5d3744a4e50ed657643d38fb2a744b'/>
<id>urn:sha1:e2bed54f0e5d3744a4e50ed657643d38fb2a744b</id>
<content type='text'>
[ Upstream commit 646bb57ce86e4d7b0bd9d33244450ae009411e48 ]

When we were enabling macvlan interfaces we weren't correctly configuring
things until ixgbe_setup_tc was called a second time either by tweaking the
number of queues or increasing the macvlan count past 15.

The issue came down to the fact that num_rx_pools is not populated until
after the queues and interrupts are reinitialized.

Instead of trying to set it sooner we can just move the call to setup at
least 1 traffic class to the SR-IOV/VMDq setup function so that we just set
it for this one case. We already had a spot that was configuring the queues
for TC 0 in the code here anyway so it makes sense to also set the number
of TCs here as well.

Fixes: 49cfbeb7a95c ("ixgbe: Fix handling of macvlan Tx offload")
Signed-off-by: Alexander Duyck &lt;alexander.h.duyck@intel.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>i40e: split XDP_TX tail and XDP_REDIRECT map flushing</title>
<updated>2018-07-22T13:16:03+00:00</updated>
<author>
<name>Jesper Dangaard Brouer</name>
<email>brouer@redhat.com</email>
</author>
<published>2018-06-26T15:39:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=fd58784465903ba4cab07692970a244440d461c5'/>
<id>urn:sha1:fd58784465903ba4cab07692970a244440d461c5</id>
<content type='text'>
[ Upstream commit 2e6893123830d04edc366e0ce59d46e622e140c1 ]

The driver was combining the XDP_TX tail flush and XDP_REDIRECT
map flushing (xdp_do_flush_map).  This is suboptimal, these two
flush operations should be kept separate.

It looks like the mistake was copy-pasted from ixgbe.

Fixes: d9314c474d4f ("i40e: add support for XDP_REDIRECT")
Signed-off-by: Jesper Dangaard Brouer &lt;brouer@redhat.com&gt;
Acked-by: Björn Töpel &lt;bjorn.topel@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ixgbe: split XDP_TX tail and XDP_REDIRECT map flushing</title>
<updated>2018-07-22T13:15:59+00:00</updated>
<author>
<name>Jesper Dangaard Brouer</name>
<email>brouer@redhat.com</email>
</author>
<published>2018-06-26T15:39:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=9428d615a6c8d065800cc6de2130676462105154'/>
<id>urn:sha1:9428d615a6c8d065800cc6de2130676462105154</id>
<content type='text'>
[ Upstream commit ad088ec480768850db019a5cc543685e868a513d ]

The driver was combining the XDP_TX tail flush and XDP_REDIRECT
map flushing (xdp_do_flush_map).  This is suboptimal, these two
flush operations should be kept separate.

Fixes: 11393cc9b9be ("xdp: Add batching support to redirect map")
Signed-off-by: Jesper Dangaard Brouer &lt;brouer@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ixgbe: fix parsing of TC actions for HW offload</title>
<updated>2018-06-01T03:01:00+00:00</updated>
<author>
<name>Ondřej Hlavatý</name>
<email>ohlavaty@redhat.com</email>
</author>
<published>2018-05-31T21:21:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=16e6653c8259ca5383126e1c6bcf7fe062af87fc'/>
<id>urn:sha1:16e6653c8259ca5383126e1c6bcf7fe062af87fc</id>
<content type='text'>
The previous code was optimistic, accepting the offload of whole action
chain when there was a single known action (drop/redirect). This results
in offloading a rule which should not be offloaded, because its behavior
cannot be reproduced in the hardware.

For example:

$ tc filter add dev eno1 parent ffff: protocol ip \
    u32 ht 800: order 1 match tcp src 42 FFFF \
    action mirred egress mirror dev enp1s16 pipe \
    drop

The controller is unable to mirror the packet to a VF, but still
offloads the rule by dropping the packet.

Change the approach of the function to a pessimistic one, rejecting the
chain when an unknown action is found. This is better suited for future
extensions.

Note that both recognized actions always return TC_ACT_SHOT, therefore
it is safe to ignore actions behind them.

Signed-off-by: Ondřej Hlavatý &lt;ohlavaty@redhat.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
