Re: [PATCH 00/28] Reenable maybe-uninitialized warnings

On Tue, Oct 18, 2016 at 12:03:28AM +0200, Arnd Bergmann wrote: > This is a set of patches that I hope to get into v4.9 in some form > in order to turn on the -Wmaybe-uninitialized warnings again. Hi Arnd, I jsut complained to Geert that I was introducing way to many bugs or pointless warnings

[PATCH 28/28] Kbuild: bring back -Wmaybe-uninitialized warning

Traditionally, we have always had warnings about uninitialized variables enabled, as this is part of -Wall, and generally a good idea [1], but it also always produced false positives, mainly because this is a variation of the halting problem and provably impossible to get right in all cases [2].

[PATCH 15/28] crypto: aesni: avoid -Wmaybe-uninitialized warning

The rfc4106 encrypy/decrypt helper functions cause an annoying false-positive warning in allmodconfig if we turn on -Wmaybe-uninitialized warnings again: arch/x86/crypto/aesni-intel_glue.c: In function ‘helper_rfc4106_decrypt’: include/linux/scatterlist.h:67:31: warning: ‘dst_sg_walk.sg’ may be

[PATCH 00/28] Reenable maybe-uninitialized warnings

This is a set of patches that I hope to get into v4.9 in some form in order to turn on the -Wmaybe-uninitialized warnings again. After talking to Linus in person at Linaro Connect about this, I spent some time on finding all the remaining warnings, and this is the resulting patch series. More

Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

Am Montag, 17. Oktober 2016, 14:03:17 CEST schrieb Andy Lutomirski: Hi Andy, > On Mon, Oct 17, 2016 at 11:36 AM, Stephan Mueller wrote: > > Am Montag, 17. Oktober 2016, 10:30:13 CEST schrieb Andy Lutomirski: > > > > Hi Andy, > > > >> Sure, but shouldn't that be a

Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

On Mon, Oct 17, 2016 at 11:36 AM, Stephan Mueller wrote: > Am Montag, 17. Oktober 2016, 10:30:13 CEST schrieb Andy Lutomirski: > > Hi Andy, >> >> Sure, but shouldn't that be a separate patch covering the whole hw_crypto >> core? > > I think that you are right -- there are

Re: [PATCH] hwrng: meson: Fix module autoload for OF registration

Hello Fabio, On 10/17/2016 04:45 PM, Fabio Estevam wrote: > On Mon, Oct 17, 2016 at 5:40 PM, Javier Martinez Canillas > wrote: > >> --- a/drivers/char/tpm/Kconfig >> +++ b/drivers/char/tpm/Kconfig >> @@ -32,7 +32,7 @@ config TCG_TIS_CORE >> >> config TCG_TIS >>

Re: [PATCH] hwrng: meson: Fix module autoload for OF registration

On Mon, Oct 17, 2016 at 04:40:14PM -0300, Javier Martinez Canillas wrote: > Signed-off-by: Javier Martinez Canillas > > drivers/char/hw_random/meson-rng.c | 1 + > drivers/char/tpm/Kconfig | 2 +- Looks like this patch should not have tpm in it. Jason -- To

Re: [PATCH] hwrng: meson: Fix module autoload for OF registration

On Mon, Oct 17, 2016 at 5:40 PM, Javier Martinez Canillas wrote: > --- a/drivers/char/tpm/Kconfig > +++ b/drivers/char/tpm/Kconfig > @@ -32,7 +32,7 @@ config TCG_TIS_CORE > > config TCG_TIS > tristate "TPM Interface Specification 1.2 Interface / TPM 2.0 FIFO >

[PATCH v2] hwrng: meson: Fix module autoload for OF registration

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

Re: [PATCH] hwrng: meson: Fix module autoload for OF registration

Hello Jason, On 10/17/2016 04:45 PM, Jason Gunthorpe wrote: > On Mon, Oct 17, 2016 at 04:40:14PM -0300, Javier Martinez Canillas wrote: > >> Signed-off-by: Javier Martinez Canillas >> >> drivers/char/hw_random/meson-rng.c | 1 + >> drivers/char/tpm/Kconfig | 2

[PATCH] hwrng: meson: Fix module autoload for OF registration

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

Am Montag, 17. Oktober 2016, 10:30:13 CEST schrieb Andy Lutomirski: Hi Andy, > > Sure, but shouldn't that be a separate patch covering the whole hw_crypto > core? I think that you are right -- there are many more cases where a memset(0) is warranted. Do you want to make this change or should

Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

On Mon, Oct 17, 2016 at 10:17 AM, Stephan Mueller wrote: > Am Montag, 17. Oktober 2016, 10:06:27 CEST schrieb Andy Lutomirski: > > Hi Andy, > >> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c >> index 9203f2d130c0..340f96e44642 100644 >> ---

Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

Am Montag, 17. Oktober 2016, 10:06:27 CEST schrieb Andy Lutomirski: Hi Andy, > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c > index 9203f2d130c0..340f96e44642 100644 > --- a/drivers/char/hw_random/core.c > +++ b/drivers/char/hw_random/core.c > @@ -84,14 +84,14 @@

[PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

hw_random carefully avoids using a stack buffer except in add_early_randomness(). This causes a crash in virtio_rng if CONFIG_VMAP_STACK=y. Reported-by: Matt Mullins Tested-by: Matt Mullins Fixes: d3cc7996473a ("hwrng: fetch randomness only after device

[PATCH -next] crypto: ccp - Fix non static symbol warning

From: Wei Yongjun Fixes the following sparse warning: drivers/crypto/ccp/ccp-dev.c:44:6: warning: symbol 'ccp_error_codes' was not declared. Should it be static? Signed-off-by: Wei Yongjun --- drivers/crypto/ccp/ccp-dev.c | 2 +- 1 file

[PATCH -next] crypto: gcm - Fix error return code in crypto_gcm_create_common()

From: Wei Yongjun Fix to return error code -EINVAL from the invalid alg ivsize error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun --- crypto/gcm.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH 4/7] crypto: doc - fix separation of cipher / req API

On Mon, 17 Oct 2016, Stephan Mueller wrote: > Am Montag, 17. Oktober 2016, 14:04:14 CEST schrieb Jani Nikula: > > Hi Jani, > >> The directive parameter is plural functions for a reason - you can >> specify multiple functions in the same directive. Splitting this to >>

Re: [PATCH 4/7] crypto: doc - fix separation of cipher / req API

Am Montag, 17. Oktober 2016, 14:04:14 CEST schrieb Jani Nikula: Hi Jani, > The directive parameter is plural functions for a reason - you can > specify multiple functions in the same directive. Splitting this to > multiple directives causes the header file to be parsed again for each >

[RESEND][PATCH] crypto: caam: add support for iMX6UL

i.MX6UL does only require three clocks to enable CAAM module. Signed-off-by: Marcus Folkesson Acked-by: Rob Herring Reviewed-by: Horia Geantă --- .../devicetree/bindings/crypto/fsl-sec4.txt| 20 +

Re: [PATCH 4/7] crypto: doc - fix separation of cipher / req API

On Sun, 16 Oct 2016, Stephan Mueller wrote: > Keep the cipher API and the request API function documentation in > separate sections. > > Signed-off-by: Stephan Mueller > --- > Documentation/crypto/api-akcipher.rst | 25 + > 1

[PATCH] padata: Remove unused but set variables

Remove the unused but set variable pinst in padata_parallel_worker to fix the following warning when building with 'W=1': kernel/padata.c: In function ‘padata_parallel_worker’: kernel/padata.c:68:26: warning: variable ‘pinst’ set but not used [-Wunused-but-set-variable] Also remove the now