Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1286591 > unrolled thread
| Started by | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| First post | 2015-12-08 16:30 +0100 |
| Last post | 2015-12-11 04:10 +0100 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
[PATCH 1/2] crypto: sahara: fix 64-bit dma_addr_t compilation Arnd Bergmann <arnd@arndb.de> - 2015-12-08 16:30 +0100
[PATCH 2/2] crypto: sahara: fix debug output for 64-bit dma_addr_t Arnd Bergmann <arnd@arndb.de> - 2015-12-08 16:30 +0100
Re: [PATCH 1/2] crypto: sahara: fix 64-bit dma_addr_t compilation Herbert Xu <herbert@gondor.apana.org.au> - 2015-12-11 04:10 +0100
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2015-12-08 16:30 +0100 |
| Subject | [PATCH 1/2] crypto: sahara: fix 64-bit dma_addr_t compilation |
| Message-ID | <qDsng-44U-27@gated-at.bofh.it> |
The sahara hardware uses DMA descriptors with 32-bit addresses, but
dma_addr_t is variable size depending on whether we want to support
any devices that use 64-bit DMA addresses in hardware.
This means that the definition of the DMA descriptor structure is wrong,
and we helpfully get a compiler warning about them too:
drivers/crypto/sahara.c:423:372: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
This changes the definition of the sahara_hw_desc and sahara_hw_link
structures to only contain fixed-length members, which is required
to make the driver work on ARM LPAE mode, and avoids most of the
gcc warnings we get.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/crypto/sahara.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index cc738f3592a3..38bf12ae5589 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -130,18 +130,18 @@
#define SAHARA_REG_IDAR 0x20
struct sahara_hw_desc {
- u32 hdr;
- u32 len1;
- dma_addr_t p1;
- u32 len2;
- dma_addr_t p2;
- dma_addr_t next;
+ u32 hdr;
+ u32 len1;
+ u32 p1;
+ u32 len2;
+ u32 p2;
+ u32 next;
};
struct sahara_hw_link {
- u32 len;
- dma_addr_t p;
- dma_addr_t next;
+ u32 len;
+ u32 p;
+ u32 next;
};
struct sahara_ctx {
--
2.1.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2015-12-08 16:30 +0100 |
| Subject | [PATCH 2/2] crypto: sahara: fix debug output for 64-bit dma_addr_t |
| Message-ID | <qDsng-44U-33@gated-at.bofh.it> |
| In reply to | #1286591 |
The sahara_dump_descriptors and sahara_dump_links functions attempt
to print a dma_addr_t value with a 0x%08x format string, which
produces a warning when dma_addr_t is 64-bit wide:
drivers/crypto/sahara.c:419:120: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
This changes the code to use the %pad format string that is meant
for dma_addr_t, which avoids the warning and gives us the correct
output in all configurations.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/crypto/sahara.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 38bf12ae5589..6c4f91c5e6b3 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -416,8 +416,8 @@ static void sahara_dump_descriptors(struct sahara_dev *dev)
return;
for (i = 0; i < SAHARA_MAX_HW_DESC; i++) {
- dev_dbg(dev->device, "Descriptor (%d) (0x%08x):\n",
- i, dev->hw_phys_desc[i]);
+ dev_dbg(dev->device, "Descriptor (%d) (%pad):\n",
+ i, &dev->hw_phys_desc[i]);
dev_dbg(dev->device, "\thdr = 0x%08x\n", dev->hw_desc[i]->hdr);
dev_dbg(dev->device, "\tlen1 = %u\n", dev->hw_desc[i]->len1);
dev_dbg(dev->device, "\tp1 = 0x%08x\n", dev->hw_desc[i]->p1);
@@ -437,8 +437,8 @@ static void sahara_dump_links(struct sahara_dev *dev)
return;
for (i = 0; i < SAHARA_MAX_HW_LINK; i++) {
- dev_dbg(dev->device, "Link (%d) (0x%08x):\n",
- i, dev->hw_phys_link[i]);
+ dev_dbg(dev->device, "Link (%d) (%pad):\n",
+ i, &dev->hw_phys_link[i]);
dev_dbg(dev->device, "\tlen = %u\n", dev->hw_link[i]->len);
dev_dbg(dev->device, "\tp = 0x%08x\n", dev->hw_link[i]->p);
dev_dbg(dev->device, "\tnext = 0x%08x\n",
--
2.1.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Herbert Xu <herbert@gondor.apana.org.au> |
|---|---|
| Date | 2015-12-11 04:10 +0100 |
| Message-ID | <qEmfL-6MN-3@gated-at.bofh.it> |
| In reply to | #1286591 |
On Tue, Dec 08, 2015 at 04:23:51PM +0100, Arnd Bergmann wrote:
> The sahara hardware uses DMA descriptors with 32-bit addresses, but
> dma_addr_t is variable size depending on whether we want to support
> any devices that use 64-bit DMA addresses in hardware.
> This means that the definition of the DMA descriptor structure is wrong,
> and we helpfully get a compiler warning about them too:
>
> drivers/crypto/sahara.c:423:372: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
>
> This changes the definition of the sahara_hw_desc and sahara_hw_link
> structures to only contain fixed-length members, which is required
> to make the driver work on ARM LPAE mode, and avoids most of the
> gcc warnings we get.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Both patches applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web