* Re: [drm-exynos:dmabuf-sync 6976/8283] drivers/ata/libata-core.c:574:19: sparse: restricted __le32 degrades to integer
[not found] <52216105.LDLPibKhwtk4ZtnD%fengguang.wu@intel.com>
@ 2013-08-31 13:04 ` Tejun Heo
0 siblings, 0 replies; only message in thread
From: Tejun Heo @ 2013-08-31 13:04 UTC (permalink / raw)
To: kbuild test robot; +Cc: Marc Carino, kbuild-all, linux-ide
Hello, Marc.
On Sat, Aug 31, 2013 at 11:20:37AM +0800, kbuild test robot wrote:
> tree: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos dmabuf-sync
> head: 22c9eba34ec4787b6a32dcf521c6e07b3abfc146
> commit: 8be5ad9acb7c11b9d717bcdbe3d6de0dab081a39 [6976/8283] libata: Populate host-to-device FIS "auxiliary" field
> reproduce: make C=1 CF=-D__CHECK_ENDIAN__
...
> > 574 fis[16] = aux & 0xff;
> 575 fis[17] = (aux >> 8) & 0xff;
> 576 fis[18] = (aux >> 16) & 0xff;
> 577 fis[19] = (aux >> 24) & 0xff;
So, this warning comes from ->aux handling in ata_tf_to_fis() and
looking at it I don't think the code is correct.
const __le32 aux = cpu_to_le32(tf->auxiliary);
...
fis[16] = aux & 0xff;
fis[17] = (aux >> 8) & 0xff;
fis[18] = (aux >> 16) & 0xff;
fis[19] = (aux >> 24) & 0xff;
If it's byte-by-byte assignments, why is it doing cpu_to_le32() too?
The above code is broken and will actually make fis[] fields to be
big-endian on big-endian machines.
Please consider the following.
u32 a = 0x01020304;
printf("%d %d %d %d\n", a & 0xff, (a >> 8) & 0xff,
(a >> 16) & 0xff, (a >> 24) & 0xff);
The output will *always* be "1 2 3 4" regardless of the endianness of
the machine.
Can you please submit a patch to fix this?
Thanks.
--
tejun
^ permalink raw reply [flat|nested] only message in thread