Why data16[0] is not converted with le16toh() while the other elements of data16[] are?

This part is a bit confusing.

mpr_regread() uses bus_space_read_4() that, on big-endian (BE) platforms, already converts from little-endian (LE) to big-endian, right?
And constant values, such as MPI2_DOORBELL_DATA_MASK, are always expected to be in host endian.
So, it seems to me that this le16toh() call is actually converting a BE value to LE and not the opposite.

IIUC, adjust_iocfacts_endianness() is the part that really fixes the endianess of the reply, with several leXXtoh() calls, as it has the knowledge of the fields present in the reply. And the comment there tell us that these le16toh() calls here are only needed to preserve U8 fields in their original offsets.

So my suggestion here is to change all data16[] conversions to be16toh(), to make it clear what is happening.

This function swaps U16 and U32 fields.

Indentation is wrong.

Each level of indentation must be a (non-expanded) tab. 4 extra spaces should be used when continuing a line of code.
This comment also applies to the rest of the changes.

See style(9).

Why do you need two calls to le32toh()here, with masks, instead of only one with no mask?

It looks like the first 16 bits of MPI2_DEFAULT_REPLY are not used

It is a bit confusing, yes. If not swapping values here, adjust_iocfacts_endianness would have to adjust 8 bit fields with adjacent fields, and I thought it would be even more confusing. The suggestion of be16toh is a good one, thanks.

Ok, but I would use le16toh() here too, just in case the first 16 bits are used someday and for consistency with the other data16 elements that are all being converted.

You need 2 more spaces here.

It would be better to put this comment before the first use of le16toh() data16.

You should use 2 tabs here.

You should use 2 tabs here.

The SMID doesn’t need to be byte swapped. It's a host-private cookie that is opaque to the controller. Be sure to also not byte-swap the retrieval of the SMID on completion.

As stated previously, this is wrong. The le16toh() call should wrap just the return from mpr_regread(), and not include the bitwise & operation and the MPI2_DOORBELL_DATA_MASK macro.

Yeah, as above, I have no idea how this can work on a BE platform.

Probably makes sense to pre-swap these values. Not necessary for this review, however.

I put this here because the original code assumes that SMID is LE, lines 2555 and 2597 for example.