From: Alex Elder <elder@linaro.org>
To: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Cc: syadagir@codeaurora.org, ejcaruso@google.com, arnd@arndb.de,
netdev@vger.kernel.org, ilias.apalodimas@linaro.org,
linux-kernel@vger.kernel.org, evgreen@chromium.org,
bjorn.andersson@linaro.org, david.brown@linaro.org,
agross@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, davem@davemloft.net,
cpratapa@codeaurora.org, benchan@google.com
Subject: Re: [PATCH 1/8] net: qualcomm: rmnet: fix struct rmnet_map_header
Date: Mon, 20 May 2019 16:23:28 -0500 [thread overview]
Message-ID: <81fd1e01-b8e3-f86a-fcc9-2bcbc51bd679@linaro.org> (raw)
In-Reply-To: <b0edef36555877350cfbab2248f8baac@codeaurora.org>
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@linaro.org>
>> ---
>> 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);
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-05-20 21:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-20 13:53 [PATCH 0/8] net: introduce "include/linux/if_rmnet.h" Alex Elder
2019-05-20 13:53 ` [PATCH 1/8] net: qualcomm: rmnet: fix struct rmnet_map_header Alex Elder
2019-05-20 15:38 ` Bjorn Andersson
2019-05-20 20:11 ` Subash Abhinov Kasiviswanathan
2019-05-20 21:23 ` Alex Elder [this message]
2019-05-21 1:32 ` Subash Abhinov Kasiviswanathan
2019-05-21 2:30 ` Alex Elder
2019-05-21 3:07 ` Bjorn Andersson
2019-05-21 11:03 ` Alex Elder
2019-05-20 13:53 ` [PATCH 2/8] net: qualcomm: rmnet: kill RMNET_MAP_GET_*() accessor macros Alex Elder
2019-05-20 15:41 ` Bjorn Andersson
2019-05-20 13:53 ` [PATCH 3/8] net: qualcomm: rmnet: use field masks instead of C bit-fields Alex Elder
2019-05-20 15:43 ` Bjorn Andersson
2019-05-20 13:53 ` [PATCH 4/8] net: qualcomm: rmnet: don't use C bit-fields in rmnet checksum header Alex Elder
2019-05-20 15:49 ` Bjorn Andersson
2019-05-20 13:53 ` [PATCH 5/8] net: qualcomm: rmnet: don't use C bit-fields in rmnet checksum trailer Alex Elder
2019-05-20 17:17 ` Bjorn Andersson
2019-05-20 13:53 ` [PATCH 6/8] net: qualcomm: rmnet: get rid of a variable in rmnet_map_ipv4_ul_csum_header() Alex Elder
2019-05-20 17:17 ` Bjorn Andersson
2019-05-20 13:53 ` [PATCH 7/8] net: qualcomm: rmnet: mark endianness of struct rmnet_map_dl_csum_trailer fields Alex Elder
2019-05-20 17:17 ` Bjorn Andersson
2019-05-20 13:53 ` [PATCH 8/8] net: introduce "include/linux/if_rmnet.h" Alex Elder
2019-05-20 17:18 ` Bjorn Andersson
2019-05-20 18:00 ` [PATCH 0/8] " Alex Elder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=81fd1e01-b8e3-f86a-fcc9-2bcbc51bd679@linaro.org \
--to=elder@linaro.org \
--cc=agross@kernel.org \
--cc=arnd@arndb.de \
--cc=benchan@google.com \
--cc=bjorn.andersson@linaro.org \
--cc=cpratapa@codeaurora.org \
--cc=davem@davemloft.net \
--cc=david.brown@linaro.org \
--cc=ejcaruso@google.com \
--cc=evgreen@chromium.org \
--cc=ilias.apalodimas@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=subashab@codeaurora.org \
--cc=syadagir@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).