linux-kernel - Re: [PATCH] staging: octeon: type change from uint<bits>

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: <20260210101952.631bf50c@pumpkin>
Date: Tue, 10 Feb 2026 10:19:52 +0000
From: David Laight <david.laight.linux@...il.com>
To: Yoelvis Oliveros <yoelvisoliveros@...il.com>
Cc: gregkh@...uxfoundation.org, linux-staging@...ts.linux.dev,
 linux-kernel@...r.kernel.org, outreachy@...ts.linux.dev
Subject: Re: [PATCH] staging: octeon: type change from uint<bits>_t to
 u<bits>

On Tue, 10 Feb 2026 00:36:31 -0400
Yoelvis Oliveros <yoelvisoliveros@...il.com> wrote:

> Runing the ckeckpatch.pl on the staging/octeon driver they where using
> uint<8/16/32/64>_T as type declaration and the checkpatch.pl was
> putting a [CHECK] flag on those and that they should be change to
> u<8/16/32/64>
> 
...
>  	struct {
> -		u64 bufs         : 8;
> -		u64 ip_offset    : 8;
> -		u64 vlan_valid   : 1;
>  		u64 vlan_stacked : 1;
> -		u64 unassigned   : 1;
> -		u64 vlan_cfi     : 1;
> -		u64 vlan_id      : 12;
> -		u64 pr           : 4;
> -		u64 unassigned2  : 8;
> -		u64 dec_ipcomp   : 1;
> -		u64 tcp_or_udp   : 1;
> -		u64 dec_ipsec    : 1;
> -		u64 is_v6        : 1;
> -		u64 software     : 1;
> -		u64 L4_error     : 1;
> -		u64 is_frag      : 1;
> -		u64 IP_exc       : 1;
> -		u64 is_bcast     : 1;
> -		u64 is_mcast     : 1;
> -		u64 not_IP       : 1;
> -		u64 rcv_error    : 1;
> -		u64 err_code     : 8;
>  	} s;

As a separate issue, what is the purpose of all these bit-field structures?
You can't portably use C bit-fields to map hardware registers or network
packets.
It isn't just byte-order, the 'bit order' can differ even for the same
endianness.

It also doesn't seem ideal to base everything on u64.
The (aligned) 8 bit fields should really be plain 'u8', there are places
where it does make a difference.

	David