On 5/20/19 10:07 PM, Bjorn Andersson wrote: > On Mon 20 May 19:30 PDT 2019, Alex Elder wrote: > >> On 5/20/19 8:32 PM, Subash Abhinov Kasiviswanathan wrote: >>>> >>>> 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. >>>> >>> >>> Higher order bit is Command / Data. >> >> So what this means is that to get the command/data bit we use: >> >> first_byte & 0x80 >> >> If that is correct I will remove this patch from the series and >> will update the subsequent patches so bit 7 is the command bit, >> bit 6 is reserved, and bits 0-5 are the pad length. >> >> I will post a v2 of the series with these changes, and will >> incorporate Bjorn's "Reviewed-by". >> > > But didn't you say that your testing show that the current bit order is > wrong? I did say that, but it seems I may have been misinterpreting what the documentation said, namely that "bit 0" in the network data stream is actually the high-order bit in the first byte. I did definitely see that bit 7 (0x80) in the first byte was the one selected by the "cd_bit" C bit-field originally, and I believed that was wrong. The other thing I can say is that I never see that bit set in my use of the rmnet driver for IPA. On top of that, the pad_len value is 0. Given that, either bit order works, because the whole first byte is 0 either way. So it turns out the testing I am able to do is not adequate to verify the change. I am hoping that Subash has an environment in which QMAP commands (with the appropriate bit set) are actually used. I'm going to wait a bit for him to confirm that, but at this time my plan is to do as I said above--remove this patch and adjust the ones that follow accordingly. -Alex > I still like the cleanup, if nothing else just to clarify and clearly > document the actual content of this header. > > Regards, > Bjorn >
