<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/net/ethernet/intel/ice, branch linux-5.0.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.0.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.0.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2019-05-31T13:45:24Z</updated>
<entry>
<title>ice: Put __ICE_PREPARED_FOR_RESET check in ice_prepare_for_reset</title>
<updated>2019-05-31T13:45:24Z</updated>
<author>
<name>Brett Creeley</name>
</author>
<published>2019-02-13T18:51:14Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=de56a5e33754f0f6f670eac06903faae062919bd'/>
<id>urn:sha1:de56a5e33754f0f6f670eac06903faae062919bd</id>
<content type='text'>
[ Upstream commit 5abac9d7e1bb9a373673811154774d4c89a7f85e ]

Currently we check if the __ICE_PREPARED_FOR_RESET bit is set prior to
calling ice_prepare_for_reset in ice_reset_subtask(), but we aren't
checking that bit in ice_do_reset() before calling
ice_prepare_for_reset(). This is not consistent and can cause issues if
ice_prepare_for_reset() is called prior to ice_do_reset(). Fix this by
checking if the __ICE_PREPARED_FOR_RESET bit is set internal to
ice_prepare_for_reset().

Signed-off-by: Brett Creeley &lt;brett.creeley@intel.com&gt;
Signed-off-by: Anirudh Venkataramanan &lt;anirudh.venkataramanan@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;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ice: Prevent unintended multiple chain resets</title>
<updated>2019-05-31T13:45:16Z</updated>
<author>
<name>Dave Ertman</name>
</author>
<published>2019-02-13T18:51:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=64d49642575f37f794869c5d93b44a328fe459a4'/>
<id>urn:sha1:64d49642575f37f794869c5d93b44a328fe459a4</id>
<content type='text'>
[ Upstream commit 2ebd4428d93a2f6ce0c813b10a1a43b6a8241fe5 ]

In the current implementation of ice_reset_subtask, if multiple reset
types are set in the pf-&gt;state, the most intrusive one is meant to be
performed only, but the bits requesting the other types are not being
cleared. This would lead to another reset being performed the next time
the service task is scheduled.

Change the flow of ice_reset_subtask so that all reset request bits in
pf-&gt;state are cleared, and we still perform the most intrusive of the
resets requested.

Signed-off-by: Dave Ertman &lt;david.m.ertman@intel.com&gt;
Signed-off-by: Anirudh Venkataramanan &lt;anirudh.venkataramanan@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;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ice: Separate if conditions for ice_set_features()</title>
<updated>2019-05-31T13:44:52Z</updated>
<author>
<name>Tony Nguyen</name>
</author>
<published>2019-04-16T17:21:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=57fbf874e4e6e99ac2653ec82883a27016d27e66'/>
<id>urn:sha1:57fbf874e4e6e99ac2653ec82883a27016d27e66</id>
<content type='text'>
[ Upstream commit 8f529ff912073f778e3cd74e87fb69a36499fc2f ]

Set features can have multiple features turned on|off in a single
call.  Grouping these all in an if/else means after one condition
is met, other conditions/features will not be evaluated.  Break
the if/else statements by feature to ensure all features will be
handled properly.

Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
Signed-off-by: Anirudh Venkataramanan &lt;anirudh.venkataramanan@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;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ice: fix ice_remove_rule_internal vsi_list handling</title>
<updated>2019-04-05T20:34:30Z</updated>
<author>
<name>Jacob Keller</name>
</author>
<published>2019-02-08T20:50:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=565e4ecefeae67d0b1575dd6016b161deda00db5'/>
<id>urn:sha1:565e4ecefeae67d0b1575dd6016b161deda00db5</id>
<content type='text'>
[ Upstream commit f9264dd687f8d3f9104c9900f8f3e5e419f27c55 ]

When adding multiple VLANs to the same VSI, the ice_add_vlan code will
share the VSI list, so as not to create multiple unnecessary VSI lists.

Consider the following flow

  ice_add_vlan(hw, &lt;VSI 0 VID 7, VSI 0 VID 8, VSI 0 VID 9&gt;)

Where we add three VLAN filters for VIDs 7, 8, and 9, all for VSI 0.

The ice_add_vlan will create a single vsi_list and share it among all
the filters.

Later, if we try to remove a VLAN,

  ice_remove_vlan(hw, &lt;VSI 0 VID 7&gt;)

Then the removal code will update the vsi_list and remove VSI 0 from it.
But, since the vsi_list is shared, this breaks the list for the other
users who reference it. We actually even free the VSI list memory, and
may result in segmentation faults.

This is due to the way that VLAN rule share VSI lists with reference
counts, and is caused because we call ice_rem_update_vsi_list even when
the ref_cnt is greater than one.

To fix this, handle the case where ref_cnt is greater than one
separately. In this case, we need to remove the associated rule without
modifying the vsi_list, since it is currently being referenced by
another rule. Instead, we just need to decrement the VSI list ref_cnt.

The case for handling sharing of VSI lists with multiple VSIs is not
currently supported by this code. No such rules will be created today,
and this code will require changes if/when such code is added.

Signed-off-by: Jacob Keller &lt;jacob.e.keller@intel.com&gt;
Reviewed-by: Bruce Allan &lt;bruce.w.allan@intel.com&gt;
Signed-off-by: Anirudh Venkataramanan &lt;anirudh.venkataramanan@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;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ice: Do not enable NAPI on q_vectors that have no rings</title>
<updated>2018-12-20T20:10:24Z</updated>
<author>
<name>Young Xiao</name>
</author>
<published>2018-11-29T01:54:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=eec903769b4ea476591ffff73bb7359f14f38c51'/>
<id>urn:sha1:eec903769b4ea476591ffff73bb7359f14f38c51</id>
<content type='text'>
If ice driver has q_vectors w/ active NAPI that has no rings,
then this will result in a divide by zero error. To correct it
I am updating the driver code so that we only support NAPI on
q_vectors that have 1 or more rings allocated to them.

See commit 13a8cd191a2b ("i40e: Do not enable NAPI on q_vectors
that have no rings") for detail.

Signed-off-by: Young Xiao &lt;YangX92@hotmail.com&gt;
Acked-by: Anirudh Venkataramanan &lt;anirudh.venkataramanan@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;
</content>
</entry>
<entry>
<title>net: ndo_bridge_setlink: Add extack</title>
<updated>2018-12-13T00:34:21Z</updated>
<author>
<name>Petr Machata</name>
</author>
<published>2018-12-12T17:02:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2fd527b72bb6f95dfe8a1902e998cb76390c431e'/>
<id>urn:sha1:2fd527b72bb6f95dfe8a1902e998cb76390c431e</id>
<content type='text'>
Drivers may not be able to implement a VLAN addition or reconfiguration.
In those cases it's desirable to explain to the user that it was
rejected (and why).

To that end, add extack argument to ndo_bridge_setlink. Adapt all users
to that change.

Following patches will use the new argument in the bridge driver.

Signed-off-by: Petr Machata &lt;petrm@mellanox.com&gt;
Acked-by: Jiri Pirko &lt;jiri@mellanox.com&gt;
Reviewed-by: Ido Schimmel &lt;idosch@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ethernet/intel: consolidate NAPI and NAPI exit</title>
<updated>2018-11-21T18:35:23Z</updated>
<author>
<name>Jesse Brandeburg</name>
</author>
<published>2018-11-08T22:55:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0bcd952feec7042d9a5383b639c8edc943402add'/>
<id>urn:sha1:0bcd952feec7042d9a5383b639c8edc943402add</id>
<content type='text'>
While reviewing code, I noticed that Eric Dumazet recommends that
drivers check the return code of napi_complete_done, and use that
to decide to enable interrupts or not when exiting poll.  One of
the Intel drivers was already fixed (ixgbe).

Upon looking at the Intel drivers as a whole, we are handling our
polling and NAPI exit in a few different ways based on whether we
have multiqueue and whether we have Tx cleanup included. Several
drivers had the bug of exiting NAPI with return 0, which appears
to mess up the accounting in the stack.

Consolidate all the NAPI routines to do best known way of exiting
and to just mostly look like each other.
1) check return code of napi_complete_done to control interrupt enable
2) return the actual amount of work done.
3) return budget immediately if need NAPI poll again

Tested the changes on e1000e with a high interrupt rate set, and
it shows about an 8% reduction in the CPU utilization when busy
polling because we aren't re-enabling interrupts when we're about
to be polled.

Signed-off-by: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Reviewed-by: Jacob Keller &lt;jacob.e.keller@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
</entry>
<entry>
<title>ice: Fix possible NULL pointer de-reference</title>
<updated>2018-11-20T19:39:04Z</updated>
<author>
<name>Bruce Allan</name>
</author>
<published>2018-11-07T18:19:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f25dad19ba70f7cc135da78ec013325042cd8c52'/>
<id>urn:sha1:f25dad19ba70f7cc135da78ec013325042cd8c52</id>
<content type='text'>
A recent update to smatch is causing it to report the error "we previously
assumed 'm_entry-&gt;vsi_list_info' could be null". Fix that.

Signed-off-by: Bruce Allan &lt;bruce.w.allan@intel.com&gt;
Signed-off-by: Anirudh Venkataramanan &lt;anirudh.venkataramanan@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;
</content>
</entry>
<entry>
<title>ice: Use Tx|Rx in comments</title>
<updated>2018-11-20T19:39:04Z</updated>
<author>
<name>Anirudh Venkataramanan</name>
</author>
<published>2018-10-26T18:44:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d337f2afb7aceb16840a2621c5e2f9e868630653'/>
<id>urn:sha1:d337f2afb7aceb16840a2621c5e2f9e868630653</id>
<content type='text'>
In code comments, use Tx|Rx instead of tx|rx

Signed-off-by: Anirudh Venkataramanan &lt;anirudh.venkataramanan@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;
</content>
</entry>
<entry>
<title>ice: Cosmetic formatting changes</title>
<updated>2018-11-20T19:39:04Z</updated>
<author>
<name>Anirudh Venkataramanan</name>
</author>
<published>2018-10-26T18:44:46Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=df17b7e02f0fa3a13c5aac26c317447d72612e1c'/>
<id>urn:sha1:df17b7e02f0fa3a13c5aac26c317447d72612e1c</id>
<content type='text'>
1. Fix several cases of double spacing
2. Fix typos
3. Capitalize abbreviations

Signed-off-by: Anirudh Venkataramanan &lt;anirudh.venkataramanan@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;
</content>
</entry>
</feed>
