Re: [PATCH 1/8] net: qualcomm: rmnet: fix struct rmnet_map_header

[Alex Elder]

On 5/20/19 3:11 PM, Subash Abhinov Kasiviswanathan wrote:
> On 2019-05-20 07:53, Alex Elder wrote:
>> The C bit-fields in the first byte of the rmnet_map_header structure
>> are defined in the wrong order. The first byte should be formatted
>> this way:
>> ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ +------- reserved_bit
>> ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ | +----- cd_bit
>> ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ | |
>> ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ v v
>> ÂÂÂ +-----------+-+-+
>>  | pad_len |R|C|
>> ÂÂÂ +-----------+-+-+
>> ÂÂÂÂ 7 6 5 4 3 2 1 0Â <-- bit position
>>
>> But the C bit-fields that define the first byte are defined this way:
>> ÂÂÂ u8 pad_len:6;
>> ÂÂÂ u8 reserved_bit:1;
>> ÂÂÂ u8 cd_bit:1;
>>
> 
> If the above illustration is supposed to be in network byte order,
> then it is wrong. The documentation has the definition for the MAP
> packet.

Network *bit* order is irrelevant to the host.  Host memory is
byte addressable only, and bit 0 is the low-order bit.

> Packet format -
> 
> BitÂÂÂÂÂÂÂÂÂÂÂÂ 0ÂÂÂÂÂÂÂÂÂÂÂÂ 1ÂÂÂÂÂÂÂÂÂÂ 2-7ÂÂÂÂÂ 8 - 15ÂÂÂÂÂÂÂÂÂÂ 16 - 31
> FunctionÂÂ Command / DataÂÂ ReservedÂÂÂÂ PadÂÂ Multiplexer IDÂÂÂ Payload length
> BitÂÂÂÂÂÂÂÂÂÂÂ 32 - x
> Function Raw Bytes

I don't know how to interpret this.  Are you saying that the low-
order bit of the first byte is the command/data flag?  Or is it
the high-order bit of the first byte?

I'm saying that what I observed when building the code was that
as originally defined, the cd_bit field was the high-order bit
(bit 7) of the first byte, which I understand to be wrong.

If you are telling me that the command/data flag resides at bit
7 of the first byte, I will update the field masks in a later
patch in this series to reflect that.

> The driver was written assuming that the host was running ARM64, so
> the structs are little endian. (I should have made it compatible
> with big and little endian earlier so that is my fault).

Little endian and big endian have no bearing on the host's
interpretation of bits within a byte.

Please clarify.  I want the patches to be correct, and what
you're explaining doesn't really straighten things out for me.

					-Alex

> In any case, this patch on its own will break the data operation on
> ARM64, so it needs to be folded with other patches.
> 
>> And although this isn't portable, I can state that when I build it
>> the result puts the bit-fields in the wrong location (e.g., the
>> cd_bit is in bit position 7, when it should be position 0).
>>
>> Fix this by reordering the definitions of these struct members.
>> Upcoming patches will reimplement these definitions portably.
>>
>> Signed-off-by: Alex Elder <elder@xxxxxxxxxx>
>> ---
>> Âdrivers/net/ethernet/qualcomm/rmnet/rmnet_map.h | 4 ++--
>> Â1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
>> b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
>> index 884f1f52dcc2..b1ae9499c0b2 100644
>> --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
>> +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
>> @@ -40,9 +40,9 @@ enum rmnet_map_commands {
>> Â};
>>
>> Âstruct rmnet_map_header {
>> -ÂÂÂ u8Â pad_len:6;
>> -ÂÂÂ u8Â reserved_bit:1;
>> ÂÂÂÂ u8Â cd_bit:1;
>> +ÂÂÂ u8Â reserved_bit:1;
>> +ÂÂÂ u8Â pad_len:6;
>> ÂÂÂÂ u8Â mux_id;
>> ÂÂÂÂ __be16 pkt_len;
>> Â}Â __aligned(1);
>