qeth_add_hw_header() is missing documentation for some of its
parameters, fix that up.
Reported-by: NHeiko Carstens <hca@linux.ibm.com>
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix kernel doc comments and remove incorrect kernel doc indicators.
Acked-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Allow the compiler to recognize and check format strings and parameters.

As reported with allmodconfig and W=1:

drivers/s390/net/qeth_core_main.c: In function ‘qeth_dbf_longtext’:
drivers/s390/net/qeth_core_main.c:6190:9: error: function ‘qeth_dbf_longtext’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format]
 6190 |         vsnprintf(dbf_txt_buf, sizeof(dbf_txt_buf), fmt, args);
      |         ^~~~~~~~~
Acked-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Various format strings don't match with types of parameters.
Fix all of them.
Acked-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The only actual user of qdio.no_input_queues is qeth_qdio_establish(),
and there we already have full awareness of the current Input Queue
configuration (1 RX queue, plus potentially 1 TX Completion queue).

So avoid this state tracking, and the ambiguity it brings with it.
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For none of the users we are under risk of running in HW IRQ context or
or with IRQs disabled. Thus we always end up in consume_skb().

But the two occurences in the RX path should really report the dropped
packet to dropmon, so have them use kfree_skb() instead. That's also
consistent with what napi_free_frags() does internally.
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

qdio.ko no longer needs to care about how the QAOBs are allocated,
from its perspective they are merely another parameter to do_QDIO().

So for a start, shift the cache into the only qdio driver that uses
QAOBs (ie. qeth). Here there's further opportunity to optimize its
usage in the future - eg. make it per-{device, TX queue}, or only
compile it when the driver is built with CQ/QAOB support.
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Reviewed-by: NBenjamin Block <bblock@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

With commit 18787eee ("qeth: use ndo_siocdevprivate") this callback
is now actually used to handle transport mode-specific _private_ ioctls.

We only have such ioctls for L3 devices. So wire up a L3-specific
.ndo_siocdevprivate() callback that handles those ioctls, and defers to
the core qeth_siocdevprivate() for all other private ioctls.

This takes the discipline one step closer to its original purpose of
providing an internal extension for the qeth_core_ccwgroup_driver.
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add the failed MAC address into the trace message. Also fix up one
format string to use %x instead of %u for the CARD_DEVID.
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Reviewed-by: NAlexandra Winter <wintera@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 406f42fa ("net-next: When a bond have a massive amount
of VLANs...") introduced a rbtree for faster Ethernet address look
up. To maintain netdev->dev_addr in this tree we need to make all
the writes to it got through appropriate helpers.

Make sure local references to netdev->dev_addr are constant.
Acked-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Currently when removing a device from cio_ignore list, we trigger a
path-verification for all the subchannels available in the system. This
could lead to path-verification requests on subchannels with an online
device, which could cause unwanted delay. Instead of all the
subchannels, trigger the path-verifications to those without an online
device.
Reported-by: NJulian Wiedmann <jwi@linux.ibm.com>
Fixes: 2297791c ("s390/cio: dont unregister subchannel from child-drivers")
Signed-off-by: NVineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: NPeter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>

Without this call an xarray entry is leaked when the vfio_ap device is
unprobed. It was missed when the below patch was rebased across the
dev_set patch. Keep the remove function in the same order as the error
unwind in probe.

Fixes: eb0feefd ("vfio/ap_ops: Convert to use vfio_register_group_dev()")
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Tested-by: NTony Krowiak <akrowiak@linux.ibm.com>
Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NTony Krowiak <akrowiak@linux.ibm.com>
Link: https://lore.kernel.org/r/0-v3-f9b50340cdbb+e4-ap_uninit_jgg@nvidia.comSigned-off-by: NAlex Williamson <alex.williamson@redhat.com>

Commit 0b9902c1 ("s390/qeth: fix deadlock during recovery") removed
taking discipline_mutex inside qeth_do_reset(), fixing potential
deadlocks. An error path was missed though, that still takes
discipline_mutex and thus has the original deadlock potential.

Intermittent deadlocks were seen when a qeth channel path is configured
offline, causing a race between qeth_do_reset and ccwgroup_remove.
Call qeth_set_offline() directly in the qeth_do_reset() error case and
then a new variant of ccwgroup_set_offline(), without taking
discipline_mutex.

Fixes: b41b554c ("s390/qeth: fix locking for discipline setup / removal")
Signed-off-by: NAlexandra Winter <wintera@linux.ibm.com>
Reviewed-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Problem: qeth_close_dev_handler is a worker that tries to acquire
card->discipline_mutex via drv->set_offline() in ccwgroup_set_offline().
Since commit b41b554c
("s390/qeth: fix locking for discipline setup / removal")
qeth_remove_discipline() is called under card->discipline_mutex and
cancels the work and waits for it to finish.

STOPLAN reception with reason code IPA_RC_VEPA_TO_VEB_TRANSITION is the
only situation that schedules close_dev_work. In that situation scheduling
qeth recovery will also result in an offline interface, when resetting the
isolation mode fails, if the external switch is still set to VEB.
And since commit 0b9902c1 ("s390/qeth: fix deadlock during recovery")
qeth recovery does not aquire card->discipline_mutex anymore.

So we accept the longer pathlength of qeth_schedule_recovery in this
error situation and re-use the existing function.

As a side-benefit this changes the hwtrap to behave like during recovery
instead of like during a user-triggered set_offline.

Fixes: b41b554c ("s390/qeth: fix locking for discipline setup / removal")
Signed-off-by: NAlexandra Winter <wintera@linux.ibm.com>
Acked-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

When qeth_set_online() calls qeth_clear_working_pool_list() to roll
back after an error exit from qeth_hardsetup_card(), we are at risk of
accessing card->qdio.in_q before it was allocated by
qeth_alloc_qdio_queues() via qeth_mpc_initialize().

qeth_clear_working_pool_list() then dereferences NULL, and by writing to
queue->bufs[i].pool_entry scribbles all over the CPU's lowcore.
Resulting in a crash when those lowcore areas are used next (eg. on
the next machine-check interrupt).

Such a scenario would typically happen when the device is first set
online and its queues aren't allocated yet. An early IO error or certain
misconfigs (eg. mismatched transport mode, bad portno) then cause us to
error out from qeth_hardsetup_card() with card->qdio.in_q still being
NULL.

Fix it by checking the pointer for NULL before accessing it.

Note that we also have (rare) paths inside qeth_mpc_initialize() where
a configuration change can cause us to free the existing queues,
expecting that subsequent code will allocate them again. If we then
error out before that re-allocation happens, the same bug occurs.

Fixes: eff73e16 ("s390/qeth: tolerate pre-filled RX buffer")
Reported-by: NStefan Raspl <raspl@linux.ibm.com>
Root-caused-by: NHeiko Carstens <hca@linux.ibm.com>
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Reviewed-by: NAlexandra Winter <wintera@linux.ibm.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Get rid of warnings like:

drivers/s390/crypto/ap_bus.c:216: warning:
 bad line:
drivers/s390/crypto/ap_bus.c:444:
 warning: Function parameter or member 'floating' not described in 'ap_interrupt_handler'
Reviewed-by: NHarald Freudenberger <freude@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>

Prevent out-of-range access if the returned SCLP SCCB response is smaller
in size than the address of the Secure-IPL flag.

Fixes: c9896acc ("s390/ipl: Provide has_secure sysfs attribute")
Cc: stable@vger.kernel.org # 5.2+
Signed-off-by: NAlexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>

The wrappers in include/linux/pci-dma-compat.h should go away.

The patch has been generated with the coccinelle script below.

@@
expression e1, e2;
@@
-    pci_set_dma_mask(e1, e2)
+    dma_set_mask(&e1->dev, e2)
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: NKarsten Graul <kgraul@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Many comments above functions start with a kernel doc indicator, but
the comments are not using kernel doc style. Get rid of the warnings
by simply removing the indicator.

E.g.:

drivers/s390/net/netiucv.c:1852: warning:
 This comment starts with '/**', but isn't a kernel-doc comment.
Reviewed-by: NAlexandra Winter <wintera@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>
Signed-off-by: NKarsten Graul <kgraul@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Many comments above functions start with a kernel doc indicator, but
the comments are not using kernel doc style. Get rid of the warnings
by simply removing the indicator.

E.g.:

drivers/s390/net/lcs.c:2355: warning:
 This comment starts with '/**', but isn't a kernel-doc comment.
Acked-by: NAlexandra Winter <wintera@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>
Signed-off-by: NKarsten Graul <kgraul@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Many comments above functions start with a kernel doc indicator, but
the comments are not using kernel doc style. Get rid of the warnings
by simply removing the indicator.

E.g.:

drivers/s390/net/ctcm_main.c:979: warning:
 This comment starts with '/**', but isn't a kernel-doc comment.
Acked-by: NAlexandra Winter <wintera@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>
Signed-off-by: NKarsten Graul <kgraul@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Many comments above functions start with a kernel doc indicator, but
the comments are not using kernel doc style. Get rid of the warnings
by simply removing the indicator.

E.g.:

drivers/s390/crypto/zcrypt_msgtype6.c:111: warning:
 This comment starts with '/**', but isn't a kernel-doc comment.
Reviewed-by: NHarald Freudenberger <freude@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>

A couple of function names don't match what the kernel doc comments
indicate.
Acked-by: NBenjamin Block <bblock@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>

Add __nonstring annotation, since the missing string termination for
id member of sclp_trace_entry is intended. This way we get rid of this
warning:

drivers/s390/char/sclp.c:84:9: warning: ‘strncpy’ output truncated before terminating nul copying 4 bytes from a string of the same length [-Wstringop-truncation]
   84 |         strncpy(e.id, id, sizeof(e.id));
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reported-by: Nkernel test robot <lkp@intel.com>
Reviewed-by: NPeter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>

Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>

Support for expanded storage was only available until z13 and z/VM 6.3
respectively. However there haven't been any use cases a long time
before for this device driver.
Therefore remove it.
Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>

Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>

Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>

Get rid of this warning:

drivers/s390/char/con3270.c:629:22: warning: cast between incompatible function types from ‘void (*)(struct raw3270_request *)’ to ‘void (*)(long unsigned int)’ [-Wcast-function-type]
  629 |                      (void (*)(unsigned long)) con3270_read_tasklet,
      |                      ^
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>

The devices owned by the parent-driver (css) was getting unregistered
from the io-subchannel driver is clearly a layering violation.
Remove the subchannel unregistration from the child-drivers.

This also means, if the device connected to the subchannel is not
operational, or not accessible, the subchannel will not be unregistered.
Instead the CIO layer will allow valid subchannels without any operational
devices in sysfs. And the userspace tooling might need to be modified to
optimally handle this new situation.
Signed-off-by: NVineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: NPeter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>

If for any reason the interrupt enable for an ap queue fails the
state machine run for the queue returned wrong return codes to the
caller. So the caller assumed interrupt support for this queue in
enabled and thus did not re-establish the high resolution timer used
for polling. In the end this let to a hang for the user space process
waiting "forever" for the reply.

This patch reworks these return codes to return correct indications
for the caller to re-establish the timer when a queue runs without
interrupt support.

Please note that this is fixing a wrong behavior after a first
failure (enable interrupt support for the queue) failed. However,
looks like this occasionally happens on KVM systems.
Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>

This is straightforward conversion, the ap_matrix_mdev is actually serving
as the vfio_device and we can replace all the mdev_get_drvdata()'s with a
simple container_of() or a dev_get_drvdata() for sysfs paths.

Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Cornelia Huck <cohuck@redhat.com>
Cc: kvm@vger.kernel.org
Cc: Christoph Hellwig <hch@lst.de>
Reviewed-by: NTony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/0-v4-0203a4ab0596+f7-vfio_ap_jgg@nvidia.comSigned-off-by: NAlex Williamson <alex.williamson@redhat.com>

Add tracing of interactions between the SCLP base driver, firmware and
other drivers to support problem determination in case of SCLP-related
issues.

For that purpose this patch introduces two new s390dbf debug areas:

  - sclp: An abbreviated log of all common interactions
  - sclp_err: A full log of failed or abnormal interactions

Tracing of full SCCB contents can be enabled for the sclp area by
setting its debug level to maximum (6).

Overview of added trace events:

  * Firmware interaction:
    - SRV1: Service call about to be issued
    - SRV2: Service call was issued
    - INT:  Interrupt received

  * Driver interaction:
    - RQAD: Request was added
    - RQOK: Request success
    - RQAB: Request aborted
    - RQTM: Request timed out
    - REG:  Event listener registered
    - UREG: Event listener unregistered
    - EVNT: Event callback
    - STCG: State-change callback

  * Abnormal events:
    - TMO:  A timeout occurred
    - UNEX: Unexpected SCCB completion

  * Other (not traced at default level):
    - SYN1: Synchronous wait start
    - SYN2: Synchronous wait end

Since the SCLP interface is used by console drivers this patch also
moves s390dbf printks outside the critical section protected by debug
area locks to prevent a potential deadlock that would otherwise be
introduced between console_owner --> sclp_lock --> sclp_debug.lock.
Signed-off-by: NPeter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>

The 0day bot reported some kernel-doc warnings in this file so clean up
all of the kernel-doc and use proper kernel-doc formatting.
There are no more kernel-doc errors or warnings reported in this file.
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Reported-by: Nkernel test robot <lkp@intel.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>
Cc: Tony Krowiak <akrowiak@linux.ibm.com>
Cc: Halil Pasic <pasic@linux.ibm.com>
Cc: Jason Herne <jjherne@linux.ibm.com>
Cc: Harald Freudenberger <freude@linux.ibm.com>
Cc: linux-s390@vger.kernel.org
Reviewed-by: NTony Krowiak <akrowiak@linux.ibm.com>
Link: https://lore.kernel.org/r/20210806050149.9614-1-rdunlap@infradead.orgSigned-off-by: NHeiko Carstens <hca@linux.ibm.com>

As .remove() is only called after a successful .probe() call, we can
trust that the drvdata is valid.
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>

The device struct provides a pointer for driver-private data. Use this
in the zcrypt drivers (as vfio_ap already does), and then remove the
custom pointer from the AP device structs.

As really_probe() will always clear the drvdata pointer on error, we
no longer have to do so ourselves.
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>

The device struct itself already contains a pointer to its driver.
Use this consistently, instead of duplicating it.
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>

It was pointed out during an unrelated patch review that locks should not
be open coded - i.e., writing the algorithm of a standard lock in a
function instead of using a lock from the standard library. The setting and
testing of a busy flag and sleeping on a wait_event is the same thing
a lock does. The open coded locks are invisible to lockdep, so potential
locking problems are not detected.

This patch removes the open coded locks used during
VFIO_GROUP_NOTIFY_SET_KVM notification. The busy flag
and wait queue were introduced to resolve a possible circular locking
dependency reported by lockdep when starting a secure execution guest
configured with AP adapters and domains. Reversing the order in which
the kvm->lock mutex and matrix_dev->lock mutex are locked resolves the
issue reported by lockdep, thus enabling the removal of the open coded
locks.
Signed-off-by: NTony Krowiak <akrowiak@linux.ibm.com>
Acked-by: NHalil Pasic <pasic@linux.ibm.com>
Link: https://lore.kernel.org/r/20210823212047.1476436-3-akrowiak@linux.ibm.comSigned-off-by: NAlex Williamson <alex.williamson@redhat.com>

The function pointer to the interception handler for the PQAP instruction
can get changed during the interception process. Let's add a
semaphore to struct kvm_s390_crypto to control read/write access to the
function pointer contained therein.

The semaphore must be locked for write access by the vfio_ap device driver
when notified that the KVM pointer has been set or cleared. It must be
locked for read access by the interception framework when the PQAP
instruction is intercepted.
Signed-off-by: NTony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Link: https://lore.kernel.org/r/20210823212047.1476436-2-akrowiak@linux.ibm.comSigned-off-by: NAlex Williamson <alex.williamson@redhat.com>

In order to support more coalesce parameters through netlink,
add two new parameter kernel_coal and extack for .set_coalesce
and .get_coalesce, then some extra info can return to user with
the netlink API.
Signed-off-by: NYufeng Mo <moyufeng@huawei.com>
Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>