Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754075Ab0BWVne (ORCPT ); Tue, 23 Feb 2010 16:43:34 -0500 Received: from kirsty.vergenet.net ([202.4.237.240]:58903 "EHLO kirsty.vergenet.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753156Ab0BWVnc (ORCPT ); Tue, 23 Feb 2010 16:43:32 -0500 Date: Wed, 24 Feb 2010 08:43:30 +1100 From: Simon Horman To: Tilman Schmidt Cc: Karsten Keil , David Miller , Hansjoerg Lipp , Karsten Keil , isdn4linux@listserv.isdn4linux.de, i4ldeveloper@listserv.isdn4linux.de, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/4] bas_gigaset: collapse CR/LF at end of AT response Message-ID: <20100223214329.GA5801@verge.net.au> References: <20100221-patch-gigaset-00.tilman@imap.cc> <20100221-patch-gigaset-02.tilman@imap.cc> <20100223063425.GA28744@verge.net.au> <4B83D5D7.3040407@imap.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B83D5D7.3040407@imap.cc> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1413 Lines: 32 On Tue, Feb 23, 2010 at 02:19:19PM +0100, Tilman Schmidt wrote: > Simon Horman schrieb: > > I am confused about what the value of MAX_RESP_SIZE means. > > Is it a hw restriction? > > It's an arbitrary limitation in the driver. The hardware specification > says nothing about the possible length of AT responses from the device, > so we had to draw a line somewhere. 512 bytes have so far proved to be > amply sufficient. > > In practice, the limit is only hit with the M10x devices (which transmit > commands and data over the same channel) when the state machine gets out > of sync and tries to interpret received payload data as AT responses. Ok, understood. Thanks for the clarification. > > It seems that up to MAX_RESP_SIZE of string-data is permitted if the line > > is terminated by CR. But only MAX_RESP_SIZE -1 bytes if the line is > > terminated by LF or CR LF. > > Note that when storing the CR in cs->respdata[0] for possible collapsing > with a subsequent LF, the cbytes counter is left at 0, so the CR gets > overwritten by the first character of the next response if there's no > intervening LF. Yes, I had to look at that for quite a while :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/