On 02/16/2018 10:16 AM, Kamil Konieczny wrote:
>
> On 15.02.2018 19:32, Marek Vasut wrote:
>> On 02/15/2018 07:06 PM, Kamil Konieczny wrote:
>>>
>>>
>>> On 15.02.2018 18:06, Marek Vasut wrote:
>>>> On 02/15/2018 06:00 PM, Kamil Konieczny wrote:
On 02/15/2018 07:06 PM, Kamil Konieczny wrote:
>
>
> On 15.02.2018 18:06, Marek Vasut wrote:
>> On 02/15/2018 06:00 PM, Kamil Konieczny wrote:
>>>
>>>
>>> On 15.02.2018 17:27, Marek Vasut wrote:
>>>> On 02/15/2018 04:41 PM, Herbert Xu wrote:
On 02/15/2018 06:00 PM, Kamil Konieczny wrote:
>
>
> On 15.02.2018 17:27, Marek Vasut wrote:
>> On 02/15/2018 04:41 PM, Herbert Xu wrote:
>>> On Thu, Jan 18, 2018 at 07:33:59PM +0100, Kamil Konieczny wrote:
>>>> First four patches add empty hash export and i
Moving the checks out of
core seems like the wrong thing to do, rather you should enhance the
checks in core if they're insufficient in my opinion.
--
Best regards,
Marek Vasut
On 01/19/2018 10:53 AM, Kamil Konieczny wrote:
> On 18.01.2018 22:31, Marek Vasut wrote:
>> On 01/18/2018 07:34 PM, Kamil Konieczny wrote:
>>> Export and import are mandatory in async hash. As drivers were
>>> rewritten, drop empty wrappers and correct init of ahash tr
h->digest = alg->digest;
> + hash->export = alg->export;
> + hash->import = alg->import;
>
> if (alg->setkey) {
> hash->setkey = alg->setkey;
> hash->has_setkey = true;
> }
> - if (alg->export)
> - hash->export = alg->export;
> - if (alg->import)
> - hash->import = alg->import;
>
> return 0;
> }
>
--
Best regards,
Marek Vasut
static struct ahash_alg dcp_sha256_alg = {
> .final = dcp_sha_final,
> .finup = dcp_sha_finup,
> .digest = dcp_sha_digest,
> + .import = dcp_sha_noimport,
> + .export = dcp_sha_noexport,
> .halg = {
> .digestsize = SHA256_DIGEST_SIZE,
> .base = {
>
--
Best regards,
Marek Vasut
e tell me is
> there any document/example project/link which I can refer.
Yes, see the link I posted in my previous email. Moreover, you can look
into the drivers in the Linux kernel and inspire yourself there.
> Thanks and regards,
> Sagar
>
>
>
> On Thu, Jun 22, 2017 a
;
> Regards,
> Sagar
--
Best regards,
Marek Vasut
it "solves" the problem, but it cripples the driver and removes
useful functionality.
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
."
This comment looks real unhelpful. I'd really appreciate a bit more
detail on how to fix it.
> [1] http://www.spinics.net/lists/linux-crypto/msg18187.html
>
> So remove the hash support for now.
>
> Signed-off-by: Fabio Estevam
> ---
> Changes since v1:
> - Fix t
56_DIGEST_SIZE,
> + .statesize = sizeof(struct sha256_state),
> .base = {
> .cra_name = "sha256",
> .cra_driver_name= "sha256-dcp",
>
>
> Will submit it as a formal pat
s have it.
>
> Signed-off-by: Arnd Bergmann
> Fixes: a2712e6c75f ("crypto: mxs-dcp - Allow MXS_DCP to be used on MX6SL")
Acked-by: Marek Vasut
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index ab7e3b668890..2569e043317e 100644
> --- a/drivers/c
on is that "openssl speed" is
> utterly crap - you don't actually know what's being tested there. Some
> things test the engine, others bypass the engine infrastructure totally
> and test the openssl software implementation instead.
>
> So, if you think "open
On Monday, June 08, 2015 at 06:52:00 AM, Herbert Xu wrote:
> On Fri, Jun 05, 2015 at 04:38:03PM +0200, Marek Vasut wrote:
> > In general, it would probably make sense to add a flag to .setkey() to
> > store the key in a keyslot. The keyslot allocation would be up to the
> >
On Friday, June 05, 2015 at 05:54:33 AM, Herbert Xu wrote:
> On Thu, Jun 04, 2015 at 05:34:39PM +0200, Marek Vasut wrote:
> > Is this really a valid way to go about crypto -- introduce all kinds
> > of obscure nuances into the API which are driver specific at best ?
>
> S
using setkey with a length other
> than that of a valid AES key. For example, you could use a one-
> byte value to select the key slot.
Is this really a valid way to go about crypto -- introduce all kinds
of obscure nuances into the API which are driver specific at best ?
Best regards,
Marek V
On Monday, June 01, 2015 at 04:50:15 PM, Herbert Xu wrote:
> On Mon, Jun 01, 2015 at 03:24:03PM +0200, Marek Vasut wrote:
> > On Friday, May 29, 2015 at 03:30:18 PM, Herbert Xu wrote:
> > > On Fri, May 29, 2015 at 03:02:59PM +0200, Marek Vasut wrote:
> > > > This
On Friday, May 29, 2015 at 03:30:18 PM, Herbert Xu wrote:
> On Fri, May 29, 2015 at 03:02:59PM +0200, Marek Vasut wrote:
> > This does look somewhat hacky to me. Wouldn't it make more sense to
> > add a CRYPTO_TFM_REQ flag ?
>
> What are you going to do when you hav
On Friday, May 29, 2015 at 03:32:11 AM, Herbert Xu wrote:
> On Fri, May 29, 2015 at 03:29:59AM +0200, Marek Vasut wrote:
> > On Friday, May 29, 2015 at 03:23:59 AM, Herbert Xu wrote:
> > > On Fri, May 29, 2015 at 03:00:35AM +0200, Marek Vasut wrote:
> > > > My unde
On Friday, May 29, 2015 at 03:23:59 AM, Herbert Xu wrote:
> On Fri, May 29, 2015 at 03:00:35AM +0200, Marek Vasut wrote:
> > My understanding (!) is that everyone should be able to use this key to
> > encrypt/decrypt their data using the AES128 engine in the DCP.
>
> If that
On Friday, May 29, 2015 at 02:45:16 AM, Herbert Xu wrote:
> On Fri, May 29, 2015 at 02:40:54AM +0200, Marek Vasut wrote:
> > On Friday, May 29, 2015 at 02:37:00 AM, Herbert Xu wrote:
> > > On Thu, May 28, 2015 at 11:01:56AM -0500, Jay Monkman wrote:
> > > > Ma
is to modify the driver so that if setkey is
> > passed a key with a length of 1 byte, the driver uses the on chip
> > key. I'm not sure if that would make it into the official kernel.
>
> What is this key and who is supposed to have access to it?
It's an AES128 key st
this in your code:
crypto_ablkcipher_set_flags(tfm, CRYPTO_TFM_REQ_CPU_KEY);
I _think_ this might be the way to go. Do a git grep on CRYPTO_TFM_REQ to
get some usecases on the TFM flags.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto&q
_code_status, "Condition Code" },
> };
> u32 ssrc = status >> JRSTA_SSRC_SHIFT;
> - const char *error = status_src[ssrc].error;
> + const char *error;
> +
> + if (ssrc >= ARRAY_SIZE(status_src)) {
> + dev_err(jrdev, "unkn
On Friday, October 31, 2014 at 08:23:53 AM, Herbert Xu wrote:
> On Fri, Oct 31, 2014 at 04:01:04AM +0100, Marek Vasut wrote:
> > I can share the last state of the document I wrote. Currently,
> > it is not possible for me to keep up with my workload and do
> > anything else, s
> Signed-off-by: Stephan Mueller
>
> Thanks for the patch Stephan!
>
> Marek Vasut has also been working on a set of
> documentation for the crypto API so he might have some comments
> on this.
Sorry for the late reply, thanks for keeping me in the loop.
I can share the
On Wednesday, July 23, 2014 at 08:52:12 PM, Corentin LABBE wrote:
> Le 23/07/2014 17:51, Marek Vasut a écrit :
> > On Wednesday, July 23, 2014 at 04:13:09 PM, Herbert Xu wrote:
> >> On Wed, Jul 23, 2014 at 04:07:20PM +0200, Marek Vasut wrote:
> >>> On Wednesday
On Wednesday, July 23, 2014 at 04:13:09 PM, Herbert Xu wrote:
> On Wed, Jul 23, 2014 at 04:07:20PM +0200, Marek Vasut wrote:
> > On Wednesday, July 23, 2014 at 03:57:35 PM, Herbert Xu wrote:
> > > On Sat, May 24, 2014 at 02:00:03PM +0200, Marek Vasut wrote:
> > > &g
On Wednesday, July 23, 2014 at 03:57:35 PM, Herbert Xu wrote:
> On Sat, May 24, 2014 at 02:00:03PM +0200, Marek Vasut wrote:
> > > + }
> > > +#endif
> > > +
> > > +#ifdef CONFIG_CRYPTO_DEV_SUNXI_SS_MD5
> > > + err = crypto_register_shash(&sunxi
> stops working mid-flight, will IMA also go bonkers or is there some
> > graceful stop?
>
> shash fallback will be used.
Ah, thank you for clearing this!
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday, July 09, 2014 at 11:21:08 PM, Joe Perches wrote:
> On Wed, 2014-07-09 at 22:39 +0200, Marek Vasut wrote:
> > The above function looks like almost verbatim copy of print_hex_dump().
> > The only difference I can spot is that it's calling seq_printf() instead
>
On Thursday, July 10, 2014 at 01:05:39 AM, Dmitry Kasatkin wrote:
> On 10 July 2014 00:00, Marek Vasut wrote:
> > On Tuesday, July 08, 2014 at 10:07:16 AM, Dmitry Kasatkin wrote:
> > [...]
> >
> >> > Right, but my concern is not about unloading the kernel module
On Wednesday, July 09, 2014 at 05:24:26 PM, Andy Shevchenko wrote:
> The new seq_hex_dump() is a complete analogue of print_hex_dump().
>
> We have few users of this functionality already. It allows to reduce their
> codebase.
>
> Signed-off-by: Andy Shevchenko
> ---
> fs/seq_file.c
the USB cable out. Will this be able to cope with such situation, for
example by switching to software operations or such in some sane way ?
I presume that's the concern here.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
t
_drv_private_jr),
> > + jrpriv = devm_kzalloc(jrdev, sizeof(struct caam_drv_private_jr),
> >
> > GFP_KERNEL);
>
> alignment. Also, why are we replacing a _m_alloc with a _z_alloc?
I am fine with replacing kmalloc with kzalloc in this context.
Best
> > SEC is backward compatible with older versions, so this patch adds those
> > missing versions in c29x device tree.
> >
> > Signed-off-by: Nitesh Narayan Lal
> > Signed-off-by: Vakul Garg
>
> Patch applied.
Are you sure DT changes go through linux-crypto
4 #undef xor_speed
> >
> > Why do we not call do_xor_speed(fastest, b1, b2); right away , but we
> > #define xor_speed() instead ? This looks like some remnant or nonsense
> > to me. Shall I remove that with a patch ?
>
> You are right.
I'm wrong. The XOR_TRY_TEM
On Sunday, June 22, 2014 at 02:33:35 PM, Russell King - ARM Linux wrote:
> On Sun, Jun 22, 2014 at 02:23:15PM +0200, Marek Vasut wrote:
> > On Sunday, June 22, 2014 at 01:58:08 PM, Corentin LABBE wrote:
> > [...]
> >
> > > >> + * This program is free soft
On Sunday, June 22, 2014 at 01:58:38 PM, Corentin LABBE wrote:
> Le 14/06/2014 21:01, Marek Vasut a écrit :
> > On Tuesday, June 10, 2014 at 02:43:15 PM, LABBE Corentin wrote:
> >> Add necessary changes for configuring and compiling the Security System
> >> driver.
>
-- dear list, shall one use sg_page()+kmap or sg_virt()?
btw. I just noticed you're just feeding the hardware FIFO in a loop with data
in
the scatterlists, do I understand it correctly ? The driver will consume quite
a
lot of CPU time to do that, can you not implement DMA here ?
[...]
Bes
On Tuesday, June 10, 2014 at 02:43:14 PM, LABBE Corentin wrote:
> Add support for the Security System included in Allwinner SoC A20.
> The Security System is a hardware cryptographic accelerator that support
> AES/MD5/SHA1/DES/3DES/PRNG algorithms.
>
> Signed-off-by: LABBE Corentin
[...]
> diff
ivers/crypto/Makefile
> | 1 +
> 2 files changed, 92 insertions(+)
This should be part of 1/4, otherwise 1/4 just adds dead code.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.ke
ONT_SHIFT)
> -#define FIFOST_CONT_MASK (1 << FIFOST_CONT_SHIFT)
>
> /*
> * Extended Length - use 32-bit extended length that
Sigh, I'm surprised the compiler didn't choke about this.
Acked-by: Marek Vasut
Best regards,
Marek Vasut
--
To unsubscribe from this list: se
On Saturday, June 07, 2014 at 03:33:34 AM, Anton Blanchard wrote:
> The NX driver has endian issues so disable it for now.
>
> Signed-off-by: Anton Blanchard
What kind of issues ? Are they hard to fix ?
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line &qu
using function: %s (%d.%03d MB/sec)\n",
152fastest->name, fastest->speed / 1000, fastest->speed % 1000);
153
154 #undef xor_speed
Why do we not call do_xor_speed(fastest, b1, b2); right away , but we #define
xor_speed() instead ? This looks like some remnant or no
Coccinelle semantic patch was used for making the change:
Reviewed-by: Marek Vasut
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
;
> return 0;
I suppose this part of the patch was not intentional ;-)
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday, May 28, 2014 at 12:01:09 PM, Corentin LABBE wrote:
> Hello
>
> I have a problem when using a simple md5 tfm.
> When I use the data that ahash_request_ctx() give me, it will cause random
> crash when removing the module later. I do not understand it, because
> .cra_ctxsize seems to be
Use skcipher_givcrypt_cast(crypto_dequeue_request(queue)) instead, which
does the same thing in much cleaner way. The skcipher_givcrypt_cast()
actually uses container_of() instead of messing around with offsetof()
too.
Signed-off-by: Marek Vasut
Reported-by: Arnd Bergmann
Cc: Herbert Xu
Cc
ork in case the ->backlog == ->list , since in that case we
will basically complete the currently dequeued request. Will this also work in
case ->backlog != ->list (that is, in case the qlen overflew max_qlen)? I'm not
sure.
Can you please help me understand this ?
Than
ll
they
just try calling crypto_enqueue_request() again to see if it still returns -
EBUSY ?
Sorry if this is an obvious question and thanks for the help!
[1] http://permalink.gmane.org/gmane.linux.kernel.cryptoapi/735
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line &q
It makes no sense for crypto_yield() to be defined in scatterwalk.h ,
move it into algapi.h as it's an internal function to crypto API.
Signed-off-by: Marek Vasut
Cc: Herbert Xu
---
include/crypto/algapi.h | 6 ++
include/crypto/scatterwalk.h | 6 --
2 files changed, 6 inser
On Sunday, May 25, 2014 at 01:58:39 PM, Corentin LABBE wrote:
[...]
> > This is one IP block and it provides 5 algorithms. Put it under one
> > config option please.
>
> I want to let the user choose what it want to be used. Someone could want
> only to accelerate md5 and to not use the PRNG. Lo
ctly comparing two datasheets...).
Better get the DT stuff correctly right from the start. That's why I'm asking
what chips contains the IP block, so we can guess the right name.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday, May 24, 2014 at 09:20:03 PM, Tomasz Figa wrote:
> Hi Marek,
>
> On 24.05.2014 13:21, Marek Vasut wrote:
> > On Thursday, May 22, 2014 at 05:09:54 PM, LABBE Corentin wrote:
> >
> > Missing commit message. Please fix this and send a V2.
> >
&
can I add a sunxi-ss directory in drivers/crypto ?
>
> Yes, I think a subdirectory would be best.
Full ACK on this one. Use drivers/crypto/sunxi-ss/ .
[...]
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
see the driver not using such ad-hoc stuff at all. Instead, it
should
just implement the r-m-w itself.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
; +- clock-names : Name of the functional clock, should be "ahb" and "mod".
> +
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I'm not applying this.
I suppose changing the commit message to "align the code with sha256 ... NOTE:
this also fixed CIDxyz." would work better and might get this applied ? I think
unification of code is always good.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday, May 22, 2014 at 05:09:56 PM, LABBE Corentin wrote:
Do I have to repeat myself ? :)
> Signed-off-by: LABBE Corentin
> ---
> drivers/crypto/Kconfig| 49 ++
> drivers/crypto/Makefile |1 +
> drivers/crypto/sunxi-ss.c | 1476
> + 3
s_clk>;
> + clock-names = "ahb", "mod";
> + };
> +
> spi2: spi@01c17000 {
> compatible = "allwinner,sun4i-a10-spi";
> reg = <0x01c17000 0x1000>;
Best regards
enabling the swapping option .
>
> depends on the definition of 'treat': I'd rather still use the
> superior 64-bit accessors on all possible arches, if we can get them
> to work.
Was there any resolution for this problem ?
Best regards,
Marek Vasut
--
To unsubscr
34 +0200 @@ -22,7 +22,6 @@ config
> ASYMMETRIC_PUBLIC_KEY_SUBTYPE
>
> config PUBLIC_KEY_ALGO_RSA
> tristate "RSA public-key algorithm"
> - select MPILIB_EXTRA
> select MPILIB
> help
> This option enables support for the RSA algorithm (PKCS
The checking for the type of algorithm implementation is pretty
strange here. Use regular flags to check for the type instead.
Signed-off-by: Marek Vasut
Cc: Bill Pemberton
Cc: Herbert Xu
Cc: Kent Yoder
Cc: Jamie Iles
Cc: Phil Sutter
---
drivers/crypto/mv_cesa.c | 4 ++--
1 file changed, 2
Signed-off-by: Marek Vasut
---
drivers/crypto/padlock-sha.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
NOTE: I didn't compile-test those, but the change should not break anything.
If possible, please test on relevant hardware.
diff --git a/drivers/crypto/padlock-sh
Signed-off-by: Marek Vasut
---
drivers/crypto/ccp/ccp-crypto-aes-xts.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
NOTE: I didn't compile-test those, but the change should not break anything.
If possible, please test on relevant hardware.
diff --git a/drivers/crypto/cc
Signed-off-by: Marek Vasut
---
drivers/crypto/mxs-dcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
NOTE: I didn't compile-test those, but the change should not break anything.
If possible, please test on relevant hardware.
diff --git a/drivers/crypto/mxs-dcp.c b/drivers/c
Signed-off-by: Marek Vasut
---
drivers/crypto/n2_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
NOTE: I didn't compile-test those, but the change should not break anything.
If possible, please test on relevant hardware.
diff --git a/drivers/crypto/n2_core.c b/dr
Signed-off-by: Marek Vasut
---
drivers/crypto/sahara.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
NOTE: I didn't compile-test those, but the change should not break anything.
If possible, please test on relevant hardware.
diff --git a/drivers/crypto/sahara.c b/drivers/c
Use a standard accessor instead of directly digging into a structure.
Signed-off-by: Marek Vasut
---
drivers/crypto/geode-aes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
NOTE: I didn't compile-test those, but the change should not break anything.
If possible, please
Signed-off-by: Marek Vasut
---
drivers/crypto/mv_cesa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
NOTE: I didn't compile-test those, but the change should not break anything.
If possible, please test on relevant hardware.
diff --git a/drivers/crypto/mv_cesa.c b/drivers/c
Signed-off-by: Marek Vasut
Cc: Benjamin Herrenschmidt
Cc: Dmitry Kasatkin
Cc: Eric Bénard
Cc: Jussi Kivilinna
Cc: Kent Yoder
Cc: Michal Ludvig
Cc: Varun Wadekar
Cc: Vladimir Zapolskiy
Cc: linux-ge...@lists.infradead.org
---
drivers/crypto/geode-aes.c | 4 ++--
1 file changed, 2
Consistently use AES_KEYSIZE_128 instead of arbitrary defined value.
Signed-off-by: Marek Vasut
Cc: Benjamin Herrenschmidt
Cc: Dmitry Kasatkin
Cc: Eric Bénard
Cc: Jussi Kivilinna
Cc: Kent Yoder
Cc: Michal Ludvig
Cc: Varun Wadekar
Cc: Vladimir Zapolskiy
Cc: linux-ge...@lists.infradead.org
This is actually defined in include/crypto/aes.h , no need to have
a a different symbol for the same thing twice.
Signed-off-by: Marek Vasut
Cc: Benjamin Herrenschmidt
Cc: Dmitry Kasatkin
Cc: Eric Bénard
Cc: Jussi Kivilinna
Cc: Kent Yoder
Cc: Michal Ludvig
Cc: Varun Wadekar
Cc: Vladimir
The AES IV length is always 128bits, just use the define from aes.h
Signed-off-by: Marek Vasut
Cc: Benjamin Herrenschmidt
Cc: Dmitry Kasatkin
Cc: Eric Bénard
Cc: Jussi Kivilinna
Cc: Kent Yoder
Cc: Michal Ludvig
Cc: Varun Wadekar
Cc: Vladimir Zapolskiy
Cc: linux-ge...@lists.infradead.org
cp.c | 47
> --- 1 file changed, 16
> insertions(+), 31 deletions(-)
You can also eliminate the DECLARE_MUTEX() for global_mutex now.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto&qu
On Thursday, May 08, 2014 at 04:01:06 PM, Herbert Xu wrote:
> On Thu, Apr 24, 2014 at 08:05:11PM +0200, Marek Vasut wrote:
> > First stab at reworking the error.c thing in Freescale CAAM.
> > This patchset cleans it up so it's not doing any too insane
> > string messing a
On Wednesday, April 30, 2014 at 09:23:40 PM, Matthias-Christian Ott wrote:
> On 04/28/14 23:37, Marek Vasut wrote:
> > On Friday, April 25, 2014 at 12:51:06 AM, Matthias-Christian Ott wrote:
> >> CRYPTO_USER requires CAP_NET_ADMIN for all operations. Most informatio
On Monday, April 28, 2014 at 11:53:23 PM, Herbert Xu wrote:
> On Mon, Apr 28, 2014 at 09:28:41PM +0200, Marek Vasut wrote:
> > On Monday, April 28, 2014 at 12:24:41 PM, Herbert Xu wrote:
> > > On Fri, Apr 18, 2014 at 01:01:42PM +0300, Horia Geanta wrote:
> > > > GFP_
please submit the patch using git send-email so we can properly review
it?
Thank you !
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
;& CRYPTO_SKEIN) selects
> CRYPTO_HASH which has unmet direct dependencies (CRYPTO)
>
> Fix this in the Kconfig by depending on CRYPTO.
>
> Reported-by: Fengguang Wu
> Signed-off-by: Jason Cooper
Reviewed-by: Marek Vasut
Best regards,
Marek Vasut
--
To unsubscribe from this lis
ting fixes
which actually fixes this SPRINTFCAT() horror properly please ?
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This macro is just like an encyclopedia of string handling done wrong.
This must die. This is so wrong on so many levels.
Signed-off-by: Marek Vasut
Cc: Herbert Xu
Cc: Horia Geanta
---
drivers/crypto/caam/error.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/crypto
Fix the checkpatch warnings that the strings were split across
multiple lines. Checkpatch now complains about lines over 80,
but this is better, since we can actually grep the source code
for these strings now.
Signed-off-by: Marek Vasut
Cc: Herbert Xu
Cc: Horia Geanta
---
drivers/crypto/caam
t in a subsequent patch to keep the changes
small and separate.
Signed-off-by: Marek Vasut
Cc: Herbert Xu
Cc: Horia Geanta
---
drivers/crypto/caam/error.c | 290 ++--
1 file changed, 147 insertions(+), 143 deletions(-)
diff --git a/drivers/crypt
Clean this function up and rework it into sensible shape. This function
now contains one single dev_err() instead of the previous insanity full
of memory allocation, possible stack overwriting, chaotic string handling
and use of SPRINTFCAT().
Signed-off-by: Marek Vasut
Cc: Herbert Xu
Cc: Horia
on this one as well.
Signed-off-by: Marek Vasut
Cc: Herbert Xu
Cc: Horia Geanta
---
drivers/crypto/caam/error.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/caam/error.c b/drivers/crypto/caam/error.c
index 3d7be4c..961331d 100644
--- a
The tentacles of this function were firmly attached to various
places in the CAAM code. Just cut them, or this cthulhu function
will sprout them anew.
Signed-off-by: Marek Vasut
Cc: Herbert Xu
Cc: Horia Geanta
---
drivers/crypto/caam/caamalg.c | 28
drivers
, report_ccb_status() and report_deco_status()
ugly and unhappy.
Signed-off-by: Marek Vasut
Cc: Herbert Xu
Cc: Horia Geanta
---
drivers/crypto/caam/error.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/caam/error.c b/drivers/crypto/caam
Clean up the remnants from the rework. Constify function arguments.
Note that checkpatch again complains about this space before newline,
but this is the original code behavior, so I'm keeping it.
Signed-off-by: Marek Vasut
Cc: Herbert Xu
Cc: Horia Geanta
---
drivers/crypto/caam/error.c
First stab at reworking the error.c thing in Freescale CAAM.
This patchset cleans it up so it's not doing any too insane
string messing anymore.
NOTE: Can someone please test this on real hardware? I have
none at hand, so THIS IS COMPILE-TESTED ONLY!
Marek Vasut (11):
crypto:
: Marek Vasut
Cc: Herbert Xu
Cc: Horia Geanta
---
drivers/crypto/caam/error.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/caam/error.c b/drivers/crypto/caam/error.c
index 961331d..7ce1d03 100644
--- a/drivers/crypto/caam
Clean this function up and rework it into sensible shape. This function
now contains one single dev_err() instead of the previous insanity full
of memory allocation, chaotic string handling and use of SPRINTFCAT().
Signed-off-by: Marek Vasut
Cc: Herbert Xu
Cc: Horia Geanta
---
drivers/crypto
Just dissolve this function so it's not in the way of applying
further white magic cleanup down the line.
Signed-off-by: Marek Vasut
Cc: Herbert Xu
Cc: Horia Geanta
---
drivers/crypto/caam/error.c | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
On Wednesday, April 23, 2014 at 07:43:35 PM, Christian Engelmayer wrote:
> On Wed, 23 Apr 2014 01:33:05 +0200, Marek Vasut wrote:
> > On Monday, April 21, 2014 at 08:45:59 PM, Christian Engelmayer wrote:
> > > + if (aad_size >= PAGE_SIZE) {
> >
> > On an unre
On Wednesday, April 23, 2014 at 07:12:19 PM, Marek Vasut wrote:
> On Wednesday, April 23, 2014 at 06:35:45 PM, Horia Geantă wrote:
>
> [...]
>
> > > This entire macro looks somewhat strange.
> >
> > I am trying to fix it with minimal changes, so the patch qualif
t;
> CAAM_ERROR_STR_MAX is 302, probably enough according to commit
> de2954d66408da3ae34effda777bb564fd17781b (crypto: caam - fix printk
> recursion for long error texts).
You are digging in Linux's crypto code, not OpenSSL. We need accurate fixes and
accurate discussio
quot;kmalloc failure in SPRINTFCAT"); \
This entire macro looks somewhat strange.
1) Can't you just snprintf() into $str + some offset ? Something like:
snprintf(str + strlen(str), str_total_sz - strlen(str), format, param);
2) Why is noone checking if the $str has enough space f
D 1163870.
>
> Signed-off-by: Christian Engelmayer
Looks OK to me, thanks.
Reviewed-by: Marek Vasut
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://
1 - 100 of 186 matches
Mail list logo
