kernel/linux.git/drivers/s390/net, branch v4.19.112

s390/qdio: fill SL with absolute addresses

2020-03-11T13:14:54+00:00

[ Upstream commit e9091ffd6a0aaced111b5d6ead5eaab5cd7101bc ] As the comment says, sl->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 Reviewed-by: Alexandra Winter Reviewed-by: Steffen Maier [for qdio] Reviewed-by: Benjamin Block Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin

s390/qeth: vnicc Fix EOPNOTSUPP precedence

2020-03-05T15:42:20+00:00

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 Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

s390/qeth: Fix initialization of vnicc cmd masks during set online

2020-01-27T13:51:18+00:00

[ Upstream commit be40a86c319706f90caca144343c64743c32b953 ] Without this patch, a command bit in the supported commands mask is only ever set to unsupported during set online. If a command is ever marked as unsupported (e.g. because of error during qeth_l2_vnicc_query_cmds), subsequent successful initialization (offline/online) would not bring it back. Fixes: caa1f0b10d18 ("s390/qeth: add VNICC enable/disable support") Signed-off-by: Alexandra Winter Signed-off-by: Julian Wiedmann Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

s390/qeth: Fix error handling during VNICC initialization

2020-01-27T13:51:17+00:00

[ Upstream commit b528965bcc827dad32a8d21745feaacfc76c9703 ] Smatch discovered the use of uninitialized variable sup_cmds in error paths. Fixes: caa1f0b10d18 ("s390/qeth: add VNICC enable/disable support") Signed-off-by: Alexandra Winter Signed-off-by: Julian Wiedmann Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

s390/qeth: Fix vnicc_is_in_use if rx_bcast not set

2020-01-17T18:47:01+00:00

commit e8a66d800471e2df7f0b484e2e46898b21d1fa82 upstream. 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 Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

s390/qeth: fix false reporting of VNIC CHAR config failure

2020-01-17T18:47:01+00:00

commit 68c57bfd52836e31bff33e5e1fc64029749d2c35 upstream. 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 Reviewed-by: Julian Wiedmann Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

s390/qeth: invoke softirqs after napi_schedule()

2019-11-20T17:46:51+00:00

[ Upstream commit 4d19db777a2f32c9b76f6fd517ed8960576cb43e ] Calling napi_schedule() from process context does not ensure that the NET_RX softirq is run in a timely fashion. So trigger it manually. This is no big issue with current code. A call to ndo_open() is usually followed by a ndo_set_rx_mode() call, and for qeth this contains a spin_unlock_bh(). Except for OSN, where qeth_l2_set_rx_mode() bails out early. Nevertheless it's best to not depend on this behaviour, and just fix the issue at its source like all other drivers do. For instance see commit 83a0c6e58901 ("i40e: Invoke softirqs after napi_reschedule"). Fixes: a1c3ed4c9ca0 ("qeth: NAPI support for l2 and l3 discipline") Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

s390/qeth: uninstall IRQ handler on device removal

2019-11-20T17:46:51+00:00

[ Upstream commit 121ca39aa5585def682a2c8592983442438b84dc ] When setting up, qeth installs its IRQ handler on the ccw devices. But the IRQ handler is not cleared on removal - so even after qeth yields control of the ccw devices, spurious interrupts would still be presented to us. Make (de-)installation of the IRQ handler part of the ccw channel setup/removal helpers, and while at it also add the appropriate locking. Shift around qeth_setup_channel() to avoid a forward declaration for qeth_irq(). Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

s390/qeth: fix VLAN attribute in bridge_hostnotify udev event

2019-06-25T03:35:59+00:00

[ Upstream commit 335726195e460cb6b3f795b695bfd31f0ea70ef0 ] Enabling sysfs attribute bridge_hostnotify triggers a series of udev events for the MAC addresses of all currently connected peers. In case no VLAN is set for a peer, the device reports the corresponding MAC addresses with VLAN ID 4096. This currently results in attribute VLAN=4096 for all non-VLAN interfaces in the initial series of events after host-notify is enabled. Instead, no VLAN attribute should be reported in the udev event for non-VLAN interfaces. Only the initial events face this issue. For dynamic changes that are reported later, the device uses a validity flag. This also changes the code so that it now sets the VLAN attribute for MAC addresses with VID 0. On Linux, no qeth interface will ever be registered with VID 0: Linux kernel registers VID 0 on all network interfaces initially, but qeth will drop .ndo_vlan_rx_add_vid for VID 0. Peers with other OSs could register MACs with VID 0. Fixes: 9f48b9db9a22 ("qeth: bridgeport support - address notifications") Signed-off-by: Alexandra Winter Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

s390/qeth: handle error from qeth_update_from_chp_desc()

2019-05-31T13:46:20+00:00

[ Upstream commit a4cdc9baee0740748f16e50cd70c2607510df492 ] Subsequent code relies on the values that qeth_update_from_chp_desc() reads from the CHP descriptor. Rather than dealing with weird errors later on, just handle it properly here. Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin