RE: [PATCH 1/2] drivers:staging:ti-st: move TI_ST from staging

Savoy, Pavan
2010-10-07T20:18:17Z

> -----Original Message-----
> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
> Sent: Thursday, October 07, 2010 3:35 PM
> To: Savoy, Pavan
> Cc: Jiri Slaby; gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@driverdev.osuosl.org; linux-bluetooth@vger.kernel.org
> Subject: Re: [PATCH 1/2] drivers:staging:ti-st: move TI_ST from staging
>
> > ldisc is the ONLY way to do it, isn't it? Do I have any other option?
>
> Userspace but even then it wouldn't solve your problem
>
> > The situation was something similar here.
> > What I was trying to get to is how we can have a per-device context if a
> driver is just a line discipline driver?
>
> tty->driver_data
> TTY private data
> tty->disc_data
> LDISC per instance private data
>
> So when your ldisc is opened attach your data to the tty->disc_data, and
> when it is closed free the data.

But, I want to attach my data not when ldsic is opened, but when ldisc is registered.
I want to begin accessing the data when ldisc is opened.

> > I have 3 sub-devices if you will on a device which is interfaced over UART,
> > One of them is Bluetooth which requires any UART Bluetooth device to have
> its
> > Own line discipline - N_HCI.
>
> The problem is that your chip by the sound of it does not talk the
> bluetooth ldisc - it talks something more complex.
>
> The obvious question then is
>
> Does it talk
>
> 1. HCI with bits nailed on
> 2. Something rather different which contains muxed data some of
> which is reformatted up to create HCI
>
> In the first case it may be worth seeing if the existing N_HCI could
> support forwarding unknown frame types to a helper. In the latter it's a
> lot trickier. It is possible to create a mux tty layer (see n_gsm.c) but
> that is almost certainly overkill for this.
>
> I wonder what Marcel thinks in terms of re-using the bluetooth ldisc ?

Yes, Marcel did suggest extending N_HCI, But even then, there need
to be like a bunch of helpers (1 for FM, 1 for GPS, 1 for NFC, 1 for power-management), also the problem of who owns the /dev/tty begins to occur, Bluetooth has a utility called hciattach, I don't want my FM radio software to run hciattach when /dev/radio0 is opened and communicated via FM.

In any case, the ti-st/ seems better now by look of things, I certainly welcome suggestions to improve it.
Also, is there any plan to re-write whole of TTY like a the i2C or the SPI bus structure?

Here I can imagine, all TTY line disciplines being sort of protocol/client drivers, the TTY sub-system in itself would be like the algos driver and then
The uart drivers (like 8250.c) can be the adapter drivers.. What say?

With something like this all I had to do was to write a new client driver.