On Tue, Jul 10, 2018 at 2:38 AM, David Miller <davem@xxxxxxxxxxxxx> wrote:
> 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.
I am trying to revert patch commit cf6bf9710c (scsi: mpt3sas: Bug fix
for big endian systems) but revert operation is not happening
smoothly, it may be due to dependency with some other patch changes.
Anyway in this patch we have reverted those hunks of cf6bf9710c patch
which are problematic other hunks of cf6bf9710c patch are good. Can't
this patch be considered? or shall I resend this patch with
description(i.e. patch header) change.
Thanks,
Sreekanth
>
> This is how regressions are handled, if a fix cannot be procured in a
> short amount of time, we revert.
>
> Thank you.
