RE: [PATCH 07/11] Bluetooth: Add UART API functions to ldisc

[Par-Gunnar HJALMDAHL]

Hi Vitaly,

> -----Original Message-----
> From: Vitaly Wool [mailto:vitalywool@xxxxxxxxx]
> Sent: den 17 december 2010 12:41
> To: Par-Gunnar HJALMDAHL
> Cc: Pavan Savoy; Alan Cox; Arnd Bergmann; Samuel Ortiz; Marcel
> Holtmann; linux-kernel@xxxxxxxxxxxxxxx; linux-
> bluetooth@xxxxxxxxxxxxxxx; Lukasz Rymanowski; Linus WALLEIJ; Par-Gunnar
> Hjalmdahl
> Subject: Re: [PATCH 07/11] Bluetooth: Add UART API functions to ldisc
> 
> Hi Par,
> 
> On Fri, Dec 17, 2010 at 12:24 PM, Par-Gunnar Hjalmdahl
> <par-gunnar.p.hjalmdahl@xxxxxxxxxxxxxx> wrote:
> > This patch adds new functions to control break and flow
> > as well as changing UART baud rate directly through the ldisc API
> > rather then using the TTY API directly.
> 
> What do you need that for?
> 

For the break and flow control it is a means for the protocol driver to set break and flow using only the hci_uart structure, i.e. without interfacing directly towards tty. This is of course not 100% necessary to make it work, but it means a clean API where the protocol drivers can perform their tasks without performing different operations on different stack levels. As it was before write was performed using hci_uart structure while flow control was done using tty structure and API, even though you could consider these functions to be similar (not in functionality of course but from a stack level perspective).

For baud rate changes it also simplifies handling a bit, since the new function also implements using the proper mutexes and calling right termios functions. It should work simply (as long as you don't want different baud rates for TX and RX which should be pretty rare).

> > It also adds a boolean parameter so it is optional to register
> > to the Bluetooth stack (for drivers where a separate module
> > registers to the Bluetooth stack instead).
> 
> I never liked this idea and I don't like it now as it scatters the
> changes needed to support devices you are aiming to support with your
> changes.
> 

OK. Sadly I can't do much about how you feel towards the change. In my opinion this is probably the best reuse we can get of existing protocols and parts. There is so much that is vendor specific if you look at for example cg2900_uart.c that it is not much you could do generic.

> Thanks,
>    Vitaly
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/