From: s.trumtrar@pengutronix.de (Steffen Trumtrar)
To: linux-arm-kernel@lists.infradead.org
Subject: [BUG?] crypto: caam: little/big endianness on ARM vs PPC
Date: Mon, 15 Jun 2015 17:59:07 +0200 [thread overview]
Message-ID: <20150615155907.GC7947@pengutronix.de> (raw)
Hi!
I'm working on CAAM support for the ARM-based i.MX6 SoCs. The current
drivers/crypto/caam driver only works for PowerPC AFAIK.
Actually, there isn't that much to do, to get support for the i.MX6 but
one patch breaks the driver severely:
commit ef94b1d834aace7101de77c3a7c2631b9ae9c5f6
crypto: caam - Add definition of rd/wr_reg64 for little endian platform
This patch adds
+#ifdef __LITTLE_ENDIAN
+static inline void wr_reg64(u64 __iomem *reg, u64 data)
+{
+ wr_reg32((u32 __iomem *)reg + 1, (data & 0xffffffff00000000ull) >> 32);
+ wr_reg32((u32 __iomem *)reg, data & 0x00000000ffffffffull);
+}
The wr_reg64 function is only used in one place in the drivers/crypto/caam/jr.c
driver: to write the dma_addr_t to the register. Without that patch everything
works fine on ARM (little endian, 32bit), with that patch the driver will write
0's into the register that holds the DMA address (the numerically-higher) -> kernel hangs.
Also, from my understanding, the comment above the defines, stating that you
have to first write the numerically-lower and then the numerically-higher address
on 32bit systems doesn't match with the implementation.
What I don't know/understand is if this makes any sense for any PowerPC implementation.
So, the question is, how to fix this? I'd prefer to do it directly in the jr driver
instead of the ifdef-ery.
Something like
if (sizeof(dma_addr_t) == sizeof(u32))
wr_reg32(&jrp->rregs->inpring_base + 1, inpbusaddr);
else if (sizeof(dma_addr_t) == sizeof(u64))
wr_reg64(...)
or just go by DT compatible and then remove the inline function definitions.
As far as I can tell, the compatible wouldn't be needed for anything else in the
jr driver, so maybe that is not optimal. On the other hand the sizeof(..)
solution would only catch little endian on 32bit and not big endian (?!)
I however don't know what combinations actually *have* to be caught, as I don't
know, which exist.
So, what do you think people?
Thanks,
Steffen Trumtrar
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next reply other threads:[~2015-06-15 15:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-15 15:59 Steffen Trumtrar [this message]
2015-06-15 16:28 ` [BUG?] crypto: caam: little/big endianness on ARM vs PPC Russell King - ARM Linux
2015-06-16 7:45 ` Steffen Trumtrar
2015-06-15 16:33 ` Jon Nettleton
2015-06-15 17:18 ` Russell King - ARM Linux
2015-08-04 17:55 ` Horia Geantă
2015-06-15 22:05 ` Herbert Xu
2015-06-16 3:27 ` Victoria Milhoan
2015-06-16 8:11 ` Jon Nettleton
2015-06-16 16:00 ` Victoria Milhoan
2015-06-16 12:53 ` Steffen Trumtrar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150615155907.GC7947@pengutronix.de \
--to=s.trumtrar@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).