I keep getting sparse warnings in crypto such as:
CHECK ../drivers/crypto/ccree/cc_hash.c
../drivers/crypto/ccree/cc_hash.c:49:9: warning: cast truncates bits from constant value (47b5481dbefa4fa4 becomes befa4fa4)
../drivers/crypto/ccree/cc_hash.c:49:26: warning: cast truncates bits from constant value (db0c2e0d64f98fa7 becomes 64f98fa7)
../drivers/crypto/ccree/cc_hash.c:49:43: warning: cast truncates bits from constant value (8eb44a8768581511 becomes 68581511)
../drivers/crypto/ccree/cc_hash.c:49:60: warning: cast truncates bits from constant value (67332667ffc00b31 becomes ffc00b31)
../drivers/crypto/ccree/cc_hash.c:50:9: warning: cast truncates bits from constant value (152fecd8f70e5939 becomes f70e5939)
../drivers/crypto/ccree/cc_hash.c:50:26: warning: cast truncates bits from constant value (9159015a3070dd17 becomes 3070dd17)
../drivers/crypto/ccree/cc_hash.c:50:43: warning: cast truncates bits from constant value (629a292a367cd507 becomes 367cd507)
../drivers/crypto/ccree/cc_hash.c:50:60: warning: cast truncates bits from constant value (cbbb9d5dc1059ed8 becomes c1059ed8)
../drivers/crypto/ccree/cc_hash.c:52:9: warning: cast truncates bits from constant value (5be0cd19137e2179 becomes 137e2179)
../drivers/crypto/ccree/cc_hash.c:52:26: warning: cast truncates bits from constant value (1f83d9abfb41bd6b becomes fb41bd6b)
../drivers/crypto/ccree/cc_hash.c:52:43: warning: cast truncates bits from constant value (9b05688c2b3e6c1f becomes 2b3e6c1f)
../drivers/crypto/ccree/cc_hash.c:52:60: warning: cast truncates bits from constant value (510e527fade682d1 becomes ade682d1)
../drivers/crypto/ccree/cc_hash.c:53:9: warning: cast truncates bits from constant value (a54ff53a5f1d36f1 becomes 5f1d36f1)
../drivers/crypto/ccree/cc_hash.c:53:26: warning: cast truncates bits from constant value (3c6ef372fe94f82b becomes fe94f82b)
../drivers/crypto/ccree/cc_hash.c:53:43: warning: cast truncates bits from constant value (bb67ae8584caa73b becomes 84caa73b)
../drivers/crypto/ccree/cc_hash.c:53:60: warning: cast truncates bits from constant value (6a09e667f3bcc908 becomes f3bcc908)
This patch removes the warning by adding a mask to keep sparse
happy.
Signed-off-by: Herbert Xu <[email protected]>
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 500def620d8f..c25b8e41c0ea 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -186,7 +186,7 @@
* lower_32_bits - return bits 0-31 of a number
* @n: the number we're accessing
*/
-#define lower_32_bits(n) ((u32)(n))
+#define lower_32_bits(n) ((u32)((n) & 0xffffffff))
struct completion;
struct pt_regs;
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, Aug 28, 2020 at 05:11:25PM +1000, Herbert Xu wrote:
> I keep getting sparse warnings in crypto such as:
>
This patch results in the following compile error when compiling
ppc:mpc85xx_defconfig.
Error log:
In file included from ./include/linux/list.h:9,
from ./include/linux/module.h:12,
from drivers/dma/fsldma.c:23:
drivers/dma/fsldma.h: In function 'fsl_ioread64':
./include/linux/kernel.h:189:37: error: invalid operands to binary & (have 'const u64 *' {aka 'const long long unsigned int *'} and 'unsigned int')
189 | #define lower_32_bits(n) ((u32)((n) & 0xffffffff))
| ^
drivers/dma/fsldma.h:208:17: note: in expansion of macro 'lower_32_bits'
208 | u32 fsl_addr = lower_32_bits(addr);
| ^~~~~~~~~~~~~
drivers/dma/fsldma.h: In function 'fsl_ioread64be':
./include/linux/kernel.h:189:37: error: invalid operands to binary & (have 'const u64 *' {aka 'const long long unsigned int *'} and 'unsigned int')
189 | #define lower_32_bits(n) ((u32)((n) & 0xffffffff))
| ^
drivers/dma/fsldma.h:222:17: note: in expansion of macro 'lower_32_bits'
222 | u32 fsl_addr = lower_32_bits(addr);
| ^~~~~~~~~~~~~
make[2]: *** [drivers/dma/fsldma.o] Error 1
Bisct log attached.
Guenter
---
# bad: [4d41ead6ead97c3730bbd186a601a64828668f01] Merge tag 'block-5.9-2020-08-28' of git://git.kernel.dk/linux-block
# good: [15bc20c6af4ceee97a1f90b43c0e386643c071b4] Merge tag 'tty-5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
git bisect start 'HEAD' '15bc20c6af4c'
# good: [5ec06b5c0d259a8c7c4376b121b2f62dfbfe57ef] Merge tag 'drm-fixes-2020-08-28' of git://anongit.freedesktop.org/drm/drm
git bisect good 5ec06b5c0d259a8c7c4376b121b2f62dfbfe57ef
# bad: [326e311b849426a95cac0149406efb2bbd13fa65] Merge tag 'pm-5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 326e311b849426a95cac0149406efb2bbd13fa65
# good: [e30942859030199dab5ad73f95faac226133c639] Merge tag 'writeback_for_v5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
git bisect good e30942859030199dab5ad73f95faac226133c639
# bad: [96d454cd2c1668010406ea4c28ab915bcbb747f4] Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
git bisect bad 96d454cd2c1668010406ea4c28ab915bcbb747f4
# good: [e9ee186bb735bfc17fa81dbc9aebf268aee5b41e] KVM: arm64: Add kvm_extable for vaxorcism code
git bisect good e9ee186bb735bfc17fa81dbc9aebf268aee5b41e
# good: [71a7f8cb1ca4ca7214a700b1243626759b6c11d4] KVM: arm64: Set HCR_EL2.PTW to prevent AT taking synchronous exception
git bisect good 71a7f8cb1ca4ca7214a700b1243626759b6c11d4
# bad: [ef91bb196b0db1013ef8705367bc2d7944ef696b] kernel.h: Silence sparse warning in lower_32_bits
git bisect bad ef91bb196b0db1013ef8705367bc2d7944ef696b
# first bad commit: [ef91bb196b0db1013ef8705367bc2d7944ef696b] kernel.h: Silence sparse warning in lower_32_bits
On Sat, Aug 29, 2020 at 03:51:16AM -0700, Guenter Roeck wrote:
>
> This patch results in the following compile error when compiling
> ppc:mpc85xx_defconfig.
>
> Error log:
> In file included from ./include/linux/list.h:9,
> from ./include/linux/module.h:12,
> from drivers/dma/fsldma.c:23:
> drivers/dma/fsldma.h: In function 'fsl_ioread64':
> ./include/linux/kernel.h:189:37: error: invalid operands to binary & (have 'const u64 *' {aka 'const long long unsigned int *'} and 'unsigned int')
> 189 | #define lower_32_bits(n) ((u32)((n) & 0xffffffff))
> | ^
> drivers/dma/fsldma.h:208:17: note: in expansion of macro 'lower_32_bits'
> 208 | u32 fsl_addr = lower_32_bits(addr);
> | ^~~~~~~~~~~~~
> drivers/dma/fsldma.h: In function 'fsl_ioread64be':
> ./include/linux/kernel.h:189:37: error: invalid operands to binary & (have 'const u64 *' {aka 'const long long unsigned int *'} and 'unsigned int')
> 189 | #define lower_32_bits(n) ((u32)((n) & 0xffffffff))
> | ^
> drivers/dma/fsldma.h:222:17: note: in expansion of macro 'lower_32_bits'
> 222 | u32 fsl_addr = lower_32_bits(addr);
> | ^~~~~~~~~~~~~
> make[2]: *** [drivers/dma/fsldma.o] Error 1
Thanks for the report. Passing a pointer to lower_32_bits is just
bad.
---8<---
The functions fsl_ioread64* were passing a pointer to lower_32_bits
which just happened to work because it was a macro that simply did
a cast on the argument.
However, now that lower_32_bits does a mask on the argument it no
longer works. Passing a pointer to lower_32_bits doesn't look
right anyway.
This patch adds explicit casts so that an integer is passed along
as the argument to lower_32_bits.
Reported-by: Guenter Roeck <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index 56f18ae99233..da5816b1706e 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -205,7 +205,7 @@ struct fsldma_chan {
#else
static u64 fsl_ioread64(const u64 __iomem *addr)
{
- u32 fsl_addr = lower_32_bits(addr);
+ u32 fsl_addr = lower_32_bits((unsigned long)addr);
u64 fsl_addr_hi = (u64)in_le32((u32 *)(fsl_addr + 1)) << 32;
return fsl_addr_hi | in_le32((u32 *)fsl_addr);
@@ -219,7 +219,7 @@ static void fsl_iowrite64(u64 val, u64 __iomem *addr)
static u64 fsl_ioread64be(const u64 __iomem *addr)
{
- u32 fsl_addr = lower_32_bits(addr);
+ u32 fsl_addr = lower_32_bits((unsigned long)addr);
u64 fsl_addr_hi = (u64)in_be32((u32 *)fsl_addr) << 32;
return fsl_addr_hi | in_be32((u32 *)(fsl_addr + 1));
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
For ppc32, the functions fsl_ioread64() & fsl_ioread64be()
use lower_32_bits() as a fancy way to cast the pointer to u32
in order to do non-atomic 64-bit IO.
But the pointer is already 32-bit, so simply cast the pointer to u32.
This fixes a compile error introduced by
ef91bb196b0d ("kernel.h: Silence sparse warning in lower_32_bits")
Fixes: ef91bb196b0db1013ef8705367bc2d7944ef696b
Reported-by: Guenter Roeck <[email protected]>
Cc: Li Yang <[email protected]>
Cc: Zhang Wei <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Vinod Koul <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Luc Van Oostenryck <[email protected]>
---
drivers/dma/fsldma.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index 56f18ae99233..6f6fa7641fa2 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -205,7 +205,7 @@ struct fsldma_chan {
#else
static u64 fsl_ioread64(const u64 __iomem *addr)
{
- u32 fsl_addr = lower_32_bits(addr);
+ u32 fsl_addr = (u32) addr;
u64 fsl_addr_hi = (u64)in_le32((u32 *)(fsl_addr + 1)) << 32;
return fsl_addr_hi | in_le32((u32 *)fsl_addr);
@@ -219,7 +219,7 @@ static void fsl_iowrite64(u64 val, u64 __iomem *addr)
static u64 fsl_ioread64be(const u64 __iomem *addr)
{
- u32 fsl_addr = lower_32_bits(addr);
+ u32 fsl_addr = (u32) addr;
u64 fsl_addr_hi = (u64)in_be32((u32 *)fsl_addr) << 32;
return fsl_addr_hi | in_be32((u32 *)(fsl_addr + 1));
--
2.28.0
On Sat, Aug 29, 2020 at 02:45:38PM +0200, Luc Van Oostenryck wrote:
> For ppc32, the functions fsl_ioread64() & fsl_ioread64be()
> use lower_32_bits() as a fancy way to cast the pointer to u32
> in order to do non-atomic 64-bit IO.
>
> But the pointer is already 32-bit, so simply cast the pointer to u32.
>
> This fixes a compile error introduced by
> ef91bb196b0d ("kernel.h: Silence sparse warning in lower_32_bits")
>
> Fixes: ef91bb196b0db1013ef8705367bc2d7944ef696b
checkpatch complains about this and prefers
Fixes: ef91bb196b0d ("kernel.h: Silence sparse warning in lower_32_bits")
Otherwise
Tested-by: Guenter Roeck <[email protected]>
> Reported-by: Guenter Roeck <[email protected]>
> Cc: Li Yang <[email protected]>
> Cc: Zhang Wei <[email protected]>
> Cc: Dan Williams <[email protected]>
> Cc: Vinod Koul <[email protected]>
> Cc: Herbert Xu <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Signed-off-by: Luc Van Oostenryck <[email protected]>
> ---
> drivers/dma/fsldma.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
> index 56f18ae99233..6f6fa7641fa2 100644
> --- a/drivers/dma/fsldma.h
> +++ b/drivers/dma/fsldma.h
> @@ -205,7 +205,7 @@ struct fsldma_chan {
> #else
> static u64 fsl_ioread64(const u64 __iomem *addr)
> {
> - u32 fsl_addr = lower_32_bits(addr);
> + u32 fsl_addr = (u32) addr;
> u64 fsl_addr_hi = (u64)in_le32((u32 *)(fsl_addr + 1)) << 32;
>
> return fsl_addr_hi | in_le32((u32 *)fsl_addr);
> @@ -219,7 +219,7 @@ static void fsl_iowrite64(u64 val, u64 __iomem *addr)
>
> static u64 fsl_ioread64be(const u64 __iomem *addr)
> {
> - u32 fsl_addr = lower_32_bits(addr);
> + u32 fsl_addr = (u32) addr;
> u64 fsl_addr_hi = (u64)in_be32((u32 *)fsl_addr) << 32;
>
> return fsl_addr_hi | in_be32((u32 *)(fsl_addr + 1));
> --
> 2.28.0
>
On 8/29/20 5:45 AM, Herbert Xu wrote:
> On Sat, Aug 29, 2020 at 03:51:16AM -0700, Guenter Roeck wrote:
>>
>> This patch results in the following compile error when compiling
>> ppc:mpc85xx_defconfig.
>>
>> Error log:
>> In file included from ./include/linux/list.h:9,
>> from ./include/linux/module.h:12,
>> from drivers/dma/fsldma.c:23:
>> drivers/dma/fsldma.h: In function 'fsl_ioread64':
>> ./include/linux/kernel.h:189:37: error: invalid operands to binary & (have 'const u64 *' {aka 'const long long unsigned int *'} and 'unsigned int')
>> 189 | #define lower_32_bits(n) ((u32)((n) & 0xffffffff))
>> | ^
>> drivers/dma/fsldma.h:208:17: note: in expansion of macro 'lower_32_bits'
>> 208 | u32 fsl_addr = lower_32_bits(addr);
>> | ^~~~~~~~~~~~~
>> drivers/dma/fsldma.h: In function 'fsl_ioread64be':
>> ./include/linux/kernel.h:189:37: error: invalid operands to binary & (have 'const u64 *' {aka 'const long long unsigned int *'} and 'unsigned int')
>> 189 | #define lower_32_bits(n) ((u32)((n) & 0xffffffff))
>> | ^
>> drivers/dma/fsldma.h:222:17: note: in expansion of macro 'lower_32_bits'
>> 222 | u32 fsl_addr = lower_32_bits(addr);
>> | ^~~~~~~~~~~~~
>> make[2]: *** [drivers/dma/fsldma.o] Error 1
>
> Thanks for the report. Passing a pointer to lower_32_bits is just
> bad.
>
> ---8<---
> The functions fsl_ioread64* were passing a pointer to lower_32_bits
> which just happened to work because it was a macro that simply did
> a cast on the argument.
>
> However, now that lower_32_bits does a mask on the argument it no
> longer works. Passing a pointer to lower_32_bits doesn't look
> right anyway.
>
> This patch adds explicit casts so that an integer is passed along
> as the argument to lower_32_bits.
>
> Reported-by: Guenter Roeck <[email protected]>
> Signed-off-by: Herbert Xu <[email protected]>
Works as well as the other patch.
Tested-by: Guenter Roeck <[email protected]>
Guenter
>
> diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
> index 56f18ae99233..da5816b1706e 100644
> --- a/drivers/dma/fsldma.h
> +++ b/drivers/dma/fsldma.h
> @@ -205,7 +205,7 @@ struct fsldma_chan {
> #else
> static u64 fsl_ioread64(const u64 __iomem *addr)
> {
> - u32 fsl_addr = lower_32_bits(addr);
> + u32 fsl_addr = lower_32_bits((unsigned long)addr);
> u64 fsl_addr_hi = (u64)in_le32((u32 *)(fsl_addr + 1)) << 32;
>
> return fsl_addr_hi | in_le32((u32 *)fsl_addr);
> @@ -219,7 +219,7 @@ static void fsl_iowrite64(u64 val, u64 __iomem *addr)
>
> static u64 fsl_ioread64be(const u64 __iomem *addr)
> {
> - u32 fsl_addr = lower_32_bits(addr);
> + u32 fsl_addr = lower_32_bits((unsigned long)addr);
> u64 fsl_addr_hi = (u64)in_be32((u32 *)fsl_addr) << 32;
>
> return fsl_addr_hi | in_be32((u32 *)(fsl_addr + 1));
>
Le 29/08/2020 à 17:05, Guenter Roeck a écrit :
> On Sat, Aug 29, 2020 at 02:45:38PM +0200, Luc Van Oostenryck wrote:
>> For ppc32, the functions fsl_ioread64() & fsl_ioread64be()
>> use lower_32_bits() as a fancy way to cast the pointer to u32
>> in order to do non-atomic 64-bit IO.
>>
>> But the pointer is already 32-bit, so simply cast the pointer to u32.
>>
>> This fixes a compile error introduced by
>> ef91bb196b0d ("kernel.h: Silence sparse warning in lower_32_bits")
>>
>> Fixes: ef91bb196b0db1013ef8705367bc2d7944ef696b
>
> checkpatch complains about this and prefers
>
> Fixes: ef91bb196b0d ("kernel.h: Silence sparse warning in lower_32_bits")
Checkpatch also complains about spacing:
CHECK:SPACING: No space is necessary after a cast
#39: FILE: drivers/dma/fsldma.h:208:
+ u32 fsl_addr = (u32) addr;
CHECK:SPACING: No space is necessary after a cast
#48: FILE: drivers/dma/fsldma.h:222:
+ u32 fsl_addr = (u32) addr;
total: 0 errors, 0 warnings, 2 checks, 16 lines checked
Christophe
>
> Otherwise
>
> Tested-by: Guenter Roeck <[email protected]>
>
>> Reported-by: Guenter Roeck <[email protected]>
>> Cc: Li Yang <[email protected]>
>> Cc: Zhang Wei <[email protected]>
>> Cc: Dan Williams <[email protected]>
>> Cc: Vinod Koul <[email protected]>
>> Cc: Herbert Xu <[email protected]>
>> Cc: [email protected]
>> Cc: [email protected]
>> Cc: [email protected]
>> Signed-off-by: Luc Van Oostenryck <[email protected]>
>> ---
>> drivers/dma/fsldma.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
>> index 56f18ae99233..6f6fa7641fa2 100644
>> --- a/drivers/dma/fsldma.h
>> +++ b/drivers/dma/fsldma.h
>> @@ -205,7 +205,7 @@ struct fsldma_chan {
>> #else
>> static u64 fsl_ioread64(const u64 __iomem *addr)
>> {
>> - u32 fsl_addr = lower_32_bits(addr);
>> + u32 fsl_addr = (u32) addr;
>> u64 fsl_addr_hi = (u64)in_le32((u32 *)(fsl_addr + 1)) << 32;
>>
>> return fsl_addr_hi | in_le32((u32 *)fsl_addr);
>> @@ -219,7 +219,7 @@ static void fsl_iowrite64(u64 val, u64 __iomem *addr)
>>
>> static u64 fsl_ioread64be(const u64 __iomem *addr)
>> {
>> - u32 fsl_addr = lower_32_bits(addr);
>> + u32 fsl_addr = (u32) addr;
>> u64 fsl_addr_hi = (u64)in_be32((u32 *)fsl_addr) << 32;
>>
>> return fsl_addr_hi | in_be32((u32 *)(fsl_addr + 1));
>> --
>> 2.28.0
>>
On Sat, Aug 29, 2020 at 5:46 AM Luc Van Oostenryck
<[email protected]> wrote:
>
> But the pointer is already 32-bit, so simply cast the pointer to u32.
Yeah, that code was completely pointless. If the pointer had actually
been 64-bit, the old code would have warned too.
The odd thing is that the fsl_iowrite64() functions make sense. It's
only the fsl_ioread64() functions that seem to be written by somebody
who is really confused.
That said, this patch only humors the confusion. The cast to 'u32' is
completely pointless. In fact, it seems to be actively wrong, because
it means that the later "fsl_addr + 1" is done entirely incorrectly -
it now literally adds "1" to an integer value, while the iowrite()
functions will add one to a "u32 __iomem *" pointer (so will do
pointer arithmetic, and add 4).
So this code has never ever worked correctly to begin with, but the
patches to fix the warning miss the point. The problem isn't the
warning, the problem is that the code is broken and completely wrong
to begin with.
And the "lower_32_bits()" thing has always been pure and utter
confusion and complete garbage.
I *think* the right patch is the one attached, but since this code is
clearly utterly broken, I'd want somebody to test it.
It has probably never ever worked on 32-bit powerpc, or did so purely
by mistake (perhaps because nobody really cares - the only 64-bit use
is this:
static dma_addr_t get_cdar(struct fsldma_chan *chan)
{
return FSL_DMA_IN(chan, &chan->regs->cdar, 64) & ~FSL_DMA_SNEN;
}
and there are two users of that: one which ignores the return value,
and one that looks like it might end up half-way working even if the
value read was garbage (it's used only to compare against a "current
descriptor" value).
Anyway, the fix is definitely not to just shut up the warning. The
warning is only a sign of utter confusion in that driver.
Can somebody with the hardware test this on 32-bit ppc?
And if not (judging by just how broken those functions are, maybe it
never did work), can somebody with a ppc32 setup at least compile-test
this patch and look at whether it makes sense, in ways the old code
did not.
Linus
On 8/29/20 10:29 AM, Linus Torvalds wrote:
> On Sat, Aug 29, 2020 at 5:46 AM Luc Van Oostenryck
> <[email protected]> wrote:
>>
>> But the pointer is already 32-bit, so simply cast the pointer to u32.
>
> Yeah, that code was completely pointless. If the pointer had actually
> been 64-bit, the old code would have warned too.
>
> The odd thing is that the fsl_iowrite64() functions make sense. It's
> only the fsl_ioread64() functions that seem to be written by somebody
> who is really confused.
>
> That said, this patch only humors the confusion. The cast to 'u32' is
> completely pointless. In fact, it seems to be actively wrong, because
> it means that the later "fsl_addr + 1" is done entirely incorrectly -
> it now literally adds "1" to an integer value, while the iowrite()
> functions will add one to a "u32 __iomem *" pointer (so will do
> pointer arithmetic, and add 4).
>
Outch.
> So this code has never ever worked correctly to begin with, but the
> patches to fix the warning miss the point. The problem isn't the
> warning, the problem is that the code is broken and completely wrong
> to begin with.
>
> And the "lower_32_bits()" thing has always been pure and utter
> confusion and complete garbage.
>
> I *think* the right patch is the one attached, but since this code is
> clearly utterly broken, I'd want somebody to test it.
>
> It has probably never ever worked on 32-bit powerpc, or did so purely
> by mistake (perhaps because nobody really cares - the only 64-bit use
> is this:
>
> static dma_addr_t get_cdar(struct fsldma_chan *chan)
> {
> return FSL_DMA_IN(chan, &chan->regs->cdar, 64) & ~FSL_DMA_SNEN;
> }
>
> and there are two users of that: one which ignores the return value,
> and one that looks like it might end up half-way working even if the
> value read was garbage (it's used only to compare against a "current
> descriptor" value).
>
> Anyway, the fix is definitely not to just shut up the warning. The
> warning is only a sign of utter confusion in that driver.
>
> Can somebody with the hardware test this on 32-bit ppc?
>
> And if not (judging by just how broken those functions are, maybe it
> never did work), can somebody with a ppc32 setup at least compile-test
> this patch and look at whether it makes sense, in ways the old code
> did not.
>
A bit more careful this time. For the attached patch:
Compile-tested-by: Guenter Roeck <[email protected]>
Except for
CHECK: spaces preferred around that '+' (ctx:VxV)
#29: FILE: drivers/dma/fsldma.h:223:
+ u32 val_lo = in_be32((u32 __iomem *)addr+1);
I don't see anything wrong with it either, so
Reviewed-by: Guenter Roeck <[email protected]>
Since I didn't see the real problem with the original code,
I'd take that with a grain of salt, though.
Guenter
On Sat, Aug 29, 2020 at 1:40 PM Guenter Roeck <[email protected]> wrote:
>
> Except for
>
> CHECK: spaces preferred around that '+' (ctx:VxV)
> #29: FILE: drivers/dma/fsldma.h:223:
> + u32 val_lo = in_be32((u32 __iomem *)addr+1);
Added spaces.
> I don't see anything wrong with it either, so
>
> Reviewed-by: Guenter Roeck <[email protected]>
>
> Since I didn't see the real problem with the original code,
> I'd take that with a grain of salt, though.
Well, honestly, the old code was so confused that just making it build
is clearly already an improvement even if everything else were to be
wrong.
So I committed my "fix". If it turns out there's more wrong in there
and somebody tests it, we can fix it again. But now it hopefully
compiles, at least.
My bet is that if that driver ever worked on ppc32, it will continue
to work whatever we do to that function.
I _think_ the old code happened to - completely by mistake - get the
value right for the case of "little endian access, with dma_addr_t
being 32-bit". Because then it would still read the upper bits wrong,
but the cast to dma_addr_t would then throw those bits away. And the
lower bits would be right.
But for big-endian accesses or for ARCH_DMA_ADDR_T_64BIT it really
looks like it always returned a completely incorrect value.
And again - the driver may have worked even with that completely
incorrect value, since the use of it seems to be very incidental.
In either case ("it didn't work before" or "it worked because the
value doesn't really matter"), I don't think I could possibly have
made things worse.
Famous last words.
Linus
On Sat, Aug 29, 2020 at 10:29:55AM -0700, Linus Torvalds wrote:
> On Sat, Aug 29, 2020 at 5:46 AM Luc Van Oostenryck
> <[email protected]> wrote:
> >
> > But the pointer is already 32-bit, so simply cast the pointer to u32.
>
> Yeah, that code was completely pointless. If the pointer had actually
> been 64-bit, the old code would have warned too.
>
> The odd thing is that the fsl_iowrite64() functions make sense. It's
> only the fsl_ioread64() functions that seem to be written by somebody
> who is really confused.
>
> That said, this patch only humors the confusion. The cast to 'u32' is
> completely pointless. In fact, it seems to be actively wrong, because
> it means that the later "fsl_addr + 1" is done entirely incorrectly -
> it now literally adds "1" to an integer value, while the iowrite()
> functions will add one to a "u32 __iomem *" pointer (so will do
> pointer arithmetic, and add 4).
>
My bad. I had noticed the '+ 1' and so automatically assumed
'OK, pointer arithmetic now' without noticing that the cast was
done only after the addition. Grrr.
FWIW, the version you committed looks much better to me.
-- Luc
Linus Torvalds <[email protected]> writes:
> On Sat, Aug 29, 2020 at 1:40 PM Guenter Roeck <[email protected]> wrote:
>>
>> Except for
>>
>> CHECK: spaces preferred around that '+' (ctx:VxV)
>> #29: FILE: drivers/dma/fsldma.h:223:
>> + u32 val_lo = in_be32((u32 __iomem *)addr+1);
>
> Added spaces.
>
>> I don't see anything wrong with it either, so
>>
>> Reviewed-by: Guenter Roeck <[email protected]>
>>
>> Since I didn't see the real problem with the original code,
>> I'd take that with a grain of salt, though.
>
> Well, honestly, the old code was so confused that just making it build
> is clearly already an improvement even if everything else were to be
> wrong.
The old code is not that old, only ~18 months:
a1ff82a9c165 ("dmaengine: fsldma: Adding macro FSL_DMA_IN/OUT implement for ARM platform") (Jan 2019)
So I think it's possible it's never been tested on 32-bit ppc at all.
I did have a 32-bit FSL machine but it lost its network card in a power
outage and now it won't boot (and I can't get to it physically).
> So I committed my "fix". If it turns out there's more wrong in there
> and somebody tests it, we can fix it again. But now it hopefully
> compiles, at least.
>
> My bet is that if that driver ever worked on ppc32, it will continue
> to work whatever we do to that function.
>
> I _think_ the old code happened to - completely by mistake - get the
> value right for the case of "little endian access, with dma_addr_t
> being 32-bit". Because then it would still read the upper bits wrong,
> but the cast to dma_addr_t would then throw those bits away. And the
> lower bits would be right.
>
> But for big-endian accesses or for ARCH_DMA_ADDR_T_64BIT it really
> looks like it always returned a completely incorrect value.
>
> And again - the driver may have worked even with that completely
> incorrect value, since the use of it seems to be very incidental.
>
> In either case ("it didn't work before" or "it worked because the
> value doesn't really matter"), I don't think I could possibly have
> made things worse.
Agreed.
Hopefully someone from NXP can test it.
cheers
Hi Linus,
On 29-08-20, 14:20, Linus Torvalds wrote:
> On Sat, Aug 29, 2020 at 1:40 PM Guenter Roeck <[email protected]> wrote:
> >
> > Except for
> >
> > CHECK: spaces preferred around that '+' (ctx:VxV)
> > #29: FILE: drivers/dma/fsldma.h:223:
> > + u32 val_lo = in_be32((u32 __iomem *)addr+1);
>
> Added spaces.
>
> > I don't see anything wrong with it either, so
> >
> > Reviewed-by: Guenter Roeck <[email protected]>
> >
> > Since I didn't see the real problem with the original code,
> > I'd take that with a grain of salt, though.
>
> Well, honestly, the old code was so confused that just making it build
> is clearly already an improvement even if everything else were to be
> wrong.
>
> So I committed my "fix". If it turns out there's more wrong in there
> and somebody tests it, we can fix it again. But now it hopefully
> compiles, at least.
>
> My bet is that if that driver ever worked on ppc32, it will continue
> to work whatever we do to that function.
>
> I _think_ the old code happened to - completely by mistake - get the
> value right for the case of "little endian access, with dma_addr_t
> being 32-bit". Because then it would still read the upper bits wrong,
> but the cast to dma_addr_t would then throw those bits away. And the
> lower bits would be right.
>
> But for big-endian accesses or for ARCH_DMA_ADDR_T_64BIT it really
> looks like it always returned a completely incorrect value.
>
> And again - the driver may have worked even with that completely
> incorrect value, since the use of it seems to be very incidental.
Thank you for the fix.
Acked-By: Vinod Koul <[email protected]>
>
> In either case ("it didn't work before" or "it worked because the
> value doesn't really matter"), I don't think I could possibly have
> made things worse.
>
> Famous last words.
I guess no one tested this on 32bits seems to have caused this.
--
~Vinod
> -----Original Message-----
> From: Linus Torvalds <[email protected]>
> Sent: Saturday, August 29, 2020 4:20 PM
> To: Guenter Roeck <[email protected]>
> Cc: Luc Van Oostenryck <[email protected]>; Herbert Xu
> <[email protected]>; Andrew Morton <akpm@linux-
> foundation.org>; Joerg Roedel <[email protected]>; Leo Li
> <[email protected]>; Zhang Wei <[email protected]>; Dan Williams
> <[email protected]>; Vinod Koul <[email protected]>; linuxppc-dev
> <[email protected]>; dma <[email protected]>; Linux
> Kernel Mailing List <[email protected]>
> Subject: Re: [PATCH] fsldma: fsl_ioread64*() do not need lower_32_bits()
>
> On Sat, Aug 29, 2020 at 1:40 PM Guenter Roeck <[email protected]> wrote:
> >
> > Except for
> >
> > CHECK: spaces preferred around that '+' (ctx:VxV)
> > #29: FILE: drivers/dma/fsldma.h:223:
> > + u32 val_lo = in_be32((u32 __iomem *)addr+1);
>
> Added spaces.
>
> > I don't see anything wrong with it either, so
> >
> > Reviewed-by: Guenter Roeck <[email protected]>
> >
> > Since I didn't see the real problem with the original code, I'd take
> > that with a grain of salt, though.
>
> Well, honestly, the old code was so confused that just making it build is
> clearly already an improvement even if everything else were to be wrong.
>
> So I committed my "fix". If it turns out there's more wrong in there and
> somebody tests it, we can fix it again. But now it hopefully compiles, at least.
>
> My bet is that if that driver ever worked on ppc32, it will continue to work
> whatever we do to that function.
>
> I _think_ the old code happened to - completely by mistake - get the value
> right for the case of "little endian access, with dma_addr_t being 32-bit".
> Because then it would still read the upper bits wrong, but the cast to
> dma_addr_t would then throw those bits away. And the lower bits would be
> right.
>
> But for big-endian accesses or for ARCH_DMA_ADDR_T_64BIT it really looks
> like it always returned a completely incorrect value.
>
> And again - the driver may have worked even with that completely incorrect
> value, since the use of it seems to be very incidental.
>
> In either case ("it didn't work before" or "it worked because the value
> doesn't really matter"), I don't think I could possibly have made things worse.
>
> Famous last words.
Thanks for the patch.
Acked-by: Li Yang <[email protected]>
We are having periodical auto regression tests covering ppc32 platforms. But looks like it missed this issue. I will ask the test team to investigate on why the test cases are not sufficient.
Regards,
Leo