On Fri, Oct 30, 2020 at 5:49 PM Xie He [off-list ref] 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.