From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762199AbYETIxb (ORCPT ); Tue, 20 May 2008 04:53:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753072AbYETIxV (ORCPT ); Tue, 20 May 2008 04:53:21 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:45117 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752466AbYETIxU (ORCPT ); Tue, 20 May 2008 04:53:20 -0400 Date: Tue, 20 May 2008 01:52:41 -0700 From: Andrew Morton To: Greg KH Cc: Alan Cox , linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/20] Implment a tty port structure and supporting logic Message-Id: <20080520015241.bd66fff0.akpm@linux-foundation.org> In-Reply-To: <20080519165049.GA19896@kroah.com> References: <20080519144557.19326.74313.stgit@core> <20080519165049.GA19896@kroah.com> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.5; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 19 May 2008 09:50:49 -0700 Greg KH wrote: > On Mon, May 19, 2008 at 03:50:07PM +0100, Alan Cox wrote: > > Right now each tty has its own port level structure which means we can share > > no code between ports. Introduce a structure and some initial minor helper > > routines so that we can move towards commonality. In doing this the USB serial > > code gets a bit of shake up as it kept using port->tty unsafely. Fixing that > > means changing the API of all the USB serial drivers. On the bright side the > > API now looks far more like the tty layer API which will become useful later > > on. > > Very nice. > > If you don't mind, I'll be glad to take this through my tree as you are > touching the usb-serial drivers so much. Andrew, any objection to this? A lot depends on what else Alan is brewing up. I only have a single tty-related patch at present (remove-is_tty.patch) and a handful of possibly-related char driver patches (proper-extern-for-mwave_s_mdd.patch, if-0-hpet_unregister.patch and riscom8-remove-redundant-null-pointer-test.patch). But if a great mountain of tty- and/or char-related patches is forthcoming, that mountain will probably have a depencency upon your tree. And that's OK too, as long as you don't go and bugger up your tree and get it dropped from linux-next! Because if that happens I'll need to temporarily drop all the dependent patches and remember to restore them, which is always a bit sad.