Harald Freudenberger 837cd1059a s390/ap: ap bus userspace notifications for some bus conditions
This patch adds notifications to userspace for two important
conditions of the ap bus:

I) Initial ap bus scan done. This indicates that the initial
   scan of all the ap devices (cards, queues) is complete and
   ap devices have been build up for all the hardware found.
   This condition is signaled with
   1) An ap bus change uevent send to userspace with an environment
      key/value pair "INITSCAN=done":
	# udevadm monitor -k -p
	...
	KERNEL[97.830919] change   /devices/ap (ap)
	ACTION=change
	DEVPATH=/devices/ap
	SUBSYSTEM=ap
	INITSCAN=done
	SEQNUM=10421
   2) A sysfs attribute /sys/bus/ap/scans which shows the
      number of completed ap bus scans done since bus init.
      So a value of 1 or greater signals that the initial
      ap bus scan is complete.
   Note: The initial ap bus scan complete condition is fulfilled
   and will be signaled even if there was no ap resource found.

II) APQN driver bindings complete. This indicates that all
    APQNs have been bound to an zcrypt or alternate device
    driver. Only with the help of an device driver an APQN
    can be used for crypto load. So the binding complete
    condition is the starting point for user space to be
    sure all crypto resources on the ap bus are available
    for use.
    This condition is signaled with
    1) An ap bus change uevent send to userspace with an environment
       key/value pair "BINDINGS=complete":
	 # udevadm monitor -k -p
	 ...
	 KERNEL[97.830975] change   /devices/ap (ap)
	 ACTION=change
	 DEVPATH=/devices/ap
	 SUBSYSTEM=ap
	 BINDINGS=complete
	 SEQNUM=10422
    2) A sysfs attribute /sys/bus/ap/bindings showing
	 "<nr of bound apqns>/<total nr of apqns> (complete)"
       when all available apqns have been bound to device drivers, or
	 "<nr of bound apqns>/<total nr of apqns>"
       when there are some apqns not bound to an device driver.
    Note: The binding complete condition is also fulfilled, when
    there are no apqns available to bind any device driver. In
    this case the binding complete will be signaled AFTER init
    scan is done.
    Note: This condition may arise multiple times when after
    initial scan modifications on the bindings take place. For
    example a manual unbind of an APQN switches the binding
    complete condition off. When at a later time the unbound APQNs
    are bound with an device driver the binding is (again) complete
    resulting in another uevent and marking the bindings sysfs
    attribute with '(complete)'.

There is also a new function to be used within the kernel:

  int ap_wait_init_apqn_bindings_complete(unsigned long timeout)

Interface to wait for the AP bus to have done one initial ap bus
scan and all detected APQNs have been bound to device drivers.
If these both conditions are not fulfilled, this function blocks
on a condition with wait_for_completion_interruptible_timeout().
If these both conditions are fulfilled (before the timeout hits)
the return value is 0. If the timeout (in jiffies) hits instead
-ETIME is returned. On failures negative return values are
returned to the caller. Please note that further unbind/bind
actions after initial binding complete is through do not cause this
function to block again.

Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2020-11-09 11:21:00 +01:00
2020-10-13 13:04:41 -07:00
2020-11-08 10:23:07 -08:00
2020-11-08 10:23:07 -08:00
2020-10-18 14:45:59 -07:00
2020-10-28 19:12:03 +01:00
2020-11-05 18:19:32 +01:00
2020-11-06 15:42:42 -08:00
2020-10-17 11:18:18 -07:00
2020-11-08 16:10:16 -08:00

Linux kernel
============

There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.

In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``.  The formatted documentation can also be read online at:

    https://www.kernel.org/doc/html/latest/

There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.

Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.
Description
Linux kernel stable tree
Readme 6 GiB
Languages
C 97.5%
Assembly 1%
Shell 0.6%
Python 0.3%
Makefile 0.3%