<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net/ethernet/intel, branch linux-5.0.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ice: Put __ICE_PREPARED_FOR_RESET check in ice_prepare_for_reset</title>
<updated>2019-05-31T13:45:24+00:00</updated>
<author>
<name>Brett Creeley</name>
<email>brett.creeley@intel.com</email>
</author>
<published>2019-02-13T18:51:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=de56a5e33754f0f6f670eac06903faae062919bd'/>
<id>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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ 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;
</pre>
</div>
</content>
</entry>
<entry>
<title>igb: Exclude device from suspend direct complete optimization</title>
<updated>2019-05-31T13:45:18+00:00</updated>
<author>
<name>Kai-Heng Feng</name>
<email>kai.heng.feng@canonical.com</email>
</author>
<published>2018-12-11T07:59:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3c910a02c9ba1862497776d349b968123e7e31be'/>
<id>3c910a02c9ba1862497776d349b968123e7e31be</id>
<content type='text'>
[ Upstream commit 5b6e13216be29ced7350d9c354a1af8fe0ad9a3e ]

igb sets different WoL settings in system suspend callback and runtime
suspend callback.

The suspend direct complete optimization leaves igb in runtime suspended
state with wrong WoL setting during system suspend.

To fix this, we need to disable suspend direct complete optimization to
let igb always use suspend callback to set correct WoL during system
suspend.

Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.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;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 5b6e13216be29ced7350d9c354a1af8fe0ad9a3e ]

igb sets different WoL settings in system suspend callback and runtime
suspend callback.

The suspend direct complete optimization leaves igb in runtime suspended
state with wrong WoL setting during system suspend.

To fix this, we need to disable suspend direct complete optimization to
let igb always use suspend callback to set correct WoL during system
suspend.

Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.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;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>e1000e: Disable runtime PM on CNP+</title>
<updated>2019-05-31T13:45:18+00:00</updated>
<author>
<name>Kai-Heng Feng</name>
<email>kai.heng.feng@canonical.com</email>
</author>
<published>2019-02-02T17:40:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=387c278ed19b33d3f160db12685c852c93be3cbe'/>
<id>387c278ed19b33d3f160db12685c852c93be3cbe</id>
<content type='text'>
[ Upstream commit 459d69c407f9ba122f12216555c3012284dc9fd7 ]

There are some new e1000e devices can only be woken up from D3 one time,
by plugging Ethernet cable. Subsequent cable plugging does set PME bit
correctly, but it still doesn't get woken up.

Since e1000e connects to the root complex directly, we rely on ACPI to
wake it up. In this case, the GPE from _PRW only works once and stops
working after that. Though it appears to be a platform bug, e1000e
maintainers confirmed that I219 does not support D3.

So disable runtime PM on CNP+ chips. We may need to disable earlier
generations if this bug also hit older platforms.

Bugzilla: https://bugzilla.kernel.org/attachment.cgi?id=280819
Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.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;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 459d69c407f9ba122f12216555c3012284dc9fd7 ]

There are some new e1000e devices can only be woken up from D3 one time,
by plugging Ethernet cable. Subsequent cable plugging does set PME bit
correctly, but it still doesn't get woken up.

Since e1000e connects to the root complex directly, we rely on ACPI to
wake it up. In this case, the GPE from _PRW only works once and stops
working after that. Though it appears to be a platform bug, e1000e
maintainers confirmed that I219 does not support D3.

So disable runtime PM on CNP+ chips. We may need to disable earlier
generations if this bug also hit older platforms.

Bugzilla: https://bugzilla.kernel.org/attachment.cgi?id=280819
Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.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;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ice: Prevent unintended multiple chain resets</title>
<updated>2019-05-31T13:45:16+00:00</updated>
<author>
<name>Dave Ertman</name>
<email>david.m.ertman@intel.com</email>
</author>
<published>2019-02-13T18:51:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=64d49642575f37f794869c5d93b44a328fe459a4'/>
<id>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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ 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;
</pre>
</div>
</content>
</entry>
<entry>
<title>i40e: don't allow changes to HW VLAN stripping on active port VLANs</title>
<updated>2019-05-31T13:45:05+00:00</updated>
<author>
<name>Nicholas Nunley</name>
<email>nicholas.d.nunley@intel.com</email>
</author>
<published>2019-02-06T23:08:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=32123c567406c1fcc68775069d2d1428d1727bab'/>
<id>32123c567406c1fcc68775069d2d1428d1727bab</id>
<content type='text'>
[ Upstream commit bfb0ebed53857cfc57f11c63fa3689940d71c1c8 ]

Modifying the VLAN stripping options when a port VLAN is configured
will break traffic for the VSI, and conceptually doesn't make sense,
so don't allow this.

Signed-off-by: Nicholas Nunley &lt;nicholas.d.nunley@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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit bfb0ebed53857cfc57f11c63fa3689940d71c1c8 ]

Modifying the VLAN stripping options when a port VLAN is configured
will break traffic for the VSI, and conceptually doesn't make sense,
so don't allow this.

Signed-off-by: Nicholas Nunley &lt;nicholas.d.nunley@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;
</pre>
</div>
</content>
</entry>
<entry>
<title>i40e: Able to add up to 16 MAC filters on an untrusted VF</title>
<updated>2019-05-31T13:45:04+00:00</updated>
<author>
<name>Adam Ludkiewicz</name>
<email>adam.ludkiewicz@intel.com</email>
</author>
<published>2019-02-06T23:08:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e6abfd1fc057e14a13ede1338fb3fe55513d31e3'/>
<id>e6abfd1fc057e14a13ede1338fb3fe55513d31e3</id>
<content type='text'>
[ Upstream commit 06b6e2a2333eb3581567a7ac43ca465ef45f4daa ]

This patch fixes the problem with the driver being able to add only 7
multicast MAC address filters instead of 16. The problem is fixed by
changing the maximum number of MAC address filters to 16+1+1 (two extra
are needed because the driver uses 1 for unicast MAC address and 1 for
broadcast).

Signed-off-by: Adam Ludkiewicz &lt;adam.ludkiewicz@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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 06b6e2a2333eb3581567a7ac43ca465ef45f4daa ]

This patch fixes the problem with the driver being able to add only 7
multicast MAC address filters instead of 16. The problem is fixed by
changing the maximum number of MAC address filters to 16+1+1 (two extra
are needed because the driver uses 1 for unicast MAC address and 1 for
broadcast).

Signed-off-by: Adam Ludkiewicz &lt;adam.ludkiewicz@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;
</pre>
</div>
</content>
</entry>
<entry>
<title>ice: Separate if conditions for ice_set_features()</title>
<updated>2019-05-31T13:44:52+00:00</updated>
<author>
<name>Tony Nguyen</name>
<email>anthony.l.nguyen@intel.com</email>
</author>
<published>2019-04-16T17:21:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=57fbf874e4e6e99ac2653ec82883a27016d27e66'/>
<id>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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ 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;
</pre>
</div>
</content>
</entry>
<entry>
<title>i40e: fix WoL support check</title>
<updated>2019-05-08T05:22:49+00:00</updated>
<author>
<name>Stefan Assmann</name>
<email>sassmann@kpanic.de</email>
</author>
<published>2019-03-21T12:45:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=56e41e46e860b672bd35022b28e2e6fb5977888b'/>
<id>56e41e46e860b672bd35022b28e2e6fb5977888b</id>
<content type='text'>
[ Upstream commit f669d24f3dd00beab452c0fc9257f6a942ffca9b ]

The current check for WoL on i40e is broken. Code comment says only
magic packet is supported, so only check for that.

Fixes: 540a152da762 (i40e/ixgbe/igb: fail on new WoL flag setting WAKE_MAGICSECURE)

Signed-off-by: Stefan Assmann &lt;sassmann@kpanic.de&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Sasha Levin (Microsoft) &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f669d24f3dd00beab452c0fc9257f6a942ffca9b ]

The current check for WoL on i40e is broken. Code comment says only
magic packet is supported, so only check for that.

Fixes: 540a152da762 (i40e/ixgbe/igb: fail on new WoL flag setting WAKE_MAGICSECURE)

Signed-off-by: Stefan Assmann &lt;sassmann@kpanic.de&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Sasha Levin (Microsoft) &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ixgbe: fix mdio bus registration</title>
<updated>2019-05-08T05:22:49+00:00</updated>
<author>
<name>Ivan Vecera</name>
<email>ivecera@redhat.com</email>
</author>
<published>2019-03-15T08:45:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ee5088ba4b2366cd78cd8155be0452f1f71be465'/>
<id>ee5088ba4b2366cd78cd8155be0452f1f71be465</id>
<content type='text'>
[ Upstream commit 7ec52b9df7d7472240fa96223185894b1897aeb0 ]

The ixgbe ignores errors returned from mdiobus_register() and leaves
adapter-&gt;mii_bus non-NULL and MDIO bus state as MDIOBUS_ALLOCATED.
This triggers a BUG from mdiobus_unregister() during ixgbe_remove() call.

Fixes: 8fa10ef01260 ("ixgbe: register a mdiobus")
Signed-off-by: Ivan Vecera &lt;ivecera@redhat.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 (Microsoft) &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 7ec52b9df7d7472240fa96223185894b1897aeb0 ]

The ixgbe ignores errors returned from mdiobus_register() and leaves
adapter-&gt;mii_bus non-NULL and MDIO bus state as MDIOBUS_ALLOCATED.
This triggers a BUG from mdiobus_unregister() during ixgbe_remove() call.

Fixes: 8fa10ef01260 ("ixgbe: register a mdiobus")
Signed-off-by: Ivan Vecera &lt;ivecera@redhat.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 (Microsoft) &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>igb: Fix WARN_ONCE on runtime suspend</title>
<updated>2019-05-08T05:22:49+00:00</updated>
<author>
<name>Arvind Sankar</name>
<email>niveditas98@gmail.com</email>
</author>
<published>2019-03-02T16:01:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=29cdcf7c4d5942b65611e74ae3366de847d52c9e'/>
<id>29cdcf7c4d5942b65611e74ae3366de847d52c9e</id>
<content type='text'>
[ Upstream commit dabb8338be533c18f50255cf39ff4f66d4dabdbe ]

The runtime_suspend device callbacks are not supposed to save
configuration state or change the power state. Commit fb29f76cc566
("igb: Fix an issue that PME is not enabled during runtime suspend")
changed the driver to not save configuration state during runtime
suspend, however the driver callback still put the device into a
low-power state. This causes a warning in the pci pm core and results in
pci_pm_runtime_suspend not calling pci_save_state or pci_finish_runtime_suspend.

Fix this by not changing the power state either, leaving that to pci pm
core, and make the same change for suspend callback as well.

Also move a couple of defines into the appropriate header file instead
of inline in the .c file.

Fixes: fb29f76cc566 ("igb: Fix an issue that PME is not enabled during runtime suspend")
Signed-off-by: Arvind Sankar &lt;niveditas98@gmail.com&gt;
Reviewed-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.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 (Microsoft) &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit dabb8338be533c18f50255cf39ff4f66d4dabdbe ]

The runtime_suspend device callbacks are not supposed to save
configuration state or change the power state. Commit fb29f76cc566
("igb: Fix an issue that PME is not enabled during runtime suspend")
changed the driver to not save configuration state during runtime
suspend, however the driver callback still put the device into a
low-power state. This causes a warning in the pci pm core and results in
pci_pm_runtime_suspend not calling pci_save_state or pci_finish_runtime_suspend.

Fix this by not changing the power state either, leaving that to pci pm
core, and make the same change for suspend callback as well.

Also move a couple of defines into the appropriate header file instead
of inline in the .c file.

Fixes: fb29f76cc566 ("igb: Fix an issue that PME is not enabled during runtime suspend")
Signed-off-by: Arvind Sankar &lt;niveditas98@gmail.com&gt;
Reviewed-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.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 (Microsoft) &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
