From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753261AbbJSJJw (ORCPT <rfc822;w@1wt.eu>);
	Mon, 19 Oct 2015 05:09:52 -0400
Received: from lb3-smtp-cloud2.xs4all.net ([194.109.24.29]:47957 "EHLO
	lb3-smtp-cloud2.xs4all.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1751103AbbJSJJv (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 19 Oct 2015 05:09:51 -0400
Message-ID: <1445245786.2581.28.camel@tiscali.nl>
Subject: Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when
 attaching ser_gigaset
From: Paul Bolle <pebolle@tiscali.nl>
To: Tilman Schmidt <tilman@imap.cc>
Cc: Peter Hurley <peter@hurleysoftware.com>, Jiri Slaby <jslaby@suse.cz>,
        linux-kernel@vger.kernel.org, "David S. Miller" <davem@davemloft.net>
Date: Mon, 19 Oct 2015 11:09:46 +0200
In-Reply-To: <561B7B01.40309@imap.cc>
References: <cover.1442326825.git.jslaby@suse.cz>
		 <350624fa32cb152bfec51f236b0b62b8d480a05a.1442326825.git.jslaby@suse.cz>
		 <4a187391f4c7d54b9c07eed08de48ffd6e0a3f20.1442326825.git.jslaby@suse.cz>
		 <CAKU3ayUyyYZzDr-AiZEW7uy=kwTtNptnOZMAKEYyn+=dd_47bg@mail.gmail.com>
		 <55F8B9D9.5060201@imap.cc>
		 <CAKU3ayVBUODUtiZS77gdzMg0R7kD8pgGu60Sdk=CRDBGt4iBQw@mail.gmail.com>
		 <55F951EA.1060001@imap.cc>
		 <CAKU3ayWYGBJ_E4vCnGoCc+vRUO9a0WNujZYbxwE+4QUJehmGsA@mail.gmail.com>
		 <55FC05C7.1000207@imap.cc> <5600028B.4050904@hurleysoftware.com>
		 <56002B48.7090008@imap.cc> <1444165247.2417.74.camel@tiscali.nl>
	 <561B7B01.40309@imap.cc>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.16.5 (3.16.5-3.fc22) 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

[Dropped stable from Cc:. I can't see how this is still relevant for
that list.]

Hi Tilman,

On ma, 2015-10-12 at 11:18 +0200, Tilman Schmidt wrote:
> While it doesn't make any sense indeed to run two instances of
> ldattach
> in parallel on one and the same serial port, it is entirely conceivable
> that someone might do so inadvertently, by not being aware that one is
> running already.

I'm wandering off topic a bit, but doesn't that imply that ldattach
should bail out with an error if someone tries to do that?


Paul Bolle