diff options
author | Marek Behún <marek.behun@nic.cz> | 2021-03-04 11:23:14 +0100 |
---|---|---|
committer | Stefan Roese <sr@denx.de> | 2021-03-12 07:44:21 +0100 |
commit | e5b3e87dfaf29cde3d125cef58406f3fbe7f5669 (patch) | |
tree | 6ae9983c5414aa0de3ae2a36d6ec12719ff0574b /drivers/ddr/marvell/axp/ddr3_dfs.c | |
parent | 107c3391b95bcc2ba09a876da4fa0c31b6c1e460 (diff) |
ddr: marvell: axp: align signature of mv_xor_mem_init() with a38x
In arch/arm/mach-mvebu/dram.c we always include axp's xor.h for common
XOR definitions, regardless whether we compile for axp or a38x.
But the declaration of this function has a different signature in axp's
xor.h from the one used in a38x' implementation - one parameter is u64
instead of u32. This can result in wrong argument's being passed to that
function on a38x with no one the wiser.
I discovered this when building U-Boot for Turris Omnia with LTO. The
compiler complains about the different signatures being thrown into the
same linking process:
axp/xor.h:67:5: warning: type of ‘mv_xor_mem_init’ does not match
original declaration [-Wlto-type-mismatch]
67 | int mv_xor_mem_init(u32 chan, u32 start_ptr, u32 block_size,
| ^
a38x/xor.c:165:5: note: type mismatch in parameter 3
165 | int mv_xor_mem_init(u32 chan, u32 start_ptr, unsigned long long
| ^
a38x/xor.c:165:5: note: type ‘long long unsigned int’ should match
type ‘u32’
Fix this by changing the type of the block_size argument in the axp's
implementation and header file to the one used in a38x (and upstream
mv-ddr-marvell).
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Diffstat (limited to 'drivers/ddr/marvell/axp/ddr3_dfs.c')
0 files changed, 0 insertions, 0 deletions