s390/ap: introduce low frequency polling possibility
authorHarald Freudenberger <freude@linux.ibm.com>
Fri, 21 Oct 2022 13:41:00 +0000 (15:41 +0200)
committerHeiko Carstens <hca@linux.ibm.com>
Mon, 20 Mar 2023 10:12:49 +0000 (11:12 +0100)
commit263c8454dbffd4b878ea9bb403e157a56de98aca
treef19d486526f2c6a69986424b956aa5570c660857
parentc81cf436e47c34d2ff29e1b3db296f00d55b1c6f
s390/ap: introduce low frequency polling possibility

For some events the ap bus needs to poll. For example
when an AP queue is reset until the reset is through.
Also when no interrupt support is available (e.g. zVM)
there is a need to poll until all requests have been
processed and all replies have been delivered.

Polling is done with a high resolution timer by default
run with a rate of 4kHz (LPAR) or 666Hz (zVM guest).

For some events (wait for reset complete, wait for irq
enabled complete) this is a much too high poll rate
which triggers a lot of TAPQ invocations.

This patch introduces the possibility for the state
machine functions to return a new wait enum
AP_SM_WAIT_LOW_TIMEOUT which gives a hint to the
ap_wait() function to eventually set up the timer
with a more relaxed timeout value of 25Hz.

This patch also includes a slight rework of the sysfs
functions parsing the timer related stuff: Use of
kstrtobool and kstrtoul instead of sscanf.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
drivers/s390/crypto/ap_bus.c
drivers/s390/crypto/ap_bus.h
drivers/s390/crypto/ap_queue.c