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

H. Nikolaus Schaller hns at goldelico.com
Thu Apr 27 12:40:20 CEST 2017


> Am 25.04.2017 um 21:56 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 
>> 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 :(

I did take another look into the serdev based solution and there wasn't much
missing. Just properly handling set_termios. So we do not have to think about
line disciplines any more.

Now, I have a version where Bluetooth is working again (/dev/ttyBT0):

It has debugging code enabled so that we e.g. see

[ 4397.009552] w2cbw_tty_open() data = dcc3b410 open_count = ++0
[ 4397.020294] w2cbw_set_power(...,1)
[ 4397.035980] w2cbw_tty_set_termios() flow = 0
[ 4397.040466] w2cbw_tty_set_termios() baud rate = 9600
[ 4397.054809] w2cbw_tty_set_termios() flow = 0
[ 4397.059295] w2cbw_tty_set_termios() baud rate = 3000000
[ 4397.081604] w2cbw_tty_set_termios() flow = 0
[ 4397.093749] w2cbw_tty_set_termios() baud rate = 3000000
Device setup complete
[ 4397.172302] w2cbw003: tty->uart 4 chars
[ 4397.810668] w2cbw003: uart->tty 11 chars
[ 4397.815704] w2cbw003: tty->uart 4 chars
[ 4397.821990] w2cbw003: uart->tty 15 chars
[ 4397.828338] w2cbw003: tty->uart 4 chars
[ 4397.833923] w2cbw003: uart->tty 13 chars
[ 4397.840270] w2cbw003: tty->uart 4 chars
[ 4397.847290] w2cbw003: uart->tty 8 chars
[ 4397.851562] w2cbw003: uart->tty 6 chars
[ 4397.857391] w2cbw003: tty->uart 4 chars
[ 4397.862548] w2cbw003: uart->tty 10 chars
[ 4397.869110] w2cbw003: tty->uart 4 chars
[ 4397.878845] w2cbw003: uart->tty 167 chars

One messages indicates some flow control, buffer flushing, parity? or timeout issue:

[ 4397.883239] Bluetooth: hci0: Frame reassembly failed (-84)

Another issue is that it is probed a second time by the call
to tty_port_register_device() (the same as observed with the
w2sg00x4 driver).

But it is basically useable (maybe slow):

root at letux:~# ./bt-scan     <--- patched for /dev/ttyBT0
Scanning ...

BD Address:	00:23:12:3D:07:A2 [mode 0, clkoffset 0x7226]
Device name:	iMac
Manufacturer:	Broadcom Corporation (15)
LMP version:	2.1 (0x4) [subver 0x21d0]
LMP features:	0xff 0xff 0x8f 0xfe 0x9b 0xff 0x79 0x83
		<3-slot packets> <5-slot packets> <encryption> <slot offset>
		<timing accuracy> <role switch> <hold mode> <sniff mode>
		<park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
		<HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme>
		<power control> <transparent SCO> <broadcast encrypt>
		<EDR ACL 2 Mbps> <EDR ACL 3 Mbps> <enhanced iscan>
		<interlaced iscan> <interlaced pscan> <inquiry with RSSI>
		<extended SCO> <EV4 packets> <EV5 packets> <AFH cap. slave>
		<AFH class. slave> <3-slot EDR ACL> <5-slot EDR ACL>
		<sniff subrating> <pause encryption> <AFH cap. master>
		<AFH class. master> <EDR eSCO 2 Mbps> <EDR eSCO 3 Mbps>
		<3-slot EDR eSCO> <extended inquiry> <simple pairing>
		<encapsulated PDU> <err. data report> <non-flush flag> <LSTO>
		<inquiry TX power> <extended features>

root at letux:~#

Latest git branch is here:

	http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/misc/w2sg-serdev

BR,
Nikolaus

-------------- 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/20170427/eeca6c84/attachment.asc>


More information about the Letux-kernel mailing list