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);
>
