- 23 Jan, 2017 11 commits
-
-
Ryder Lee authored
Dummy patch to fix typo and indentation. Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ryder Lee authored
This patch only regroup functions by usage. This will help to integrate the GCM support patch later by adjusting some shared code section, such as common code which will be reused by GCM, AES mode setting, and DMA transfer. Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ryder Lee authored
This patch introduces a new callback 'resume' in the struct mtk_aes_rec. This callback is run to resume/complete the processing of the crypto request when woken up by AES interrupts when DMA completion. This callback will help implementing the GCM mode support in further patches. Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ryder Lee authored
This patch changes mtk_aes_handle_queue() to make it more generic. The function argument is now a pointer to struct crypto_async_request, which is the common base of struct ablkcipher_request and struct aead_request. Also this patch introduces struct mtk_aes_base_ctx which will be the common base of all the transformation contexts. Hence the very same queue will be used to manage both block cipher and AEAD requests (such as gcm and authenc implemented in further patches). Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ryder Lee authored
This patch fixes mtk_aes_xmit() data transfer bug. The original function uses the same loop and ring->pos to handle both command and result descriptors. But this produces incomplete results when src.sg_len != dst.sg_len. To solve the problem, we splits the descriptors into different loops and uses cmd_pos and res_pos to record them respectively. Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ryder Lee authored
This patch moves hardware control block members from mtk_*_rec to transformation context and refines related definition. This makes operational context to manage its own control information easily for each DMA transfer. Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Denys Vlasenko authored
A lot of asm-optimized routines in arch/x86/crypto/ keep its constants in .data. This is wrong, they should be on .rodata. Mnay of these constants are the same in different modules. For example, 128-bit shuffle mask 0x000102030405060708090A0B0C0D0E0F exists in at least half a dozen places. There is a way to let linker merge them and use just one copy. The rules are as follows: mergeable objects of different sizes should not share sections. You can't put them all in one .rodata section, they will lose "mergeability". GCC puts its mergeable constants in ".rodata.cstSIZE" sections, or ".rodata.cstSIZE.<object_name>" if -fdata-sections is used. This patch does the same: .section .rodata.cst16.SHUF_MASK, "aM", @progbits, 16 It is important that all data in such section consists of 16-byte elements, not larger ones, and there are no implicit use of one element from another. When this is not the case, use non-mergeable section: .section .rodata[.VAR_NAME], "a", @progbits This reduces .data by ~15 kbytes: text data bss dec hex filename 11097415 2705840 2630712 16433967 fac32f vmlinux-prev.o 11112095 2690672 2630712 16433479 fac147 vmlinux.o Merged objects are visible in System.map: ffffffff81a28810 r POLY ffffffff81a28810 r POLY ffffffff81a28820 r TWOONE ffffffff81a28820 r TWOONE ffffffff81a28830 r PSHUFFLE_BYTE_FLIP_MASK <- merged regardless of ffffffff81a28830 r SHUF_MASK <------------- the name difference ffffffff81a28830 r SHUF_MASK ffffffff81a28830 r SHUF_MASK .. ffffffff81a28d00 r K512 <- merged three identical 640-byte tables ffffffff81a28d00 r K512 ffffffff81a28d00 r K512 Use of object names in section name suffixes is not strictly necessary, but might help if someday link stage will use garbage collection to eliminate unused sections (ld --gc-sections). Signed-off-by:
Denys Vlasenko <dvlasenk@redhat.com> CC: Herbert Xu <herbert@gondor.apana.org.au> CC: Josh Poimboeuf <jpoimboe@redhat.com> CC: Xiaodong Liu <xiaodong.liu@intel.com> CC: Megha Dey <megha.dey@intel.com> CC: linux-crypto@vger.kernel.org CC: x86@kernel.org CC: linux-kernel@vger.kernel.org Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Denys Vlasenko authored
%progbits form is used on ARM (where @ is a comment char). x86 consistently uses @progbits everywhere else. Signed-off-by:
Denys Vlasenko <dvlasenk@redhat.com> CC: Herbert Xu <herbert@gondor.apana.org.au> CC: Josh Poimboeuf <jpoimboe@redhat.com> CC: Xiaodong Liu <xiaodong.liu@intel.com> CC: Megha Dey <megha.dey@intel.com> CC: George Spelvin <linux@horizon.com> CC: linux-crypto@vger.kernel.org CC: x86@kernel.org CC: linux-kernel@vger.kernel.org Reviewed-by:
Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
The GNU assembler for ARM version 2.22 or older fails to infer the element size from the vmov instructions, and aborts the build in the following way; .../aes-neonbs-core.S: Assembler messages: .../aes-neonbs-core.S:817: Error: bad type for scalar -- `vmov q1h[1],r10' .../aes-neonbs-core.S:817: Error: bad type for scalar -- `vmov q1h[0],r9' .../aes-neonbs-core.S:817: Error: bad type for scalar -- `vmov q1l[1],r8' .../aes-neonbs-core.S:817: Error: bad type for scalar -- `vmov q1l[0],r7' .../aes-neonbs-core.S:818: Error: bad type for scalar -- `vmov q2h[1],r10' .../aes-neonbs-core.S:818: Error: bad type for scalar -- `vmov q2h[0],r9' .../aes-neonbs-core.S:818: Error: bad type for scalar -- `vmov q2l[1],r8' .../aes-neonbs-core.S:818: Error: bad type for scalar -- `vmov q2l[0],r7' Fix this by setting the element size explicitly, by replacing vmov with vmov.32. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Rabin Vincent authored
tcrypt is very tight-lipped when it succeeds, but a bit more feedback would be useful when developing or debugging crypto drivers, especially since even a successful run ends with the module failing to insert. Add a couple of debug prints, which can be enabled with dynamic debug: Before: # insmod tcrypt.ko mode=10 insmod: can't insert 'tcrypt.ko': Resource temporarily unavailable After: # insmod tcrypt.ko mode=10 dyndbg tcrypt: testing ecb(aes) tcrypt: testing cbc(aes) tcrypt: testing lrw(aes) tcrypt: testing xts(aes) tcrypt: testing ctr(aes) tcrypt: testing rfc3686(ctr(aes)) tcrypt: all tests passed insmod: can't insert 'tcrypt.ko': Resource temporarily unavailable Signed-off-by:
Rabin Vincent <rabinv@axis.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Nicolas Iooss authored
The fourth argument of dma_map_sg() and dma_unmap_sg() is an item of dma_data_direction enum. Function img_hash_xmit_dma() wrongly used DMA_MEM_TO_DEV, which is an item of dma_transfer_direction enum. Replace DMA_MEM_TO_DEV (which value is 1) with DMA_TO_DEVICE (which value is fortunately also 1) when calling dma_map_sg() and dma_unmap_sg(). Signed-off-by:
Nicolas Iooss <nicolas.iooss_linux@m4x.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 13 Jan, 2017 9 commits
-
-
Gonglei \(Arei\) authored
Some hardware accelerators (like intel aesni or the s390 cpacf functions) have lower priorities than virtio crypto, and those drivers are faster than the same in the host via virtio. So let's lower the priority of virtio-crypto's algorithm, make it's higher than software implementations but lower than the hardware ones. Suggested-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Gonglei <arei.gonglei@huawei.com> Acked-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
The ARMv8-M architecture introduces 'tt' and 'ttt' instructions, which means we can no longer use 'tt' as a register alias on recent versions of binutils for ARM. So replace the alias with 'ttab'. Fixes: 81edb426 ("crypto: arm/aes - replace scalar AES cipher") Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Shannon Nelson authored
Signed-off-by:
Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Shannon Nelson authored
Add the new register layout constants and the requisite logic for using them. Signed-off-by:
Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Shannon Nelson authored
Since we're going to need to keep track of more than just one attribute of the hardware, we'll change the use of the data field from the match struct from a single flag to a struct pointer. This patch adds the struct template and initial descriptions. Signed-off-by:
Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Shannon Nelson authored
If the self-test fails, it probably won't actually suddenly start working. Currently, this causes an endless spew of error messages on the console and in the logs, so this patch adds a limiter to the test. Reported-by:
Sowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by:
Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Wei Yongjun authored
Fixes the following sparse warning: drivers/crypto/mediatek/mtk-platform.c:585:27: warning: symbol 'of_crypto_id' was not declared. Should it be static? Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
When working on AES in CCM mode for ARM, my code passed the internal tcrypt test before I had even bothered to implement the AES-192 and AES-256 code paths, which is strange because the tcrypt does contain AES-192 and AES-256 test vectors for CCM. As it turned out, the define AES_CCM_ENC_TEST_VECTORS was out of sync with the actual number of test vectors, causing only the AES-128 ones to be executed. So get rid of the defines, and wrap the test vector references in a macro that calculates the number of vectors automatically. The following test vector counts were out of sync with the respective defines: BF_CTR_ENC_TEST_VECTORS 2 -> 3 BF_CTR_DEC_TEST_VECTORS 2 -> 3 TF_CTR_ENC_TEST_VECTORS 2 -> 3 TF_CTR_DEC_TEST_VECTORS 2 -> 3 SERPENT_CTR_ENC_TEST_VECTORS 2 -> 3 SERPENT_CTR_DEC_TEST_VECTORS 2 -> 3 AES_CCM_ENC_TEST_VECTORS 8 -> 14 AES_CCM_DEC_TEST_VECTORS 7 -> 17 AES_CCM_4309_ENC_TEST_VECTORS 7 -> 23 AES_CCM_4309_DEC_TEST_VECTORS 10 -> 23 CAMELLIA_CTR_ENC_TEST_VECTORS 2 -> 3 CAMELLIA_CTR_DEC_TEST_VECTORS 2 -> 3 Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
This replaces the unwieldy generated implementation of bit-sliced AES in CBC/CTR/XTS modes that originated in the OpenSSL project with a new version that is heavily based on the OpenSSL implementation, but has a number of advantages over the old version: - it does not rely on the scalar AES cipher that also originated in the OpenSSL project and contains redundant lookup tables and key schedule generation routines (which we already have in crypto/aes_generic.) - it uses the same expanded key schedule for encryption and decryption, reducing the size of the per-key data structure by 1696 bytes - it adds an implementation of AES in ECB mode, which can be wrapped by other generic chaining mode implementations - it moves the handling of corner cases that are non critical to performance to the glue layer written in C - it was written directly in assembler rather than generated from a Perl script Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 12 Jan, 2017 17 commits
-
-
Ard Biesheuvel authored
This is a reimplementation of the NEON version of the bit-sliced AES algorithm. This code is heavily based on Andy Polyakov's OpenSSL version for ARM, which is also available in the kernel. This is an alternative for the existing NEON implementation for arm64 authored by me, which suffers from poor performance due to its reliance on the pathologically slow four register variant of the tbl/tbx NEON instruction. This version is about ~30% (*) faster than the generic C code, but only in cases where the input can be 8x interleaved (this is a fundamental property of bit slicing). For this reason, only the chaining modes ECB, XTS and CTR are implemented. (The significance of ECB is that it could potentially be used by other chaining modes) * Measured on Cortex-A57. Note that this is still an order of magnitude slower than the implementations that use the dedicated AES instructions introduced in ARMv8, but those are part of an optional extension, and so it is good to have a fallback. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
This replaces the scalar AES cipher that originates in the OpenSSL project with a new implementation that is ~15% (*) faster (on modern cores), and reuses the lookup tables and the key schedule generation routines from the generic C implementation (which is usually compiled in anyway due to networking and other subsystems depending on it). Note that the bit sliced NEON code for AES still depends on the scalar cipher that this patch replaces, so it is not removed entirely yet. * On Cortex-A57, the performance increases from 17.0 to 14.9 cycles per byte for 128-bit keys. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
This adds a scalar implementation of AES, based on the precomputed tables that are exposed by the generic AES code. Since rotates are cheap on arm64, this implementation only uses the 4 core tables (of 1 KB each), and avoids the prerotated ones, reducing the D-cache footprint by 75%. On Cortex-A57, this code manages 13.0 cycles per byte, which is ~34% faster than the generic C code. (Note that this is still >13x slower than the code that uses the optional ARMv8 Crypto Extensions, which manages <1 cycles per byte.) Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
In addition to wrapping the AES-CTR cipher into the async SIMD wrapper, which exposes it as an async skcipher that defers processing to process context, expose our AES-CTR implementation directly as a synchronous cipher as well, but with a lower priority. This makes the AES-CTR transform usable in places where synchronous transforms are required, such as the MAC802.11 encryption code, which executes in sotfirq context, where SIMD processing is allowed on arm64. Users of the async transform will keep the existing behavior. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
This is a straight port to ARM/NEON of the x86 SSE3 implementation of the ChaCha20 stream cipher. It uses the new skcipher walksize attribute to process the input in strides of 4x the block size. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
This is a straight port to arm64/NEON of the x86 SSE3 implementation of the ChaCha20 stream cipher. It uses the new skcipher walksize attribute to process the input in strides of 4x the block size. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Arnd Bergmann authored
After I enabled COMPILE_TEST for non-ARM targets, I ran into these warnings: crypto/mediatek/mtk-aes.c: In function 'mtk_aes_info_map': crypto/mediatek/mtk-aes.c:224:28: error: format '%d' expects argument of type 'int', but argument 3 has type 'long unsigned int' [-Werror=format=] dev_err(cryp->dev, "dma %d bytes error\n", sizeof(*info)); crypto/mediatek/mtk-sha.c:344:28: error: format '%d' expects argument of type 'int', but argument 3 has type 'long unsigned int' [-Werror=format=] crypto/mediatek/mtk-sha.c:550:21: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'size_t {aka long unsigned int}' [-Werror=format=] The correct format for size_t is %zu, so use that in all three cases. Fixes: 785e5c61 ("crypto: mediatek - Add crypto driver support for some MediaTek chips") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Arnd Bergmann authored
Building the mediatek driver on an older ARM architecture results in a harmless warning: warning: (ARCH_OMAP2PLUS_TYPICAL && CRYPTO_DEV_MEDIATEK) selects NEON which has unmet direct dependencies (VFPv3 && CPU_V7) We could add an explicit dependency on CPU_V7, but it seems nicer to open up the build to additional configurations. This replaces the ARM optimized algorithm selection with the normal one that all other drivers use, and that in turn lets us relax the dependency on ARM and drop a number of the unrelated 'select' statements. Obviously a real user would still select those other optimized drivers as a fallback, but as there is no strict dependency, we can leave that up to the user. Fixes: 785e5c61 ("crypto: mediatek - Add crypto driver support for some MediaTek chips") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Herbert Xu authored
The kernel on x86-64 cannot use gcc attribute align to align to a 16-byte boundary. This patch reverts to the old way of aligning it by hand. Fixes: 9ae433bc ("crypto: chacha20 - convert generic and...") Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org>
-
Andrew Lutomirski authored
There are some hashes (e.g. sha224) that have some internal trickery to make sure that only the correct number of output bytes are generated. If something goes wrong, they could potentially overrun the output buffer. Make the test more robust by allocating only enough space for the correct output size so that memory debugging will catch the error if the output is overrun. Tested by intentionally breaking sha224 to output all 256 internally-generated bits while running on KASAN. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Andy Lutomirski <luto@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Colin Ian King authored
In the case where keylen <= bs mtk_sha_setkey returns an uninitialized return value in err. Fix this by returning 0 instead of err. Issue detected by static analysis with cppcheck. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Javier Martinez Canillas authored
The function is used to check either the platform device ID name or the OF node's compatible (depending how the device was registered) to know which device type was registered. But the driver is for a DT-only platform and so there's no need for this level of indirection since the devices can only be registered via OF. Suggested-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Acked-by:
Jamie Iles <jamie@jamieiles.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Javier Martinez Canillas authored
This driver is only used in the picoxcell platform and this is DT-only. So only a OF device ID table is needed and there's no need to have a platform device ID table. This patch removes the unneeded table. Suggested-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Acked-by:
Jamie Iles <jamie@jamieiles.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Javier Martinez Canillas authored
Driver only has runtime but no build time dependency with ARCH_PICOXCELL. So it can be built for testing purposes if COMPILE_TEST option is enabled. This is useful to have more build coverage and make sure that the driver is not affected by changes that could cause build regressions. Suggested-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Acked-by:
Jamie Iles <jamie@jamieiles.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Gideon Israel Dsouza authored
Continuing from this commit: 52f5684c ("kernel: use macros from compiler.h instead of __attribute__((...))") I submitted 4 total patches. They are part of task I've taken up to increase compiler portability in the kernel. I've cleaned up the subsystems under /kernel /mm /block and /security, this patch targets /crypto. There is <linux/compiler.h> which provides macros for various gcc specific constructs. Eg: __weak for __attribute__((weak)). I've cleaned all instances of gcc specific attributes with the right macros for the crypto subsystem. I had to make one additional change into compiler-gcc.h for the case when one wants to use this: __attribute__((aligned) and not specify an alignment factor. From the gcc docs, this will result in the largest alignment for that data type on the target machine so I've named the macro __aligned_largest. Please advise if another name is more appropriate. Signed-off-by:
Gideon Israel Dsouza <gidisrael@gmail.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Eric Biggers authored
It's recommended to use kmemdup instead of kmalloc followed by memcpy. Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linuxHerbert Xu authored
Merging 4.10-rc3 so that the cryptodev tree builds on ARM64.
-
- 08 Jan, 2017 3 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds authored
Pull USB fixes from Greg KH: "Here are a bunch of USB fixes for 4.10-rc3. Yeah, it's a lot, an artifact of the holiday break I think. Lots of gadget and the usual XHCI fixups for reported issues (one day that driver will calm down...) Also included are a bunch of usb-serial driver fixes, and for good measure, a number of much-reported MUSB driver issues have finally been resolved. All of these have been in linux-next with no reported issues" * tag 'usb-4.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (72 commits) USB: fix problems with duplicate endpoint addresses usb: ohci-at91: use descriptor-based gpio APIs correctly usb: storage: unusual_uas: Add JMicron JMS56x to unusual device usb: hub: Move hub_port_disable() to fix warning if PM is disabled usb: musb: blackfin: add bfin_fifo_offset in bfin_ops usb: musb: fix compilation warning on unused function usb: musb: Fix trying to free already-free IRQ 4 usb: musb: dsps: implement clear_ep_rxintr() callback usb: musb: core: add clear_ep_rxintr() to musb_platform_ops USB: serial: ti_usb_3410_5052: fix NULL-deref at open USB: serial: spcp8x5: fix NULL-deref at open USB: serial: quatech2: fix sleep-while-atomic in close USB: serial: pl2303: fix NULL-deref at open USB: serial: oti6858: fix NULL-deref at open USB: serial: omninet: fix NULL-derefs at open and disconnect USB: serial: mos7840: fix misleading interrupt-URB comment USB: serial: mos7840: remove unused write URB USB: serial: mos7840: fix NULL-deref at open USB: serial: mos7720: remove obsolete port initialisation USB: serial: mos7720: fix parallel probe ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-miscLinus Torvalds authored
Pull char/misc fixes from Greg KH: "Here are a few small char/misc driver fixes for 4.10-rc3. Two MEI driver fixes, and three NVMEM patches for reported issues, and a new Hyper-V driver MAINTAINER update. Nothing major at all, all have been in linux-next with no reported issues" * tag 'char-misc-4.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: hyper-v: Add myself as additional MAINTAINER nvmem: fix nvmem_cell_read() return type doc nvmem: imx-ocotp: Fix wrong register size nvmem: qfprom: Allow single byte accesses for read/write mei: move write cb to completion on credentials failures mei: bus: fix mei_cldev_enable KDoc
-