netdev - Re: [PATCH v8 08/15] octeontx2-af: Add RVU block LF provisioning support

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a3koXRBzLmuaBOD2GmdV8v6AdKDNr+tGCTQCz5yjzQ7wQ@mail.gmail.com>
Date:   Mon, 8 Oct 2018 14:11:35 +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,
        sgoutham@...vell.com
Subject: Re: [PATCH v8 08/15] octeontx2-af: Add RVU block LF provisioning support

On Sun, Oct 7, 2018 at 5:00 PM <sunil.kovvuri@...il.com> wrote:
>
> +/* Structure for requesting resource provisioning.
> + * 'modify' flag to be used when either requesting more
> + * or to detach partial of a cetain resource type.
> + * Rest of the fields specify how many of what type to
> + * be attached.
> + */
> +struct rsrc_attach {
> +       struct mbox_msghdr hdr;
> +       u8   modify:1;
> +       u8   npalf:1;
> +       u8   nixlf:1;
> +       u16  sso;
> +       u16  ssow;
> +       u16  timlfs;
> +       u16  cptlfs;
> +};
> +
> +/* Structure for relinquishing resources.
> + * 'partial' flag to be used when relinquishing all resources
> + * but only of a certain type. If not set, all resources of all
> + * types provisioned to the RVU function will be detached.
> + */
> +struct rsrc_detach {
> +       struct mbox_msghdr hdr;
> +       u8 partial:1;
> +       u8 npalf:1;
> +       u8 nixlf:1;
> +       u8 sso:1;
> +       u8 ssow:1;
> +       u8 timlfs:1;
> +       u8 cptlfs:1;
> +};

Are these bitfields part of the message that gets sent to the
underlying implementation? It seems there is still an endianess
issue then.

       Arnd