From: Sreekanth Reddy <sreekanth.reddy@xxxxxxxxxxxx>
Date: Mon, 9 Jul 2018 17:12:51 +0530
> This is a shared structure between the host drivers and HBA device.
> HBA Firmware sends the information though this structures which are
> defined in the MPI headers. Now we can't change the order of these u8
> objects.
>
> typedef struct _MPI2_DEFAULT_REPLY {
> U16 FunctionDependent1; /*0x00 */
> U8 MsgLength; /*0x02 */
> U8 Function; /*0x03 */
> U16 FunctionDependent2; /*0x04 */
When a big-endian cpu stores a 16-bit or 32-bit value into a piece of
"cpu memory", which is what you are doing before interpreting the u8
values, you must define the u8 components in the endianness order
they will be stored in.
Alternatively, you must extract the 8-bit values by hand using
shifts and masks in a local variable.
The huge problem is that you are mixing and matching I/O memory
accessors which do endianness swaps for you, and normal cpu
loads and stores into a data structure in cpu memory, then
reading smaller sized components back and expects this all to
work out properly.
In fact, if you want to keep the structure definition above
as-is, you should swap the I/O memory read value _BACK_ to
cpu endianness before storing it.
And in fact that is what the code is doing now, which you broke by
trying to "fix" it.
Meanwhile, this discussion has been drawn out way way way too long,
and the fact is that your change broke big endian instead of fixing
any real problem whatsoever. You did not test your change on any real
big endian system.
Therefore, as requested from the very beginning, would you please
revert this change which broke big endian and for which you do not
have a satisfactory resolution for at this time.
This is how regressions are handled, if a fix cannot be procured in a
short amount of time, we revert.
Thank you.
