netdev - Re: [PATCH 13/15] octeontx2-af: Add support for CGX link management

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAK8P3a2RvKrT9BYOGaNEWd=_Qg9xg+GWysok+eyQLsTmrv6UqA@mail.gmail.com>
Date:   Fri, 28 Sep 2018 12:00:55 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Sunil Kovvuri <sunil.kovvuri@...il.com>
Cc:     Networking <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>, linux-soc@...r.kernel.org,
        lcherian@...vell.com, nmani@...vell.com
Subject: Re: [PATCH 13/15] octeontx2-af: Add support for CGX link management

On Fri, Sep 28, 2018 at 11:31 AM Sunil Kovvuri <sunil.kovvuri@...il.com> wrote:
> On Fri, Sep 28, 2018 at 1:49 PM Arnd Bergmann <arnd@...db.de> wrote:
> > On Fri, Sep 28, 2018 at 8:09 AM <sunil.kovvuri@...il.com> 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