[Letux-kernel] Letux-4.11-rc and Bluetooth

[H. Nikolaus Schaller]

> Am 25.04.2017 um 21:46 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 
>> Am 25.04.2017 um 21:31 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>> Hi,
>> 
>>> Am 25.04.2017 um 21:05 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>> 
>>> On Tue, 25 Apr 2017 20:02:39 +0200
>>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>> 
>>>> I just realized that we have switched for the serdev driver for GPS
>>>> in Letux-4.11-rc.
>>>> 
>>>> Since we have a special misc/w2cbw003 driver which similarily
>>>> checks for open()/close() on the /dev/tty we have broken
>>>> Bluetooth power management...
>>>> 
>>>> It is not difficult to fix, just some copy&paste the serdev parts
>>>> into the w2cbw003 bluetooth power driver. I will try to do asap.
>> 
>> Well, the copy&paste part was simple and I have pushed it to the w2sg-serdev branch.
>> 
>> http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/misc/w2sg-serdev
>> 
>> But it is definitively not enough :(
>> 
>> The problem is that we have again a man-in-the-middle approach, i.e. on one
>> side the serdev interface and on the other a new /dev/tty. This works in
>> one direction only. The other is missing because we don't need it for GPS.
>> 
>> Next, hciattach assumes that it can tamper with the tty port's baud rate, flow
>> control etc. So this has to be passed to the serdev.
>> 
>> Makes a lot of additional glue code which has to be developed :(
>> 
>> Hm. Maybe a better strategy would be to not open the serdev?
>> AFAIR, this should make the /dev/ttyO remain available as standard UART.
>> 
>> But then we must install some "line discipline" to get notified about the
>> open()/close() actions. And I have no idea if the serdev API provides enough
>> struct pointers to get up to the pointer where we can install the ldisc.
>> 
> 
> It seems to be possible through:
> 
> struct serdev_controller *ctrl = serdev->ctrl;
> struct serport *serport = serdev_controller_get_drvdata(ctrl);
> struct tty_struct *tty = serport->tty;
> 
> and then
> 
> * struct tty_ldisc_ops ops = { .open = open_handler; .close = close_handler; };
> * create ldisc
> * int tty_register_ldisc(int disc, struct tty_ldisc_ops *new_ldisc)
> * tty_set_ldisc(struct tty_struct *tty, int disc)
> 
> An unanswered question is where to get the 'disc' number from. Can we
> assign it freely? It seems to be an index into an array [0..NR_LDISCS-1]

Ah, I got it:

http://lxr.free-electrons.com/source/include/uapi/linux/tty.h#L8

Well, there are currently 25 LDICSs and NR_LDISCS is 30. So there is not much
room for arbitrarily assigning new ones. And likely there is some Cerberus
disallowing to add new constants for such a simple thing as power control.

But wait: there is N_HCI for Bluetooth...

So, maybe, should we extend http://lxr.free-electrons.com/source/drivers/bluetooth/hci_ldisc.c#L863
for handling the W2CBW explicitly and just control power? But then it can't be a serdev any
more...

Argh... No obvious solution :(

> 
> Other question: does an UART tty already have an ldisc assigned? E.g. one
> that handles modem control?
> 
> And finally an interesting thing: we can intercept set_termios and get the
> additional modem control lines for the RS232 driver (DTR, RING etc.).
> 
>> I would even prefer this approach if it is possible... It would be much
>> less glue code and would avoid this double copying we have in the w2sg driver.
>> 
>>>> 
>>> Yes, noticed it also yesterday.
>>> 
>>> BTW:
>>> For things like
>>> mdbus2 -s org.bluez /org/bluez/hci0 org.bluez.NetworkServer1.Register panu btbr0
>>> to work, we also need
>>> CONFIG_BRIDGE.
>>> The former pand commandline tool works without. But it does not play
>>> well together with recent bluez.
>> 
>> I see. Have added it to the defconfig.
>> 
>> BR,
>> Nikolaus
>> 
>> _______________________________________________
>> http://projects.goldelico.com/p/gta04-kernel/
>> Letux-kernel mailing list
>> Letux-kernel at openphoenux.org
>> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
> 
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20170425/40cf014c/attachment-0001.asc>