Return-Path: MIME-Version: 1.0 In-Reply-To: References: <20101022135130.617f0ce8@lxorguk.ukuu.org.uk> <20101029172443.61f7b067@pyx> Date: Mon, 6 Dec 2010 10:06:02 +0100 Message-ID: Subject: Re: [PATCH 5/9] mfd: Add UART support for the ST-Ericsson CG2900. From: Par-Gunnar Hjalmdahl To: Vitaly Wool Cc: Alan Cox , linus.walleij@stericsson.com, linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org, Arnd Bergmann , Marcel Holtmann Content-Type: text/plain; charset=ISO-8859-1 List-ID: Hi Vitaly, 2010/12/3 Vitaly Wool : > Hi Par, > > On Fri, Dec 3, 2010 at 10:16 AM, Par-Gunnar Hjalmdahl > wrote: >> 2010/10/29 Alan Cox : > >> By the way, I will soon release a new patch set for CG2900 (hopefully >> next week), which contains major rework. It's hard to explain >> everything here and now but changes include: >> =A0- Reuse of existing HCI line discipline under /drivers/bluetooth/. >> Line discipline has been modified so it is selectable from protocol if >> line discipline should register to Bluetooth stack or not. > > So is it true that if there's the other chip with similar > functionality I have to implement support for, I'll have to pretty > much duplicate your line discipline driver? > What will be in the protocol file, i.e. the same level as hci_h4.c, hci_bcsp.c, etc, will be to ~80% vendor specific. The only H4 channels that are in a standardized specification are the Bluetooth channels 1-4. Other channels such as FM and GPS are vendor specific. I've seen that for example TI has the same channels for FM and GPS, but these channels, 8 and 9, are in no way standardized. The CG2900 also carries a number of other channels, such as debug and device channels, which I'm pretty sure is individual for this chip. This identification of the channels is also only one function, even though it is an important function. There are also a lot of other code regarding baud rate settings, low power handling, etc that I'm positive will not apply to chips of other vendors. It is of course possible that other chips from ST-Ericsson, current and future, will be able to reuse this file, but as I said I doubt that other vendors might be able to use it. > Isn't it better to have a new line discipline that the standard > drivers (H4, LL, ...) will be applicable to? > > ~Vitaly > I'm not certain what you mean. We are modifying the line discipline a bit, but the only thing we have needed to do with existing protocol drivers has been to add a boolean parameter for the protocol settings (so they will register to the Bluetooth stack). I don't see why we should create a new line discipline driver and then move the existing protocol drivers to this. /P-G