* Re: Serial Port connection with DBus API
From: Barry Byford @ 2017-04-07 21:56 UTC (permalink / raw)
To: Bluez mailing list
In-Reply-To: <CAAu3APbw0JyPfKUi6PZ4Nr2Uh5WXtDprDVFBTj3xr+801b9L6w@mail.gmail.com>
Hi,
I've made progress by adding a dbus configuration file in
/etc/dbus-1/system.d and the python script is starting up. However on
startup btmon is reporting the following:
= bluetoothd: Invalid value for profile option Channel
= bluetoothd: RFCOMM server failed for SerialPort: socket(STREAM,
RFCOMM): Protocol not supported (93)
My assumption is that this is coming from the options on
RegisterProfile. However it is not obvious to me what the settings
should be. Any suggestions?
My Python script is:
import socket
from pydbus import SystemBus
from gi.repository import GLib
loop = GLib.MainLoop()
dbus = SystemBus()
class Profile(object):
"""
<node>
<interface name='org.bluez.Profile1'>
<method name='Release'>
</method>
<method name='Cancel'>
</method>
<method name='NewConnection'>
<arg type='o' name='path' direction='in'/>
<arg type='h' name='fd' direction='in'/>
<arg type='a{sv}' name='properties' direction='in'/>
</method>
<method name='RequestDisconnection'>
<arg type='o' name='path' direction='in'/>
</method>
</interface>
</node>
"""
def __init__(self, mac_address):
self.server_address = mac_address
self.server_sock = None
self.port = 1
pass
def Release(self):
pass
def Cancel(self):
pass
def NewConnection(self, path, fd, properties):
print('New connection', path, fd, properties)
self.server_sock = socket.socket(socket.AF_BLUETOOTH,
socket.SOCK_STREAM, socket.BTPROTO_RFCOMM)
self.server_sock.settimeout(0.01)
self.server_sock.bind((self.server_address, self.port))
self.server_sock.listen(1)
try:
client, address = self.server_sock.accept()
while True:
data = client.recv(1024)
if data:
print(data)
except:
print('Debug!')
def RequestDisconnection(self, path):
print('Disconnection', path)
self.server_sock.close()
self.server_sock = None
if __name__ == '__main__':
profile_mngr = dbus.get('org.bluez', '/org/bluez')
spp_uuid = '00001101-0000-1000-8000-00805f9b34fb'
rfcom_uuid = '00000003-0000-1000-8000-00805F9B34FB'
l2cap_uuid = '00000100-0000-1000-8000-00805f9b34fb'
opts = {
'AutoConnect': GLib.Variant('b', True),
'Channel': GLib.Variant('i', 1),
'Service': GLib.Variant('s', rfcom_uuid),
'Role': GLib.Variant('s', 'server'),
'Name': GLib.Variant('s', 'SerialPort')
}
dbus.publish('ukBaz.bluezero', Profile('00:00:00:00:5A:AD'))
profile_mngr.RegisterProfile('/ukBaz/bluezero', spp_uuid, opts)
loop.run()
The full output of btmon is:
Bluetooth monitor ver 5.43
= Note: Linux version 4.9.0-linaro-lt-qcom (aarch64) 0.650926
= Note: Bluetooth subsystem version 2.22 0.650947
= New Index: 00:00:00:00:5A:AD (Primary,SMD,hci0) [hci0] 0.650954
= Open Index: 00:00:00:00:5A:AD [hci0] 0.650961
= Index Info: 00:00:00:00:5A:AD (Qualcomm) [hci0] 0.650969
@ MGMT Open: bluetoothd (privileged) version 1.14 {0x0001} 0.650983
@ MGMT Open: btmon (privileged) version 1.14 {0x0002} 0.651098
= bluetoothd: Invalid value for profile option Channel 7.672569
= bluetoothd: RFCOMM server failed for SerialPort: socket(STREAM,... 7.675858
> HCI Event: Connect Request (0x04) plen 10 [hci0] 19.885300
Address: 64:BC:0C:F6:22:F8 (LG Electronics (Mobile Communications))
Class: 0x5a020c
Major class: Phone (cellular, cordless, payphone, modem)
Minor class: Smart phone
Networking (LAN, Ad hoc)
Capturing (Scanner, Microphone)
Object Transfer (v-Inbox, v-Folder)
Telephony (Cordless telephony, Modem, Headset)
Link type: ACL (0x01)
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7 [hci0] 19.885506
Address: 64:BC:0C:F6:22:F8 (LG Electronics (Mobile Communications))
Role: Master (0x00)
> HCI Event: Command Status (0x0f) plen 4 [hci0] 19.886181
Accept Connection Request (0x01|0x0009) ncmd 1
Status: Success (0x00)
> HCI Event: Role Change (0x12) plen 8 [hci0] 20.138773
Status: Success (0x00)
Address: 64:BC:0C:F6:22:F8 (LG Electronics (Mobile Communications))
Role: Master (0x00)
> HCI Event: Connect Complete (0x03) plen 11 [hci0] 20.142779
Status: Success (0x00)
Handle: 1
Address: 64:BC:0C:F6:22:F8 (LG Electronics (Mobile Communications))
Link type: ACL (0x01)
Encryption: Disabled (0x00)
< HCI Command: Read Remote Supported F.. (0x01|0x001b) plen 2 [hci0] 20.143326
Handle: 1
> HCI Event: Command Status (0x0f) plen 4 [hci0] 20.143779
Read Remote Supported Features (0x01|0x001b) ncmd 1
Status: Success (0x00)
> HCI Event: Read Remote Supported Features (0x0b) plen 11 [hci0] 20.143809
Status: Success (0x00)
Handle: 1
Features: 0xff 0xfe 0x8f 0xfe 0xd8 0x3f 0x5b 0x87
3 slot packets
5 slot packets
Encryption
Slot offset
Timing accuracy
Role switch
Hold mode
Sniff mode
Power control requests
Channel quality driven data rate (CQDDR)
SCO link
HV2 packets
HV3 packets
u-law log synchronous data
A-law log synchronous data
CVSD synchronous data
Paging parameter negotiation
Power control
Transparent synchronous data
Broadcast Encryption
Enhanced Data Rate ACL 2 Mbps mode
Enhanced Data Rate ACL 3 Mbps mode
Enhanced inquiry scan
Interlaced inquiry scan
Interlaced page scan
RSSI with inquiry results
Extended SCO link (EV3 packets)
AFH capable slave
AFH classification slave
LE Supported (Controller)
3-slot Enhanced Data Rate ACL packets
5-slot Enhanced Data Rate ACL packets
Sniff subrating
Pause encryption
AFH capable master
AFH classification master
Enhanced Data Rate eSCO 2 Mbps mode
Extended Inquiry Response
Simultaneous LE and BR/EDR (Controller)
Secure Simple Pairing
Encapsulated PDU
Non-flushable Packet Boundary Flag
Link Supervision Timeout Changed Event
Inquiry TX Power Level
Enhanced Power Control
Extended features
< HCI Command: Write Scan Enable (0x03|0x001a) plen 1 [hci0] 20.143972
Scan enable: No Scans (0x00)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 20.144612
Write Scan Enable (0x03|0x001a) ncmd 1
Status: Success (0x00)
< HCI Command: Read Remote Extended Fe.. (0x01|0x001c) plen 3 [hci0] 20.144763
Handle: 1
Page: 1
> HCI Event: Command Status (0x0f) plen 4 [hci0] 20.145061
Read Remote Extended Features (0x01|0x001c) ncmd 1
Status: Success (0x00)
> HCI Event: Read Remote Extended Features (0x23) plen 13 [hci0] 20.145089
Status: Success (0x00)
Handle: 1
Page: 1/2
Features: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Secure Simple Pairing (Host Support)
LE Supported (Host)
Simultaneous LE and BR/EDR (Host)
Secure Connections (Host Support)
< HCI Command: Remote Name Request (0x01|0x0019) plen 10 [hci0] 20.145291
Address: 64:BC:0C:F6:22:F8 (LG Electronics (Mobile Communications))
Page scan repetition mode: R2 (0x02)
Page scan mode: Mandatory (0x00)
Clock offset: 0x0000
< ACL Data TX: Handle 1 flags 0x00 dlen 10 [hci0] 20.145326
L2CAP: Information Request (0x0a) ident 1 len 2
Type: Extended features supported (0x0002)
> HCI Event: Command Status (0x0f) plen 4 [hci0] 20.145898
Remote Name Request (0x01|0x0019) ncmd 1
Status: Success (0x00)
> HCI Event: Page Scan Repetition Mode Change (0x20) plen 7 [hci0] 20.149914
Address: 64:BC:0C:F6:22:F8 (LG Electronics (Mobile Communications))
Page scan repetition mode: R1 (0x01)
> HCI Event: Max Slots Change (0x1b) plen 3 [hci0] 20.153646
Handle: 1
Max slots: 5
> HCI Event: Remote Name Req Complete (0x07) plen 255 [hci0] 20.154938
Status: Success (0x00)
Address: 64:BC:0C:F6:22:F8 (LG Electronics (Mobile Communications))
Name: Nexus 5X
@ MGMT Event: Device Connected (0x000b) plen 28 {0x0002} [hci0] 20.155049
BR/EDR Address: 64:BC:0C:F6:22:F8 (LG Electronics (Mobile
Communications))
Flags: 0x00000000
Data length: 15
Name (complete): Nexus 5X
Class: 0x5a020c
Major class: Phone (cellular, cordless, payphone, modem)
Minor class: Smart phone
Networking (LAN, Ad hoc)
Capturing (Scanner, Microphone)
Object Transfer (v-Inbox, v-Folder)
Telephony (Cordless telephony, Modem, Headset)
@ MGMT Event: Device Connected (0x000b) plen 28 {0x0001} [hci0] 20.155049
BR/EDR Address: 64:BC:0C:F6:22:F8 (LG Electronics (Mobile
Communications))
Flags: 0x00000000
Data length: 15
Name (complete): Nexus 5X
Class: 0x5a020c
Major class: Phone (cellular, cordless, payphone, modem)
Minor class: Smart phone
Networking (LAN, Ad hoc)
Capturing (Scanner, Microphone)
Object Transfer (v-Inbox, v-Folder)
Telephony (Cordless telephony, Modem, Headset)
> ACL Data RX: Handle 1 flags 0x02 dlen 10 [hci0] 20.293653
L2CAP: Information Request (0x0a) ident 2 len 2
Type: Extended features supported (0x0002)
< ACL Data TX: Handle 1 flags 0x00 dlen 16 [hci0] 20.293854
L2CAP: Information Response (0x0b) ident 2 len 8
Type: Extended features supported (0x0002)
Result: Success (0x0000)
Features: 0x000002b8
Enhanced Retransmission Mode
Streaming Mode
FCS Option
Fixed Channels
Unicast Connectionless Data Reception
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 20.392999
Num handles: 1
Handle: 1
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 20.395496
Num handles: 1
Handle: 1
Count: 1
> ACL Data RX: Handle 1 flags 0x02 dlen 16 [hci0] 20.492372
L2CAP: Information Response (0x0b) ident 1 len 8
Type: Extended features supported (0x0002)
Result: Success (0x0000)
Features: 0x000000b8
Enhanced Retransmission Mode
Streaming Mode
FCS Option
Fixed Channels
< ACL Data TX: Handle 1 flags 0x00 dlen 10 [hci0] 20.492531
L2CAP: Information Request (0x0a) ident 2 len 2
Type: Fixed channels supported (0x0003)
> ACL Data RX: Handle 1 flags 0x02 dlen 10 [hci0] 20.493632
L2CAP: Information Request (0x0a) ident 3 len 2
Type: Fixed channels supported (0x0003)
< ACL Data TX: Handle 1 flags 0x00 dlen 20 [hci0] 20.493768
L2CAP: Information Response (0x0b) ident 3 len 12
Type: Fixed channels supported (0x0003)
Result: Success (0x0000)
Channels: 0x0000000000000086
L2CAP Signaling (BR/EDR)
Connectionless reception
Security Manager (BR/EDR)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 20.591765
Num handles: 1
Handle: 1
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 20.592972
Num handles: 1
Handle: 1
Count: 1
> ACL Data RX: Handle 1 flags 0x02 dlen 20 [hci0] 20.729872
L2CAP: Information Response (0x0b) ident 2 len 12
Type: Fixed channels supported (0x0003)
Result: Success (0x0000)
Channels: 0x0000000000000082
L2CAP Signaling (BR/EDR)
Security Manager (BR/EDR)
> ACL Data RX: Handle 1 flags 0x02 dlen 12 [hci0] 20.731116
L2CAP: Connection Request (0x02) ident 4 len 4
PSM: 1 (0x0001)
Source CID: 76
< ACL Data TX: Handle 1 flags 0x00 dlen 16 [hci0] 20.731327
L2CAP: Connection Response (0x03) ident 4 len 8
Destination CID: 64
Source CID: 76
Result: Connection successful (0x0000)
Status: No further information available (0x0000)
< ACL Data TX: Handle 1 flags 0x00 dlen 23 [hci0] 20.731355
L2CAP: Configure Request (0x04) ident 3 len 15
Destination CID: 76
Flags: 0x0000
Option: Retransmission and Flow Control (0x04) [mandatory]
Mode: Basic (0x00)
TX window size: 0
Max transmit: 0
Retransmission timeout: 0
Monitor timeout: 0
Maximum PDU size: 0
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 20.734232
Num handles: 1
Handle: 1
Count: 1
> ACL Data RX: Handle 1 flags 0x02 dlen 16 [hci0] 20.768614
L2CAP: Configure Request (0x04) ident 5 len 8
Destination CID: 64
Flags: 0x0000
Option: Maximum Transmission Unit (0x01) [mandatory]
MTU: 672
< ACL Data TX: Handle 1 flags 0x00 dlen 18 [hci0] 20.768765
L2CAP: Configure Response (0x05) ident 5 len 10
Source CID: 76
Flags: 0x0000
Result: Success (0x0000)
Option: Maximum Transmission Unit (0x01) [mandatory]
MTU: 672
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 20.769242
Num handles: 1
Handle: 1
Count: 1
> ACL Data RX: Handle 1 flags 0x02 dlen 14 [hci0] 20.796104
L2CAP: Configure Response (0x05) ident 3 len 6
Source CID: 64
Flags: 0x0000
Result: Success (0x0000)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 20.796754
Num handles: 1
Handle: 1
Count: 1
> ACL Data RX: Handle 1 flags 0x02 dlen 38 [hci0] 20.798611
Channel: 64 len 34 [PSM 1 mode 0] {chan 0}
SDP: Service Search Attribute Request (0x06) tid 0 len 29
Search pattern: [len 19]
Sequence (6) with 17 bytes [8 extra bits] len 19
UUID (3) with 16 bytes [0 extra bits] len 17
00001101-0000-1000-8000-00805f9b34fb
Serial Port
Max record count: 656
Attribute list: [len 7]
Sequence (6) with 5 bytes [8 extra bits] len 7
Unsigned Integer (1) with 4 bytes [0 extra bits] len 5
0x0000ffff
Continuation state: 0
< ACL Data TX: Handle 1 flags 0x00 dlen 14 [hci0] 20.799655
Channel: 76 len 10 [PSM 1 mode 0] {chan 0}
SDP: Service Search Attribute Response (0x07) tid 0 len 5
Attribute bytes: 2
Continuation state: 0
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 20.891773
Num handles: 1
Handle: 1
Count: 1
> ACL Data RX: Handle 1 flags 0x02 dlen 12 [hci0] 20.919861
L2CAP: Disconnection Request (0x06) ident 6 len 4
Destination CID: 64
Source CID: 76
< ACL Data TX: Handle 1 flags 0x00 dlen 12 [hci0] 20.920045
L2CAP: Disconnection Response (0x07) ident 6 len 4
Destination CID: 64
Source CID: 76
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 20.992989
Num handles: 1
Handle: 1
Count: 1
< HCI Command: Disconnect (0x01|0x0006) plen 3 [hci0] 24.950685
Handle: 1
Reason: Remote User Terminated Connection (0x13)
> HCI Event: Command Status (0x0f) plen 4 [hci0] 24.951252
Disconnect (0x01|0x0006) ncmd 1
Status: Success (0x00)
> HCI Event: Disconnect Complete (0x05) plen 4 [hci0] 24.959359
Status: Success (0x00)
Handle: 1
Reason: Connection Terminated By Local Host (0x16)
@ MGMT Event: Device Disconnected (0x000c) plen 8 {0x0002} [hci0] 24.959474
BR/EDR Address: 64:BC:0C:F6:22:F8 (LG Electronics (Mobile
Communications))
Reason: Connection terminated by local host (0x02)
@ MGMT Event: Device Disconnected (0x000c) plen 8 {0x0001} [hci0] 24.959474
BR/EDR Address: 64:BC:0C:F6:22:F8 (LG Electronics (Mobile
Communications))
Reason: Connection terminated by local host (0x02)
< HCI Command: Write Scan Enable (0x03|0x001a) plen 1 [hci0] 24.991008
Scan enable: Page Scan (0x02)
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 24.993260
Write Scan Enable (0x03|0x001a) ncmd 1
Status: Success (0x00)
On 7 April 2017 at 14:47, Barry Byford <31baz66@gmail.com> wrote:
> Hello,
>
> I am trying to create a serial port server that can be connected to by
> an already existing Android app.
>
> The app is trying connect on channel 1. I am taking the
> test/test-profile example as my starting point.
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test/test-profile?h=5.43
>
> My code is far from finished but I thought it would be enough to
> accept the connection (or at least print that a new connection attempt
> had happened.) However I am getting an access denied error and I'm
> concerned that I'm going down the wrong route on this and it might be
> simpler than I am making it.
>
> Error message
> $ python3 BTspp.py
> Traceback (most recent call last):
> File "BTclassic.py", line 54, in <module>
> dbus.publish('org.bluez.Profile1', Profile('x', 'y'))
> File "/usr/local/lib/python3.5/dist-packages/pydbus/publication.py",
> line 42, in publish
> return Publication(self, bus_name, *objects)
> File "/usr/local/lib/python3.5/dist-packages/pydbus/publication.py",
> line 35, in __init__
> self._at_exit(bus.request_name(bus_name,
> allow_replacement=allow_replacement, replace=replace).__exit__)
> File "/usr/local/lib/python3.5/dist-packages/pydbus/request_name.py",
> line 29, in request_name
> return NameOwner(self, name, allow_replacement, replace)
> File "/usr/local/lib/python3.5/dist-packages/pydbus/request_name.py",
> line 8, in __init__
> res = bus.dbus.RequestName(name, flags)
> File "/usr/local/lib/python3.5/dist-packages/pydbus/proxy_method.py",
> line 75, in __call__
> 0, timeout_to_glib(timeout), None).unpack()
> GLib.Error: g-dbus-error-quark:
> GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection
> ":1.47" is not allowed to own the service "org.bluez.Profile1" due to
> security policies in the configuration file (9
>
> Python code so far:
>
> from pydbus import SystemBus
> from gi.repository import GLib
>
> loop = GLib.MainLoop()
>
> dbus = SystemBus()
>
>
> class Profile(object):
> """
> <node>
> <interface name='org.bluez.Profile1'>
> <method name='Release'>
> </method>
> <method name='Cancel'>
> </method>
> <method name='NewConnection'>
> <arg type='o' name='path' direction='in'/>
> <arg type='h' name='fd' direction='in'/>
> <arg type='a{sv}' name='properties' direction='in'/>
> </method>
> <method name='RequestDisconnection'>
> <arg type='o' name='path' direction='in'/>
> </method>
> </interface>
> </node>
> """
> def __init__(self, x, y):
> pass
>
> def Release(self):
> pass
>
> def Cancel(self):
> pass
>
> def NewConnection(self, path, fd, properties):
> print('New connection', path, fd, properties)
>
> def RequestDisconnection(self, path):
> pass
>
> if __name__ == '__main__':
> profile_mngr = dbus.get('org.bluez', '/org/bluez')
> uuid = "00001101-0000-1000-8000-00805f9b34fb"
> opts = {
> "AutoConnect": GLib.Variant('b', True),
> 'Channel': GLib.Variant('i', 1),
> 'Service': GLib.Variant('s', uuid),
> 'Name': GLib.Variant('s', 'Serial Port')
> }
>
> # my_profile = Profile(dbus, '/org/bluez/example')
> dbus.publish('org.bluez.Profile1', Profile('x', 'y'))
> profile_mngr.RegisterProfile('/foo/bar/profile', uuid, opts)
>
> loop.run()
>
>
> Is there a simpler way of doing this?
>
> Thanks,
> Barry
^ permalink raw reply
* Re: Serial Port connection with DBus API
From: Johan Hedberg @ 2017-04-08 7:18 UTC (permalink / raw)
To: Barry Byford; +Cc: Bluez mailing list
In-Reply-To: <CAAu3APbMKQY2dnD=TUAb_3BqFKk0s2bzuFFLX8=h-1g7gm8G=Q@mail.gmail.com>
Hi Barry,
On Fri, Apr 07, 2017, Barry Byford wrote:
> = bluetoothd: Invalid value for profile option Channel
Let's look at your code:
> > 'Channel': GLib.Variant('i', 1),
Yep, that's wrong. The expected D-Bus type for 'Channel' is UINT16,
which is 'q' and not 'i'.
> = bluetoothd: RFCOMM server failed for SerialPort: socket(STREAM,
> RFCOMM): Protocol not supported (93)
That usually means that your kernel is incorrectly configured and
lacking RFCOMM support.
Johan
^ permalink raw reply
* Re: Serial Port connection with DBus API
From: Barry Byford @ 2017-04-08 7:57 UTC (permalink / raw)
To: Bluez mailing list
In-Reply-To: <20170408071834.GA12144@x1c>
Hi Johan,
On 8 April 2017 at 08:18, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Barry,
>
> On Fri, Apr 07, 2017, Barry Byford wrote:
>> = bluetoothd: Invalid value for profile option Channel
>
> Let's look at your code:
>
>> > 'Channel': GLib.Variant('i', 1),
>
> Yep, that's wrong. The expected D-Bus type for 'Channel' is UINT16,
> which is 'q' and not 'i'.
Works like a charm. Thanks.
>> = bluetoothd: RFCOMM server failed for SerialPort: socket(STREAM,
>> RFCOMM): Protocol not supported (93)
>
> That usually means that your kernel is incorrectly configured and
> lacking RFCOMM support.
Ah! Sounds like more of an issue. Gives me something to investigate.
Thanks again.
^ permalink raw reply
* Re: [PATCHv3 02/10] serdev: add serdev_device_wait_until_sent
From: Greg Kroah-Hartman @ 2017-04-08 16:57 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, Rob Herring,
Samuel Thibault, Pavel Machek, Tony Lindgren, Jiri Slaby,
Mark Rutland, linux-bluetooth, linux-serial, devicetree,
linux-kernel
In-Reply-To: <20170328155939.31566-3-sre@kernel.org>
On Tue, Mar 28, 2017 at 05:59:31PM +0200, Sebastian Reichel wrote:
> Add method, which waits until the transmission buffer has been sent.
> Note, that the change in ttyport_write_wakeup is related, since
> tty_wait_until_sent will hang without that change.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Pavel Machek <pavel@ucw.cz>
> Signed-off-by: Sebastian Reichel <sre@kernel.org>
> ---
> Changes since PATCHv2:
> * Avoid goto in ttyport_write_wakeup
> ---
> drivers/tty/serdev/core.c | 11 +++++++++++
> drivers/tty/serdev/serdev-ttyport.c | 18 ++++++++++++++----
> include/linux/serdev.h | 3 +++
> 3 files changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> index f4c6c90add78..a63b74031e22 100644
> --- a/drivers/tty/serdev/core.c
> +++ b/drivers/tty/serdev/core.c
> @@ -173,6 +173,17 @@ void serdev_device_set_flow_control(struct serdev_device *serdev, bool enable)
> }
> EXPORT_SYMBOL_GPL(serdev_device_set_flow_control);
>
> +void serdev_device_wait_until_sent(struct serdev_device *serdev, long timeout)
> +{
> + struct serdev_controller *ctrl = serdev->ctrl;
> +
> + if (!ctrl || !ctrl->ops->wait_until_sent)
> + return;
> +
> + ctrl->ops->wait_until_sent(ctrl, timeout);
> +}
> +EXPORT_SYMBOL_GPL(serdev_device_wait_until_sent);
Is this still needed now that we have serdev_device_write() with an
unlimited timeout available?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] monitor: Add support for decoding LE Channel Selection Algorithm Event
From: Szymon Janc @ 2017-04-09 19:39 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20170406134135.30944-1-szymon.janc@codecoup.pl>
On Thursday, 6 April 2017 15:41:35 CEST Szymon Janc wrote:
> > HCI Event: LE Meta Event (0x3e) plen 4 44.589780
>
> LE Channel Selection Algorithm (0x14)
> Handle: 1
> LE Channel Selection Algorithm #2 (0x01)
> ---
> monitor/bt.h | 6 ++++++
> monitor/packet.c | 30 +++++++++++++++++++++++++++++-
> 2 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/monitor/bt.h b/monitor/bt.h
> index 1a21592..0b77a10 100644
> --- a/monitor/bt.h
> +++ b/monitor/bt.h
> @@ -2736,6 +2736,12 @@ struct bt_hci_evt_le_direct_adv_report {
> int8_t rssi;
> } __attribute__ ((packed));
>
> +#define BT_HCI_EVT_LE_CHAN_SELECT_ALG 0x14
> +struct bt_hci_evt_le_chan_select_alg {
> + uint16_t handle;
> + uint8_t algorithm;
> +} __attribute__ ((packed));
> +
> #define BT_HCI_ERR_SUCCESS 0x00
> #define BT_HCI_ERR_UNKNOWN_COMMAND 0x01
> #define BT_HCI_ERR_UNKNOWN_CONN_ID 0x02
> diff --git a/monitor/packet.c b/monitor/packet.c
> index 0cae6d7..5d927f5 100644
> --- a/monitor/packet.c
> +++ b/monitor/packet.c
> @@ -3754,6 +3754,25 @@ static void print_3d_broadcast(const void *data,
> uint8_t size) period, period_frac);
> }
>
> +static void print_le_channel_select_alg(uint8_t alg)
> +{
> + const char *str;
> +
> + switch (alg) {
> + case 0x00:
> + str = "LE Channel Selection Algorithm #1";
> + break;
> + case 0x01:
> + str = "LE Channel Selection Algorithm #2";
> + break;
> + default:
> + str = "Reserved";
> + break;
> + }
> +
> + print_field("%s (0x%2.2x)", str, alg);
> +}
> +
> void packet_hexdump(const unsigned char *buf, uint16_t len)
> {
> static const char hexdigits[] = "0123456789abcdef";
> @@ -8531,6 +8550,14 @@ static void le_direct_adv_report_evt(const void
> *data, uint8_t size) packet_hexdump(data + sizeof(*evt), size -
> sizeof(*evt));
> }
>
> +static void le_chan_select_alg_evt(const void *data, uint8_t size)
> +{
> + const struct bt_hci_evt_le_chan_select_alg *evt = data;
> +
> + print_handle(evt->handle);
> + print_le_channel_select_alg(evt->algorithm);
> +}
> +
> struct subevent_data {
> uint8_t subevent;
> const char *str;
> @@ -8605,7 +8632,8 @@ static const struct subevent_data
> le_meta_event_table[] = { { 0x11, "LE Scan Timeout" },
> { 0x12, "LE Advertising Set Terminated" },
> { 0x13, "LE Scan Request Received" },
> - { 0x14, "LE Channel Selection Algorithm" },
> + { 0x14, "LE Channel Selection Algorithm",
> + le_chan_select_alg_evt, 3, true},
> { }
> };
Applied.
--
pozdrawiam
Szymon Janc
^ permalink raw reply
* Re: [PATCHv3 02/10] serdev: add serdev_device_wait_until_sent
From: Rob Herring @ 2017-04-10 13:46 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Sebastian Reichel, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Samuel Thibault, Pavel Machek, Tony Lindgren,
Jiri Slaby, Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20170408165740.GA20058@kroah.com>
On Sat, Apr 8, 2017 at 11:57 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Tue, Mar 28, 2017 at 05:59:31PM +0200, Sebastian Reichel wrote:
>> Add method, which waits until the transmission buffer has been sent.
>> Note, that the change in ttyport_write_wakeup is related, since
>> tty_wait_until_sent will hang without that change.
>>
>> Acked-by: Rob Herring <robh@kernel.org>
>> Acked-by: Pavel Machek <pavel@ucw.cz>
>> Signed-off-by: Sebastian Reichel <sre@kernel.org>
>> ---
>> Changes since PATCHv2:
>> * Avoid goto in ttyport_write_wakeup
>> ---
>> drivers/tty/serdev/core.c | 11 +++++++++++
>> drivers/tty/serdev/serdev-ttyport.c | 18 ++++++++++++++----
>> include/linux/serdev.h | 3 +++
>> 3 files changed, 28 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
>> index f4c6c90add78..a63b74031e22 100644
>> --- a/drivers/tty/serdev/core.c
>> +++ b/drivers/tty/serdev/core.c
>> @@ -173,6 +173,17 @@ void serdev_device_set_flow_control(struct serdev_device *serdev, bool enable)
>> }
>> EXPORT_SYMBOL_GPL(serdev_device_set_flow_control);
>>
>> +void serdev_device_wait_until_sent(struct serdev_device *serdev, long timeout)
>> +{
>> + struct serdev_controller *ctrl = serdev->ctrl;
>> +
>> + if (!ctrl || !ctrl->ops->wait_until_sent)
>> + return;
>> +
>> + ctrl->ops->wait_until_sent(ctrl, timeout);
>> +}
>> +EXPORT_SYMBOL_GPL(serdev_device_wait_until_sent);
>
> Is this still needed now that we have serdev_device_write() with an
> unlimited timeout available?
Yes, because only this waits until the data is on the wire.
Rob
^ permalink raw reply
* Re: [PATCHv3 02/10] serdev: add serdev_device_wait_until_sent
From: Greg Kroah-Hartman @ 2017-04-10 14:03 UTC (permalink / raw)
To: Rob Herring
Cc: Sebastian Reichel, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Samuel Thibault, Pavel Machek, Tony Lindgren,
Jiri Slaby, Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAL_JsqLK=pbF7Nx-2w98t62N53zbL1oGZpGEbZUK-xg5ms4AZw@mail.gmail.com>
On Mon, Apr 10, 2017 at 08:46:57AM -0500, Rob Herring wrote:
> On Sat, Apr 8, 2017 at 11:57 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Tue, Mar 28, 2017 at 05:59:31PM +0200, Sebastian Reichel wrote:
> >> Add method, which waits until the transmission buffer has been sent.
> >> Note, that the change in ttyport_write_wakeup is related, since
> >> tty_wait_until_sent will hang without that change.
> >>
> >> Acked-by: Rob Herring <robh@kernel.org>
> >> Acked-by: Pavel Machek <pavel@ucw.cz>
> >> Signed-off-by: Sebastian Reichel <sre@kernel.org>
> >> ---
> >> Changes since PATCHv2:
> >> * Avoid goto in ttyport_write_wakeup
> >> ---
> >> drivers/tty/serdev/core.c | 11 +++++++++++
> >> drivers/tty/serdev/serdev-ttyport.c | 18 ++++++++++++++----
> >> include/linux/serdev.h | 3 +++
> >> 3 files changed, 28 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> >> index f4c6c90add78..a63b74031e22 100644
> >> --- a/drivers/tty/serdev/core.c
> >> +++ b/drivers/tty/serdev/core.c
> >> @@ -173,6 +173,17 @@ void serdev_device_set_flow_control(struct serdev_device *serdev, bool enable)
> >> }
> >> EXPORT_SYMBOL_GPL(serdev_device_set_flow_control);
> >>
> >> +void serdev_device_wait_until_sent(struct serdev_device *serdev, long timeout)
> >> +{
> >> + struct serdev_controller *ctrl = serdev->ctrl;
> >> +
> >> + if (!ctrl || !ctrl->ops->wait_until_sent)
> >> + return;
> >> +
> >> + ctrl->ops->wait_until_sent(ctrl, timeout);
> >> +}
> >> +EXPORT_SYMBOL_GPL(serdev_device_wait_until_sent);
> >
> > Is this still needed now that we have serdev_device_write() with an
> > unlimited timeout available?
>
> Yes, because only this waits until the data is on the wire.
What "wire" is that? The serial wire? How do you know this? Many usb
to serial devices have no way to determine this, given that there is
another uart hanging off of the end of a USB connection.
Doesn't serdev_device_write() return when the write is finished? I
think we need some good documentation here for all of the different
variants of how to send data, as I'm sure confused...
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCHv3 02/10] serdev: add serdev_device_wait_until_sent
From: Rob Herring @ 2017-04-10 16:12 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Sebastian Reichel, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Samuel Thibault, Pavel Machek, Tony Lindgren,
Jiri Slaby, Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Andrey Smirnov
In-Reply-To: <20170410140313.GA31894@kroah.com>
+ Andrey
On Mon, Apr 10, 2017 at 9:03 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Mon, Apr 10, 2017 at 08:46:57AM -0500, Rob Herring wrote:
>> On Sat, Apr 8, 2017 at 11:57 AM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> > On Tue, Mar 28, 2017 at 05:59:31PM +0200, Sebastian Reichel wrote:
>> >> Add method, which waits until the transmission buffer has been sent.
>> >> Note, that the change in ttyport_write_wakeup is related, since
>> >> tty_wait_until_sent will hang without that change.
>> >>
>> >> Acked-by: Rob Herring <robh@kernel.org>
>> >> Acked-by: Pavel Machek <pavel@ucw.cz>
>> >> Signed-off-by: Sebastian Reichel <sre@kernel.org>
>> >> ---
>> >> Changes since PATCHv2:
>> >> * Avoid goto in ttyport_write_wakeup
>> >> ---
>> >> drivers/tty/serdev/core.c | 11 +++++++++++
>> >> drivers/tty/serdev/serdev-ttyport.c | 18 ++++++++++++++----
>> >> include/linux/serdev.h | 3 +++
>> >> 3 files changed, 28 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
>> >> index f4c6c90add78..a63b74031e22 100644
>> >> --- a/drivers/tty/serdev/core.c
>> >> +++ b/drivers/tty/serdev/core.c
>> >> @@ -173,6 +173,17 @@ void serdev_device_set_flow_control(struct serdev_device *serdev, bool enable)
>> >> }
>> >> EXPORT_SYMBOL_GPL(serdev_device_set_flow_control);
>> >>
>> >> +void serdev_device_wait_until_sent(struct serdev_device *serdev, long timeout)
>> >> +{
>> >> + struct serdev_controller *ctrl = serdev->ctrl;
>> >> +
>> >> + if (!ctrl || !ctrl->ops->wait_until_sent)
>> >> + return;
>> >> +
>> >> + ctrl->ops->wait_until_sent(ctrl, timeout);
>> >> +}
>> >> +EXPORT_SYMBOL_GPL(serdev_device_wait_until_sent);
>> >
>> > Is this still needed now that we have serdev_device_write() with an
>> > unlimited timeout available?
>>
>> Yes, because only this waits until the data is on the wire.
>
> What "wire" is that? The serial wire? How do you know this? Many usb
> to serial devices have no way to determine this, given that there is
> another uart hanging off of the end of a USB connection.
Okay, maybe it's just out of linux s/w buffers for h/w which you don't
know. It is the same semantics as tty_wait_until_sent which is
documented as: "Wait for characters pending in a tty driver to hit the
wire, or for a timeout to occur (eg due to flow control)"
> Doesn't serdev_device_write() return when the write is finished?
No, it returns when data is accepted by the tty layer (as serdev has
no buffering of its own).
> I
> think we need some good documentation here for all of the different
> variants of how to send data, as I'm sure confused...
Fair enough. However, I think that's somewhat orthogonal to this function.
There's 2 modes of sending data which are basically sync and async operation.
- serdev_device_write_buf - Only sends what can be immediately
accepted by lower layers. Caller should provide write_wakeup callback
to be notified.
- serdev_device_write - Sleeps until all data is accepted by lower
layers or a timeout occurs.
It's valid to call serdev_device_wait_until_sent in either case.
Yes, the naming is not the best, but we kept serdev_device_write_buf
to avoid any cross tree merges. We can remove or rename later as it is
just a wrapper now for serdev_device_write.
Rob
^ permalink raw reply
* Re: [PATCHv3 02/10] serdev: add serdev_device_wait_until_sent
From: Sebastian Reichel @ 2017-04-10 17:10 UTC (permalink / raw)
To: Rob Herring
Cc: Greg Kroah-Hartman, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Samuel Thibault, Pavel Machek, Tony Lindgren,
Jiri Slaby, Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Andrey Smirnov
In-Reply-To: <CAL_JsqJCjob6NDfHe0r7X3dXPEniKh5vChXhBxfyHZRu7Fov7A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3810 bytes --]
Hi,
On Mon, Apr 10, 2017 at 11:12:39AM -0500, Rob Herring wrote:
> On Mon, Apr 10, 2017 at 9:03 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Mon, Apr 10, 2017 at 08:46:57AM -0500, Rob Herring wrote:
> >> On Sat, Apr 8, 2017 at 11:57 AM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> > On Tue, Mar 28, 2017 at 05:59:31PM +0200, Sebastian Reichel wrote:
> >> >> Add method, which waits until the transmission buffer has been sent.
> >> >> Note, that the change in ttyport_write_wakeup is related, since
> >> >> tty_wait_until_sent will hang without that change.
> >> >>
> >> >> Acked-by: Rob Herring <robh@kernel.org>
> >> >> Acked-by: Pavel Machek <pavel@ucw.cz>
> >> >> Signed-off-by: Sebastian Reichel <sre@kernel.org>
> >> >> ---
> >> >> Changes since PATCHv2:
> >> >> * Avoid goto in ttyport_write_wakeup
> >> >> ---
> >> >> drivers/tty/serdev/core.c | 11 +++++++++++
> >> >> drivers/tty/serdev/serdev-ttyport.c | 18 ++++++++++++++----
> >> >> include/linux/serdev.h | 3 +++
> >> >> 3 files changed, 28 insertions(+), 4 deletions(-)
> >> >>
> >> >> diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> >> >> index f4c6c90add78..a63b74031e22 100644
> >> >> --- a/drivers/tty/serdev/core.c
> >> >> +++ b/drivers/tty/serdev/core.c
> >> >> @@ -173,6 +173,17 @@ void serdev_device_set_flow_control(struct serdev_device *serdev, bool enable)
> >> >> }
> >> >> EXPORT_SYMBOL_GPL(serdev_device_set_flow_control);
> >> >>
> >> >> +void serdev_device_wait_until_sent(struct serdev_device *serdev, long timeout)
> >> >> +{
> >> >> + struct serdev_controller *ctrl = serdev->ctrl;
> >> >> +
> >> >> + if (!ctrl || !ctrl->ops->wait_until_sent)
> >> >> + return;
> >> >> +
> >> >> + ctrl->ops->wait_until_sent(ctrl, timeout);
> >> >> +}
> >> >> +EXPORT_SYMBOL_GPL(serdev_device_wait_until_sent);
> >> >
> >> > Is this still needed now that we have serdev_device_write() with an
> >> > unlimited timeout available?
> >>
> >> Yes, because only this waits until the data is on the wire.
> >
> > What "wire" is that? The serial wire? How do you know this? Many usb
> > to serial devices have no way to determine this, given that there is
> > another uart hanging off of the end of a USB connection.
>
> Okay, maybe it's just out of linux s/w buffers for h/w which you don't
> know. It is the same semantics as tty_wait_until_sent which is
> documented as: "Wait for characters pending in a tty driver to hit the
> wire, or for a timeout to occur (eg due to flow control)"
For embedded h/w it usually means the serial wire. tty_wait_until_sent()
first waits for the tty buffer to be empty and then calls wait_until_sent()
in the driver providing the tty. In case of serial-core that is
implemented by uart_wait_until_sent(), which waits for the serial
driver's tx_empty() operation becoming true (grepping for
".tx_empty" returned 81 hits for me). Also at least some of the usb to
serial adapters seem to support this using usb_serial_generic_wait_until_sent()
and ".tx_empty":
$ git grep "\.tx_empty"
cp210x.c: .tx_empty = cp210x_tx_empty,
f81534.c: .tx_empty = f81534_tx_empty,
ftdi_sio.c: .tx_empty = ftdi_tx_empty,
io_ti.c: .tx_empty = edge_tx_empty,
io_ti.c: .tx_empty = edge_tx_empty,
mxuport.c: .tx_empty = mxuport_tx_empty,
ti_usb_3410_5052.c: .tx_empty = ti_tx_empty,
ti_usb_3410_5052.c: .tx_empty = ti_tx_empty,
The other ones will only wait for empty s/w buffer, but that's
already the case for tty_wait_until_sent(), so IMHO a different
problem.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCHv3 00/10] Nokia H4+ support
From: Sebastian Reichel @ 2017-04-10 23:10 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Greg Kroah-Hartman, Gustavo F. Padovan, Johan Hedberg,
Samuel Thibault, Pavel Machek, Tony Lindgren, Jiri Slaby,
Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, David S. Miller, Rob Herring
In-Reply-To: <CAL_Jsq+NU3M5yuBpK1UGgzCVvq0eABMApCqEe3_d5+tDaABsgQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]
Hi,
On Wed, Apr 05, 2017 at 01:16:58PM -0500, Rob Herring wrote:
> On Fri, Mar 31, 2017 at 8:33 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Wed, Mar 29, 2017 at 11:33:26PM +0200, Marcel Holtmann wrote:
> >> Hi Rob,
> >>
> >> >> Here is PATCHv3 for the Nokia bluetooth patchset. I addressed all comments from
> >> >> Rob and Pavel regarding the serdev patches and dropped the *.dts patches, since
> >> >> they were queued by Tony. I also changed the patch order, so that the serdev
> >> >> patches come first. All of them have Acked-by from Rob, so I think it makes
> >> >> sense to merge them to serdev subsystem (now) and provide an immutable branch
> >> >> for the bluetooth subsystem.
> >> >
> >> > Greg doesn't read cover letters generally and since the serdev patches
> >> > are Cc rather than To him, he's probably not planning to pick them up.
> >>
> >> I wonder actually if we should merge all of these via bluetooth-next
> >> tree with proper Ack from Greg. However it would be good to also get
> >> buy in from Dave for merging this ultimately through net-next.
> >
> > I don't really care where it goes. I can take the whole thing in my
> > tty/serial tree now if no one objects and I get an ack from the relevant
> > maintainers {hint...}
>
> I think it is better if it goes thru BT tree. I have another driver
> converted that is dependent on this series. There's a couple other
> serdev changes on the list too, but this shouldn't depend on them.
Is this waiting for something, or could it be queued to
bluetooth-next then? It would be nice to finally have
this in 4.12 :)
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCHv3 00/10] Nokia H4+ support
From: Marcel Holtmann @ 2017-04-11 11:36 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Greg Kroah-Hartman, Gustavo F. Padovan, Johan Hedberg,
Samuel Thibault, Pavel Machek, Tony Lindgren, Jiri Slaby,
Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, David S. Miller, Rob Herring
In-Reply-To: <20170410231041.vz35anezpzhscu4t@earth>
Hi Sebastian,
>>>>>> Here is PATCHv3 for the Nokia bluetooth patchset. I addressed all comments from
>>>>>> Rob and Pavel regarding the serdev patches and dropped the *.dts patches, since
>>>>>> they were queued by Tony. I also changed the patch order, so that the serdev
>>>>>> patches come first. All of them have Acked-by from Rob, so I think it makes
>>>>>> sense to merge them to serdev subsystem (now) and provide an immutable branch
>>>>>> for the bluetooth subsystem.
>>>>>
>>>>> Greg doesn't read cover letters generally and since the serdev patches
>>>>> are Cc rather than To him, he's probably not planning to pick them up.
>>>>
>>>> I wonder actually if we should merge all of these via bluetooth-next
>>>> tree with proper Ack from Greg. However it would be good to also get
>>>> buy in from Dave for merging this ultimately through net-next.
>>>
>>> I don't really care where it goes. I can take the whole thing in my
>>> tty/serial tree now if no one objects and I get an ack from the relevant
>>> maintainers {hint...}
>>
>> I think it is better if it goes thru BT tree. I have another driver
>> converted that is dependent on this series. There's a couple other
>> serdev changes on the list too, but this shouldn't depend on them.
>
> Is this waiting for something, or could it be queued to
> bluetooth-next then? It would be nice to finally have
> this in 4.12 :)
I would prefer if we can get an ACK from Greg. Then I merge it through the bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCHv4 0/2] cfg80211: mac80211: BTCOEX feature support
From: Arend Van Spriel @ 2017-04-11 12:02 UTC (permalink / raw)
To: c_traja, linux-wireless
Cc: ath10k, johannes, tamizhchelvam, linux-bluetooth, Marcel Holtmann
In-Reply-To: <1491905730-16392-1-git-send-email-c_traja@qti.qualcomm.com>
+ linux-bluetooth, Marcel
On 11-4-2017 12:15, c_traja@qti.qualcomm.com wrote:
> From: Tamizh chelvam <c_traja@qti.qualcomm.com>
>
> This patchset add support for BTCOEX feature to enable/disable and
> modifying btcoex priority value via nl80211
So you make a distinction between WMM ACs, but what about the different
types/profiles of BT traffic?
Regards,
Arend
> Tamizh chelvam (2):
> cfg80211: Add support to enable or disable btcoex and set
> btcoex_priority
> mac80211: Add support to enable or disable btcoex and set btcoex
> priority value
>
> v4 :
> * Moved btcoex_priority_support_flag enum to nl80211.h and renamed it.
> * fixed typo.
>
> v3 :
> * Introduced NL80211_EXT_FEATURE_BTCOEX_PRIORITY to expose
> btcoex priority support and removed bool variable.
>
> v2 :
> * Introduced NL80211_CMD_SET_BTCOEX to enable/disable btcoex and
> to set/modify btcoex_priority.
> * Added bool variable in wiphy structure to advertise btcoex_priority
> feature and removed BITMAP calculation for btcoex_priority value.
>
> include/net/cfg80211.h | 6 +++++
> include/net/mac80211.h | 5 +++++
> include/uapi/linux/nl80211.h | 50 ++++++++++++++++++++++++++++++++++++++++++
> net/mac80211/cfg.c | 9 ++++++++
> net/mac80211/driver-ops.h | 15 +++++++++++++
> net/mac80211/trace.h | 20 +++++++++++++++++
> net/wireless/nl80211.c | 45 +++++++++++++++++++++++++++++++++++++
> net/wireless/rdev-ops.h | 13 +++++++++++
> net/wireless/trace.h | 17 ++++++++++++++
> 9 files changed, 180 insertions(+)
>
^ permalink raw reply
* Re: [PATCHv3 00/10] Nokia H4+ support
From: Greg Kroah-Hartman @ 2017-04-11 14:06 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Sebastian Reichel, Gustavo F. Padovan, Johan Hedberg,
Samuel Thibault, Pavel Machek, Tony Lindgren, Jiri Slaby,
Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, David S. Miller, Rob Herring
In-Reply-To: <4FEFA1D8-BE23-40FB-BAA3-3EC910FE9F96@holtmann.org>
On Tue, Apr 11, 2017 at 01:36:44PM +0200, Marcel Holtmann wrote:
> Hi Sebastian,
>
> >>>>>> Here is PATCHv3 for the Nokia bluetooth patchset. I addressed all comments from
> >>>>>> Rob and Pavel regarding the serdev patches and dropped the *.dts patches, since
> >>>>>> they were queued by Tony. I also changed the patch order, so that the serdev
> >>>>>> patches come first. All of them have Acked-by from Rob, so I think it makes
> >>>>>> sense to merge them to serdev subsystem (now) and provide an immutable branch
> >>>>>> for the bluetooth subsystem.
> >>>>>
> >>>>> Greg doesn't read cover letters generally and since the serdev patches
> >>>>> are Cc rather than To him, he's probably not planning to pick them up.
> >>>>
> >>>> I wonder actually if we should merge all of these via bluetooth-next
> >>>> tree with proper Ack from Greg. However it would be good to also get
> >>>> buy in from Dave for merging this ultimately through net-next.
> >>>
> >>> I don't really care where it goes. I can take the whole thing in my
> >>> tty/serial tree now if no one objects and I get an ack from the relevant
> >>> maintainers {hint...}
> >>
> >> I think it is better if it goes thru BT tree. I have another driver
> >> converted that is dependent on this series. There's a couple other
> >> serdev changes on the list too, but this shouldn't depend on them.
> >
> > Is this waiting for something, or could it be queued to
> > bluetooth-next then? It would be nice to finally have
> > this in 4.12 :)
>
> I would prefer if we can get an ACK from Greg. Then I merge it through the bluetooth-next tree.
Sorry thought this was coming through mine:
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge away!
greg k-h
^ permalink raw reply
* [PATCH 1/6] 6lowpan: Don't set IFF_NO_QUEUE
From: Luiz Augusto von Dentz @ 2017-04-11 19:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: patrik.flykt, aar, jukka.rissanen, linux-wpan
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
There is no point in setting IFF_NO_QUEUE should already have taken
care of setting it if tx_queue_len is not set, in fact this may
actually disable queue for interfaces that require it and do set
tx_queue_len.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
net/6lowpan/core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/6lowpan/core.c b/net/6lowpan/core.c
index 5f9909a..40d3d72 100644
--- a/net/6lowpan/core.c
+++ b/net/6lowpan/core.c
@@ -35,7 +35,6 @@ int lowpan_register_netdevice(struct net_device *dev,
dev->type = ARPHRD_6LOWPAN;
dev->mtu = IPV6_MIN_MTU;
- dev->priv_flags |= IFF_NO_QUEUE;
lowpan_dev(dev)->lltype = lltype;
--
2.9.3
^ permalink raw reply related
* [PATCH 2/6] Bluetooth: 6lowpan: Don't drop packets when run out of credits
From: Luiz Augusto von Dentz @ 2017-04-11 19:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: patrik.flykt, aar, jukka.rissanen, linux-wpan
In-Reply-To: <20170411192103.3209-1-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Since l2cap_chan_send will now queue the packets there is no point in
checking the credits anymore.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
net/bluetooth/6lowpan.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 5b91e85..22bd936 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -478,15 +478,8 @@ static int send_pkt(struct l2cap_chan *chan, struct sk_buff *skb,
return 0;
}
- if (!err)
- err = (!chan->tx_credits ? -EAGAIN : 0);
-
- if (err < 0) {
- if (err == -EAGAIN)
- netdev->stats.tx_dropped++;
- else
- netdev->stats.tx_errors++;
- }
+ if (err < 0)
+ netdev->stats.tx_errors++;
return err;
}
--
2.9.3
^ permalink raw reply related
* [PATCH 3/6] Bluetooth: 6lowpan: Use netif APIs to flow control
From: Luiz Augusto von Dentz @ 2017-04-11 19:21 UTC (permalink / raw)
To: linux-bluetooth; +Cc: patrik.flykt, aar, jukka.rissanen, linux-wpan
In-Reply-To: <20170411192103.3209-1-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Rely on netif_wake_queue and netif_stop_queue to flow control when
transmit resources are unavailable.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
net/bluetooth/6lowpan.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 22bd936..dc7fda3 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -867,12 +867,28 @@ static struct sk_buff *chan_alloc_skb_cb(struct l2cap_chan *chan,
static void chan_suspend_cb(struct l2cap_chan *chan)
{
+ struct lowpan_btle_dev *dev;
+
BT_DBG("chan %p suspend", chan);
+
+ dev = lookup_dev(chan->conn);
+ if (!dev || !dev->netdev)
+ return;
+
+ netif_stop_queue(dev->netdev);
}
static void chan_resume_cb(struct l2cap_chan *chan)
{
+ struct lowpan_btle_dev *dev;
+
BT_DBG("chan %p resume", chan);
+
+ dev = lookup_dev(chan->conn);
+ if (!dev || !dev->netdev)
+ return;
+
+ netif_wake_queue(dev->netdev);
}
static long chan_get_sndtimeo_cb(struct l2cap_chan *chan)
--
2.9.3
^ permalink raw reply related
* [PATCH 4/6] Bluetooth: L2CAP: Add l2cap_le_flowctl_send
From: Luiz Augusto von Dentz @ 2017-04-11 19:21 UTC (permalink / raw)
To: linux-bluetooth; +Cc: patrik.flykt, aar, jukka.rissanen, linux-wpan
In-Reply-To: <20170411192103.3209-1-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Consolidate code sending data to LE CoC channels and adds proper
accounting of packets sent, the remaining credits and how many packets
are queued.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
net/bluetooth/l2cap_core.c | 27 +++++++++++++++++++--------
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 3a202b0..f88ac995 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -2425,6 +2425,22 @@ static int l2cap_segment_le_sdu(struct l2cap_chan *chan,
return 0;
}
+static void l2cap_le_flowctl_send(struct l2cap_chan *chan)
+{
+ int sent = 0;
+
+ BT_DBG("chan %p", chan);
+
+ while (chan->tx_credits && !skb_queue_empty(&chan->tx_q)) {
+ l2cap_do_send(chan, skb_dequeue(&chan->tx_q));
+ chan->tx_credits--;
+ sent++;
+ }
+
+ BT_DBG("Sent %d credits %u queued %u", sent, chan->tx_credits,
+ skb_queue_len(&chan->tx_q));
+}
+
int l2cap_chan_send(struct l2cap_chan *chan, struct msghdr *msg, size_t len)
{
struct sk_buff *skb;
@@ -2472,10 +2488,7 @@ int l2cap_chan_send(struct l2cap_chan *chan, struct msghdr *msg, size_t len)
skb_queue_splice_tail_init(&seg_queue, &chan->tx_q);
- while (chan->tx_credits && !skb_queue_empty(&chan->tx_q)) {
- l2cap_do_send(chan, skb_dequeue(&chan->tx_q));
- chan->tx_credits--;
- }
+ l2cap_le_flowctl_send(chan);
if (!chan->tx_credits)
chan->ops->suspend(chan);
@@ -5567,10 +5580,8 @@ static inline int l2cap_le_credits(struct l2cap_conn *conn,
chan->tx_credits += credits;
- while (chan->tx_credits && !skb_queue_empty(&chan->tx_q)) {
- l2cap_do_send(chan, skb_dequeue(&chan->tx_q));
- chan->tx_credits--;
- }
+ /* Resume sending */
+ l2cap_le_flowctl_send(chan);
if (chan->tx_credits)
chan->ops->resume(chan);
--
2.9.3
^ permalink raw reply related
* [PATCH 5/6] Bluetooth: 6lowpan: Set tx_queue_len to DEFAULT_TX_QUEUE_LEN
From: Luiz Augusto von Dentz @ 2017-04-11 19:21 UTC (permalink / raw)
To: linux-bluetooth; +Cc: patrik.flykt, aar, jukka.rissanen, linux-wpan
In-Reply-To: <20170411192103.3209-1-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Make netdev queue packets if we run out of credits.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
net/bluetooth/6lowpan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index dc7fda3..a4deba6 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -20,6 +20,7 @@
#include <net/ipv6.h>
#include <net/ip6_route.h>
#include <net/addrconf.h>
+#include <net/pkt_sched.h>
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
@@ -594,6 +595,7 @@ static void netdev_setup(struct net_device *dev)
dev->flags = IFF_RUNNING | IFF_POINTOPOINT |
IFF_MULTICAST;
dev->watchdog_timeo = 0;
+ dev->tx_queue_len = DEFAULT_TX_QUEUE_LEN;
dev->netdev_ops = &netdev_ops;
dev->header_ops = &header_ops;
--
2.9.3
^ permalink raw reply related
* [PATCH 6/6] bluetooth: Do not set IFF_POINTOPOINT
From: Luiz Augusto von Dentz @ 2017-04-11 19:21 UTC (permalink / raw)
To: linux-bluetooth; +Cc: patrik.flykt, aar, jukka.rissanen, linux-wpan
In-Reply-To: <20170411192103.3209-1-luiz.dentz@gmail.com>
From: Patrik Flykt <patrik.flykt@linux.intel.com>
The IPv6 stack needs to send and receive Neighbor Discovery
messages. Remove the IFF_POINTOPOINT flag.
Signed-off-by: Patrik Flykt <patrik.flykt@linux.intel.com>
Reviewed-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
net/bluetooth/6lowpan.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index a4deba6..6089599 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -592,8 +592,7 @@ static void netdev_setup(struct net_device *dev)
{
dev->hard_header_len = 0;
dev->needed_tailroom = 0;
- dev->flags = IFF_RUNNING | IFF_POINTOPOINT |
- IFF_MULTICAST;
+ dev->flags = IFF_RUNNING | IFF_MULTICAST;
dev->watchdog_timeo = 0;
dev->tx_queue_len = DEFAULT_TX_QUEUE_LEN;
--
2.9.3
^ permalink raw reply related
* RE: [PATCHv4 0/2] cfg80211: mac80211: BTCOEX feature support
From: Tamizh Chelvam Raja @ 2017-04-12 7:08 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless@vger.kernel.org
Cc: ath10k@lists.infradead.org, johannes@sipsolutions.net,
tamizhchelvam@codeaurora.org, linux-bluetooth@vger.kernel.org,
Marcel Holtmann
In-Reply-To: <50d867d1-740c-85b9-2bab-6ef49c4d87c1@broadcom.com>
> + linux-bluetooth, Marcel
>=20
> On 11-4-2017 12:15, c_traja@qti.qualcomm.com wrote:
> > From: Tamizh chelvam <c_traja@qti.qualcomm.com>
> >
> > This patchset add support for BTCOEX feature to enable/disable and
> > modifying btcoex priority value via nl80211
>=20
> So you make a distinction between WMM ACs, but what about the different
> types/profiles of BT traffic?
>
[Tamizh] There will be BT high and BT low traffic. It will be decided by BT=
module. Firmware internally checks BT low traffic with wlan traffic. If we=
enable some of
wlan frames as high priority, those frames will have more priority than BT =
low traffic.
=20
> Regards,
> Arend
>=20
> > Tamizh chelvam (2):
> > cfg80211: Add support to enable or disable btcoex and set
> > btcoex_priority
> > mac80211: Add support to enable or disable btcoex and set btcoex
> > priority value
> >
> > v4 :
> > * Moved btcoex_priority_support_flag enum to nl80211.h and renamed it=
.
> > * fixed typo.
> >
> > v3 :
> > * Introduced NL80211_EXT_FEATURE_BTCOEX_PRIORITY to expose
> > btcoex priority support and removed bool variable.
> >
> > v2 :
> > * Introduced NL80211_CMD_SET_BTCOEX to enable/disable btcoex and
> > to set/modify btcoex_priority.
> > * Added bool variable in wiphy structure to advertise btcoex_priority
> > feature and removed BITMAP calculation for btcoex_priority value.
> >
> > include/net/cfg80211.h | 6 +++++
> > include/net/mac80211.h | 5 +++++
> > include/uapi/linux/nl80211.h | 50
> ++++++++++++++++++++++++++++++++++++++++++
> > net/mac80211/cfg.c | 9 ++++++++
> > net/mac80211/driver-ops.h | 15 +++++++++++++
> > net/mac80211/trace.h | 20 +++++++++++++++++
> > net/wireless/nl80211.c | 45
> +++++++++++++++++++++++++++++++++++++
> > net/wireless/rdev-ops.h | 13 +++++++++++
> > net/wireless/trace.h | 17 ++++++++++++++
> > 9 files changed, 180 insertions(+)
> >
^ permalink raw reply
* Re: [PATCH V2 00/16] hci_ldisc hci_uart_tty_close() fixes
From: Dean Jenkins @ 2017-04-12 9:13 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Gustavo F . Padovan, Johan Hedberg, linux-bluetooth
In-Reply-To: <1491584678-27228-1-git-send-email-Dean_Jenkins@mentor.com>
Hi Marcel,
On 07/04/17 18:04, Dean Jenkins wrote:
> This is patchset V2 which reorganises hci_uart_tty_close() to overcome a design
> flaw related to the proper closure of the Data Link protocol layer. In the worst
> case scenario a kernel crash occurs.
>
>
> Previous Discussions
> ====================
>
> Please refer to the discussion on my RFC patchset V1 that can be found here:
> https://www.spinics.net/lists/linux-bluetooth/msg70077.html
>
>
> Changes between V1 and V2
> =========================
>
> 1. Implemented some minor code style changes that were suggested by Marcel
> Holtmann.
> 2. Reordered some of the patches to better group together related changes.
>
>
> Terms used
> ==========
>
> Data Link protocol:
>
> This refers to the serial link protocol used by the UART based Bluetooth Radio
> Module. h4, BCSP and h5 are examples of Data Link protocols and there are other
> protocols available.
>
> Data Link protocol layer:
>
> This refers to the "proto" protocols that implement the Data Link protocol on
> the Linux side of the UART link.
>
> These protocols are implemented with a function pointer interface and therefore
> a specific Data Link protocol can be bound within the UART HCI driver.
>
>
> Overview of Data Link protocol data flow
> ========================================
>
> The Data Link protocol layer uses serial protocol frames to transport
> information such as HCI messages to the Bluetooth Radio Module.
>
> Internally within the Linux kernel, the Data Link protocol layer supplies
> protocol frames via the HCI UART LDISC and TTY layers to the UART driver. Any
> breakage in this data "pipe" will cause a disruption of the communications with
> the Bluetooth Radio Module.
>
>
> Overview of Design Flaw
> =======================
>
> There are a number of issues relating to the implementation of
> hci_uart_tty_close().
>
> The areas of concern are:
>
> a) poor locking of hu->proto->close() with respect to the other "proto" function
> pointers. This means hu->proto->close() can asynchronously remove resources
> used by the other "proto" function pointers resulting in malfunctions and
> kernel crashes.
>
> b) tearing down parts of the data "pipe" between the Data Link protocol layer
> and the UART driver despite attempting to send HCI commands and trying to
> handle retransmissions within hci_uart_tty_close(). This results in a loss of
> communications with the Bluetooth Radio Module. Note that a loss of
> communications can cause the Data Link protocol layer to independently
> attempt to retransmit such as in the case of BCSP.
>
> c) suspect HCI_QUIRK_RESET_ON_CLOSE has been broken for many years because it
> is not possible to get the HCI RESET command successfully ACK'ed due to the
> data "pipe" being cut in multiple places during the execution of
> tty_ldisc_close().
>
> Please note the issue is independent of the implementation of the Data Link
> protocol layer. BCSP closedown scenarios have been used as an example.
>
>
> Test cases
> ==========
>
> Test 1
> ------
>
> Setup Bluetooth to use a BCSP based UART Bluetooth Radio Module. In this case
> use the Bluez hciattach utility.
>
> Then kill the userland hciattach program by doing
> killall hciattach
>
> When hciattach terminates, SIGTERM handling causes ioctl TIOCSETD to run
> kernel function tty_set_ldisc().
>
> Test 2
> ------
>
> Setup Bluetooth to use a BCSP based UART Bluetooth Radio Module. In this case
> use the Bluez btattach utility.
>
> Note that btattach does not establish a BCSP connection due to missing some BCSP
> protocol implementation. However, this is ideal in exposing the design flaw.
>
> Here is an example test script that can trigger a Bluetooth kernel crash in
> relation to hci_uart_tty_close().
>
> #!/bin/bash
>
> let i=1
>
> while [ true ]
> do
> echo "loop $i"
> ./btattach -A /dev/ttyUSB0 -P bcsp &
> sleep 5
> echo "now killing..."
> killall btattach
> i=$(($i + 1))
> done
>
> Kernel crashes within 10 minutes of starting the script.
>
> h4 can also be shown to fail by using
> ./btattach -A /dev/ttyUSB0 -P h4 &
>
> Note that in my test run, h4 was communicating with a BCSP enabled Bluetooth
> Radio Module. The probability of a crash is increased when poor communications
> occur.
>
> When btattach gets a SIGTERM, the program terminates with a group_exit() system
> call which causes tty_set_ldisc() to run to perform clean-up.
>
>
> Analysis of hci_uart_tty_close() callstack
> ==========================================
>
> Crash 1 - Sending HCI RESET command due to HCI_QUIRK_RESET_ON_CLOSE
> -------
>
> From tests 1 and 2 the callstack can be:
>
> tty_set_ldisc() takes a tty ref lock via tty_ldisc_lock
> tty_ldisc_close()
> hci_uart_tty_close()
> hci_unregister_dev()
> hci_dev_do_close()
> __hci_req_sync() which tries to send a HCI RESET command which depends on
> HCI_QUIRK_RESET_ON_CLOSE being enabled and that is the default condition. This
> is done by queueing up the HCI RESET command which adds a work-item to the
> hdev->workqueue and waits 2 seconds for a response
>
> Subsequently in a parallel thread to hci_uart_tty_close()
> hdev->workqueue runs and processes the work-item by calling
> hci_cmd_work()
> hci_send_frame()
> hci_uart_send_frame()
> hci_uart_tx_wakeup() to schedule hci_uart_write_work() via the work queue
> hu->write_work
>
> Subsequently in a parallel thread to hci_uart_tty_close()
> hci_uart_write_work()
> hci_uart_dequeue()
> hu->proto->dequeue()
> bcsp_dequeue()
> tty->ops->write() to write the BCSP frame to the UART driver via TTY layer
>
> Subsequently in a parallel thread to hci_uart_tty_close()
> BCSP re-transmission timer expires after 250ms due to no ACK from the Bluetooth
> Radio Module.
> bcsp_timed_event()
> hci_uart_tx_wakeup() to schedule hci_uart_write_work() via the work queue
> hu->write_work
>
> Subsequently in a parallel thread to hci_uart_tty_close()
> hci_uart_write_work()
> hci_uart_dequeue()
> hu->proto->dequeue()
> bcsp_dequeue()
> tty->ops->write() to write the BCSP frame to the UART driver via TTY layer
>
> Subsequently in a parallel thread to hci_uart_tty_close()
> BCSP re-transmission timer expires after 250ms due to no ACK from the Bluetooth
> Radio Module.
> bcsp_timed_event()
> hci_uart_tx_wakeup() to schedule hci_uart_write_work() via the work queue
> hu->write_work
>
> Subsequently in a parallel thread to hci_uart_tty_close()
> hci_uart_write_work()
> hci_uart_dequeue()
> hu->proto->dequeue()
> bcsp_dequeue()
> tty->ops->write() to write the BCSP frame to the UART driver via TTY layer
>
> etc. BCSP attempts to retransmit every 250ms during the execution of
> hci_uart_tty_close() until bcsp_close() is called via hu->proto->close().
>
> Here is an example kernel crash log for kernel 4.10.5 + debug
> (sorry for the bad kernel version string 4.10.54.10.5_debug+)
>
> [ 1561.709737] BUG: unable to handle kernel NULL pointer dereference at 0000000000000044
> [ 1561.709829] IP: _raw_spin_lock_irqsave+0x22/0x40
> [ 1561.709862] PGD 0
> [ 1561.709889] Oops: 0002 1 SMP
> [ 1561.709911] Modules linked in: ftdi_sio rfcomm hci_uart btqca xt_set ip_set_hash_ip nf_log_ipv6 ip_set nf_log_ipv4 nf_log_common xt_LOG ip6table_nat nf_nat_ipv6 xt_recent iptable_nat nf_nat_ipv4 ipt_REJECT nf_reject_ipv4 iptable_mangle iptable_raw nf_conntrack_ipv4 nf_defrag_ipv4 xt_comment ip6t_REJECT nf_reject_ipv6 xt_addrtype bridge stp llc xt_mark ip6table_mangle nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp xt_tcpudp nf_nat_sip xt_CT nf_nat_pptp nf_nat_proto_gre nf_nat_irc ip6table_raw nf_nat_h323 xt_multiport nf_nat_ftp nf_nat_amanda nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_nat nf_conntrack_tftp nf_conntrack_sip nf_conntrack_sane nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nfnetlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323
> [ 1561.710172] nf_conntrack_ftp ts_kmp nf_conntrack_amanda nf_conntrack iptable_filter ip_tables ip6table_filter ip6_tables x_tables lockd grace ctr ccm af_packet bnep msr usbserial uvcvideo btusb btrtl arc4 brcmsmac btbcm videobuf2_vmalloc btintel cordic videobuf2_memops bluetooth intel_powerclamp brcmutil videobuf2_v4l2 videobuf2_core mac80211 videodev coretemp kvm_intel kvm joydev media cfg80211 iTCO_wdt iTCO_vendor_support snd_hda_codec_hdmi snd_hda_codec_realtek psmouse snd_hda_codec_generic toshiba_acpi input_leds bcma snd_hda_intel irqbypass snd_hda_codec toshiba_bluetooth cpufreq_ondemand sparse_keymap crc32c_intel cpufreq_conservative industrialio snd_hda_core serio_raw wmi rfkill thermal cpufreq_powersave battery ac snd_hwdep snd_pcm acpi_cpufreq snd_timer snd toshiba_haps mei_me mei e1000e
> [ 1561.718028] fjes soundcore evdev ptp lpc_ich shpchp pps_core intel_ips tpm_tis tpm_tis_core nvram tpm sch_fq_codel sunrpc ipv6 crc_ccitt autofs4 hid_generic usbhid hid sdhci_pci mmc_block sdhci sr_mod ehci_pci ehci_hcd mmc_core usbcore usb_common i915 video button i2c_algo_bit drm_kms_helper drm [last unloaded: ftdi_sio]
> [ 1561.721317] CPU: 1 PID: 4473 Comm: kworker/1:0 Not tainted 4.10.54.10.5_debug+ #12
> [ 1561.722981] Hardware name: TOSHIBA Satellite R630/Portable PC, BIOS Version 1.40 07/20/2010
> [ 1561.724660] Workqueue: events hci_uart_write_work [hci_uart]
> [ 1561.726377] task: ffff98d9b4f15100 task.stack: ffffa868c1178000
> [ 1561.728568] RIP: 0010:_raw_spin_lock_irqsave+0x22/0x40
> [ 1561.730355] RSP: 0000:ffffa868c117bda8 EFLAGS: 00010046
> [ 1561.731993] RAX: 0000000000000000 RBX: 0000000000000296 RCX: 0000000000079ad6
> [ 1561.733646] RDX: 0000000000000001 RSI: ffff98da77c5c580 RDI: 0000000000000044
> [ 1561.735314] RBP: ffffa868c117bdb0 R08: 000000000001c5a0 R09: ffffffff9965a54a
> [ 1561.736991] R10: fffff48441dc9a80 R11: ffff98da73403700 R12: 0000000000000030
> [ 1561.738641] R13: 0000000000000044 R14: 0000000000000030 R15: ffff98d9b4e50000
> [ 1561.740288] FS: 0000000000000000(0000) GS:ffff98da77c40000(0000) knlGS:0000000000000000
> [ 1561.741940] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1561.743585] CR2: 0000000000000044 CR3: 0000000128d1a000 CR4: 00000000000006e0
> [ 1561.745238] Call Trace:
> [ 1561.746882] skb_dequeue+0x1d/0x70
> [ 1561.748512] bcsp_dequeue+0x27/0x180 [hci_uart]
> [ 1561.750130] ? kfree_skbmem+0x5a/0x60
> [ 1561.751742] hci_uart_write_work+0xc4/0x100 [hci_uart]
> [ 1561.753356] process_one_work+0x151/0x410
> [ 1561.754930] worker_thread+0x69/0x4b0
> [ 1561.756507] kthread+0x114/0x150
> [ 1561.758076] ? rescuer_thread+0x340/0x340
> [ 1561.759636] ? kthread_park+0x90/0x90
> [ 1561.761191] ret_from_fork+0x2c/0x40
> [ 1561.762693] Code: 89 e5 e8 82 96 98 ff 5d c3 66 66 66 66 90 55 48 89 e5 53 9c 58 66 66 90 66 90 48 89 c3 fa 66 66 90 66 66 90 31 c0 ba 01 00 00 00 <f0> 0f b1 17 85 c0 75 06 48 89 d8 5b 5d c3 89 c6 e8 29 83 98 ff
> [ 1561.766034] RIP: _raw_spin_lock_irqsave+0x22/0x40 RSP: ffffa868c117bda8
> [ 1561.768033] CR2: 0000000000000044
> [ 1561.774555] --[ end trace 51cc1d3575c0e559 ]--
>
>
> Crash 2 - Sending HCI commands but get no ACKs
> -------
>
> Using test 2 and h4, a similar crash could be triggered for h4_dequeue().
>
> In this case HCI is attempting to send multiple HCI commands.
>
> tty_set_ldisc() takes a tty ref lock via tty_ldisc_lock
> tty_ldisc_close()
> hci_uart_tty_close()
> hci_unregister_dev()
> hci_dev_do_close()
>
> HCI commands become queued up by adding work-items to the hdev->workqueue.
>
> Subsequently in a parallel thread to hci_uart_tty_close()
> hdev->workqueue runs and processes a work-item by calling
> hci_cmd_work()
> hci_send_frame()
> hci_uart_send_frame()
> hci_uart_tx_wakeup() to schedule hci_uart_write_work() via the work queue
> hu->write_work
>
> Subsequently in a parallel thread to hci_uart_tty_close()
> hci_uart_write_work()
> hci_uart_dequeue()
> hu->proto->dequeue()
> tty->ops->write() to write the h4 frame to the UART driver via TTY layer
>
> Subsequently in a parallel thread to hci_uart_tty_close()
> hdev->workqueue runs and processes a work-item by calling
> hci_cmd_work()
> hci_send_frame()
> hci_uart_send_frame()
> hci_uart_tx_wakeup() to schedule hci_uart_write_work() via the work queue
> hu->write_work
>
> Subsequently in a parallel thread to hci_uart_tty_close()
> hci_uart_write_work()
> hci_uart_dequeue()
> hu->proto->dequeue()
> tty->ops->write() to write the h4 frame to the UART driver via TTY layer
>
> etc. Note that HCI TX timeouts occur.
>
> Here is an example kernel crash log for kernel 4.10.5 + debug
> (sorry for the bad kernel version string 4.10.54.10.5_debug+)
>
> [ 563.702430] BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
> [ 563.702491] IP: _raw_spin_lock_irqsave+0x22/0x40
> [ 563.702520] PGD 13230e067
> [ 563.702521] PUD 1238d6067
> [ 563.702540] PMD 0
> [ 563.704521] Oops: 0002 1 SMP
> [ 563.706215] Modules linked in: hci_uart btqca nf_log_ipv6 ip6table_nat nf_nat_ipv6 ip6t_REJECT nf_reject_ipv6 ip6table_mangle xt_set ip_set_hash_ip ip_set nf_log_ipv4 nf_log_common xt_LOG xt_recent iptable_nat nf_nat_ipv4 xt_comment ipt_REJECT nf_reject_ipv4 xt_addrtype bridge stp llc xt_mark iptable_mangle xt_tcpudp iptable_raw nf_conntrack_ipv4 nf_defrag_ipv4 xt_CT nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp ip6table_raw nf_nat_sip xt_multiport nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_h323 nf_nat_ftp xt_conntrack nf_nat_amanda nf_nat nf_conntrack_tftp nf_conntrack_sip nf_conntrack_sane nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nfnetlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp
> [ 563.715634] ts_kmp nf_conntrack_amanda nf_conntrack iptable_filter ip_tables ip6table_filter ip6_tables x_tables lockd grace ctr ccm af_packet bnep msr arc4 brcmsmac uvcvideo cordic brcmutil ftdi_sio videobuf2_vmalloc usbserial intel_powerclamp mac80211 videobuf2_memops btusb videobuf2_v4l2 btrtl coretemp snd_hda_codec_hdmi btbcm videobuf2_core btintel kvm_intel snd_hda_codec_realtek bluetooth kvm videodev joydev cfg80211 snd_hda_codec_generic media snd_hda_intel snd_hda_codec psmouse snd_hda_core irqbypass e1000e snd_hwdep input_leds snd_pcm iTCO_wdt iTCO_vendor_support serio_raw crc32c_intel toshiba_acpi snd_timer ptp mei_me fjes bcma snd mei thermal sparse_keymap toshiba_haps industrialio lpc_ich soundcore battery ac pps_core shpchp intel_ips toshiba_bluetooth wmi rfkill tpm_tis tpm_tis_core
> [ 563.726159] tpm cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq evdev nvram sunrpc sch_fq_codel ipv6 crc_ccitt autofs4 hid_generic usbhid hid sdhci_pci mmc_block sdhci sr_mod ehci_pci ehci_hcd mmc_core usbcore usb_common i915 video button i2c_algo_bit drm_kms_helper drm
> [ 563.730623] CPU: 0 PID: 29 Comm: kworker/0:1 Not tainted 4.10.54.10.5_debug+ #13
> [ 563.732862] Hardware name: TOSHIBA Satellite R630/Portable PC, BIOS Version 1.40 07/20/2010
> [ 563.735127] Workqueue: events hci_uart_write_work [hci_uart]
> [ 563.737376] task: ffffa03f32951b00 task.stack: ffffbc4ec0768000
> [ 563.739620] RIP: 0010:_raw_spin_lock_irqsave+0x22/0x40
> [ 563.741839] RSP: 0018:ffffbc4ec076bdd8 EFLAGS: 00010046
> [ 563.744059] RAX: 0000000000000000 RBX: 0000000000000202 RCX: ffffa03f37c1cd60
> [ 563.746286] RDX: 0000000000000001 RSI: ffffa03f37c18ae0 RDI: 000000000000001c
> [ 563.748493] RBP: ffffbc4ec076bde0 R08: ffffa03f32332380 R09: 0000000000000001
> [ 563.750690] R10: ffffe9de427ce800 R11: ffffa03f33498600 R12: 0000000000000008
> [ 563.752884] R13: 000000000000001c R14: ffffa03e79b1ad38 R15: ffffa03e79b1a240
> [ 563.755075] FS: 0000000000000000(0000) GS:ffffa03f37c00000(0000) knlGS:0000000000000000
> [ 563.757260] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 563.759426] CR2: 000000000000001c CR3: 000000011d7a3000 CR4: 00000000000006f0
> [ 563.761610] Call Trace:
> [ 563.763798] skb_dequeue+0x1d/0x70
> [ 563.765975] h4_dequeue+0x16/0x20 [hci_uart]
> [ 563.768128] hci_uart_write_work+0xc4/0x100 [hci_uart]
> [ 563.770262] process_one_work+0x151/0x410
> [ 563.772368] worker_thread+0x69/0x4b0
> [ 563.774466] kthread+0x114/0x150
> [ 563.776519] ? rescuer_thread+0x340/0x340
> [ 563.778546] ? kthread_park+0x90/0x90
> [ 563.780566] ret_from_fork+0x2c/0x40
> [ 563.782559] Code: 89 e5 e8 82 96 98 ff 5d c3 66 66 66 66 90 55 48 89 e5 53 9c 58 66 66 90 66 90 48 89 c3 fa 66 66 90 66 66 90 31 c0 ba 01 00 00 00 <f0> 0f b1 17 85 c0 75 06 48 89 d8 5b 5d c3 89 c6 e8 29 83 98 ff
> [ 563.786800] RIP: _raw_spin_lock_irqsave+0x22/0x40 RSP: ffffbc4ec076bdd8
> [ 563.788940] CR2: 000000000000001c
> [ 563.798389] --[ end trace 326429e7baa9f359 ]--
>
>
> Detailed analysis
> =================
>
> The failure can be rare due to the following mitigations:
>
> a) the Data Link protocol layer might be idle when hci_uart_tty_close() runs.
> b) the system never shuts down Bluetooth so hci_uart_tty_close() does not run.
> c) HCI_QUIRK_RESET_ON_CLOSE is disabled so the HCI RESET command is not sent.
>
> Please note that disabling HCI_QUIRK_RESET_ON_CLOSE helps to reduce the
> probability that a crash occurs. However, it is not a fix.
>
> It can be seen that the following threads can be running concurrently with
> hci_uart_tty_close():
>
> a) hci_cmd_work() via the work queue hdev->workqueue
> b) hci_uart_write_work() via the work queue hu->write_work
> c) Data Link protocol layer retransmission timer such as bcsp_timed_event()
>
> In order to send a HCI command the Data Link protocol layer must be able to send
> and receive frames from the UART port that is physically connected to the UART
> based Bluetooth Radio Module. If this data "pipe" is broken then the Data Link
> protocol layer may perform retransmissions such as in the case of BCSP. In
> addition, a loss of communications causes the HCI command to not be ACK'ed so
> causes a HCI command timeout to occur.
>
> In the case of HCI_QUIRK_RESET_ON_CLOSE, the sending of the HCI RESET command
> has a 2 second timeout which will block __hci_req_sync() for up to 2 seconds.
>
> The hu->proto->dequeue() kernel crash occurs because hu->proto->close() was
> called which removes the resources needed by hu->proto->dequeue(). This causes
> a NULL pointer dereference kernel crash to occur when hu->proto->dequeue()
> executes.
>
> The reason why hu->proto->close() can run before or during hu->proto->dequeue()
> is because the call to cancel_work_sync(&hu->write_work) is ineffective. This is
> because hci_cmd_work() and BCSP bcsp_timed_event() can schedule work-items
> after the cancel_work_sync() completed.
>
> Note that flushing can corrupt any protocol serial frames being sent from the
> Data Link protocol layer to the UART driver and this is undesirable.
>
>
> Solution
> ========
>
> Reorganise hci_uart_tty_close() so that hci_unregister_dev() can run with no
> interference to the data "pipe" between the Data Link protocol layer such as
> BCSP and the UART driver.
>
> The patchset cleans up the HCI_UART_REGISTERED and HCI_UART_PROTO_READY flag
> handling so that:
>
> a) hdev is only valid when HCI_UART_REGISTERED is in the set state.
> b) the "proto" Data Link function pointers can only be used when
> HCI_UART_PROTO_READY is in the set state.
>
> The most important patch is
> "Bluetooth: hci_ldisc: Use rwlocking to avoid closing proto races"
>
> This patch adds rwlocking around the clearing of the flag HCI_UART_PROTO_READY.
> This is because the atomic flag HCI_UART_PROTO_READY cannot always prevent a
> thread using a Data Link protocol layer function pointer during or after closure
> of the Data Link protocol layer. This can result in a kernel crash. Remember
> that the BCSP retransmission handling runs in a separate thread and tries to
> send a new frame. Therefore there is a small window of a race condition for the
> flag HCI_UART_PROTO_READY to be seen in the set state and then calls the
> "proto" function pointer after the Data Link protocol layer has been closed,
> resulting in a kernel crash.
>
>
> Overview of patches
> -------------------
>
> The patches were rebased onto the bluetooth-next/master branch commit:
> 3eed895 Bluetooth: L2CAP: Don't return -EAGAIN if out of credits
>
> Tidy-up patches (mainly for h5 binding error handling)
> Bluetooth: hci_ldisc: Add missing return in hci_uart_init_work()
> Bluetooth: hci_ldisc: Ensure hu->hdev set to NULL before freeing hdev
> Bluetooth: hci_ldisc: Add missing clear HCI_UART_PROTO_READY
>
> Adds a comment to warn that hci_unregister_dev() may send a HCI RESET command
> Bluetooth: hci_ldisc: Add HCI RESET comment to hci_unregister_dev()
> call
>
> Simplifies the relationship between HCI_UART_REGISTERED and HCI_UART_PROTO_READY
> Bluetooth: hci_ldisc: Separate flag handling in hci_uart_tty_close()
>
> Prevents "proto" functions being used immediately before and after
> hu->proto->close()
> Bluetooth: hci_ldisc: Add protocol check to hci_uart_send_frame()
> Bluetooth: hci_ldisc: Add protocol check to hci_uart_dequeue()
> Bluetooth: hci_ldisc: Add protocol check to hci_uart_tx_wakeup()
> Bluetooth: hci_ldisc: Use rwlocking to avoid closing proto races
>
> Prevents the "data" pipe being cut too early inside hci_uart_tty_close()
> Bluetooth: hci_ldisc: Tidy-up HCI_UART_REGISTERED in
> hci_uart_tty_close()
> Bluetooth: hci_ldisc: hci_uart_tty_close() move hci_uart_close()
> Bluetooth: hci_ldisc: hci_uart_tty_close() detach tty after last msg
> Bluetooth: hci_ldisc: hci_uart_tty_close() move cancel_work_sync()
> Bluetooth: hci_ldisc: hci_uart_tty_close() free hu->tx_skb
> Bluetooth: hci_ldisc: Simplify flushing
>
> Prevent concurrency of hci_uart_tty_ioctl() with hci_uart_tty_close()
> Bluetooth: hci_ldisc: Add ioctl_mutex avoiding concurrency
>
>
> Further work
> ============
>
> This patchset tackles the issues of hci_uart_tty_close().
>
> However, the TTY layer needs investigation because tty_set_ldisc() has a tty ref
> lock during the execution of hci_uart_tty_close() which:
>
> a) prevents flush_to_ldisc() from passing the received UART data to the Data
> Link protocol layer.
> b) prevents hci_uart_tty_wakeup() from passing the Data Link protocol layer's
> transmission data to the UART driver.
>
> Therefore, the TTY layer cuts the data "pipe" during the execution of
> hci_uart_tty_close() causing a loss of communications with the Bluetooth Radio
> Module.
>
> This patchset does not attempt to fix the TTY layer. This means that the
> HCI_QUIRK_RESET_ON_CLOSE will remain being unsuccessful in sending the HCI RESET
> command. In fact, all attempts at sending an HCI command during
> hci_uart_tty_close() will still fail.
>
>
> Dean Jenkins (16):
> Bluetooth: hci_ldisc: Add missing return in hci_uart_init_work()
> Bluetooth: hci_ldisc: Ensure hu->hdev set to NULL before freeing hdev
> Bluetooth: hci_ldisc: Add missing clear HCI_UART_PROTO_READY
> Bluetooth: hci_ldisc: Add HCI RESET comment to hci_unregister_dev()
> call
> Bluetooth: hci_ldisc: Separate flag handling in hci_uart_tty_close()
> Bluetooth: hci_ldisc: Add protocol check to hci_uart_send_frame()
> Bluetooth: hci_ldisc: Add protocol check to hci_uart_dequeue()
> Bluetooth: hci_ldisc: Add protocol check to hci_uart_tx_wakeup()
> Bluetooth: hci_ldisc: Use rwlocking to avoid closing proto races
> Bluetooth: hci_ldisc: Tidy-up HCI_UART_REGISTERED in
> hci_uart_tty_close()
> Bluetooth: hci_ldisc: hci_uart_tty_close() move hci_uart_close()
> Bluetooth: hci_ldisc: hci_uart_tty_close() detach tty after last msg
> Bluetooth: hci_ldisc: hci_uart_tty_close() move cancel_work_sync()
> Bluetooth: hci_ldisc: hci_uart_tty_close() free hu->tx_skb
> Bluetooth: hci_ldisc: Simplify flushing
> Bluetooth: hci_ldisc: Add ioctl_mutex avoiding concurrency
>
> drivers/bluetooth/hci_ldisc.c | 105 ++++++++++++++++++++++++++++++++----------
> drivers/bluetooth/hci_uart.h | 3 ++
> 2 files changed, 84 insertions(+), 24 deletions(-)
>
If you have not already noticed, I have sent you my V2 HCI UART LDISC
patchset for you to look at.
I look forward to receiving your comments and feedback.
Thank you,
Best regards,
Dean
--
Dean Jenkins
Embedded Software Engineer
Linux Transportation Solutions
Mentor Embedded Software Division
Mentor Graphics (UK) Ltd.
^ permalink raw reply
* Errors with SelectConfiguration callback implementation with bluez
From: Sudha S @ 2017-04-12 9:15 UTC (permalink / raw)
To: linux-bluetooth
Hi ,
I am a Bluez newbie and wanted your help with an issue that I am facing .
My linux system is running bluez 5.42 . The bluetooth application is
implementing media-api.txt api's to stream audio to a bluetooth
speaker .
The Registration to end point is succesfful with SBC as the codec.
Once this is successful, the application registers for the
SelectConfiguration and SetConfiguration callback . These are defined
in a xml .
In my application, I am receiving the "SelectConfiguation" callback .
With this , a reply is sent to bluez with the selected parameters .
However I am getting the following errors :
-------------------------------------------------------------------------------------------------------
../bluez-5.42/profiles/audio/media.c:media_endpoint_async_call()
Calling SelectConfiguration: name = :1.1 path =
/MediaEndpoint/A2DPSource
Endpoint replied with an error: org.freedesktop.DBus.Error.NoReply
../bluez-5.42/profiles/audio/a2dp.c:select_cb() Endpoint replied an
invalid configuration
Request your inputs on this .
The code snippet when sending a reply to the "SelectConfiguration"
static void handle_method_call(GDBusConnection *conn,
const gchar *sender,
const gchar *object_path,
const gchar *interface_name,
const gchar *method_name,
GVariant *parameters,
GDBusMethodInvocation *invocation,
gpointer user_data)
{
if (!g_strcmp0(method_name, "SelectConfiguration")) {
printf("SelectConfiguration received !!!!!!!!!");
GVariantBuilder *c;
GVariant* arr;
c = g_variant_builder_new(G_VARIANT_TYPE ("ay"));
g_variant_builder_add(c , "y", 0x21);
g_variant_builder_add(c , "y", 0x15);
g_variant_builder_add(c , "y", 2);
g_variant_builder_add(c , "y", 32);
arr = g_variant_builder_end (c);
GVariant* tupleParam = g_variant_new_tuple(&arr, 1);
GDBusMessage *reply;
reply = g_dbus_message_new_method_reply
(g_dbus_method_invocation_get_message (invocation));
g_dbus_message_set_body(reply, tupleParam);
GError* error = NULL;
bool result = g_dbus_connection_send_message(mGdbusConnection,
reply,
G_DBUS_SEND_MESSAGE_FLAGS_NONE,
NULL,
&error);
}
Thanks ,
Sudha.S
^ permalink raw reply
* [PATCH BlueZ 1/5] monitor: Add description for filter in scan parameters
From: Łukasz Rymanowski @ 2017-04-12 12:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Łukasz Rymanowski
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
Type: Active (0x01)
Interval: 30.000 msec (0x0030)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Accept all advertisement, inc. directed unresolved RPA (0x02)
---
monitor/packet.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/monitor/packet.c b/monitor/packet.c
index 5d927f5..219542e 100644
--- a/monitor/packet.c
+++ b/monitor/packet.c
@@ -6309,6 +6309,12 @@ static void le_set_scan_parameters_cmd(const void *data, uint8_t size)
case 0x01:
str = "Ignore not in white list";
break;
+ case 0x02:
+ str = "Accept all advertisement, inc. directed unresolved RPA";
+ break;
+ case 0x03:
+ str = "Ignore not in white list, exc. directed unresolved RPA";
+ break;
default:
str = "Reserved";
break;
--
2.9.3
^ permalink raw reply related
* [PATCH BlueZ 2/5] monitor: Add LE Read PHY decoding
From: Łukasz Rymanowski @ 2017-04-12 12:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Łukasz Rymanowski
In-Reply-To: <20170412121336.783-1-lukasz.rymanowski@codecoup.pl>
---
monitor/bt.h | 11 +++++++++++
monitor/packet.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/monitor/bt.h b/monitor/bt.h
index 0b77a10..a6c12a3 100644
--- a/monitor/bt.h
+++ b/monitor/bt.h
@@ -2134,6 +2134,17 @@ struct bt_hci_rsp_le_read_max_data_length {
uint16_t max_rx_time;
} __attribute__ ((packed));
+#define BT_HCI_CMD_LE_READ_PHY 0x2030
+struct bt_hci_cmd_le_read_phy {
+ uint16_t handle;
+} __attribute__((packed));
+struct bt_hci_rsp_le_read_phy {
+ uint8_t status;
+ uint16_t handle;
+ uint8_t tx_phy;
+ uint8_t rx_phy;
+} __attribute__((packed));
+
#define BT_HCI_EVT_INQUIRY_COMPLETE 0x01
struct bt_hci_evt_inquiry_complete {
uint8_t status;
diff --git a/monitor/packet.c b/monitor/packet.c
index 219542e..673b571 100644
--- a/monitor/packet.c
+++ b/monitor/packet.c
@@ -6737,6 +6737,45 @@ static void le_read_max_data_length_rsp(const void *data, uint8_t size)
print_field("Max RX time: %d", le16_to_cpu(rsp->max_rx_time));
}
+static void le_read_phy_cmd(const void *data, uint8_t size)
+{
+ const struct bt_hci_cmd_le_read_phy *cmd = data;
+
+ print_handle(cmd->handle);
+}
+
+static void print_le_phy(const char *prefix, uint8_t phy)
+{
+ const char *str;
+
+ switch (phy) {
+ case 0x01:
+ str = "LE 1M";
+ break;
+ case 0x02:
+ str = "LE 2M";
+ break;
+ case 0x03:
+ str = "LE Coded";
+ break;
+ default:
+ str = "Reserved";
+ break;
+ }
+
+ print_field("%s: %s (0x%2.2x)", prefix, str, phy);
+}
+
+static void le_read_phy_rsp(const void *data, uint8_t size)
+{
+ const struct bt_hci_rsp_le_read_phy *rsp = data;
+
+ print_status(rsp->status);
+ print_handle(rsp->handle);
+ print_le_phy("TX PHY", rsp->tx_phy);
+ print_le_phy("RX PHY", rsp->rx_phy);
+}
+
struct opcode_data {
uint16_t opcode;
int bit;
@@ -7432,7 +7471,9 @@ static const struct opcode_data opcode_table[] = {
{ 0x202f, 283, "LE Read Maximum Data Length",
null_cmd, 0, true,
le_read_max_data_length_rsp, 9, true },
- { 0x2030, 284, "LE Read PHY" },
+ { 0x2030, 284, "LE Read PHY",
+ le_read_phy_cmd, 2, true,
+ le_read_phy_rsp, 5, true},
{ 0x2031, 285, "LE Set Default PHY" },
{ 0x2032, 286, "LE Set PHY" },
{ 0x2033, 287, "LE Enhanced Receiver Test" },
--
2.9.3
^ permalink raw reply related
* [PATCH BlueZ 3/5] monitor: Add LE Set default PHY decoding
From: Łukasz Rymanowski @ 2017-04-12 12:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Łukasz Rymanowski
In-Reply-To: <20170412121336.783-1-lukasz.rymanowski@codecoup.pl>
< HCI Command: LE Set Default PHY (0x08|0x0031) plen 3
All PHYs preference: 0x00
TX PHYs preference: 0x07
LE 1M
LE 2M
LE Coded
RX PHYs preference: 0x0e
LE 2M
LE Coded
Reserved (0x08)
< HCI Command: LE Set Default PHY (0x08|0x0031) plen 3
All PHYs preference: 0x03
No TX PHY preference
No RX PHY preference
TX PHYs preference: 0x00
RX PHYs preference: 0x00
---
monitor/bt.h | 7 ++++++
monitor/packet.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 76 insertions(+), 1 deletion(-)
diff --git a/monitor/bt.h b/monitor/bt.h
index a6c12a3..9dd726e 100644
--- a/monitor/bt.h
+++ b/monitor/bt.h
@@ -2145,6 +2145,13 @@ struct bt_hci_rsp_le_read_phy {
uint8_t rx_phy;
} __attribute__((packed));
+#define BT_HCI_CMD_LE_SET_DEFAULT_PHY 0x2031
+struct bt_hci_cmd_le_set_default_phy {
+ uint8_t all_phys;
+ uint8_t tx_phys;
+ uint8_t rx_phys;
+} __attribute__((packed));
+
#define BT_HCI_EVT_INQUIRY_COMPLETE 0x01
struct bt_hci_evt_inquiry_complete {
uint8_t status;
diff --git a/monitor/packet.c b/monitor/packet.c
index 673b571..f8b42ac 100644
--- a/monitor/packet.c
+++ b/monitor/packet.c
@@ -6776,6 +6776,73 @@ static void le_read_phy_rsp(const void *data, uint8_t size)
print_le_phy("RX PHY", rsp->rx_phy);
}
+static const struct {
+ uint8_t bit;
+ const char *str;
+} le_phys[] = {
+ { 0, "LE 1M" },
+ { 1, "LE 2M" },
+ { 2, "LE Coded"},
+ { }
+};
+
+static const struct {
+ uint8_t bit;
+ const char *str;
+} le_phy_preference[] = {
+ { 0, "No TX PHY preference" },
+ { 1, "No RX PHY preference" },
+ { }
+};
+
+static void le_set_default_phy_cmd(const void *data, uint8_t size)
+{
+ const struct bt_hci_cmd_le_set_default_phy *cmd = data;
+ int i;
+ uint8_t mask = cmd->all_phys;
+
+ print_field("All PHYs preference: 0x%2.2x", cmd->all_phys);
+
+ for (i = 0; le_phy_preference[i].str; i++) {
+ if (cmd->all_phys & (((uint8_t) 1) << le_phy_preference[i].bit)) {
+ print_field(" %s", le_phy_preference[i].str);
+ mask &= ~(((uint64_t) 1) << le_phy_preference[i].bit);
+ }
+ }
+
+ if (mask)
+ print_text(COLOR_UNKNOWN_OPTIONS_BIT, " Reserved"
+ " (0x%2.2x)", mask);
+
+ print_field("TX PHYs preference: 0x%2.2x", cmd->tx_phys);
+ mask = cmd->tx_phys;
+
+ for (i = 0; le_phys[i].str; i++) {
+ if (cmd->tx_phys & (((uint8_t) 1) << le_phys[i].bit)) {
+ print_field(" %s", le_phys[i].str);
+ mask &= ~(((uint64_t) 1) << le_phys[i].bit);
+ }
+ }
+
+ if (mask)
+ print_text(COLOR_UNKNOWN_OPTIONS_BIT, " Reserved"
+ " (0x%2.2x)", mask);
+
+ print_field("RX PHYs preference: 0x%2.2x", cmd->rx_phys);
+ mask = cmd->rx_phys;
+
+ for (i = 0; le_phys[i].str; i++) {
+ if (cmd->rx_phys & (((uint8_t) 1) << le_phys[i].bit)) {
+ print_field(" %s", le_phys[i].str);
+ mask &= ~(((uint64_t) 1) << le_phys[i].bit);
+ }
+ }
+
+ if (mask)
+ print_text(COLOR_UNKNOWN_OPTIONS_BIT, " Reserved"
+ " (0x%2.2x)", mask);
+}
+
struct opcode_data {
uint16_t opcode;
int bit;
@@ -7474,7 +7541,8 @@ static const struct opcode_data opcode_table[] = {
{ 0x2030, 284, "LE Read PHY",
le_read_phy_cmd, 2, true,
le_read_phy_rsp, 5, true},
- { 0x2031, 285, "LE Set Default PHY" },
+ { 0x2031, 285, "LE Set Default PHY",
+ le_set_default_phy_cmd, 3, true},
{ 0x2032, 286, "LE Set PHY" },
{ 0x2033, 287, "LE Enhanced Receiver Test" },
{ 0x2034, 288, "LE Enhanced Transmitter Test" },
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox