| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fix bug "s5p-sss crypto driver doesn't set next AES-CBC IV". While at this,
fix also AES-CTR mode. Tested on Odroid U3 with Eric Biggers branch
"iv-out-testing".
Signed-off-by: Kamil Konieczny <[email protected]>
Reported-by: Eric Biggers <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
When generating a split key or hashing the key, DMA mapping the key
buffers coming directly from user is incorrect, since they are
not guaranteed to be DMAable.
Update driver to first copy user-provided key in the output buffer
("key_out") and then use this buffer for in-place computation
(split key generation, respectively key hashing).
Signed-off-by: Horia Geantă <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Fix a side effect of adding xcbc support, which leads to DMA mapping the
key twice.
Fixes: 12b8567f6fa4 ("crypto: caam - add support for xcbc(aes)")
Signed-off-by: Horia Geantă <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
When driver started using state->caam_ctxt for storing both running hash
and final hash, it was not updated to handle different DMA unmap
lengths.
Cc: <[email protected]> # v4.19+
Fixes: c19650d6ea99 ("crypto: caam - fix DMA mapping of stack memory")
Signed-off-by: Franck LENORMAND <[email protected]>
Signed-off-by: Horia Geantă <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Replace hard coded AES block size with define.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
There is no need to have the struct stm32_hash_dev *hdev static
since new value always be assigned before use it.
Signed-off-by: Mao Wenan <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Fixed Traffic Stall caused by
- Subcommands except last should have more bit set
- For esn case subcommand is required for linear skb only
- Also Optimized is_eth_imm usage
Signed-off-by: Atul Gupta <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/crypto/marvell/cipher.c: In function 'mv_cesa_skcipher_dma_req_init':
drivers/crypto/marvell/cipher.c:325:15: warning:
variable 'ivsize' set but not used [-Wunused-but-set-variable]
It's not used any more after 0c99620f0ac1 ("crypto: marvell - Use an unique
pool to copy results of requests")
Signed-off-by: YueHaibing <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The current content of some of the driver messages and the way that they
are issued results in some confusion, especially in the area of the PSP
as it relates to SEV support. If SEV is not supported, a message is issued
that says "psp initialization failed." This makes it seem like there was
a problem, when in fact, the PSP support is just disabled if SEV is not
supported.
Update the driver to check SEV support a bit earlier and issue a debug-
level message if SEV is not supported, followed by a debug-level message
that the PSP is disabled. This way you will only see PSP messages if SEV
is supported or if debug information is desired. Also, remove the overall
"enabled" and "disabled" messages for the driver and rely on the CCP and
PSP support to issue component-specific messages.
Signed-off-by: Tom Lendacky <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
For chain mode in cipher(eg. AES-CBC/DES-CBC), the iv is continuously
updated in the operation. The new iv value should be written to device
register by software.
Reported-by: Eric Biggers <[email protected]>
Fixes: 433cd2c617bf ("crypto: rockchip - add crypto driver for rk3288")
Cc: <[email protected]> # v4.5+
Signed-off-by: Zhang Zhijie <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
In some cases, the nents of src scatterlist is different from
dst scatterlist. So two variables are used to handle the nents
of src&dst scatterlist.
Reported-by: Eric Biggers <[email protected]>
Fixes: 433cd2c617bf ("crypto: rockchip - add crypto driver for rk3288")
Cc: <[email protected]> # v4.5+
Signed-off-by: Zhang Zhijie <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Add missing break statement in order to prevent the code from falling
through to case S_DIN_to_DES.
This bug was found thanks to the ongoing efforts to enable
-Wimplicit-fallthrough.
Fixes: 63ee04c8b491 ("crypto: ccree - add skcipher support")
Cc: [email protected]
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Add cpu_relax() in the loop that tries to enqueue the FDs.
Signed-off-by: Horia Geantă <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Avoid console being flooded with prints in case HW is too busy to accept
new enqueue requests.
Signed-off-by: Horia Geantă <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Driver was relying on an older DPIO API, which provided a CPU-affine DPIO
in case it was called with preemption disabled.
Since this is no longer the case, save the CPU-affine DPIO in per-cpu
private structure during setup and further use it on the hot path.
Note that preemption is no longer disabled while trying to enqueue an
FD. Thus it might be possible to run the enqueue on a different CPU
(due to migration, when in process context), however this wouldn't be a
functionality issue.
Since we allow for all cores to enqueue, we take care of data
structures setup to handle the case when number of (Rx, Tx) queue pairs
is smaller than number of cores.
Signed-off-by: Horia Geantă <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Last user of cdev_list_lock was removed in commit
6422ccc5fbefb ("crypto/chelsio/chtls: listen fails with multiadapt")
Cc: Atul Gupta <[email protected]>
Cc: Harsh Jain <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Pull changes from Freescale SoC drivers tree that are required by
subsequent caam/qi2 patches.
|
|
Commit 1358c13a48c4 ("crypto: ccree - fix resume race condition on init")
was missing a "inline" qualifier for stub function used when CONFIG_PM
is not set causing a build warning.
Fixes: 1358c13a48c4 ("crypto: ccree - fix resume race condition on init")
Cc: [email protected] # v4.20
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The netfilter conflicts were rather simple overlapping
changes.
However, the cls_tcindex.c stuff was a bit more complex.
On the 'net' side, Cong is fixing several races and memory
leaks. Whilst on the 'net-next' side we have Vlad adding
the rtnl-ness support.
What I've decided to do, in order to resolve this, is revert the
conversion over to using a workqueue that Cong did, bringing us back
to pure RCU. I did it this way because I believe that either Cong's
races don't apply with have Vlad did things, or Cong will have to
implement the race fix slightly differently.
Signed-off-by: David S. Miller <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto fix from Herbert Xu:
"This fixes a crash on resume in the ccree driver"
* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: ccree - fix resume race condition on init
|
|
Modify setkey callback for cbc des and 3des to check for weak keys.
Signed-off-by: Iuliana Prodan <[email protected]>
Reviewed-by: Horia Geantă <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Add ecb mode support for aes, des, 3des and arc4 ciphers.
ecb(*) reuses existing skcipher implementation, updating it with support
for no IV.
Signed-off-by: Iuliana Prodan <[email protected]>
Reviewed-by: Horia Geantă <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Some arc4 cipher algorithm defines show up in two places:
crypto/arc4.c and drivers/crypto/bcm/cipher.h.
Let's export them in a common header and update their users.
Signed-off-by: Iuliana Prodan <[email protected]>
Reviewed-by: Horia Geantă <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The mapped_{src,dst}_nents _returned_ from the dma_map_sg call (which
could be less than src/dst_nents) have to be used to generate the aead,
skcipher job descriptors.
Signed-off-by: Iuliana Prodan <[email protected]>
Reviewed-by: Horia Geantă <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
An ipvlan bug fix in 'net' conflicted with the abstraction away
of the IPV6 specific support in 'net-next'.
Similarly, a bug fix for mlx5 in 'net' conflicted with the flow
action conversion in 'net-next'.
Signed-off-by: David S. Miller <[email protected]>
|
|
This patch removes an unused label.
Reported-by: Stephen Rothwell <[email protected]>
Fixes: f0fcf9ade46a ("crypto: qat - no need to check return...")
Signed-off-by: Herbert Xu <[email protected]>
|
|
when the source sg contains more than 1 fragment and
destination sg contains 1 fragment, the caam driver
mishandle the buffers to be sent to caam.
Fixes: f2147b88b2b1 ("crypto: caam - Convert GCM to new AEAD interface")
Cc: <[email protected]> # 4.2+
Signed-off-by: Pankaj Gupta <[email protected]>
Signed-off-by: Arun Pathak <[email protected]>
Reviewed-by: Horia Geanta <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
A kexec reboot may leave the firmware in INIT or WORKING state.
Currently, we issue PLATFORM_INIT command during the probe without
checking the current state. The PLATFORM_INIT command fails if the
FW is already in INIT state. Lets check the current state, if FW
is not in UNINIT state then transition it to UNINIT before
initializing or upgrading the FW.
Signed-off-by: Brijesh Singh <[email protected]>
Cc: Tom Lendacky <[email protected]>
Cc: Gary Hook <[email protected]>
Reviewed-by: Tom Lendacky <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
We were enabling autosuspend, which is using data set by the
hash module, prior to the hash module being inited, casuing
a crash on resume as part of the startup sequence if the race
was lost.
This was never a real problem because the PM infra was using low
res timers so we were always winning the race, until commit 8234f6734c5d
("PM-runtime: Switch autosuspend over to using hrtimers") changed that :-)
Fix this by seperating the PM setup and enablement and doing the
latter only at the end of the init sequence.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Cc: Vincent Guittot <[email protected]>
Cc: [email protected] # v4.20
Signed-off-by: Herbert Xu <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto fix from Herbert Xu:
"This fixes a bug in cavium/nitrox where the callback is invoked prior
to the DMA unmap"
* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: cavium/nitrox - Invoke callback after DMA unmap
|
|
Roland reports the following issue and provides a root cause analysis:
"On a v4.19 i.MX6 system with IMA and CONFIG_DMA_API_DEBUG enabled, a
warning is generated when accessing files on a filesystem for which IMA
measurement is enabled:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at kernel/dma/debug.c:1181 check_for_stack.part.9+0xd0/0x120
caam_jr 2101000.jr0: DMA-API: device driver maps memory from stack [addr=b668049e]
Modules linked in:
CPU: 0 PID: 1 Comm: switch_root Not tainted 4.19.0-20181214-1 #2
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[<c010efb8>] (dump_backtrace) from [<c010f2d0>] (show_stack+0x20/0x24)
[<c010f2b0>] (show_stack) from [<c08b04f4>] (dump_stack+0xa0/0xcc)
[<c08b0454>] (dump_stack) from [<c012b610>] (__warn+0xf0/0x108)
[<c012b520>] (__warn) from [<c012b680>] (warn_slowpath_fmt+0x58/0x74)
[<c012b62c>] (warn_slowpath_fmt) from [<c0199acc>] (check_for_stack.part.9+0xd0/0x120)
[<c01999fc>] (check_for_stack.part.9) from [<c019a040>] (debug_dma_map_page+0x144/0x174)
[<c0199efc>] (debug_dma_map_page) from [<c065f7f4>] (ahash_final_ctx+0x5b4/0xcf0)
[<c065f240>] (ahash_final_ctx) from [<c065b3c4>] (ahash_final+0x1c/0x20)
[<c065b3a8>] (ahash_final) from [<c03fe278>] (crypto_ahash_op+0x38/0x80)
[<c03fe240>] (crypto_ahash_op) from [<c03fe2e0>] (crypto_ahash_final+0x20/0x24)
[<c03fe2c0>] (crypto_ahash_final) from [<c03f19a8>] (ima_calc_file_hash+0x29c/0xa40)
[<c03f170c>] (ima_calc_file_hash) from [<c03f2b24>] (ima_collect_measurement+0x1dc/0x240)
[<c03f2948>] (ima_collect_measurement) from [<c03f0a60>] (process_measurement+0x4c4/0x6b8)
[<c03f059c>] (process_measurement) from [<c03f0cdc>] (ima_file_check+0x88/0xa4)
[<c03f0c54>] (ima_file_check) from [<c02d8adc>] (path_openat+0x5d8/0x1364)
[<c02d8504>] (path_openat) from [<c02dad24>] (do_filp_open+0x84/0xf0)
[<c02daca0>] (do_filp_open) from [<c02cf50c>] (do_open_execat+0x84/0x1b0)
[<c02cf488>] (do_open_execat) from [<c02d1058>] (__do_execve_file+0x43c/0x890)
[<c02d0c1c>] (__do_execve_file) from [<c02d1770>] (sys_execve+0x44/0x4c)
[<c02d172c>] (sys_execve) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
---[ end trace 3455789a10e3aefd ]---
The cause is that the struct ahash_request *req is created as a
stack-local variable up in the stack (presumably somewhere in the IMA
implementation), then passed down into the CAAM driver, which tries to
dma_single_map the req->result (indirectly via map_seq_out_ptr_result)
in order to make that buffer available for the CAAM to store the result
of the following hash operation.
The calling code doesn't know how req will be used by the CAAM driver,
and there could be other such occurrences where stack memory is passed
down to the CAAM driver. Therefore we should rather fix this issue in
the CAAM driver where the requirements are known."
Fix this problem by:
-instructing the crypto engine to write the final hash in state->caam_ctx
-subsequently memcpy-ing the final hash into req->result
Cc: <[email protected]> # v4.19+
Reported-by: Roland Hieber <[email protected]>
Signed-off-by: Horia Geantă <[email protected]>
Tested-by: Roland Hieber <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The header search path -I. in kernel Makefiles is very suspicious;
it allows the compiler to search for headers in the top of $(srctree),
where obviously no header file exists.
'git grep BCMDRIVER' has no hit. So, this macro is not referenced.
I was able to build this driver without the extra compiler options.
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Currently, the Kbuild core manipulates header search paths in a crazy
way [1].
To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consistent, and finally get rid of the gross hacks.
Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
("kbuild: do not drop -I without parameter").
[1]: https://patchwork.kernel.org/patch/9632347/
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The request unmap and bounce buffer copying is currently unnecessarily
done while holding the queue spin lock.
Signed-off-by: Lars Persson <[email protected]>
Signed-off-by: Vincent Whitchurch <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Avoid plain memcmp() on the AEAD tag value as this could leak
information through a timing side channel.
Signed-off-by: Lars Persson <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The implementation assumed that the client always wants the whole 16
byte AES-GCM tag. Now we respect the requested authentication tag size
fetched using crypto_aead_authsize().
Signed-off-by: Lars Persson <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The driver was optimized to only do cache maintenance for the last
word of the dma descriptor status array. Unfortunately an omission
also passed the last word as the address of the array start to the DMA
engine. In most cases this goes unnoticed since the hardware aligns
the address to a 64 byte boundary.
Signed-off-by: Lars Persson <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Clients may submit a new requests from the completion callback
context. The driver was not prepared to receive a request in this
state because it already held the request queue lock and a recursive
lock error is triggered.
Now all completions are queued up until we are ready to drop the queue
lock and then delivered.
The fault was triggered by TCP over an IPsec connection in the LTP
test suite:
LTP: starting tcp4_ipsec02 (tcp_ipsec.sh -p ah -m transport -s "100 1000 65535")
BUG: spinlock recursion on CPU#1, genload/943
lock: 0xbf3c3094, .magic: dead4ead, .owner: genload/943, .owner_cpu: 1
CPU: 1 PID: 943 Comm: genload Tainted: G O 4.9.62-axis5-devel #6
Hardware name: Axis ARTPEC-6 Platform
(unwind_backtrace) from [<8010d134>] (show_stack+0x18/0x1c)
(show_stack) from [<803a289c>] (dump_stack+0x84/0x98)
(dump_stack) from [<8016e164>] (do_raw_spin_lock+0x124/0x128)
(do_raw_spin_lock) from [<804de1a4>] (artpec6_crypto_submit+0x2c/0xa0)
(artpec6_crypto_submit) from [<804def38>] (artpec6_crypto_prepare_submit_hash+0xd0/0x54c)
(artpec6_crypto_prepare_submit_hash) from [<7f3165f0>] (ah_output+0x2a4/0x3dc [ah4])
(ah_output [ah4]) from [<805df9bc>] (xfrm_output_resume+0x178/0x4a4)
(xfrm_output_resume) from [<805d283c>] (xfrm4_output+0xac/0xbc)
(xfrm4_output) from [<80587928>] (ip_queue_xmit+0x140/0x3b4)
(ip_queue_xmit) from [<805a13b4>] (tcp_transmit_skb+0x4c4/0x95c)
(tcp_transmit_skb) from [<8059f218>] (tcp_rcv_state_process+0xdf4/0xdfc)
(tcp_rcv_state_process) from [<805a7530>] (tcp_v4_do_rcv+0x64/0x1ac)
(tcp_v4_do_rcv) from [<805a9724>] (tcp_v4_rcv+0xa34/0xb74)
(tcp_v4_rcv) from [<80581d34>] (ip_local_deliver_finish+0x78/0x2b0)
(ip_local_deliver_finish) from [<8058259c>] (ip_local_deliver+0xe4/0x104)
(ip_local_deliver) from [<805d23ec>] (xfrm4_transport_finish+0xf4/0x144)
(xfrm4_transport_finish) from [<805df564>] (xfrm_input+0x4f4/0x74c)
(xfrm_input) from [<804de420>] (artpec6_crypto_task+0x208/0x38c)
(artpec6_crypto_task) from [<801271b0>] (tasklet_action+0x60/0xec)
(tasklet_action) from [<801266d4>] (__do_softirq+0xcc/0x3a4)
(__do_softirq) from [<80126d20>] (irq_exit+0xf4/0x15c)
(irq_exit) from [<801741e8>] (__handle_domain_irq+0x68/0xbc)
(__handle_domain_irq) from [<801014f0>] (gic_handle_irq+0x50/0x94)
(gic_handle_irq) from [<80657370>] (__irq_usr+0x50/0x80)
Signed-off-by: Lars Persson <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The hardware cannot restore the context correctly when it operates in
SHA512 mode. This is too restrictive when operating in a framework that
can interleave multiple hash sessions.
Signed-off-by: Lars Persson <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The hardware implementation of SHA384 was not correct and it cannot
be used in any situation.
Signed-off-by: Lars Persson <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
When building without CONFIG_HW_RANDOM_PPC4XX, I hit the following build failure:
drivers/crypto/amcc/crypto4xx_core.c: In function 'crypto4xx_probe':
drivers/crypto/amcc/crypto4xx_core.c:1407:20: error: passing argument 1 of 'ppc4xx_trng_probe' from incompatible pointer type [-Werror=incompatible-pointer-types]
In file included from drivers/crypto/amcc/crypto4xx_core.c:50:0:
drivers/crypto/amcc/crypto4xx_trng.h:28:20: note: expected 'struct crypto4xx_device *' but argument is of type 'struct crypto4xx_core_device *'
drivers/crypto/amcc/crypto4xx_core.c: In function 'crypto4xx_remove':
drivers/crypto/amcc/crypto4xx_core.c:1434:21: error: passing argument 1 of 'ppc4xx_trng_remove' from incompatible pointer type [-Werror=incompatible-pointer-types]
In file included from drivers/crypto/amcc/crypto4xx_core.c:50:0:
drivers/crypto/amcc/crypto4xx_trng.h:30:20: note: expected 'struct crypto4xx_device *' but argument is of type 'struct crypto4xx_core_device *'
This patch fix the needed argument of ppc4xx_trng_probe()/ppc4xx_trng_remove() in that case.
Fixes: 5343e674f32f ("crypto4xx: integrate ppc4xx-rng into crypto4xx")
Signed-off-by: Corentin Labbe <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Fix a static code checker warning:
drivers/crypto/chelsio/chcr_algo.c:3681
chcr_aead_op() warn: passing zero to 'PTR_ERR'
Fixes: 2debd3325e55 ("crypto: chcr - Add AEAD algos.")
Signed-off-by: YueHaibing <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Signed-off-by: Roland Hieber <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: "Horia Geantă" <[email protected]>
Cc: Aymen Sghaier <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Horia Geantă <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Tom Lendacky <[email protected]>
Cc: Gary Hook <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Gary R Hook <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
functions
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Herbert Xu <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: Srikanth Jampala <[email protected]>
Cc: Yangtao Li <[email protected]>
Cc: Gadam Sreerama <[email protected]>
Cc: Eric Biggers <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Herbert Xu <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: Robert Richter <[email protected]>
Cc: Jan Glauber <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Jan Glauber <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Jesper Nilsson <[email protected]>
Cc: Lars Persson <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Lars Persson <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Yael Chemla <[email protected]>
Cc: Gilad Ben-Yossef <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Acked-By: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Giovanni Cabiddu <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: Conor McLoughlin <[email protected]>
Cc: Waiman Long <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|