On Fri, Sep 28, 2018 at 11:31 AM Sunil Kovvuri <sunil.kovvuri@xxxxxxxxx> wrote:
> On Fri, Sep 28, 2018 at 1:49 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > On Fri, Sep 28, 2018 at 8:09 AM <sunil.kovvuri@xxxxxxxxx> wrote:
> This communication between firmware and kernel driver is done using couple of
> scratch registers. With limited space available we had to resort to bitfields.
> Your point about endianness is correct. As you might be aware that the device to
> which this driver registers to, is only found on OcteonTx2 SOC which operates
> in a standalone mode. As of now we are not targeting to make these drivers
> work in big-endian mode.
>
> We would prefer to make big-endian related changes later on, test them
> fully and
> submit patches, would this be okay ?
>
> If not we will define big endian bit fields in all command structures
> and re-submit.
Generally speaking, I think all drivers should be written in a portable way,
since you never know whether they will be reused in a different way later,
copied into other drivers, or used in creative ways by your users.
I would therefore recommend to change the bitfields now, but not
necessarily test big-endian builds. Well-written code should just work
out of the box in either endianess, and if someone finds a problem
there later, they can fix it themselves or report it. Just don't use
nonportable code intentionally.
Arnd
