Re: [PATCH] staging: octeon: type change from uint<bits>_t to u<bits>

[David Laight <david.laight.linux@gmail.com>]

On Tue, 10 Feb 2026 00:36:31 -0400
Yoelvis Oliveros <yoelvisoliveros@gmail.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