On 11.02.2022 10:57:34, Stéphane Grosjean wrote: > endianess is handled by lower level functions (see for ex > pcan_usb_fd_get_user_devid()/pcan_usb_fd_set_user_devid() in PATCH > 2/6). > > This data is really a number and must be treated as such. What's the use case for the data/number? What's the big picture? > The "ethtool -e" interface only displays a silly memory dump not very > practical to read a number (especially a 32-bit one), requiring the > use of hexdump such as: > > ethtool -e can1 raw on | hexdump -v -e '1 "%u\n"' On a little endian system this gives: | ➜ (pts/0) frogger@rpi4b4:~ (master) sudo ethtool -e can0 | Offset Values | ------ ------ | 0x0000: 11 22 33 44 On a big endian we see: | root@DistroKit:~ ethtool -e can0 | Offset Values | ------ ------ | 0x0000: 44 33 22 11 However, if we pass it through hexdump it's always the same: | root@DistroKit:~ ethtool -e can0 raw on|hexdump -v -e '1 "%u\n"' | 1144201745 | ➜ (pts/0) frogger@rpi4b4:~ (master) sudo ethtool -e can0 raw on|hexdump -v -e '1 "%u\n"' | 1144201745 Why does the hexdump give the same number? I think it interprets the memory in native endianness. > to have a usable display. Unfortunately, these formats do not take > endianess into account (AFAIK). Maybe you know another way? I think from the ethtool's point of view the "EEPROM" contents is a stream of bytes. With your patches the EEPROM contents is not the same on big and little endian systems, rather the EEPROM contents is a 32 bit number in native endianness. From my point of view I think it's more consistent to have the EEPROM contain a u32 in little endian. But I'm really interested in the use cases. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: PGP signature
