On 1/22/19 4:14 PM, Greg Kroah-Hartman wrote:
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
Cc: Lars Persson
Cc: Herbert Xu
Cc: "David S
On Tue, Jan 22, 2019 at 10:06:54PM +, Gary R Hook wrote:
> On 1/22/19 9:14 AM, Greg Kroah-Hartman wrote:
> > 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 th
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
---
drivers/crypto/chelsio/chcr_algo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletion
On 1/22/19 9:14 AM, Greg Kroah-Hartman wrote:
> 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.
Stupid question(s) time.
If we don't care about failures (becau
From: Atul Gupta
Date: Thu, 17 Jan 2019 20:55:53 -0800
> build protos is required for tls_hw_prot also hence moved to
> 'tls_build_proto' and called as required from tls_init
> and tls_hw_proto. This is required since build_protos
> for v4 is moved from tls_register to tls_init in
> commit <28cb6
From: Atul Gupta
Date: Thu, 17 Jan 2019 20:56:39 -0800
> Enable Inline TLS record by default
>
> Signed-off-by: Atul Gupta
Applied.
From: Atul Gupta
Date: Thu, 17 Jan 2019 20:56:21 -0800
> free tls context in sock destruct. close may not be the last
> call to free sock but force releasing the ctx in close
> will result in GPF when ctx referred again in tcp_done
>
> [ 515.330477] general protection fault: [#1] SMP PTI
>
On 2019-01-22 5:40 a.m., Greg Kroah-Hartman wrote:
> On Wed, Jan 16, 2019 at 11:25:17AM -0700, Logan Gunthorpe wrote:
>> This is resend number 6 since the last change to this series.
>>
>> This cleanup was requested by Greg KH back in June of 2017. I've resent the
>> series
>> a couple times a
On 1/22/2019 5:14 PM, Greg Kroah-Hartman wrote:
> 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ă"
> Cc: Aymen Sghaier
> Cc: Herbert Xu
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
Add slimSSS node to DT and crypto AES support for Exynos5433. Tested on
Exynos5433 board with crypto run-time self tests and with tcrypt with
command insmod tcrypt.ko mode=500 sec=1
Kamil Konieczny (3):
arm64: dts: exynos: add SlimSSS for Exynos5433
dt-bindings: crypto: document Exynos5433 Sli
Signed-off-by: Roland Hieber
---
drivers/crypto/caam/caamhash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index bb1a2cdf19512..b65e2e54c5625 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/c
Document DT bindings for crypto Samsung Exynos5433 SlimSSS (Slim Security
SubSystem) IP.
Signed-off-by: Kamil Konieczny
---
.../devicetree/bindings/crypto/samsung-sss.txt | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/cry
Add AES crypto HW acceleration for Exynos5433, with the help of SlimSSS IP.
Signed-off-by: Kamil Konieczny
---
drivers/crypto/s5p-sss.c | 50
1 file changed, 46 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.
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
Cc: "David S. Miller"
Cc: Srikanth Jampala
Cc: Yangtao Li
Cc: Gadam Sreerama
Cc: Eric Biggers
C
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
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Conor McLoughlin
Cc: Waiman Long
Cc: qat-li...@in
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
Cc: Gilad Ben-Yossef
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-crypto@vger.kernel.org
Signe
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
Cc: Lars Persson
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-arm-ker...@axis.com
Cc: linux
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ă"
Cc: Aymen Sghaier
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-crypto@vger.kernel.org
Signe
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
Cc: "David S. Miller"
Cc: Robert Richter
Cc: Jan Glauber
Cc: linux-crypto@vger.kernel.org
Signed-
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
Cc: Gary Hook
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-crypto@vger.kernel.org
Signed-off-
When calling debugfs code, there is no need to ever check the return
value of the call, as no logic should ever change if a call works
properly or not. Fix up a bunch of crypto-specific code to not care
about the results of debugfs.
Greg Kroah-Hartman (7):
crypto: qat: no need to check return v
Recent AEAD changes in testmgr framework introduced by commit
a0d608ee5ebf ("crypto: testmgr - unify the AEAD encryption and decryption test
vectors")
uncovered an error in the CAAM drivers, since they don't correctly
handle the case when AEAD output length is zero.
Add checks to avoid feeding ze
On Mon, 21 Jan 2019 at 20:58, Bhupesh Sharma wrote:
>
> Hi Sumit,
>
> On Mon, Jan 21, 2019 at 3:00 PM Sumit Garg wrote:
> >
> > Introduce a generic TEE bus driver concept for TEE based kernel drivers
> > which would like to communicate with TEE based devices/services.
> >
> > In this TEE bus conc
On Wed, Jan 16, 2019 at 11:25:17AM -0700, Logan Gunthorpe wrote:
> This is resend number 6 since the last change to this series.
>
> This cleanup was requested by Greg KH back in June of 2017. I've resent the
> series
> a couple times a cycle since then, updating and fixing as feedback was slowly
25 matches
Mail list logo
