aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/scripts/gdb/linux/interrupts.py
diff options
context:
space:
mode:
authorSimon Horman <horms@kernel.org>2025-05-20 15:25:41 +0100
committerDavid S. Miller <davem@davemloft.net>2025-05-25 15:08:24 +0100
commitb3456571cea18e64b9eaf55044db56d45326134d (patch)
tree768c3dc64d71e6703be2e174141252588ebe2e08 /scripts/gdb/linux/interrupts.py
parentocteontx2-af: NPC: Clear Unicast rule on nixlf detach (diff)
downloadwireguard-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