crypto: talitos: Init zero_entry more compatibly

PATCH In review Aaron Sierra 2 participants 15 messages Jul 31, 2015 – Aug 10, 2015 1 message not in the archive Crypto API

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Aaron Sierra

author

2015-07-31 18:17 UTC #1 lore raw

PATCH 1/1 crypto: talitos: Init zero_entry more compatibly

Compiling this driver with my GCC 4.3.1 e500v2 cross-compiler resulted in a failed build due to the anonymous union/structures introduced in this commit:

crypto: talitos - enhanced talitos_desc struct for SEC1

The build error was:

drivers/crypto/talitos.h:56: error: unknown field 'len' specified in initializer drivers/crypto/talitos.h:56: warning: missing braces around initializer drivers/crypto/talitos.h:56: warning: (near initialization for 'zero_entry.<anonymous>') drivers/crypto/talitos.h:57: error: unknown field 'j_extent' specified in initializer drivers/crypto/talitos.h:58: error: unknown field 'eptr' specified in initializer drivers/crypto/talitos.h:58: warning: excess elements in struct initializer drivers/crypto/talitos.h:58: warning: (near initialization for 'zero_entry') make[2]: *** [drivers/crypto/talitos.o] Error 1
make[1]: *** [drivers/crypto] Error 2
make: *** [drivers] Error 2

This patch works around the errors by changing the static constant zero_entry's initializer to use an initialization shorthand.

Signed-off-by Aaron Sierra <[email protected]>

---
 drivers/crypto/talitos.h | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

drivers/crypto/talitos.h +1 -6

index 314daf5..bf88fe7 100644
@@ -52,12 +52,7 @@ struct talitos_ptr {
 	__be32 ptr;     /* address */
 };
 
-static const struct talitos_ptr zero_entry = {
-	.len = 0,
-	.j_extent = 0,
-	.eptr = 0,
-	.ptr = 0
-};
+static const struct talitos_ptr zero_entry = {{{ 0 }}};
 
 /* descriptor */
 struct talitos_desc {

Signature · 1 line

1.9.1

Aaron Sierra

author

2015-07-31 20:53 UTC #2 lore raw

PATCH 1/1 crypto: talitos: Prevent panic in probe error path

RNG unregistration and per-channel FIFO cleanup can cause a kernel panic, depending on how early in talitos_probe() an error occurs. This patch prevents these panics from happening.

For completeness, this patch also sets device drvdata to NULL after the private structure is freed in talitos_remove().

Signed-off-by Aaron Sierra <[email protected]>

---
 drivers/crypto/talitos.c | 33 +++++++++++++++++++++++----------
 drivers/crypto/talitos.h |  2 +-
 2 files changed, 24 insertions(+), 11 deletions(-)

drivers/crypto/talitos.c +23 ~~-10~~

index 83aca95..684fe89 100644
@@ -766,21 +766,33 @@ static int talitos_rng_init(struct hwrng *rng)
 static int talitos_register_rng(struct device *dev)
 {
 	struct talitos_private *priv = dev_get_drvdata(dev);
+	int err = 0;
 
-	priv->rng.name		= dev_driver_string(dev),
-	priv->rng.init		= talitos_rng_init,
-	priv->rng.data_present	= talitos_rng_data_present,
-	priv->rng.data_read	= talitos_rng_data_read,
-	priv->rng.priv		= (unsigned long)dev;
+	priv->rng = kzalloc(sizeof(struct hwrng), GFP_KERNEL);
+	if (!priv->rng)
+		return -ENOMEM;
+
+	priv->rng->name		= dev_driver_string(dev),
+	priv->rng->init		= talitos_rng_init,
+	priv->rng->data_present	= talitos_rng_data_present,
+	priv->rng->data_read	= talitos_rng_data_read,
+	priv->rng->priv		= (unsigned long)dev;
+
+	err = hwrng_register(priv->rng);
+	if (err) {
+		kfree(priv->rng);
+		priv->rng = NULL;
+	}
 
-	return hwrng_register(&priv->rng);
+	return err;
 }
 
 static void talitos_unregister_rng(struct device *dev)
 {
 	struct talitos_private *priv = dev_get_drvdata(dev);
 
-	hwrng_unregister(&priv->rng);
+	if (priv->rng)
+		hwrng_unregister(priv->rng);
 }
 
 /*

@@ -2727,7 +2739,7 @@ static int talitos_remove(struct platform_device *ofdev)
 	if (hw_supports(dev, DESC_HDR_SEL0_RNG))
 		talitos_unregister_rng(dev);
 
-	for (i = 0; i < priv->num_channels; i++)
+	for (i = 0; priv->chan && i < priv->num_channels; i++)
 		kfree(priv->chan[i].fifo);
 
 	kfree(priv->chan);

@@ -2746,6 +2758,8 @@ static int talitos_remove(struct platform_device *ofdev)
 
 	kfree(priv);
 
+	dev_set_drvdata(dev, NULL);
+
 	return 0;
 }

@@ -2905,8 +2919,7 @@ static int talitos_probe(struct platform_device *ofdev)
 	priv->reg = of_iomap(np, 0);
 	if (!priv->reg) {
 		dev_err(dev, "failed to of_iomap\n");
-		err = -ENOMEM;
-		goto err_out;
+		return -ENOMEM;
 	}
 
 	/* get SEC version capabilities from device tree */

drivers/crypto/talitos.h +1 -1

index bf88fe7..e86f67c 100644
@@ -148,7 +148,7 @@ struct talitos_private {
 	struct list_head alg_list;
 
 	/* hwrng device */
-	struct hwrng rng;
+	struct hwrng *rng;
 };
 
 extern int talitos_submit(struct device *dev, int ch, struct talitos_desc *desc,

Signature · 1 line

1.9.1

Herbert Xu

maintainer

2015-08-04 07:18 UTC #3 lore raw

Re: [PATCH] crypto: talitos: Prevent panic in probe error path

drivers/crypto/talitos.c static int talitos_probe(struct platform_device *ofdev) · line 2923

Quoted 9 lines · Aaron Sierra

drivers/crypto/talitos.c +1 -2

@@ -2905,8 +2919,7 @@ static int talitos_probe(struct platform_device *ofdev)
 	priv->reg = of_iomap(np, 0);
 	if (!priv->reg) {
 		dev_err(dev, "failed to of_iomap\n");
-		err = -ENOMEM;
-		goto err_out;
+		return -ENOMEM;
 	}

This is the only bit that seems remotely related to your change description. Please ensure that your patch actually corresponds to your changelog and do not include unrelated changes without documenting them.

And even this bit is wrong because you're leaking priv.

Cheers,

Signature · 3 lines

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Aaron Sierra

author

2015-08-04 14:45 UTC #4 lore raw

Re: [PATCH] crypto: talitos: Prevent panic in probe error path

----- Original Message -----

Quoted 20 lines

From: "Herbert Xu" <[email protected]>
Sent: Tuesday, August 4, 2015 2:18:05 AM
drivers/crypto/talitos.c static int talitos_probe(struct platform_device · line 2924
Quoted 10 lines · Aaron Sierra
drivers/crypto/talitos.c +1 -2
@@ -2905,8 +2919,7 @@ static int talitos_probe(struct platform_device
 *ofdev)
 	priv->reg = of_iomap(np, 0);
 	if (!priv->reg) {
 		dev_err(dev, "failed to of_iomap\n");
-		err = -ENOMEM;
-		goto err_out;
+		return -ENOMEM;
 	}
This is the only bit that seems remotely related to your change description. Please ensure that your patch actually corresponds to your changelog and do not include unrelated changes without documenting them.

Quoted 1 line

And even this bit is wrong because you're leaking priv.

Herbert,

You are correct about the leak and I regret introducing that (I am also leaking priv->rng), but I disagree with your dismissal of the rest of the changes as unrelated to the changelog.

The probe error path for this driver, for all intents and purposes, is the talitos_remove() function due to the common "goto err_out".

Without my patch applied, talitos_remove() will panic under the two conditions that I outlined in the changelog:

1. If the RNG device hasn't been registered via talitos_register_rng() prior to entry into talitos_remove(), then the attempt to unregister the RNG "device" will cause a panic.

2. If the priv->chan array has not been allocated prior to entry into talitos_remove(), then the per-channel FIFO cleanup will panic because of the dereference of that NULL "array".

Both of the above scenarios occur if talitos_probe_irq() fails.

The patch that I submitted resolves issue #1 by changing priv->rng to a struct hwrng pointer, which allows talitos_unregister_rng() to know whether an RNG device has been registered (or at least prepared for registration). As an alternative, I considered introducing a boolean to serve the same purpose.

It resolves issue #2 by checking that priv->chan is not NULL in the per-channel FIFO cleanup for loop.

-Aaron

Herbert Xu

maintainer

2015-08-05 00:08 UTC #5 lore raw

Re: [PATCH] crypto: talitos: Prevent panic in probe error path

Quoted 4 lines · Aaron Sierra

You are correct about the leak and I regret introducing that (I am also leaking priv->rng), but I disagree with your dismissal of the rest of the changes as unrelated to the changelog.

I understand the problem, but your change description is way too vague and does not correspond to the change, especially the bit where you're replacing the static variable with kzalloc. You should have included the following text in your description.

Quoted 14 lines

The probe error path for this driver, for all intents and purposes, is the talitos_remove() function due to the common "goto err_out".
Without my patch applied, talitos_remove() will panic under the two conditions that I outlined in the changelog:
1. If the RNG device hasn't been registered via talitos_register_rng() prior to entry into talitos_remove(), then the attempt to unregister the RNG "device" will cause a panic.
2. If the priv->chan array has not been allocated prior to entry into talitos_remove(), then the per-channel FIFO cleanup will panic because of the dereference of that NULL "array".

Quoted 7 lines

Both of the above scenarios occur if talitos_probe_irq() fails.
The patch that I submitted resolves issue #1 by changing priv->rng to a struct hwrng pointer, which allows talitos_unregister_rng() to know whether an RNG device has been registered (or at least prepared for registration). As an alternative, I considered introducing a boolean to serve the same purpose.

I would prefer a boolean as that means less churn.

Thanks,

Signature · 3 lines

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Aaron Sierra

author

2015-08-05 14:25 UTC #6 lore raw

Re: [PATCH] crypto: talitos: Prevent panic in probe error path

----- Original Message -----

Quoted 30 lines

From: "Herbert Xu" <[email protected]>
Sent: Tuesday, August 4, 2015 7:08:13 PM
Quoted 4 lines · Aaron Sierra
You are correct about the leak and I regret introducing that (I am also leaking priv->rng), but I disagree with your dismissal of the rest of the changes as unrelated to the changelog.
I understand the problem, but your change description is way too vague and does not correspond to the change, especially the bit where you're replacing the static variable with kzalloc. You should have included the following text in your description.
Quoted 16 lines
The probe error path for this driver, for all intents and purposes, is the talitos_remove() function due to the common "goto err_out".
Without my patch applied, talitos_remove() will panic under the two conditions that I outlined in the changelog:
1. If the RNG device hasn't been registered via talitos_register_rng() prior to entry into talitos_remove(), then the attempt to unregister the RNG "device" will cause a panic.
2. If the priv->chan array has not been allocated prior to entry into talitos_remove(), then the per-channel FIFO cleanup will panic because of the dereference of that NULL "array".
Both of the above scenarios occur if talitos_probe_irq() fails.

Quoted 8 lines

Quoted 5 lines
The patch that I submitted resolves issue #1 by changing priv->rng to a struct hwrng pointer, which allows talitos_unregister_rng() to know whether an RNG device has been registered (or at least prepared for registration). As an alternative, I considered introducing a boolean to serve the same purpose.
I would prefer a boolean as that means less churn.

Herbert,
Thanks for the feedback. I'll address your concerns in the next version.

-Aaron

Aaron Sierra

author

2015-08-05 21:53 UTC #7 lore raw

PATCH v2 1/1 crypto: talitos: Prevent panic in probe error path

In reply to Aaron Sierra

The probe error path for this driver, for all intents and purposes, is the talitos_remove() function due to the common "goto err_out".

Without this patch applied, talitos_remove() will panic under these two conditions:

1. If the RNG device hasn't been registered via talitos_register_rng() prior to entry into talitos_remove(), then the attempt to unregister the RNG "device" will cause a panic.

2. If the priv->chan array has not been allocated prior to entry into talitos_remove(), then the per-channel FIFO cleanup will panic because of the dereference of that NULL "array".

Both of the above scenarios occur if talitos_probe_irq() fails.

This patch resolves issue #1 by introducing a boolean to mask the hwrng_unregister() call in talitos_unregister_rng() if RNG device registration was unsuccessful.

It resolves issue #2 by checking that priv->chan is not NULL in the per-channel FIFO cleanup for loop.

For completeness, this patch also sets device drvdata to NULL after the private structure is freed in talitos_remove().

Signed-off-by Aaron Sierra <[email protected]>

---
 drivers/crypto/talitos.c | 14 ++++++++++++--
 drivers/crypto/talitos.h |  1 +
 2 files changed, 13 insertions(+), 2 deletions(-)

drivers/crypto/talitos.c +12 -2

index 83aca95..74f1a62 100644
@@ -766,6 +766,7 @@ static int talitos_rng_init(struct hwrng *rng)
 static int talitos_register_rng(struct device *dev)
 {
 	struct talitos_private *priv = dev_get_drvdata(dev);
+	int err;
 
 	priv->rng.name		= dev_driver_string(dev),
 	priv->rng.init		= talitos_rng_init,

@@ -773,14 +774,22 @@ static int talitos_register_rng(struct device *dev)
 	priv->rng.data_read	= talitos_rng_data_read,
 	priv->rng.priv		= (unsigned long)dev;
 
-	return hwrng_register(&priv->rng);
+	err = hwrng_register(&priv->rng);
+	if (!err)
+		priv->rng_registered = true;
+
+	return err;
 }
 
 static void talitos_unregister_rng(struct device *dev)
 {
 	struct talitos_private *priv = dev_get_drvdata(dev);
 
+	if (!priv->rng_registered)
+		return;
+
 	hwrng_unregister(&priv->rng);
+	priv->rng_registered = false;
 }
 
 /*

@@ -2727,7 +2736,7 @@ static int talitos_remove(struct platform_device *ofdev)
 	if (hw_supports(dev, DESC_HDR_SEL0_RNG))
 		talitos_unregister_rng(dev);
 
-	for (i = 0; i < priv->num_channels; i++)
+	for (i = 0; priv->chan && i < priv->num_channels; i++)
 		kfree(priv->chan[i].fifo);
 
 	kfree(priv->chan);

@@ -2745,6 +2754,7 @@ static int talitos_remove(struct platform_device *ofdev)
 	iounmap(priv->reg);
 
 	kfree(priv);
+	dev_set_drvdata(dev, NULL);
 
 	return 0;
 }

drivers/crypto/talitos.h +1 -0

index 163cfe7..0090f32 100644
@@ -149,6 +149,7 @@ struct talitos_private {
 
 	/* hwrng device */
 	struct hwrng rng;
+	bool rng_registered;
 };
 
 extern int talitos_submit(struct device *dev, int ch, struct talitos_desc *desc,

Signature · 1 line

1.9.1

Aaron Sierra

author

2015-08-06 18:46 UTC #8 lore raw

Re: [PATCH v2] crypto: talitos: Prevent panic in probe error path

Quoted 2 lines

For completeness, this patch also sets device drvdata to NULL after the private structure is freed in talitos_remove().

[snip]

Quoted 9 lines

drivers/crypto/talitos.c +1 -0

@@ -2745,6 +2754,7 @@ static int talitos_remove(struct platform_device
 *ofdev)
 	iounmap(priv->reg);
 
 	kfree(priv);
+	dev_set_drvdata(dev, NULL);
 
 	return 0;

}

I just found this drvdata cleanup hasn't been required for a few years, due to the following commit:

commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
Author: Hans de Goede <[email protected]>
Date: Wed May 23 00:09:34 2012 +0200

device-core: Ensure drvdata = NULL when no driver is bound

Should I submit a v3 patch without this cleanup, assuming there aren't other changes requested?

-Aaron

Herbert Xu

maintainer

2015-08-10 15:41 UTC #9 lore raw

Re: [PATCH v2] crypto: talitos: Prevent panic in probe error path

Quoted 4 lines · Aaron Sierra

I just found this drvdata cleanup hasn't been required for a few years, due to the following commit:

Quoted 8 lines

commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
Author: Hans de Goede <[email protected]>
Date: Wed May 23 00:09:34 2012 +0200
device-core: Ensure drvdata = NULL when no driver is bound
Should I submit a v3 patch without this cleanup, assuming there aren't other changes requested?

I have applied your patch with the dev_set_drvdata change removed.

Thanks,

Signature · 3 lines

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Herbert Xu

maintainer

2015-08-02 02:00 UTC #10 lore raw

In reply to Aaron Sierra

drivers/crypto/talitos.h struct talitos_ptr { · line 55

Quoted 8 lines · Aaron Sierra

drivers/crypto/talitos.h +1 -6

-static const struct talitos_ptr zero_entry = {
-	.len = 0,
-	.j_extent = 0,
-	.eptr = 0,
-	.ptr = 0
-};
+static const struct talitos_ptr zero_entry = {{{ 0 }}};

Please get rid of the initialiser completely.

Thanks,

Signature · 3 lines

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Aaron Sierra

author

2015-08-03 16:15 UTC #11 lore raw

PATCH v2 1/1 crypto: talitos: Remove zero_entry static initializer

In reply to Aaron Sierra

Compiling the talitos driver with my GCC 4.3.1 e500v2 cross-compiler resulted in a failed build due to the anonymous union/structures introduced in this commit:

crypto: talitos - enhanced talitos_desc struct for SEC1

The build error was:

This patch eliminates the errors by moving the static constant zero_entry to the talitos_private structure. As a member of that structure, zero_entry gets initialized for free (and compatibly) by the kzalloc() during device probe.

Signed-off-by Aaron Sierra <[email protected]>

---
 drivers/crypto/talitos.c | 14 +++++++-------
 drivers/crypto/talitos.h |  8 +-------
 2 files changed, 8 insertions(+), 14 deletions(-)

drivers/crypto/talitos.c +7 -7

index 83aca95..5347570 100644
@@ -1663,7 +1663,7 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
 	bool is_sec1 = has_ftr_sec1(priv);
 
 	/* first DWORD empty */
-	desc->ptr[0] = zero_entry;
+	desc->ptr[0] = priv->zero_entry;
 
 	/* cipher iv */
 	to_talitos_ptr(&desc->ptr[1], edesc->iv_dma, is_sec1);

@@ -1693,7 +1693,7 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
 			       DMA_FROM_DEVICE);
 
 	/* last DWORD empty */
-	desc->ptr[6] = zero_entry;
+	desc->ptr[6] = priv->zero_entry;
 
 	ret = talitos_submit(dev, ctx->ch, desc, callback, areq);
 	if (ret != -EINPROGRESS) {

@@ -1833,7 +1833,7 @@ static int common_nonsnoop_hash(struct talitos_edesc *edesc,
 	bool is_sec1 = has_ftr_sec1(priv);
 
 	/* first DWORD empty */
-	desc->ptr[0] = zero_entry;
+	desc->ptr[0] = priv->zero_entry;
 
 	/* hash context in */
 	if (!req_ctx->first || req_ctx->swinit) {

@@ -1843,7 +1843,7 @@ static int common_nonsnoop_hash(struct talitos_edesc *edesc,
 				       DMA_TO_DEVICE);
 		req_ctx->swinit = 0;
 	} else {
-		desc->ptr[1] = zero_entry;
+		desc->ptr[1] = priv->zero_entry;
 		/* Indicate next op is not the first. */
 		req_ctx->first = 0;
 	}

@@ -1853,7 +1853,7 @@ static int common_nonsnoop_hash(struct talitos_edesc *edesc,
 		map_single_talitos_ptr(dev, &desc->ptr[2], ctx->keylen,
 				       (char *)&ctx->key, DMA_TO_DEVICE);
 	else
-		desc->ptr[2] = zero_entry;
+		desc->ptr[2] = priv->zero_entry;
 
 	/*
 	 * data in

@@ -1862,7 +1862,7 @@ static int common_nonsnoop_hash(struct talitos_edesc *edesc,
 			      DMA_TO_DEVICE, &desc->ptr[3]);
 
 	/* fifth DWORD empty */
-	desc->ptr[4] = zero_entry;
+	desc->ptr[4] = priv->zero_entry;
 
 	/* hash/HMAC out -or- hash context out */
 	if (req_ctx->last)

@@ -1875,7 +1875,7 @@ static int common_nonsnoop_hash(struct talitos_edesc *edesc,
 				       req_ctx->hw_context, DMA_FROM_DEVICE);
 
 	/* last DWORD empty */
-	desc->ptr[6] = zero_entry;
+	desc->ptr[6] = priv->zero_entry;
 
 	if (is_sec1 && from_talitos_ptr_len(&desc->ptr[3], true) == 0)
 		talitos_handle_buggy_hash(ctx, edesc, &desc->ptr[3]);

drivers/crypto/talitos.h +1 -7

index 314daf5..153c56a 100644
@@ -52,13 +52,6 @@ struct talitos_ptr {
 	__be32 ptr;     /* address */
 };
 
-static const struct talitos_ptr zero_entry = {
-	.len = 0,
-	.j_extent = 0,
-	.eptr = 0,
-	.ptr = 0
-};
-
 /* descriptor */
 struct talitos_desc {
 	__be32 hdr;                     /* header high bits */

@@ -142,6 +135,7 @@ struct talitos_private {
 	unsigned int fifo_len;
 
 	struct talitos_channel *chan;
+	const struct talitos_ptr zero_entry;
 
 	/* next channel to be assigned next incoming descriptor */
 	atomic_t last_chan ____cacheline_aligned;

Signature · 1 line

1.9.1

Herbert Xu

maintainer

2015-08-03 23:31 UTC #12 lore raw

Re: [PATCH v2] crypto: talitos: Remove zero_entry static initializer

Quoted 19 lines · Aaron Sierra

Compiling the talitos driver with my GCC 4.3.1 e500v2 cross-compiler resulted in a failed build due to the anonymous union/structures introduced in this commit:
crypto: talitos - enhanced talitos_desc struct for SEC1
The build error was:
drivers/crypto/talitos.h:56: error: unknown field 'len' specified in initializer drivers/crypto/talitos.h:56: warning: missing braces around initializer drivers/crypto/talitos.h:56: warning: (near initialization for 'zero_entry.<anonymous>') drivers/crypto/talitos.h:57: error: unknown field 'j_extent' specified in initializer drivers/crypto/talitos.h:58: error: unknown field 'eptr' specified in initializer drivers/crypto/talitos.h:58: warning: excess elements in struct initializer drivers/crypto/talitos.h:58: warning: (near initialization for 'zero_entry') make[2]: *** [drivers/crypto/talitos.o] Error 1
make[1]: *** [drivers/crypto] Error 2
make: *** [drivers] Error 2

Quoted 4 lines

This patch eliminates the errors by moving the static constant zero_entry to the talitos_private structure. As a member of that structure, zero_entry gets initialized for free (and compatibly) by the kzalloc() during device probe.

Why? A static variable is always zeroed. Please just get rid of the initialisation and it will work.

Cheers,

Signature · 3 lines

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Aaron Sierra

author

2015-08-03 23:48 UTC #13 lore raw

Re: [PATCH v2] crypto: talitos: Remove zero_entry static initializer

----- Original Message -----

Quoted 29 lines

From: "Herbert Xu" <[email protected]>
Sent: Monday, August 3, 2015 6:31:20 PM
Quoted 25 lines · Aaron Sierra
Compiling the talitos driver with my GCC 4.3.1 e500v2 cross-compiler resulted in a failed build due to the anonymous union/structures introduced in this commit:
crypto: talitos - enhanced talitos_desc struct for SEC1
The build error was:
drivers/crypto/talitos.h:56: error: unknown field 'len' specified in initializer
drivers/crypto/talitos.h:56: warning: missing braces around initializer drivers/crypto/talitos.h:56: warning: (near initialization for 'zero_entry.<anonymous>')
drivers/crypto/talitos.h:57: error: unknown field 'j_extent' specified in initializer
drivers/crypto/talitos.h:58: error: unknown field 'eptr' specified in initializer
drivers/crypto/talitos.h:58: warning: excess elements in struct initializer
drivers/crypto/talitos.h:58: warning: (near initialization for 'zero_entry')
make[2]: *** [drivers/crypto/talitos.o] Error 1
make[1]: *** [drivers/crypto] Error 2
make: *** [drivers] Error 2

Quoted 7 lines

Quoted 4 lines
This patch eliminates the errors by moving the static constant zero_entry to the talitos_private structure. As a member of that structure, zero_entry gets initialized for free (and compatibly) by the kzalloc() during device probe.
Why? A static variable is always zeroed. Please just get rid of the initialisation and it will work.

Thanks for elaborating. I'll make the change.

-Aaron

Aaron Sierra

author

2015-08-03 23:57 UTC #14 lore raw

PATCH v3 1/1 crypto: talitos: Remove zero_entry static initializer

In reply to Aaron Sierra

Compiling the talitos driver with my GCC 4.3.1 e500v2 cross-compiler resulted in a failed build due to the anonymous union/structures introduced in this commit:

crypto: talitos - enhanced talitos_desc struct for SEC1

The build error was:

This patch eliminates the errors by relying on the C standard's implicit assignment of zero to static variables.

Signed-off-by Aaron Sierra <[email protected]>

---
 drivers/crypto/talitos.h | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

drivers/crypto/talitos.h +1 -6

index 314daf5..163cfe7 100644
@@ -52,12 +52,7 @@ struct talitos_ptr {
 	__be32 ptr;     /* address */
 };
 
-static const struct talitos_ptr zero_entry = {
-	.len = 0,
-	.j_extent = 0,
-	.eptr = 0,
-	.ptr = 0
-};
+static const struct talitos_ptr zero_entry;
 
 /* descriptor */
 struct talitos_desc {

Signature · 1 line

1.9.1

Herbert Xu

maintainer Applied

2015-08-04 09:45 UTC #15 lore raw

Re: [PATCH v3] crypto: talitos: Remove zero_entry static initializer

Quoted 19 lines · Aaron Sierra

Compiling the talitos driver with my GCC 4.3.1 e500v2 cross-compiler resulted in a failed build due to the anonymous union/structures introduced in this commit:
crypto: talitos - enhanced talitos_desc struct for SEC1
The build error was:
drivers/crypto/talitos.h:56: error: unknown field 'len' specified in initializer drivers/crypto/talitos.h:56: warning: missing braces around initializer drivers/crypto/talitos.h:56: warning: (near initialization for 'zero_entry.<anonymous>') drivers/crypto/talitos.h:57: error: unknown field 'j_extent' specified in initializer drivers/crypto/talitos.h:58: error: unknown field 'eptr' specified in initializer drivers/crypto/talitos.h:58: warning: excess elements in struct initializer drivers/crypto/talitos.h:58: warning: (near initialization for 'zero_entry') make[2]: *** [drivers/crypto/talitos.o] Error 1
make[1]: *** [drivers/crypto] Error 2
make: *** [drivers] Error 2

Quoted 4 lines

This patch eliminates the errors by relying on the C standard's implicit assignment of zero to static variables.
Signed-off-by Aaron Sierra <[email protected]>

Applied.

Signature · 3 lines

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt