From: Greg KH <gregkh@linuxfoundation.org>
To: daniel.starke@siemens.com
Cc: linux-serial@vger.kernel.org, jirislaby@kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2 1/1] tty: n_gsm: fix SW flow control encoding/handling
Date: Wed, 26 Jan 2022 14:52:15 +0100 [thread overview]
Message-ID: <YfFSD8WZiXs3yMmo@kroah.com> (raw)
In-Reply-To: <20220120101857.2509-1-daniel.starke@siemens.com>
On Thu, Jan 20, 2022 at 02:18:57AM -0800, daniel.starke@siemens.com wrote:
> n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010.
> See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516
> The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to
> the newer 27.010 here. Chapter 5.2.7.3 states that DC1 (XON) and DC3 (XOFF)
> are the control characters defined in ISO/IEC 646. These shall be quoted if
> seen in the data stream to avoid interpretation as flow control characters.
>
> ISO/IEC 646 refers to the set of ISO standards described as the ISO
> 7-bit coded character set for information interchange. Its final version
> is also known as ITU T.50.
> See https://www.itu.int/rec/T-REC-T.50-199209-I/en
>
> To abide the standard it is needed to quote DC1 and DC3 correctly if these
> are seen as data bytes and not as control characters. The current
> implementation already tries to enforce this but fails to catch all
> defined cases. 3GPP 27.010 chapter 5.2.7.3 clearly states that the most
> significant bit shall be ignored for DC1 and DC3 handling. The current
> implementation handles only the case with the most significant bit set 0.
> Cases in which DC1 and DC3 have the most significant bit set 1 are left
> unhandled.
>
> This patch fixes this by masking the data bytes with ISO_IEC_646_MASK (only
> the 7 least significant bits set 1) before comparing them with XON
> (a.k.a. DC1) and XOFF (a.k.a. DC3) when testing which byte values need
> quotation via byte stuffing.
>
> Fixes: e1eaea46bb40 (tty: n_gsm line discipline, 2010-03-26)
Nit, no need for a date here, our tools get mad about stuff like this.
Look at the proper format for "Fixes:" line in the documentation.
thanks,
greg k-h
prev parent reply other threads:[~2022-01-26 13:52 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-20 10:18 [PATCH v2 1/1] tty: n_gsm: fix SW flow control encoding/handling daniel.starke
2022-01-26 13:52 ` Greg KH [this message]
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=YfFSD8WZiXs3yMmo@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=daniel.starke@siemens.com \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=stable@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.