isp: Endianness of firmware data

Sepherosa Ziehau sepherosa at
Thu Jun 1 18:07:33 PDT 2017

On Fri, Jun 2, 2017 at 4:58 AM, Ján Sučan <sucanjan at> wrote:
> Hello to all,
> I would like to ask for a help with an issue for which I am not sure
> about a clean solution.
> With isp driver firmware I wanted to do the same as I did with mxge: to
> move firmware data from arrays in C header files to uuencode .uu files
> in a sys/contrib/isp.
> The issue is that the firmware is stored in arrays of uint16_t. The isp
> driver has macros for handling the firmware data on both little-endian
> and big-endian machines. But it seems, that it uses some of those
> uint16_t values not caring about endianness (see the
> sys/dev/disk/isp/isp.c line 841 where the value is used directly for
> controlling number of repetitions of a while cycle).
> Currently, the correct order is ensured at compile-time. If the firmware
> is moved to files it will be saved with fixed endianness. So it wil be
> OK on little-endian and bad on big-endian or the other way around.
> I think of modifying firmware data right after firmware_get() so driver
> will find expected endianness.

Maybe just generate two version of uu files (one big endian, one
little endian), and install the correct version of uu file (we only
support little endian currently).  This may be simpler than other


Tomorrow Will Never Die

More information about the Kernel mailing list