On Fri, Oct 30, 2020 at 5:49 PM Xie He <xie.he.0...@gmail.com> wrote: > > Add an fh->ea2 check to the initial checks in fr_rx. fh->ea2 == 1 means > the second address byte is the final address byte. We only support the > case where the address length is 2 bytes. If the address length is not > 2 bytes, the control field and the protocol field would not be the 3rd > and 4th byte as we assume. (Say it is 3 bytes, then the control field > and the protocol field would be the 4th and 5th byte instead.)
No, I don't think adding this explanation (about why address lengths other than 2 are not supported) is necessary. The code of this driver completely doesn't support address lengths other than 2 for many reasons, not only the reason above. The code for parsing and generating the address field (q922_to_dlci and dlci_to_q922) supports only 2-byte address fields. Also, the structure of the sending code of this driver can only generate headers with a 2-byte address field. Frame Relay networks usually have a fixed address length, that means a certain network usually has only 1 fixed address length. If this driver sends frames with 2-byte address fields, it shouldn't expect it would receive frames with 3-byte or 4-byte address fields. There are too many reasons, and I think just saying we only support 2-byte address fields is completely enough. Explaining the reason as above seems weird and inadequate to me, and also unnecessary to me. Therefore, I will resend this patch series with this explanation (about why address lengths other than 2 are not supported) removed.
