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

Savoy, Pavan pavan_savoy at ti.com
Thu Oct 7 19:19:07 UTC 2010


Alan,
 

> -----Original Message-----
> From: Alan Cox [mailto:alan at lxorguk.ukuu.org.uk]
> Sent: Thursday, October 07, 2010 2:38 PM
> To: Savoy, Pavan
> Cc: Jiri Slaby; gregkh at suse.de; linux-kernel at vger.kernel.org;
> devel at driverdev.osuosl.org
> Subject: Re: [PATCH 1/2] drivers:staging:ti-st: move TI_ST from staging
> 
> > The situation here was to access the UART from a kernel driver. Say we have
> > a V4L2 FM radio over the UART, How can I write a v4L2 driver? I has to be a
> > line discipline driver correct?
> 
> Why would you want to ? you can just control it from user space. If you
> did want to drive it from the kernel then an ldisc would be one way to do
> it I guess.

ldisc is the ONLY way to do it, isn't it? Do I have any other option?

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?

Few months ago, something similar was discussed....
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.

Another is FM, which needs to be a V4L2 device.
Now being V4L2 device, I need to access the UART from kernel, but I cannot
since BT would be using it via the N_HCI ldisc.

Coming to what Jiri, was commenting was about the ldisc_ops structure, which
Just needs to be static and not really kmalloc-ed in heap.
I did it because, I imagined some day TTY ldisc drivers had capability to have
It's own per-device context/private_data (in addition to) tty driver_data or
Something like tty ldisc_data would be good.





> Alan



More information about the devel mailing list