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

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

[Alan Cox]

> 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.

> 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 ?

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

[Savoy, Pavan]

> -----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.

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

[Alan Cox]

> 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.

How can you attach per tty data when the ldisc is registered - the
relevant tty driver might not even have been loaded at that point. The
user may not even have been to the shop and bought it even !

What sort of data is this ?

> 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.

I would have assumed the hotplug script would have run your own attach
and daemon and the FM radio etc would talk to the ldisc via other kernel
interfaces it presented.

So whenever the hardware is detected it would load the hardware driver
The hardware driver would create a tty instance for each physical port
The hotplug user space would run 'ti-st-attach' as a helper which would
load the ldisc and set up the bluetooth as well as providing exported
methods for FM radio etc.

> 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?

They already are, with the one oddity being that something needs to have
it opened from user space and to attach the ldisc. Thats fixable but hard
to fix and I'm not aware of any plan to do so - mostly because nobody
needs it so far.

Alan

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

[Savoy, Pavan]

> -----Original Message-----
> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
> Sent: Thursday, October 07, 2010 4:00 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
> 
> > 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.
> 
> How can you attach per tty data when the ldisc is registered - the
> relevant tty driver might not even have been loaded at that point. The
> user may not even have been to the shop and bought it even !
> 
> What sort of data is this ?

Data related to requesting the user-space to open/install the ldisc.
Imagine a UEVENT structure or PID of the user-space process to which I need
to send a signal .. I currently use rfkill.

> > 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.
> 
> I would have assumed the hotplug script would have run your own attach
> and daemon and the FM radio etc would talk to the ldisc via other kernel
> interfaces it presented.
> 
> So whenever the hardware is detected it would load the hardware driver
> The hardware driver would create a tty instance for each physical port
> The hotplug user space would run 'ti-st-attach' as a helper which would
> load the ldisc and set up the bluetooth as well as providing exported
> methods for FM radio etc.

Yes, pretty similar to what I am doing now. I have this daemon which waits
for events from my ldisc driver, and on receiving the notification it
opens the uart, ioctl's the TIOCSETD and allows the tty to be accessed over
the ldisc.

> > 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?
> 
> They already are, with the one oddity being that something needs to have
> it opened from user space and to attach the ldisc. Thats fixable but hard
> to fix and I'm not aware of any plan to do so - mostly because nobody
> needs it so far.

Yes, that oddity was the reason this notification had to be done.
I could as well have opened it up on boot and attached the ldisc, but I chose
to use it whenever other drivers wanted to - as in when hci0 is UP, or /dev/radio0 is opened.

> Alan

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

[Marcel Holtmann]

Hi Alan,

> > 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.
> 
> > 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 ?

If you get a sane proposal, then yes, N_HCI could act as multiplexer and
forward certain frame types.

This all depends on how clear the separation is. If you expect to send
HCI commands from these "clients" then there is a problem with the
Bluetooth subsystem and its enforced flow control. You don't wanna mess
with that since it has side effects. And I am not giving outside drivers
real control over. The Bluetooth drivers have to stay dumb transport
drivers without any Bluetooth core logic.

So can you give me a few quick hints on what you would need to forward
actually.

Regards

Marcel