<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/net/ethernet/ibm, branch linux-5.7.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.7.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.7.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2020-08-05T07:58:45Z</updated>
<entry>
<title>ibmvnic: Fix IRQ mapping disposal in error path</title>
<updated>2020-08-05T07:58:45Z</updated>
<author>
<name>Thomas Falcon</name>
</author>
<published>2020-07-29T21:36:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=30007e098da0becf77c9974690c8af69faa4e247'/>
<id>urn:sha1:30007e098da0becf77c9974690c8af69faa4e247</id>
<content type='text'>
[ Upstream commit 27a2145d6f826d1fad9de06ac541b1016ced3427 ]

RX queue IRQ mappings are disposed in both the TX IRQ and RX IRQ
error paths. Fix this and dispose of TX IRQ mappings correctly in
case of an error.

Fixes: ea22d51a7831 ("ibmvnic: simplify and improve driver probe function")
Signed-off-by: Thomas Falcon &lt;tlfalcon@linux.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ibmvnic: continue to init in CRQ reset returns H_CLOSED</title>
<updated>2020-07-16T06:13:14Z</updated>
<author>
<name>Dany Madden</name>
</author>
<published>2020-06-18T19:24:13Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2a3b8a9cbaded0ed06c673f9efeaeb3146213dff'/>
<id>urn:sha1:2a3b8a9cbaded0ed06c673f9efeaeb3146213dff</id>
<content type='text'>
[ Upstream commit 8b40eb73509f5704a0e8cd25de0163876299f1a7 ]

Continue the reset path when partner adapter is not ready or H_CLOSED is
returned from reset crq. This patch allows the CRQ init to proceed to
establish a valid CRQ for traffic to flow after reset.

Signed-off-by: Dany Madden &lt;drt@linux.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ibmvnic: Harden device login requests</title>
<updated>2020-06-30T19:36:14Z</updated>
<author>
<name>Thomas Falcon</name>
</author>
<published>2020-06-15T15:29:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ff1a59dc9de754fa24a747b8cc08b72d304cb9ab'/>
<id>urn:sha1:ff1a59dc9de754fa24a747b8cc08b72d304cb9ab</id>
<content type='text'>
[ Upstream commit dff515a3e71dc8ab3b9dcc2e23a9b5fca88b3c18 ]

The VNIC driver's "login" command sequence is the final step
in the driver's initialization process with device firmware,
confirming the available device queue resources to be utilized
by the driver. Under high system load, firmware may not respond
to the request in a timely manner or may abort the request. In
such cases, the driver should reattempt the login command
sequence. In case of a device error, the number of retries
is bounded.

Signed-off-by: Thomas Falcon &lt;tlfalcon@linux.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ibmveth: Fix max MTU limit</title>
<updated>2020-06-30T19:35:45Z</updated>
<author>
<name>Thomas Falcon</name>
</author>
<published>2020-06-18T15:43:46Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=53511aab8b88adb4d0fc3bb4d905c98e7fe5601f'/>
<id>urn:sha1:53511aab8b88adb4d0fc3bb4d905c98e7fe5601f</id>
<content type='text'>
[ Upstream commit 5948378b26d89f8aa5eac37629dbd0616ce8d7a7 ]

The max MTU limit defined for ibmveth is not accounting for
virtual ethernet buffer overhead, which is twenty-two additional
bytes set aside for the ethernet header and eight additional bytes
of an opaque handle reserved for use by the hypervisor. Update the
max MTU to reflect this overhead.

Fixes: d894be57ca92 ("ethernet: use net core MTU range checking in more drivers")
Fixes: 110447f8269a ("ethernet: fix min/max MTU typos")
Signed-off-by: Thomas Falcon &lt;tlfalcon@linux.ibm.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>ibmvnic: Flush existing work items before device removal</title>
<updated>2020-06-24T15:48:32Z</updated>
<author>
<name>Thomas Falcon</name>
</author>
<published>2020-06-12T18:34:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7028ba6cfd0ae27bf172023f145115b1823ce540'/>
<id>urn:sha1:7028ba6cfd0ae27bf172023f145115b1823ce540</id>
<content type='text'>
[ Upstream commit 6954a9e4192b86d778fb52b525fd7b62d51b1147 ]

Ensure that all scheduled work items have completed before continuing
with device removal and after further event scheduling has been
halted. This patch fixes a bug where a scheduled driver reset event
is processed following device removal.

Signed-off-by: Thomas Falcon &lt;tlfalcon@linux.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drivers/net/ibmvnic: Update VNIC protocol version reporting</title>
<updated>2020-05-30T00:20:59Z</updated>
<author>
<name>Thomas Falcon</name>
</author>
<published>2020-05-28T16:19:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=784688993ebac34dffe44a9f2fabbe126ebfd4db'/>
<id>urn:sha1:784688993ebac34dffe44a9f2fabbe126ebfd4db</id>
<content type='text'>
VNIC protocol version is reported in big-endian format, but it
is not byteswapped before logging. Fix that, and remove version
comparison as only one protocol version exists at this time.

Signed-off-by: Thomas Falcon &lt;tlfalcon@linux.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ibmvnic: Skip fatal error reset after passive init</title>
<updated>2020-04-30T20:27:17Z</updated>
<author>
<name>Juliet Kim</name>
</author>
<published>2020-04-30T18:22:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f9c6cea0b38518741c8dcf26ac056d26ee2fd61d'/>
<id>urn:sha1:f9c6cea0b38518741c8dcf26ac056d26ee2fd61d</id>
<content type='text'>
During MTU change, the following events may happen.
Client-driven CRQ initialization fails due to partner’s CRQ closed,
causing client to enqueue a reset task for FATAL_ERROR. Then passive
(server-driven) CRQ initialization succeeds, causing client to
release CRQ and enqueue a reset task for failover. If the passive
CRQ initialization occurs before the FATAL reset task is processed,
the FATAL error reset task would try to access a CRQ message queue
that was freed, causing an oops. The problem may be most likely to
occur during DLPAR add vNIC with a non-default MTU, because the DLPAR
process will automatically issue a change MTU request.

Fix this by not processing fatal error reset if CRQ is passively
initialized after client-driven CRQ initialization fails.

Signed-off-by: Juliet Kim &lt;julietk@linux.vnet.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net</title>
<updated>2020-03-13T05:34:48Z</updated>
<author>
<name>David S. Miller</name>
</author>
<published>2020-03-13T04:29:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1d343579312311aa9875b34d5a921f5e2ec69f0a'/>
<id>urn:sha1:1d343579312311aa9875b34d5a921f5e2ec69f0a</id>
<content type='text'>
Minor overlapping changes, nothing serious.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: ibm: remove set but not used variables 'err'</title>
<updated>2020-03-12T06:32:55Z</updated>
<author>
<name>Chen Zhou</name>
</author>
<published>2020-03-11T06:54:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9b96a3e6dd4bf3b92df15798f088ee6b35928712'/>
<id>urn:sha1:9b96a3e6dd4bf3b92df15798f088ee6b35928712</id>
<content type='text'>
Fixes gcc '-Wunused-but-set-variable' warning:

drivers/net/ethernet/ibm/emac/core.c: In function __emac_mdio_write:
drivers/net/ethernet/ibm/emac/core.c:875:9: warning:
	variable err set but not used [-Wunused-but-set-variable]

Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Chen Zhou &lt;chenzhou10@huawei.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ibmvnic: Do not process device remove during device reset</title>
<updated>2020-03-10T22:50:42Z</updated>
<author>
<name>Juliet Kim</name>
</author>
<published>2020-03-10T14:23:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7d7195a026bac47ac9943f11f84b7546276209dd'/>
<id>urn:sha1:7d7195a026bac47ac9943f11f84b7546276209dd</id>
<content type='text'>
The ibmvnic driver does not check the device state when the device
is removed. If the device is removed while a device reset is being
processed, the remove may free structures needed by the reset,
causing an oops.

Fix this by checking the device state before processing device remove.

Signed-off-by: Juliet Kim &lt;julietk@linux.vnet.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
