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

From: Savoy, Pavan
Date: Thu Oct 07 2010 - 15:19:29 EST



Alan,


> -----Original Message-----
> From: Alan Cox [mailto:alan@xxxxxxxxxxxxxxxxxxx]
> Sent: Thursday, October 07, 2010 2:38 PM
> To: Savoy, Pavan
> Cc: Jiri Slaby; gregkh@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> devel@xxxxxxxxxxxxxxxxxxxx
> 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
--
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/