1. 09 Oct, 2018 37 commits
  2. 08 Oct, 2018 2 commits
    • Julian Wiedmann's avatar
      s390/ccwgroup: add get_ccwgroupdev_by_busid() · 346e485d
      Julian Wiedmann authored
      Provide function to find a ccwgroup device by its busid.
      Acked-by: default avatarSebastian Ott <sebott@linux.ibm.com>
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      346e485d
    • Harald Freudenberger's avatar
      s390/zcrypt: multiple zcrypt device nodes support · 00fab235
      Harald Freudenberger authored
      This patch is an extension to the zcrypt device driver to provide,
      support and maintain multiple zcrypt device nodes. The individual
      zcrypt device nodes can be restricted in terms of crypto cards,
      domains and available ioctls. Such a device node can be used as a
      base for container solutions like docker to control and restrict
      the access to crypto resources.
      
      The handling is done with a new sysfs subdir /sys/class/zcrypt.
      Echoing a name (or an empty sting) into the attribute "create" creates
      a new zcrypt device node. In /sys/class/zcrypt a new link will appear
      which points to the sysfs device tree of this new device. The
      attribute files "ioctlmask", "apmask" and "aqmask" in this directory
      are used to customize this new zcrypt device node instance. Finally
      the zcrypt device node can be destroyed by echoing the name into
      /sys/class/zcrypt/destroy. The internal structs holding the device
      info are reference counted - so a destroy will not hard remove a
      device but only marks it as removable when the reference counter drops
      to zero.
      
      The mask values are bitmaps in big endian order starting with bit 0.
      So adapter number 0 is the leftmost bit, mask is 0x8000...  The sysfs
      attributes accept 2 different formats:
      * Absolute hex string starting with 0x like "0x12345678" does set
        the mask starting from left to right. If the given string is shorter
        than the mask it is padded with 0s on the right. If the string is
        longer than the mask an error comes back (EINVAL).
      * Relative format - a concatenation (done with ',') of the
        terms +<bitnr>[-<bitnr>] or -<bitnr>[-<bitnr>]. <bitnr> may be any
        valid number (hex, decimal or octal) in the range 0...255. Here are
        some examples:
          "+0-15,+32,-128,-0xFF"
          "-0-255,+1-16,+0x128"
          "+1,+2,+3,+4,-5,-7-10"
      
      A simple usage examples:
      
        # create new zcrypt device 'my_zcrypt':
        echo "my_zcrypt" >/sys/class/zcrypt/create
        # go into the device dir of this new device
        echo "my_zcrypt" >create
        cd my_zcrypt/
        ls -l
        total 0
        -rw-r--r-- 1 root root 4096 Jul 20 15:23 apmask
        -rw-r--r-- 1 root root 4096 Jul 20 15:23 aqmask
        -r--r--r-- 1 root root 4096 Jul 20 15:23 dev
        -rw-r--r-- 1 root root 4096 Jul 20 15:23 ioctlmask
        lrwxrwxrwx 1 root root    0 Jul 20 15:23 subsystem -> ../../../../class/zcrypt
        ...
        # customize this zcrypt node clone
        # enable only adapter 0 and 2
        echo "0xa0" >apmask
        # enable only domain 6
        echo "+6" >aqmask
        # enable all 256 ioctls
        echo "+0-255" >ioctls
        # now the /dev/my_zcrypt may be used
        # finally destroy it
        echo "my_zcrypt" >/sys/class/zcrypt/destroy
      
      Please note that a very similar 'filtering behavior' also applies to
      the parent z90crypt device. The two mask attributes apmask and aqmask
      in /sys/bus/ap act the very same for the z90crypt device node. However
      the implementation here is totally different as the ap bus acts on
      bind/unbind of queue devices and associated drivers but the effect is
      still the same. So there are two filters active for each additional
      zcrypt device node: The adapter/domain needs to be enabled on the ap
      bus level and it needs to be active on the zcrypt device node level.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      00fab235
  3. 20 Sep, 2018 1 commit
    • Julian Wiedmann's avatar
      s390/qdio: clean up AOB handling · ccc413f6
      Julian Wiedmann authored
      I've stumbled over this too many times now... AOBs are only ever used on
      Output Queues. So in qdio_kick_handler(), move the call to their handler
      into the Output-only path, and get rid of the convoluted contains_aobs()
      helper. No functional change.
      
      While at it, also remove
      1. the unused sbal_state->aob field. For processing an async completion,
         upper-layer drivers get their AOB pointer from the CQ buffer.
      2. an unused EXPORT for qdio_allocate_aob(). External users would have
         no way of passing an allocated AOB back into qdio.ko anyways...
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      ccc413f6