From d635711daa98be86d4c7fd01499c34f566b54ccb Mon Sep 17 00:00:00 2001 From: André Fabian Silva Delgado Date: Fri, 10 Jun 2016 05:30:17 -0300 Subject: Linux-libre 4.6.2-gnu --- Documentation/DocBook/crypto-API.tmpl | 242 +++++++++------------ Documentation/DocBook/device-drivers.tmpl | 3 +- Documentation/DocBook/gpu.tmpl | 124 +++++++---- Documentation/DocBook/media/v4l/controls.xml | 58 +++++ .../DocBook/media/v4l/media-ioc-g-topology.xml | 3 - Documentation/DocBook/media/v4l/media-types.xml | 81 ++++++- Documentation/DocBook/media/v4l/pixfmt-y12i.xml | 49 +++++ Documentation/DocBook/media/v4l/pixfmt-y8i.xml | 80 +++++++ Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml | 26 ++- Documentation/DocBook/media/v4l/pixfmt-yuv422m.xml | 166 ++++++++++++++ Documentation/DocBook/media/v4l/pixfmt-yuv444m.xml | 177 +++++++++++++++ Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml | 154 ------------- Documentation/DocBook/media/v4l/pixfmt-z16.xml | 81 +++++++ Documentation/DocBook/media/v4l/pixfmt.xml | 13 +- .../DocBook/media/v4l/vidioc-query-dv-timings.xml | 14 +- .../DocBook/media/v4l/vidioc-querystd.xml | 10 + Documentation/DocBook/usb.tmpl | 12 + 17 files changed, 930 insertions(+), 363 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-y12i.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-y8i.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-yuv422m.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-yuv444m.xml delete mode 100644 Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-z16.xml (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/crypto-API.tmpl b/Documentation/DocBook/crypto-API.tmpl index 07df23ea0..348619fca 100644 --- a/Documentation/DocBook/crypto-API.tmpl +++ b/Documentation/DocBook/crypto-API.tmpl @@ -348,10 +348,7 @@ type: - blkcipher for synchronous block ciphers - - - ablkcipher for asynchronous block ciphers + skcipher for symmetric key ciphers cipher for single block ciphers that may be used with @@ -484,6 +481,9 @@ CRYPTO_ALG_TYPE_RNG Random Number Generation + + CRYPTO_ALG_TYPE_AKCIPHER Asymmetric cipher + CRYPTO_ALG_TYPE_PCOMPRESS Enhanced version of CRYPTO_ALG_TYPE_COMPRESS allowing for segmented compression / @@ -597,7 +597,7 @@ kernel crypto API | IPSEC Layer v v +-----------+ +-----------+ | | | | -| ablkcipher| | ahash | +| skcipher | | ahash | | (ctr) | ---+ | (ghash) | +-----------+ | +-----------+ | @@ -658,7 +658,7 @@ kernel crypto API | IPSEC Layer - The GCM AEAD cipher type implementation now invokes the ABLKCIPHER API + The GCM AEAD cipher type implementation now invokes the SKCIPHER API with the instantiated CTR(AES) cipher handle. @@ -669,7 +669,7 @@ kernel crypto API | IPSEC Layer - That means that the ABLKCIPHER implementation of CTR(AES) only + That means that the SKCIPHER implementation of CTR(AES) only implements the CTR block chaining mode. After performing the block chaining operation, the CIPHER implementation of AES is invoked. @@ -677,7 +677,7 @@ kernel crypto API | IPSEC Layer - The ABLKCIPHER of CTR(AES) now invokes the CIPHER API with the AES + The SKCIPHER of CTR(AES) now invokes the CIPHER API with the AES cipher handle to encrypt one block. @@ -706,7 +706,7 @@ kernel crypto API | IPSEC Layer For example, CBC(AES) is implemented with cbc.c, and aes-generic.c. The ASCII art picture above applies as well with the difference that only - step (4) is used and the ABLKCIPHER block chaining mode is CBC. + step (4) is used and the SKCIPHER block chaining mode is CBC. @@ -904,15 +904,14 @@ kernel crypto API | Caller - Multi-Block Ciphers [BLKCIPHER] [ABLKCIPHER] + Multi-Block Ciphers Example of transformations: cbc(aes), ecb(arc4), ... This section describes the multi-block cipher transformation - implementations for both synchronous [BLKCIPHER] and - asynchronous [ABLKCIPHER] case. The multi-block ciphers are + implementations. The multi-block ciphers are used for transformations which operate on scatterlists of data supplied to the transformation functions. They output the result into a scatterlist of data as well. @@ -921,16 +920,15 @@ kernel crypto API | Caller Registration Specifics - The registration of [BLKCIPHER] or [ABLKCIPHER] algorithms + The registration of multi-block cipher algorithms is one of the most standard procedures throughout the crypto API. Note, if a cipher implementation requires a proper alignment of data, the caller should use the functions of - crypto_blkcipher_alignmask() or crypto_ablkcipher_alignmask() - respectively to identify a memory alignment mask. The kernel - crypto API is able to process requests that are unaligned. + crypto_skcipher_alignmask() to identify a memory alignment mask. + The kernel crypto API is able to process requests that are unaligned. This implies, however, additional overhead as the kernel crypto API needs to perform the realignment of the data which may imply moving of data. @@ -945,14 +943,13 @@ kernel crypto API | Caller Please refer to the single block cipher description for schematics - of the block cipher usage. The usage patterns are exactly the same - for [ABLKCIPHER] and [BLKCIPHER] as they are for plain [CIPHER]. + of the block cipher usage. Specifics Of Asynchronous Multi-Block Cipher - There are a couple of specifics to the [ABLKCIPHER] interface. + There are a couple of specifics to the asynchronous interface. @@ -1692,7 +1689,28 @@ read(opfd, out, outlen); !Finclude/linux/crypto.h cipher_alg !Finclude/crypto/rng.h rng_alg - Asynchronous Block Cipher API + Symmetric Key Cipher API +!Pinclude/crypto/skcipher.h Symmetric Key Cipher API +!Finclude/crypto/skcipher.h crypto_alloc_skcipher +!Finclude/crypto/skcipher.h crypto_free_skcipher +!Finclude/crypto/skcipher.h crypto_has_skcipher +!Finclude/crypto/skcipher.h crypto_skcipher_ivsize +!Finclude/crypto/skcipher.h crypto_skcipher_blocksize +!Finclude/crypto/skcipher.h crypto_skcipher_setkey +!Finclude/crypto/skcipher.h crypto_skcipher_reqtfm +!Finclude/crypto/skcipher.h crypto_skcipher_encrypt +!Finclude/crypto/skcipher.h crypto_skcipher_decrypt + + Symmetric Key Cipher Request Handle +!Pinclude/crypto/skcipher.h Symmetric Key Cipher Request Handle +!Finclude/crypto/skcipher.h crypto_skcipher_reqsize +!Finclude/crypto/skcipher.h skcipher_request_set_tfm +!Finclude/crypto/skcipher.h skcipher_request_alloc +!Finclude/crypto/skcipher.h skcipher_request_free +!Finclude/crypto/skcipher.h skcipher_request_set_callback +!Finclude/crypto/skcipher.h skcipher_request_set_crypt + + Asynchronous Block Cipher API - Deprecated !Pinclude/linux/crypto.h Asynchronous Block Cipher API !Finclude/linux/crypto.h crypto_alloc_ablkcipher !Finclude/linux/crypto.h crypto_free_ablkcipher @@ -1704,7 +1722,7 @@ read(opfd, out, outlen); !Finclude/linux/crypto.h crypto_ablkcipher_encrypt !Finclude/linux/crypto.h crypto_ablkcipher_decrypt - Asynchronous Cipher Request Handle + Asynchronous Cipher Request Handle - Deprecated !Pinclude/linux/crypto.h Asynchronous Cipher Request Handle !Finclude/linux/crypto.h crypto_ablkcipher_reqsize !Finclude/linux/crypto.h ablkcipher_request_set_tfm @@ -1733,10 +1751,9 @@ read(opfd, out, outlen); !Finclude/crypto/aead.h aead_request_free !Finclude/crypto/aead.h aead_request_set_callback !Finclude/crypto/aead.h aead_request_set_crypt -!Finclude/crypto/aead.h aead_request_set_assoc !Finclude/crypto/aead.h aead_request_set_ad - Synchronous Block Cipher API + Synchronous Block Cipher API - Deprecated !Pinclude/linux/crypto.h Synchronous Block Cipher API !Finclude/linux/crypto.h crypto_alloc_blkcipher !Finclude/linux/crypto.h crypto_free_blkcipher @@ -1761,19 +1778,6 @@ read(opfd, out, outlen); !Finclude/linux/crypto.h crypto_cipher_setkey !Finclude/linux/crypto.h crypto_cipher_encrypt_one !Finclude/linux/crypto.h crypto_cipher_decrypt_one - - Synchronous Message Digest API -!Pinclude/linux/crypto.h Synchronous Message Digest API -!Finclude/linux/crypto.h crypto_alloc_hash -!Finclude/linux/crypto.h crypto_free_hash -!Finclude/linux/crypto.h crypto_has_hash -!Finclude/linux/crypto.h crypto_hash_blocksize -!Finclude/linux/crypto.h crypto_hash_digestsize -!Finclude/linux/crypto.h crypto_hash_init -!Finclude/linux/crypto.h crypto_hash_update -!Finclude/linux/crypto.h crypto_hash_final -!Finclude/linux/crypto.h crypto_hash_digest -!Finclude/linux/crypto.h crypto_hash_setkey Message Digest Algorithm Definitions !Pinclude/crypto/hash.h Message Digest Algorithm Definitions @@ -1825,15 +1829,36 @@ read(opfd, out, outlen); !Finclude/crypto/rng.h crypto_alloc_rng !Finclude/crypto/rng.h crypto_rng_alg !Finclude/crypto/rng.h crypto_free_rng +!Finclude/crypto/rng.h crypto_rng_generate !Finclude/crypto/rng.h crypto_rng_get_bytes !Finclude/crypto/rng.h crypto_rng_reset !Finclude/crypto/rng.h crypto_rng_seedsize !Cinclude/crypto/rng.h + Asymmetric Cipher API +!Pinclude/crypto/akcipher.h Generic Public Key API +!Finclude/crypto/akcipher.h akcipher_alg +!Finclude/crypto/akcipher.h akcipher_request +!Finclude/crypto/akcipher.h crypto_alloc_akcipher +!Finclude/crypto/akcipher.h crypto_free_akcipher +!Finclude/crypto/akcipher.h crypto_akcipher_set_pub_key +!Finclude/crypto/akcipher.h crypto_akcipher_set_priv_key + + Asymmetric Cipher Request Handle +!Finclude/crypto/akcipher.h akcipher_request_alloc +!Finclude/crypto/akcipher.h akcipher_request_free +!Finclude/crypto/akcipher.h akcipher_request_set_callback +!Finclude/crypto/akcipher.h akcipher_request_set_crypt +!Finclude/crypto/akcipher.h crypto_akcipher_maxsize +!Finclude/crypto/akcipher.h crypto_akcipher_encrypt +!Finclude/crypto/akcipher.h crypto_akcipher_decrypt +!Finclude/crypto/akcipher.h crypto_akcipher_sign +!Finclude/crypto/akcipher.h crypto_akcipher_verify + Code Examples - Code Example For Asynchronous Block Cipher Operation + Code Example For Symmetric Key Cipher Operation struct tcrypt_result { @@ -1842,15 +1867,15 @@ struct tcrypt_result { }; /* tie all data structures together */ -struct ablkcipher_def { +struct skcipher_def { struct scatterlist sg; - struct crypto_ablkcipher *tfm; - struct ablkcipher_request *req; + struct crypto_skcipher *tfm; + struct skcipher_request *req; struct tcrypt_result result; }; /* Callback function */ -static void test_ablkcipher_cb(struct crypto_async_request *req, int error) +static void test_skcipher_cb(struct crypto_async_request *req, int error) { struct tcrypt_result *result = req->data; @@ -1862,15 +1887,15 @@ static void test_ablkcipher_cb(struct crypto_async_request *req, int error) } /* Perform cipher operation */ -static unsigned int test_ablkcipher_encdec(struct ablkcipher_def *ablk, - int enc) +static unsigned int test_skcipher_encdec(struct skcipher_def *sk, + int enc) { int rc = 0; if (enc) - rc = crypto_ablkcipher_encrypt(ablk->req); + rc = crypto_skcipher_encrypt(sk->req); else - rc = crypto_ablkcipher_decrypt(ablk->req); + rc = crypto_skcipher_decrypt(sk->req); switch (rc) { case 0: @@ -1878,52 +1903,52 @@ static unsigned int test_ablkcipher_encdec(struct ablkcipher_def *ablk, case -EINPROGRESS: case -EBUSY: rc = wait_for_completion_interruptible( - &ablk->result.completion); - if (!rc && !ablk->result.err) { - reinit_completion(&ablk->result.completion); + &sk->result.completion); + if (!rc && !sk->result.err) { + reinit_completion(&sk->result.completion); break; } default: - pr_info("ablkcipher encrypt returned with %d result %d\n", - rc, ablk->result.err); + pr_info("skcipher encrypt returned with %d result %d\n", + rc, sk->result.err); break; } - init_completion(&ablk->result.completion); + init_completion(&sk->result.completion); return rc; } /* Initialize and trigger cipher operation */ -static int test_ablkcipher(void) +static int test_skcipher(void) { - struct ablkcipher_def ablk; - struct crypto_ablkcipher *ablkcipher = NULL; - struct ablkcipher_request *req = NULL; + struct skcipher_def sk; + struct crypto_skcipher *skcipher = NULL; + struct skcipher_request *req = NULL; char *scratchpad = NULL; char *ivdata = NULL; unsigned char key[32]; int ret = -EFAULT; - ablkcipher = crypto_alloc_ablkcipher("cbc-aes-aesni", 0, 0); - if (IS_ERR(ablkcipher)) { - pr_info("could not allocate ablkcipher handle\n"); - return PTR_ERR(ablkcipher); + skcipher = crypto_alloc_skcipher("cbc-aes-aesni", 0, 0); + if (IS_ERR(skcipher)) { + pr_info("could not allocate skcipher handle\n"); + return PTR_ERR(skcipher); } - req = ablkcipher_request_alloc(ablkcipher, GFP_KERNEL); + req = skcipher_request_alloc(skcipher, GFP_KERNEL); if (IS_ERR(req)) { pr_info("could not allocate request queue\n"); ret = PTR_ERR(req); goto out; } - ablkcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG, - test_ablkcipher_cb, - &ablk.result); + skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG, + test_skcipher_cb, + &sk.result); /* AES 256 with random key */ get_random_bytes(&key, 32); - if (crypto_ablkcipher_setkey(ablkcipher, key, 32)) { + if (crypto_skcipher_setkey(skcipher, key, 32)) { pr_info("key could not be set\n"); ret = -EAGAIN; goto out; @@ -1945,26 +1970,26 @@ static int test_ablkcipher(void) } get_random_bytes(scratchpad, 16); - ablk.tfm = ablkcipher; - ablk.req = req; + sk.tfm = skcipher; + sk.req = req; /* We encrypt one block */ - sg_init_one(&ablk.sg, scratchpad, 16); - ablkcipher_request_set_crypt(req, &ablk.sg, &ablk.sg, 16, ivdata); - init_completion(&ablk.result.completion); + sg_init_one(&sk.sg, scratchpad, 16); + skcipher_request_set_crypt(req, &sk.sg, &sk.sg, 16, ivdata); + init_completion(&sk.result.completion); /* encrypt data */ - ret = test_ablkcipher_encdec(&ablk, 1); + ret = test_skcipher_encdec(&sk, 1); if (ret) goto out; pr_info("Encryption triggered successfully\n"); out: - if (ablkcipher) - crypto_free_ablkcipher(ablkcipher); + if (skcipher) + crypto_free_skcipher(skcipher); if (req) - ablkcipher_request_free(req); + skcipher_request_free(req); if (ivdata) kfree(ivdata); if (scratchpad) @@ -1974,77 +1999,6 @@ out: - Code Example For Synchronous Block Cipher Operation - - -static int test_blkcipher(void) -{ - struct crypto_blkcipher *blkcipher = NULL; - char *cipher = "cbc(aes)"; - // AES 128 - charkey = -"\x12\x34\x56\x78\x90\xab\xcd\xef\x12\x34\x56\x78\x90\xab\xcd\xef"; - chariv = -"\x12\x34\x56\x78\x90\xab\xcd\xef\x12\x34\x56\x78\x90\xab\xcd\xef"; - unsigned int ivsize = 0; - char *scratchpad = NULL; // holds plaintext and ciphertext - struct scatterlist sg; - struct blkcipher_desc desc; - int ret = -EFAULT; - - blkcipher = crypto_alloc_blkcipher(cipher, 0, 0); - if (IS_ERR(blkcipher)) { - printk("could not allocate blkcipher handle for %s\n", cipher); - return -PTR_ERR(blkcipher); - } - - if (crypto_blkcipher_setkey(blkcipher, key, strlen(key))) { - printk("key could not be set\n"); - ret = -EAGAIN; - goto out; - } - - ivsize = crypto_blkcipher_ivsize(blkcipher); - if (ivsize) { - if (ivsize != strlen(iv)) - printk("IV length differs from expected length\n"); - crypto_blkcipher_set_iv(blkcipher, iv, ivsize); - } - - scratchpad = kmalloc(crypto_blkcipher_blocksize(blkcipher), GFP_KERNEL); - if (!scratchpad) { - printk("could not allocate scratchpad for %s\n", cipher); - goto out; - } - /* get some random data that we want to encrypt */ - get_random_bytes(scratchpad, crypto_blkcipher_blocksize(blkcipher)); - - desc.flags = 0; - desc.tfm = blkcipher; - sg_init_one(&sg, scratchpad, crypto_blkcipher_blocksize(blkcipher)); - - /* encrypt data in place */ - crypto_blkcipher_encrypt(&desc, &sg, &sg, - crypto_blkcipher_blocksize(blkcipher)); - - /* decrypt data in place - * crypto_blkcipher_decrypt(&desc, &sg, &sg, - */ crypto_blkcipher_blocksize(blkcipher)); - - - printk("Cipher operation completed\n"); - return 0; - -out: - if (blkcipher) - crypto_free_blkcipher(blkcipher); - if (scratchpad) - kzfree(scratchpad); - return ret; -} - - - Code Example For Use of Operational State Memory With SHASH diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index cdd8b24db..184f3c7b5 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -229,6 +229,7 @@ X!Isound/sound_firmware.c !Iinclude/media/v4l2-dv-timings.h !Iinclude/media/v4l2-event.h !Iinclude/media/v4l2-flash-led-class.h +!Iinclude/media/v4l2-mc.h !Iinclude/media/v4l2-mediabus.h !Iinclude/media/v4l2-mem2mem.h !Iinclude/media/v4l2-of.h @@ -368,7 +369,7 @@ X!Ilib/fonts/fonts.c !Iinclude/linux/input-polldev.h !Edrivers/input/input-polldev.c - Matrix keyboars/keypads + Matrix keyboards/keypads !Iinclude/linux/input/matrix_keypad.h Sparse keymap support diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index a8669330b..ab037f6fa 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -1621,6 +1621,12 @@ void intel_crt_init(struct drm_device *dev) !Pdrivers/gpu/drm/drm_dp_helper.c dp helpers !Iinclude/drm/drm_dp_helper.h !Edrivers/gpu/drm/drm_dp_helper.c + + + Display Port Dual Mode Adaptor Helper Functions Reference +!Pdrivers/gpu/drm/drm_dp_dual_mode_helper.c dp dual mode helpers +!Iinclude/drm/drm_dp_dual_mode_helper.h +!Edrivers/gpu/drm/drm_dp_dual_mode_helper.c Display Port MST Helper Functions Reference @@ -1816,7 +1822,7 @@ void intel_crt_init(struct drm_device *dev) Description/Restrictions - DRM + DRM Generic “rotation” BITMASK @@ -2068,7 +2074,7 @@ void intel_crt_init(struct drm_device *dev) property to suggest an Y offset for a connector - Optional + Optional “scaling mode” ENUM { "None", "Full", "Center", "Full aspect" } @@ -2092,6 +2098,61 @@ void intel_crt_init(struct drm_device *dev) TBD + “DEGAMMA_LUT” + BLOB + 0 + CRTC + DRM property to set the degamma lookup table + (LUT) mapping pixel data from the framebuffer before it is + given to the transformation matrix. The data is an interpreted + as an array of struct drm_color_lut elements. Hardware might + choose not to use the full precision of the LUT elements nor + use all the elements of the LUT (for example the hardware + might choose to interpolate between LUT[0] and LUT[4]). + + + “DEGAMMA_LUT_SIZE” + RANGE | IMMUTABLE + Min=0, Max=UINT_MAX + CRTC + DRM property to gives the size of the lookup + table to be set on the DEGAMMA_LUT property (the size depends + on the underlying hardware). + + + “CTM” + BLOB + 0 + CRTC + DRM property to set the current + transformation matrix (CTM) apply to pixel data after the + lookup through the degamma LUT and before the lookup through + the gamma LUT. The data is an interpreted as a struct + drm_color_ctm. + + + “GAMMA_LUT” + BLOB + 0 + CRTC + DRM property to set the gamma lookup table + (LUT) mapping pixel data after to the transformation matrix to + data sent to the connector. The data is an interpreted as an + array of struct drm_color_lut elements. Hardware might choose + not to use the full precision of the LUT elements nor use all + the elements of the LUT (for example the hardware might choose + to interpolate between LUT[0] and LUT[4]). + + + “GAMMA_LUT_SIZE” + RANGE | IMMUTABLE + Min=0, Max=UINT_MAX + CRTC + DRM property to gives the size of the lookup + table to be set on the GAMMA_LUT property (the size depends on + the underlying hardware). + + i915 Generic "Broadcast RGB" @@ -2886,52 +2947,8 @@ void (*postclose) (struct drm_device *, struct drm_file *); File Operations - const struct file_operations *fops - File operations for the DRM device node. - - Drivers must define the file operations structure that forms the DRM - userspace API entry point, even though most of those operations are - implemented in the DRM core. The open, - release and ioctl - operations are handled by - - .owner = THIS_MODULE, - .open = drm_open, - .release = drm_release, - .unlocked_ioctl = drm_ioctl, - #ifdef CONFIG_COMPAT - .compat_ioctl = drm_compat_ioctl, - #endif - - - - Drivers that implement private ioctls that requires 32/64bit - compatibility support must provide their own - compat_ioctl handler that processes private - ioctls and calls drm_compat_ioctl for core ioctls. - - - The read and poll - operations provide support for reading DRM events and polling them. They - are implemented by - - .poll = drm_poll, - .read = drm_read, - .llseek = no_llseek, - - - - The memory mapping implementation varies depending on how the driver - manages memory. Pre-GEM drivers will use drm_mmap, - while GEM-aware drivers will use drm_gem_mmap. See - . - - .mmap = drm_gem_mmap, - - - - No other file operation is supported by the DRM API. - +!Pdrivers/gpu/drm/drm_fops.c file operations +!Edrivers/gpu/drm/drm_fops.c IOCTLs @@ -3319,6 +3336,12 @@ int num_ioctls; !Pdrivers/gpu/drm/i915/intel_csr.c csr support for dmc !Idrivers/gpu/drm/i915/intel_csr.c + + Video BIOS Table (VBT) +!Pdrivers/gpu/drm/i915/intel_bios.c Video BIOS Table (VBT) +!Idrivers/gpu/drm/i915/intel_bios.c +!Idrivers/gpu/drm/i915/intel_bios.h + @@ -3460,6 +3483,7 @@ int num_ioctls; Public constants +!Finclude/linux/vga_switcheroo.h vga_switcheroo_handler_flags_t !Finclude/linux/vga_switcheroo.h vga_switcheroo_client_id !Finclude/linux/vga_switcheroo.h vga_switcheroo_state @@ -3488,6 +3512,10 @@ int num_ioctls; Backlight control !Pdrivers/platform/x86/apple-gmux.c Backlight control + + Public functions +!Iinclude/linux/apple-gmux.h + diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index f13a42909..361040e6b 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -2329,6 +2329,14 @@ to search and match for the present Macroblock (MB) in the reference picture. Th vertical search range for motion estimation module in video encoder. + + + V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME  + button + Force a key frame for the next queued buffer. Applicable to encoders. +This is a general, codec-agnostic keyframe control. + + V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE  @@ -5069,6 +5077,46 @@ interface and may change in the future. This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors. + + V4L2_CID_DV_TX_IT_CONTENT_TYPE + enum v4l2_dv_it_content_type + + Configures the IT Content Type + of the transmitted video. This information is sent over HDMI and DisplayPort connectors + as part of the AVI InfoFrame. The term 'IT Content' is used for content that originates + from a computer as opposed to content from a TV broadcast or an analog source. The + enum v4l2_dv_it_content_type defines the possible content types: + + + + + + V4L2_DV_IT_CONTENT_TYPE_GRAPHICS  + Graphics content. Pixel data should be passed unfiltered and without + analog reconstruction. + + + V4L2_DV_IT_CONTENT_TYPE_PHOTO  + Photo content. The content is derived from digital still pictures. + The content should be passed through with minimal scaling and picture + enhancements. + + + V4L2_DV_IT_CONTENT_TYPE_CINEMA  + Cinema content. + + + V4L2_DV_IT_CONTENT_TYPE_GAME  + Game content. Audio and video latency should be minimized. + + + V4L2_DV_IT_CONTENT_TYPE_NO_ITC  + No IT Content information is available and the ITC bit in the AVI + InfoFrame is set to 0. + + + + V4L2_CID_DV_RX_POWER_PRESENT bitmask @@ -5098,6 +5146,16 @@ interface and may change in the future. This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors. + + V4L2_CID_DV_RX_IT_CONTENT_TYPE + enum v4l2_dv_it_content_type + + Reads the IT Content Type + of the received video. This information is sent over HDMI and DisplayPort connectors + as part of the AVI InfoFrame. The term 'IT Content' is used for content that originates + from a computer as opposed to content from a TV broadcast or an analog source. See + V4L2_CID_DV_TX_IT_CONTENT_TYPE for the available content types. + diff --git a/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml b/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml index 63152ab9e..e0d49fa32 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml @@ -48,9 +48,6 @@ Description - - NOTE: This new ioctl is programmed to be added on Kernel 4.6. Its definition/arguments may change until its final version. - The typical usage of this ioctl is to call it twice. On the first call, the structure defined at &media-v2-topology; should be zeroed. At return, if no errors happen, this ioctl will return the diff --git a/Documentation/DocBook/media/v4l/media-types.xml b/Documentation/DocBook/media/v4l/media-types.xml index 0ee0f3386..5e3f20fdc 100644 --- a/Documentation/DocBook/media/v4l/media-types.xml +++ b/Documentation/DocBook/media/v4l/media-types.xml @@ -80,7 +80,46 @@ MEDIA_ENT_F_TUNER - Digital TV, analog TV, radio and/or software radio tuner. + Digital TV, analog TV, radio and/or software radio tuner, + with consists on a PLL tuning stage that converts radio + frequency (RF) signal into an Intermediate Frequency (IF). + Modern tuners have internally IF-PLL decoders for audio + and video, but older models have those stages implemented + on separate entities. + + + + MEDIA_ENT_F_IF_VID_DECODER + IF-PLL video decoder. It receives the IF from a PLL + and decodes the analog TV video signal. This is commonly + found on some very old analog tuners, like Philips MK3 + designs. They all contain a tda9887 (or some software + compatible similar chip, like tda9885). Those devices + use a different I2C address than the tuner PLL. + + + + MEDIA_ENT_F_IF_AUD_DECODER + IF-PLL sound decoder. It receives the IF from a PLL + and decodes the analog TV audio signal. This is commonly + found on some very old analog hardware, like Micronas + msp3400, Philips tda9840, tda985x, etc. Those devices + use a different I2C address than the tuner PLL and + should be controlled together with the IF-PLL video + decoder. + + + + MEDIA_ENT_F_AUDIO_CAPTURE + Audio Capture Function Entity. + + + MEDIA_ENT_F_AUDIO_PLAYBACK + Audio Playback Function Entity. + + + MEDIA_ENT_F_AUDIO_MIXER + Audio Mixer Function Entity. @@ -162,6 +201,46 @@ Device node interface for Software Defined Radio (V4L) typically, /dev/swradio? + + MEDIA_INTF_T_ALSA_PCM_CAPTURE + Device node interface for ALSA PCM Capture + typically, /dev/snd/pcmC?D?c + + + MEDIA_INTF_T_ALSA_PCM_PLAYBACK + Device node interface for ALSA PCM Playback + typically, /dev/snd/pcmC?D?p + + + MEDIA_INTF_T_ALSA_CONTROL + Device node interface for ALSA Control + typically, /dev/snd/controlC? + + + MEDIA_INTF_T_ALSA_COMPRESS + Device node interface for ALSA Compress + typically, /dev/snd/compr? + + + MEDIA_INTF_T_ALSA_RAWMIDI + Device node interface for ALSA Raw MIDI + typically, /dev/snd/midi? + + + MEDIA_INTF_T_ALSA_HWDEP + Device node interface for ALSA Hardware Dependent + typically, /dev/snd/hwC?D? + + + MEDIA_INTF_T_ALSA_SEQUENCER + Device node interface for ALSA Sequencer + typically, /dev/snd/seq + + + MEDIA_INTF_T_ALSA_TIMER + Device node interface for ALSA Timer + typically, /dev/snd/timer + diff --git a/Documentation/DocBook/media/v4l/pixfmt-y12i.xml b/Documentation/DocBook/media/v4l/pixfmt-y12i.xml new file mode 100644 index 000000000..4a2d1e5f6 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-y12i.xml @@ -0,0 +1,49 @@ + + + V4L2_PIX_FMT_Y12I ('Y12I') + &manvol; + + + V4L2_PIX_FMT_Y12I + Interleaved grey-scale image, e.g. from a stereo-pair + + + Description + + This is a grey-scale image with a depth of 12 bits per pixel, but with +pixels from 2 sources interleaved and bit-packed. Each pixel is stored in a +24-bit word in the little-endian order. On a little-endian machine these pixels +can be deinterlaced using + + + +__u8 *buf; +left0 = 0xfff & *(__u16 *)buf; +right0 = *(__u16 *)(buf + 1) >> 4; + + + + + <constant>V4L2_PIX_FMT_Y12I</constant> 2 pixel data stream taking 3 bytes + + + Bit-packed representation + pixels cross the byte boundary and have a ratio of 3 bytes for each + interleaved pixel. + + + + + + Y'0left[7:0] + Y'0right[3:0]Y'0left[11:8] + Y'0right[11:4] + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-y8i.xml b/Documentation/DocBook/media/v4l/pixfmt-y8i.xml new file mode 100644 index 000000000..99f389d4c --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-y8i.xml @@ -0,0 +1,80 @@ + + + V4L2_PIX_FMT_Y8I ('Y8I ') + &manvol; + + + V4L2_PIX_FMT_Y8I + Interleaved grey-scale image, e.g. from a stereo-pair + + + Description + + This is a grey-scale image with a depth of 8 bits per pixel, but with +pixels from 2 sources interleaved. Each pixel is stored in a 16-bit word. E.g. +the R200 RealSense camera stores pixel from the left sensor in lower and from +the right sensor in the higher 8 bits. + + + <constant>V4L2_PIX_FMT_Y8I</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Y'00left + Y'00right + Y'01left + Y'01right + Y'02left + Y'02right + Y'03left + Y'03right + + + start + 8: + Y'10left + Y'10right + Y'11left + Y'11right + Y'12left + Y'12right + Y'13left + Y'13right + + + start + 16: + Y'20left + Y'20right + Y'21left + Y'21right + Y'22left + Y'22right + Y'23left + Y'23right + + + start + 24: + Y'30left + Y'30right + Y'31left + Y'31right + Y'32left + Y'32right + Y'33left + Y'33right + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml b/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml index e781cc617..7d13fe966 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml @@ -1,35 +1,43 @@ - + - V4L2_PIX_FMT_YUV420M ('YM12') + V4L2_PIX_FMT_YUV420M ('YM12'), V4L2_PIX_FMT_YVU420M ('YM21') &manvol; - V4L2_PIX_FMT_YUV420M - Variation of V4L2_PIX_FMT_YUV420 - with planes non contiguous in memory. + V4L2_PIX_FMT_YUV420M + V4L2_PIX_FMT_YVU420M + Variation of V4L2_PIX_FMT_YUV420 and + V4L2_PIX_FMT_YVU420 with planes non contiguous + in memory. Description This is a multi-planar format, as opposed to a packed format. -The three components are separated into three sub- images or planes. +The three components are separated into three sub-images or planes. -The Y plane is first. The Y plane has one byte per pixel. The Cb data + The Y plane is first. The Y plane has one byte per pixel. +For V4L2_PIX_FMT_YUV420M the Cb data constitutes the second plane which is half the width and half the height of the Y plane (and of the image). Each Cb belongs to four pixels, a two-by-two square of the image. For example, Cb0 belongs to Y'00, Y'01, Y'10, and Y'11. The Cr data, just like the Cb plane, is -in the third plane. +in the third plane. + + V4L2_PIX_FMT_YVU420M is the same except +the Cr data is stored in the second plane and the Cb data in the third plane. + If the Y plane has pad bytes after each row, then the Cb and Cr planes have half as many pad bytes after their rows. In other words, two Cx rows (including padding) is exactly as long as one Y row (including padding). - V4L2_PIX_FMT_YUV420M is intended to be + V4L2_PIX_FMT_YUV420M and +V4L2_PIX_FMT_YVU420M are intended to be used only in drivers and applications that support the multi-planar API, described in . diff --git a/Documentation/DocBook/media/v4l/pixfmt-yuv422m.xml b/Documentation/DocBook/media/v4l/pixfmt-yuv422m.xml new file mode 100644 index 000000000..dd502802c --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-yuv422m.xml @@ -0,0 +1,166 @@ + + + V4L2_PIX_FMT_YUV422M ('YM16'), V4L2_PIX_FMT_YVU422M ('YM61') + &manvol; + + + V4L2_PIX_FMT_YUV422M + V4L2_PIX_FMT_YVU422M + Planar formats with ½ horizontal resolution, also + known as YUV and YVU 4:2:2 + + + + Description + + This is a multi-planar format, as opposed to a packed format. +The three components are separated into three sub-images or planes. + + The Y plane is first. The Y plane has one byte per pixel. +For V4L2_PIX_FMT_YUV422M the Cb data +constitutes the second plane which is half the width of the Y plane (and of the +image). Each Cb belongs to two pixels. For example, +Cb0 belongs to Y'00, +Y'01. The Cr data, just like the Cb plane, is +in the third plane. + + V4L2_PIX_FMT_YVU422M is the same except +the Cr data is stored in the second plane and the Cb data in the third plane. + + + If the Y plane has pad bytes after each row, then the Cb +and Cr planes have half as many pad bytes after their rows. In other +words, two Cx rows (including padding) is exactly as long as one Y row +(including padding). + + V4L2_PIX_FMT_YUV422M and +V4L2_PIX_FMT_YVU422M are intended to be +used only in drivers and applications that support the multi-planar API, +described in . + + + <constant>V4L2_PIX_FMT_YUV422M</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start0 + 0: + Y'00 + Y'01 + Y'02 + Y'03 + + + start0 + 4: + Y'10 + Y'11 + Y'12 + Y'13 + + + start0 + 8: + Y'20 + Y'21 + Y'22 + Y'23 + + + start0 + 12: + Y'30 + Y'31 + Y'32 + Y'33 + + + + start1 + 0: + Cb00 + Cb01 + + + start1 + 2: + Cb10 + Cb11 + + + start1 + 4: + Cb20 + Cb21 + + + start1 + 6: + Cb30 + Cb31 + + + + start2 + 0: + Cr00 + Cr01 + + + start2 + 2: + Cr10 + Cr11 + + + start2 + 4: + Cr20 + Cr21 + + + start2 + 6: + Cr30 + Cr31 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YCY + YCY + + + 1 + YCY + YCY + + + 2 + YCY + YCY + + + 3 + YCY + YCY + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-yuv444m.xml b/Documentation/DocBook/media/v4l/pixfmt-yuv444m.xml new file mode 100644 index 000000000..1b7335940 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-yuv444m.xml @@ -0,0 +1,177 @@ + + + V4L2_PIX_FMT_YUV444M ('YM24'), V4L2_PIX_FMT_YVU444M ('YM42') + &manvol; + + + V4L2_PIX_FMT_YUV444M + V4L2_PIX_FMT_YVU444M + Planar formats with full horizontal resolution, also + known as YUV and YVU 4:4:4 + + + + Description + + This is a multi-planar format, as opposed to a packed format. +The three components are separated into three sub-images or planes. + + The Y plane is first. The Y plane has one byte per pixel. +For V4L2_PIX_FMT_YUV444M the Cb data +constitutes the second plane which is the same width and height as the Y plane +(and as the image). The Cr data, just like the Cb plane, is in the third plane. + + + V4L2_PIX_FMT_YVU444M is the same except +the Cr data is stored in the second plane and the Cb data in the third plane. + + If the Y plane has pad bytes after each row, then the Cb +and Cr planes have the same number of pad bytes after their rows. + + V4L2_PIX_FMT_YUV444M and +V4L2_PIX_FMT_YUV444M are intended to be +used only in drivers and applications that support the multi-planar API, +described in . + + + <constant>V4L2_PIX_FMT_YUV444M</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start0 + 0: + Y'00 + Y'01 + Y'02 + Y'03 + + + start0 + 4: + Y'10 + Y'11 + Y'12 + Y'13 + + + start0 + 8: + Y'20 + Y'21 + Y'22 + Y'23 + + + start0 + 12: + Y'30 + Y'31 + Y'32 + Y'33 + + + + start1 + 0: + Cb00 + Cb01 + Cb02 + Cb03 + + + start1 + 4: + Cb10 + Cb11 + Cb12 + Cb13 + + + start1 + 8: + Cb20 + Cb21 + Cb22 + Cb23 + + + start1 + 12: + Cb20 + Cb21 + Cb32 + Cb33 + + + + start2 + 0: + Cr00 + Cr01 + Cr02 + Cr03 + + + start2 + 4: + Cr10 + Cr11 + Cr12 + Cr13 + + + start2 + 8: + Cr20 + Cr21 + Cr22 + Cr23 + + + start2 + 12: + Cr30 + Cr31 + Cr32 + Cr33 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YCYC + YCYC + + + 1 + YCYC + YCYC + + + 2 + YCYC + YCYC + + + 3 + YCYC + YCYC + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml b/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml deleted file mode 100644 index 233066790..000000000 --- a/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml +++ /dev/null @@ -1,154 +0,0 @@ - - - V4L2_PIX_FMT_YVU420M ('YM21') - &manvol; - - - V4L2_PIX_FMT_YVU420M - Variation of V4L2_PIX_FMT_YVU420 - with planes non contiguous in memory. - - - - Description - - This is a multi-planar format, as opposed to a packed format. -The three components are separated into three sub-images or planes. - -The Y plane is first. The Y plane has one byte per pixel. The Cr data -constitutes the second plane which is half the width and half -the height of the Y plane (and of the image). Each Cr belongs to four -pixels, a two-by-two square of the image. For example, -Cr0 belongs to Y'00, -Y'01, Y'10, and -Y'11. The Cb data, just like the Cr plane, constitutes -the third plane. - - If the Y plane has pad bytes after each row, then the Cr -and Cb planes have half as many pad bytes after their rows. In other -words, two Cx rows (including padding) is exactly as long as one Y row -(including padding). - - V4L2_PIX_FMT_YVU420M is intended to be -used only in drivers and applications that support the multi-planar API, -described in . - - - <constant>V4L2_PIX_FMT_YVU420M</constant> 4 × 4 -pixel image - - - Byte Order. - Each cell is one byte. - - - - - - start0 + 0: - Y'00 - Y'01 - Y'02 - Y'03 - - - start0 + 4: - Y'10 - Y'11 - Y'12 - Y'13 - - - start0 + 8: - Y'20 - Y'21 - Y'22 - Y'23 - - - start0 + 12: - Y'30 - Y'31 - Y'32 - Y'33 - - - - start1 + 0: - Cr00 - Cr01 - - - start1 + 2: - Cr10 - Cr11 - - - - start2 + 0: - Cb00 - Cb01 - - - start2 + 2: - Cb10 - Cb11 - - - - - - - - - Color Sample Location. - - - - - - - 01 - 23 - - - 0 - YY - YY - - - - C - C - - - 1 - YY - YY - - - - - - 2 - YY - YY - - - - C - C - - - 3 - YY - YY - - - - - - - - - diff --git a/Documentation/DocBook/media/v4l/pixfmt-z16.xml b/Documentation/DocBook/media/v4l/pixfmt-z16.xml new file mode 100644 index 000000000..3d87e4bf8 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-z16.xml @@ -0,0 +1,81 @@ + + + V4L2_PIX_FMT_Z16 ('Z16 ') + &manvol; + + + V4L2_PIX_FMT_Z16 + Interleaved grey-scale image, e.g. from a stereo-pair + + + Description + + This is a 16-bit format, representing depth data. Each pixel is a +distance to the respective point in the image coordinates. Distance unit can +vary and has to be negotiated with the device separately. Each pixel is stored +in a 16-bit word in the little endian byte order. + + + + <constant>V4L2_PIX_FMT_Z16</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Z00low + Z00high + Z01low + Z01high + Z02low + Z02high + Z03low + Z03high + + + start + 8: + Z10low + Z10high + Z11low + Z11high + Z12low + Z12high + Z13low + Z13high + + + start + 16: + Z20low + Z20high + Z21low + Z21high + Z22low + Z22high + Z23low + Z23high + + + start + 24: + Z30low + Z30high + Z31low + Z31high + Z32low + Z32high + Z33low + Z33high + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index d871245d2..5a08aeea4 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -1620,6 +1620,8 @@ information. &sub-y10b; &sub-y16; &sub-y16-be; + &sub-y8i; + &sub-y12i; &sub-uv8; &sub-yuyv; &sub-uyvy; @@ -1628,7 +1630,8 @@ information. &sub-y41p; &sub-yuv420; &sub-yuv420m; - &sub-yvu420m; + &sub-yuv422m; + &sub-yuv444m; &sub-yuv410; &sub-yuv422p; &sub-yuv411p; @@ -1641,6 +1644,14 @@ information. &sub-m420; +
+ Depth Formats + Depth data provides distance to points, mapped onto the image plane + + + &sub-z16; +
+
Compressed Formats diff --git a/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml b/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml index e9c70a8f3..0c93677d1 100644 --- a/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml +++ b/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml @@ -60,9 +60,19 @@ input automatically, similar to sensing the video standard. To do so, applications call VIDIOC_QUERY_DV_TIMINGS with a pointer to a &v4l2-dv-timings;. Once the hardware detects the timings, it will fill in the -timings structure. +timings structure. -If the timings could not be detected because there was no signal, then +Please note that drivers shall not switch timings automatically +if new timings are detected. Instead, drivers should send the +V4L2_EVENT_SOURCE_CHANGE event (if they support this) and expect +that userspace will take action by calling VIDIOC_QUERY_DV_TIMINGS. +The reason is that new timings usually mean different buffer sizes as well, and you +cannot change buffer sizes on the fly. In general, applications that receive the +Source Change event will have to call VIDIOC_QUERY_DV_TIMINGS, +and if the detected timings are valid they will have to stop streaming, set the new +timings, allocate new buffers and start streaming again. + +If the timings could not be detected because there was no signal, then ENOLINK is returned. If a signal was detected, but it was unstable and the receiver could not lock to the signal, then ENOLCK is returned. If the receiver could lock to the signal, diff --git a/Documentation/DocBook/media/v4l/vidioc-querystd.xml b/Documentation/DocBook/media/v4l/vidioc-querystd.xml index 222348542..3ceae35fa 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querystd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querystd.xml @@ -59,6 +59,16 @@ then the driver will return V4L2_STD_UNKNOWN. When detection is not possible or fails, the set must contain all standards supported by the current video input or output. +Please note that drivers shall not switch the video standard +automatically if a new video standard is detected. Instead, drivers should send the +V4L2_EVENT_SOURCE_CHANGE event (if they support this) and expect +that userspace will take action by calling VIDIOC_QUERYSTD. +The reason is that a new video standard can mean different buffer sizes as well, and you +cannot change buffer sizes on the fly. In general, applications that receive the +Source Change event will have to call VIDIOC_QUERYSTD, +and if the detected video standard is valid they will have to stop streaming, set the new +standard, allocate new buffers and start streaming again. + diff --git a/Documentation/DocBook/usb.tmpl b/Documentation/DocBook/usb.tmpl index 4cd5b2cd0..bc776be0f 100644 --- a/Documentation/DocBook/usb.tmpl +++ b/Documentation/DocBook/usb.tmpl @@ -732,6 +732,18 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param) or SET_INTERFACE. + USBDEVFS_DROP_PRIVILEGES + This is used to relinquish the ability + to do certain operations which are considered to be + privileged on a usbfs file descriptor. + This includes claiming arbitrary interfaces, resetting + a device on which there are currently claimed interfaces + from other users, and issuing USBDEVFS_IOCTL calls. + The ioctl parameter is a 32 bit mask of interfaces + the user is allowed to claim on this file descriptor. + You may issue this ioctl more than one time to narrow + said mask. + -- cgit v1.2.3-54-g00ecf