Re: [net] can: gs_usb: fix endianess problem with candleLight firmware

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 20.11.20 12:39, Marc Kleine-Budde wrote:
On 11/20/20 12:23 PM, Oliver Hartkopp wrote:


On 20.11.20 11:38, Marc Kleine-Budde wrote:
The firmware on the original USB2CAN by Geschwister Schneider Technologie
Entwicklungs- und Vertriebs UG exchanges all data between the host and the
device in host byte order. This is done with the struct
gs_host_config::byte_order member, which is sent first to indicate the desired
byte order.

The widely used open source firmware candleLight doesn't support this feature
and exchanges the data in little endian byte order. This breaks if a device
with candleLight firmware is used on big endianess systems.

Looks like this problem showed up pretty late.

There are not that many BE users out there...

Won't it be better to implement the feature in the candlelight firmware
so that only the big endian users need to upgrade the candlelight
firmware instead of disabling this nice feature?

It's easier to update the Linux driver, for LE Linux host systems this is
basically a no-op.

Ok. And with these changes

>   struct gs_host_config {
> -	u32 byte_order;
> +	__le32 byte_order;
>   } __packed;


>
> -	hconf->byte_order = 0x0000beef;
> +	hconf->byte_order = cpu_to_le32(0x0000beef);
>

the original GS_USB hardware is pinned to always provide little endian, right?




[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux