> -----Original Message----- > From: Alan Cox [mailto:alan@xxxxxxxxxxxxxxxxxxx] > Sent: Thursday, October 07, 2010 3:35 PM > To: Savoy, Pavan > Cc: Jiri Slaby; gregkh@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > devel@xxxxxxxxxxxxxxxxxxxx; linux-bluetooth@xxxxxxxxxxxxxxx > 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. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
