<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/drivers/s390/net, branch linux-5.5.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-5.5.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-5.5.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2020-03-18T06:19:06+00:00</updated>
<entry>
<title>s390/qeth: handle error when backing RX buffer</title>
<updated>2020-03-18T06:19:06+00:00</updated>
<author>
<name>Julian Wiedmann</name>
<email>jwi@linux.ibm.com</email>
</author>
<published>2020-03-10T17:38:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f4bd31aeeaf53c4fdf5ef04384b946d4694dcb3d'/>
<id>urn:sha1:f4bd31aeeaf53c4fdf5ef04384b946d4694dcb3d</id>
<content type='text'>
[ Upstream commit 17413852804d7e86e6f0576cca32c1541817800e ]

qeth_init_qdio_queues() fills the RX ring with an initial set of
RX buffers. If qeth_init_input_buffer() fails to back one of the RX
buffers with memory, we need to bail out and report the error.

Fixes: 4a71df50047f ("qeth: new qeth device driver")
Signed-off-by: Julian Wiedmann &lt;jwi@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>s390/qeth: don't reset default_out_queue</title>
<updated>2020-03-18T06:19:05+00:00</updated>
<author>
<name>Julian Wiedmann</name>
<email>jwi@linux.ibm.com</email>
</author>
<published>2020-03-10T17:38:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4c02e8c24c5048c74cee0dfdc83b4ac1a6ff712d'/>
<id>urn:sha1:4c02e8c24c5048c74cee0dfdc83b4ac1a6ff712d</id>
<content type='text'>
[ Upstream commit 240c1948491b81cfe40f84ea040a8f2a4966f101 ]

When an OSA device in prio-queue setup is reduced to 1 TX queue due to
HW restrictions, we reset its the default_out_queue to 0.

In the old code this was needed so that qeth_get_priority_queue() gets
the queue selection right. But with proper multiqueue support we already
reduced dev-&gt;real_num_tx_queues to 1, and so the stack puts all traffic
on txq 0 without even calling .ndo_select_queue.

Thus we can preserve the user's configuration, and apply it if the OSA
device later re-gains support for multiple TX queues.

Fixes: 73dc2daf110f ("s390/qeth: add TX multiqueue support for OSA devices")
Signed-off-by: Julian Wiedmann &lt;jwi@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>s390/qdio: fill SL with absolute addresses</title>
<updated>2020-03-12T06:18:27+00:00</updated>
<author>
<name>Julian Wiedmann</name>
<email>jwi@linux.ibm.com</email>
</author>
<published>2020-02-10T09:48:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=23941733dc41a71c6c8cca7bdcca06c9b3b63812'/>
<id>urn:sha1:23941733dc41a71c6c8cca7bdcca06c9b3b63812</id>
<content type='text'>
[ Upstream commit e9091ffd6a0aaced111b5d6ead5eaab5cd7101bc ]

As the comment says, sl-&gt;sbal holds an absolute address. qeth currently
solves this through wild casting, while zfcp doesn't care.

Handle this properly in the code that actually builds the SL.

Signed-off-by: Julian Wiedmann &lt;jwi@linux.ibm.com&gt;
Reviewed-by: Alexandra Winter &lt;wintera@linux.ibm.com&gt;
Reviewed-by: Steffen Maier &lt;maier@linux.ibm.com&gt; [for qdio]
Reviewed-by: Benjamin Block &lt;bblock@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/qeth: fix off-by-one in RX copybreak check</title>
<updated>2020-03-05T15:45:19+00:00</updated>
<author>
<name>Julian Wiedmann</name>
<email>jwi@linux.ibm.com</email>
</author>
<published>2020-02-20T14:54:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=227fb1306d0638a7bf1e9a97f033b07cc52def57'/>
<id>urn:sha1:227fb1306d0638a7bf1e9a97f033b07cc52def57</id>
<content type='text'>
commit 54a61fbc020fd2e305680871c453abcf7fc0339b upstream.

The RX copybreak is intended as the _max_ value where the frame's data
should be copied. So for frame_len == copybreak, don't build an SG skb.

Fixes: 4a71df50047f ("qeth: new qeth device driver")
Signed-off-by: Julian Wiedmann &lt;jwi@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>s390/qeth: vnicc Fix EOPNOTSUPP precedence</title>
<updated>2020-03-05T15:45:19+00:00</updated>
<author>
<name>Alexandra Winter</name>
<email>wintera@linux.ibm.com</email>
</author>
<published>2020-02-20T14:54:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e912bd31c1dfcb13addf29ba44ebc13dba70dc18'/>
<id>urn:sha1:e912bd31c1dfcb13addf29ba44ebc13dba70dc18</id>
<content type='text'>
commit 6f3846f0955308b6d1b219419da42b8de2c08845 upstream.

When getting or setting VNICC parameters, the error code EOPNOTSUPP
should have precedence over EBUSY.

EBUSY is used because vnicc feature and bridgeport feature are mutually
exclusive, which is a temporary condition.
Whereas EOPNOTSUPP indicates that the HW does not support all or parts of
the vnicc feature.
This issue causes the vnicc sysfs params to show 'blocked by bridgeport'
for HW that does not support VNICC at all.

Fixes: caa1f0b10d18 ("s390/qeth: add VNICC enable/disable support")
Signed-off-by: Alexandra Winter &lt;wintera@linux.ibm.com&gt;
Signed-off-by: Julian Wiedmann &lt;jwi@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>s390/qeth: fix initialization on old HW</title>
<updated>2019-12-25T06:41:06+00:00</updated>
<author>
<name>Julian Wiedmann</name>
<email>jwi@linux.ibm.com</email>
</author>
<published>2019-12-23T14:03:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0b698c838e84149b690c7e979f78cccb6f8aa4b9'/>
<id>urn:sha1:0b698c838e84149b690c7e979f78cccb6f8aa4b9</id>
<content type='text'>
I stumbled over an old OSA model that claims to support DIAG_ASSIST,
but then rejects the cmd to query its DIAG capabilities.

In the old code this was ok, as the returned raw error code was &gt; 0.
Now that we translate the raw codes to errnos, the "rc &lt; 0" causes us
to fail the initialization of the device.

The fix is trivial: don't bail out when the DIAG query fails. Such an
error is not critical, we can still use the device (with a slightly
reduced set of features).

Fixes: 742d4d40831d ("s390/qeth: convert remaining legacy cmd callbacks")
Signed-off-by: Julian Wiedmann &lt;jwi@linux.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>s390/qeth: vnicc Fix init to default</title>
<updated>2019-12-25T06:41:06+00:00</updated>
<author>
<name>Alexandra Winter</name>
<email>wintera@linux.ibm.com</email>
</author>
<published>2019-12-23T14:03:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d1b9ae1864fc3c000e0eb4af8482d78c63e0915a'/>
<id>urn:sha1:d1b9ae1864fc3c000e0eb4af8482d78c63e0915a</id>
<content type='text'>
During vnicc_init wanted_char should be compared to cur_char and not
to QETH_VNICC_DEFAULT. Without this patch there is no way to enforce
the default values as desired values.

Note, that it is expected, that a card comes online with default values.
This patch was tested with private card firmware.

Fixes: caa1f0b10d18 ("s390/qeth: add VNICC enable/disable support")
Signed-off-by: Alexandra Winter &lt;wintera@linux.ibm.com&gt;
Signed-off-by: Julian Wiedmann &lt;jwi@linux.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>s390/qeth: Fix vnicc_is_in_use if rx_bcast not set</title>
<updated>2019-12-25T06:41:06+00:00</updated>
<author>
<name>Alexandra Winter</name>
<email>wintera@linux.ibm.com</email>
</author>
<published>2019-12-23T14:03:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e8a66d800471e2df7f0b484e2e46898b21d1fa82'/>
<id>urn:sha1:e8a66d800471e2df7f0b484e2e46898b21d1fa82</id>
<content type='text'>
Symptom: After vnicc/rx_bcast has been manually set to 0,
	bridge_* sysfs parameters can still be set or written.
Only occurs on HiperSockets, as OSA doesn't support changing rx_bcast.

Vnic characteristics and bridgeport settings are mutually exclusive.
rx_bcast defaults to 1, so manually setting it to 0 should disable
bridge_* parameters.

Instead it makes sense here to check the supported mask. If the card
does not support vnicc at all, bridge commands are always allowed.

Fixes: caa1f0b10d18 ("s390/qeth: add VNICC enable/disable support")
Signed-off-by: Alexandra Winter &lt;wintera@linux.ibm.com&gt;
Signed-off-by: Julian Wiedmann &lt;jwi@linux.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>s390/qeth: fix false reporting of VNIC CHAR config failure</title>
<updated>2019-12-25T06:41:06+00:00</updated>
<author>
<name>Alexandra Winter</name>
<email>wintera@linux.ibm.com</email>
</author>
<published>2019-12-23T14:03:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=68c57bfd52836e31bff33e5e1fc64029749d2c35'/>
<id>urn:sha1:68c57bfd52836e31bff33e5e1fc64029749d2c35</id>
<content type='text'>
Symptom: Error message "Configuring the VNIC characteristics failed"
in dmesg whenever an OSA interface on z15 is set online.

The VNIC characteristics get re-programmed when setting a L2 device
online. This follows the selected 'wanted' characteristics - with the
exception that the INVISIBLE characteristic unconditionally gets
switched off.

For devices that don't support INVISIBLE (ie. OSA), the resulting
IO failure raises a noisy error message
("Configuring the VNIC characteristics failed").
For IQD, INVISIBLE is off by default anyways.

So don't unnecessarily special-case the INVISIBLE characteristic, and
thereby suppress the misleading error message on OSA devices.

Fixes: caa1f0b10d18 ("s390/qeth: add VNICC enable/disable support")
Signed-off-by: Alexandra Winter &lt;wintera@linux.ibm.com&gt;
Reviewed-by: Julian Wiedmann &lt;jwi@linux.ibm.com&gt;
Signed-off-by: Julian Wiedmann &lt;jwi@linux.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>s390/qeth: lock the card while changing its hsuid</title>
<updated>2019-12-25T06:41:06+00:00</updated>
<author>
<name>Julian Wiedmann</name>
<email>jwi@linux.ibm.com</email>
</author>
<published>2019-12-23T14:03:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5b6c7b55cfe26224b0f41b1c226d3534c542787f'/>
<id>urn:sha1:5b6c7b55cfe26224b0f41b1c226d3534c542787f</id>
<content type='text'>
qeth_l3_dev_hsuid_store() initially checks the card state, but doesn't
take the conf_mutex to ensure that the card stays in this state while
being reconfigured.

Rework the code to take this lock, and drop a redundant state check in a
helper function.

Fixes: b333293058aa ("qeth: add support for af_iucv HiperSockets transport")
Signed-off-by: Julian Wiedmann &lt;jwi@linux.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
