From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset To: Peter Hurley References: <350624fa32cb152bfec51f236b0b62b8d480a05a.1442326825.git.jslaby@suse.cz> <4a187391f4c7d54b9c07eed08de48ffd6e0a3f20.1442326825.git.jslaby@suse.cz> <55F8B9D9.5060201@imap.cc> <55F951EA.1060001@imap.cc> <55FC05C7.1000207@imap.cc> <5600028B.4050904@hurleysoftware.com> Cc: Jiri Slaby , "stable@vger.kernel.org" , Linux kernel mailing list , "David S. Miller" From: Tilman Schmidt Message-ID: <56002B48.7090008@imap.cc> Date: Mon, 21 Sep 2015 18:07:36 +0200 MIME-Version: 1.0 In-Reply-To: <5600028B.4050904@hurleysoftware.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rf7aiVP3e3Dpj0cf6j9UGGHus6DBoi9lh" Sender: linux-kernel-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rf7aiVP3e3Dpj0cf6j9UGGHus6DBoi9lh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am 21.09.2015 um 15:13 schrieb Peter Hurley: > On 09/18/2015 08:38 AM, Tilman Schmidt wrote: >> Am 17.09.2015 um 20:13 schrieb Peter Hurley: [...] >>> So for example, if you manually set N_PPP (as if by user error) >> >> User error wouldn't suffice, as the LD would get reset to N_TTY when t= he >> serial device is closed. You would have to write a program that >> deliberately switched the LD first to N_PPP and then to N_GIGASET_M101= >> without closing the device in between. >=20 > ??? >=20 > The tool you authored will do it from the command line >=20 > $ ldattach PPP /dev/ttyS1 > $ ldattach GIGASET_M101 /dev/ttyS1 >=20 > Note that nothing here closes the serial device 'in between', and > the tty core has switched directly from PPP to GIGASET_M101. > n_tty->receive_room is now 64K. Indeed it does. I stand corrected. The possibility of running ldattach a second time without terminating the first instance didn't occur to me. > Please add switching from line disciplines other than N_TTY to your > regression testing. I don't do regression tests for the driver anymore since I stepped down as a maintainer, so that would be up to the present maintainer of ser_gigaset. But I see no reason for that. As I already explained, N_TTY is the only problematic case. >>> and then set this line discipline, tty->receive_room will be 64K, not= 4K. >> >> That wouldn't affect the operation of ser_gigaset, >=20 > I've explained this before to you, but here it is again: >=20 > tty->receive_room announces the maximum amt of data the line discipline= > can accept from tty core with each call to its receive_buf() method (fo= r > line disciplines that don't provide flow control). >=20 > If the line discipline sets ->receive_room to 64K but can only handle > 8K (as in the case of GIGASET_M101), then data loss should be the expec= ted > result. If you'd care to look at the actual code you'd notice that it truly won't make any difference. The receive_buf() method of ser_gigaset is prepared to drop data and log an error when its receive buffer overflows, no matter how big the block of data passed from tty core is. The only difference a smaller ->receive_room value might possibly make is to distribute the overflowing data to more receive_buf() calls. (Note that the Gigaset M101 device operates at 115200 bits/sec max. so it takes at least 700 msecs to transmit 8k bytes. If we ever get into a situation where tty core actually accumulates more than that amount of data before forwarding it to GIGASET_M101 then we have a more serious problem anyway.) Again, I won't oppose applying this patch to stable releases before 3.10. I just don't see the need, so it would be up to you to advocate such a request. --=20 Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Unge=C3=B6ffnet mindestens haltbar bis: (siehe R=C3=BCckseite) --rf7aiVP3e3Dpj0cf6j9UGGHus6DBoi9lh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWACtRAAoJEFPuqx0v+F+q+FwH/jlkbykV30rbPgqKq6X5VdVg zQbChK+sedMaVCML8Wl52ozHKlCOrTnyuiHuPpFxtH0c5tuiEDmcWRhEVQRx4bkU MpKKVcpeDuwCkJWzcf9BGFOtLo9aMf6qquM+TeKuG0qBZPl98rbazzrfC0AX+dyy J2P0Yx2VItdtnXr6qJlrDn9IbXwB0lFnCMb+OenpSWQgxlKLK2v4C440g8Ndpgx5 MCqf0/pK/NEaPBCtqMb/Qap6v3OdlW1r4whiqDMTJBMwEvEKYr9LNsWm1rH+pgt6 bVfb1xwAzkyyvtAh8IW3z4kdnS4BQDR2W24U0xg1roxYyxc6Xhq0l5IQFQe81kA= =9icw -----END PGP SIGNATURE----- --rf7aiVP3e3Dpj0cf6j9UGGHus6DBoi9lh--