Re: [drm-exynos:dmabuf-sync 6976/8283] drivers/ata/libata-core.c:574:19: sparse: restricted __le32 degrades to integer

[Tejun Heo <tj@kernel.org>]

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