diff options
author | 2025-05-20 15:25:41 +0100 | |
---|---|---|
committer | 2025-05-25 15:08:24 +0100 | |
commit | b3456571cea18e64b9eaf55044db56d45326134d (patch) | |
tree | 768c3dc64d71e6703be2e174141252588ebe2e08 /scripts/gdb/linux/utils.py | |
parent | octeontx2-af: NPC: Clear Unicast rule on nixlf detach (diff) | |
download | wireguard-linux-b3456571cea18e64b9eaf55044db56d45326134d.tar.xz wireguard-linux-b3456571cea18e64b9eaf55044db56d45326134d.zip |
net: dlink: Correct endian treatment of t_SROM data
As it's name suggests, parse_eeprom() parses EEPROM data.
This is done by reading data, 16 bits at a time as follows:
for (i = 0; i < 128; i++)
((__le16 *) sromdata)[i] = cpu_to_le16(read_eeprom(np, i));
sromdata is at the same memory location as psrom.
And the type of psrom is a pointer to struct t_SROM.
As can be seen in the loop above, data is stored in sromdata, and thus
psrom, as 16-bit little-endian values. However, the integer fields of
t_SROM are host byte order.
In the case of the led_mode field this results in a but which has been
addressed by commit e7e5ae71831c ("net: dlink: Correct endianness
handling of led_mode").
In the case of the remaining fields, which are updated by this patch,
I do not believe this does not result in any bugs. But it does seem
best to correctly annotate the endianness of integers.
Flagged by Sparse as:
.../dl2k.c:344:35: warning: restricted __le32 degrades to integer
Compile tested only.
No run-time change intended.
Signed-off-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions