Re: [PATCH net-next v09 1/8] hinic3: Async Event Queue interfaces

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 17 Jul 2025 11:02:29 +0300 Gur Stavi wrote:
> On Tue, 15 Jul 2025 08:28:36 +0800 Fan Gong wrote:
> > +/* Data provided to/by cmdq is arranged in structs with little endian fields but
> > + * every dword (32bits) should be swapped since HW swaps it again when it
> > + * copies it from/to host memory. This is a mandatory swap regardless of the
> > + * CPU endianness.  
> 
> > This comment makes no sense, FWIW. The device writes a byte steam
> > to host memory. For what you're saying to make sense the device would
> > have to intentionally switch the endian based on the host CPU.
> > And if it could do that why wouldn't it do it in the opposite
> > direction, avoiding the swap ? :/
> >
> > I suppose the device is always writing in be32 words, and you should
> > be converting from be32.
> >  
> 
> Lets assume the following is a simplified PACKED cmdq struct:
> 
> struct some_cmdq {
> 	__le16 a;
> 	__le32 b;
> 	__le16 c;
> };
> 
> Lets denote x0 as lsb of field x. x3 as msb of 32 bits field.
> 
> Byte stream in CPU memory is:
> a0, a1, b0, b1, b2, b3, c0, c1
> 
> The HW expects the following byte stream:
> b1, b0, a1, a0, c1, c0, b3 ,b2
> 
> A native struct would be:
> 
> struct some_cmdq {
> 	__be16 b_lo;
> 	__be16 a;
> 	__be16 c;
> 	__be16 b_hi;
> }
> 
> It does not make sense from code readability perspective.
> While this is a simplified example, there are similar problems in real cmdq
> structs.
> Also group of fields that makes sense (based on their names) for being
> logically near each other become separated in "native" big endian arrangements.
> 
> This is a case where driver need to compensate for bad HW decisions.

My point was just that the calculation does not survive change of
endian on the host. You given an example of the host struct being
in LE and then the swap working out. But IIRC the driver does not
use LE for its view of the fields. So the host view of the struct
is:

struct some_cmdq {
 	u16 a;
 	u32 b;
 	u16 c;
};

The comment saying that the swap is "regardless of host endianness"
is just confusion on the part of the author :/