Johan Hedberg [Mon, 14 Oct 2013 13:20:05 +0000 (16:20 +0300)]
Bluetooth: Add missing error handling for Set Connectable
If the HCI commands related to the Set Connectable command fail we will
get a non-zero status in the request completion callback. In such a case
we must respond with the appropriate command status message to user space.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Mon, 14 Oct 2013 13:20:04 +0000 (16:20 +0300)]
Bluetooth: Move more logic into set_connectable complete callback
This patch moves the responsibility of setting/clearing the
HCI_CONNECTABLE flag to the request completion callback of the Set
Connectable command. This will allow us to cleanly add support for LE
Advertising hooks in later patches.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch moves all the decisions of which HCI commands to send (or not
to send) to the code between hci_req_init() and hci_req_run() this
allows us to further extend the request with further commands but still
keep the same logic of handling whether to return a direct mgmt response
in the case that no HCI commands were sent.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Marcel Holtmann [Mon, 14 Oct 2013 09:53:54 +0000 (02:53 -0700)]
Bluetooth: Introduce L2CAP channel callback for resuming
Clearing the BT_SK_SUSPEND socket flag from the L2CAP core is causing
a dependency on the socket. So intead of doing that, use a channel
callback into the socket handling to resume.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Mon, 14 Oct 2013 09:45:34 +0000 (02:45 -0700)]
Bluetooth: Introduce L2CAP channel flag for defer setup
The L2CAP core should not look into the socket flags to figure out the
setting of defer setup. So introduce a L2CAP channel flag that mirrors
the socket flag.
Since the defer setup option is only set in one place this becomes a
really easy thing to do.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 13 Oct 2013 19:55:29 +0000 (12:55 -0700)]
Bluetooth: Provide msg_name callback for L2CAP connectionless channels
The L2CAP connectionless channels use SOCK_DGRAM and recvmsg() and need
to receive the remote BD_ADDR and PSM information via msg_name from
the recvmsg() system call.
So in case the L2CAP socket is for connectionless channels, provide
a msg_name callback that can update the data. Also store the remote
BD_ADDR and PSM in the skb so it can be extracted later on.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 13 Oct 2013 17:34:02 +0000 (10:34 -0700)]
Bluetooth: Store RFCOMM address information in its own socket structure
The address information of RFCOMM sockets should be stored in its
own socket structure. Trying to generalize them is not helpful since
different transports have different address types.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 13 Oct 2013 17:34:01 +0000 (10:34 -0700)]
Bluetooth: Store SCO address information in its own socket structure
The address information of SCO sockets should be stored in its own
socket structure. Trying to generalize them is not helpful since
different transports have different address types.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 13 Oct 2013 17:15:22 +0000 (10:15 -0700)]
Bluetooth: Use SCO addresses from HCI connection directly
Instead of storing a pointer to the addresses for the HCI device
and HCI connection, use them directly. With the recent changes
to address tracking of HCI connections, this becomes simple.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 13 Oct 2013 15:50:41 +0000 (08:50 -0700)]
Bluetooth: Return the correct address type for L2CAP sockets
The L2CAP sockets can use BR/EDR public, LE public and LE random
addresses for various combinations of source and destination
devices. So make sure that getsockname(), getpeername() and
accept() return the correct address type.
For this the address type of the source and destination is stored
with the L2CAP channel information. The stored address type is
not the one specific for the HCI protocol. It is the address
type used for the L2CAP sockets and the management interface.
The underlying HCI connections store the HCI address type. If
needed, it gets converted to the socket address type.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 13 Oct 2013 15:12:47 +0000 (08:12 -0700)]
Bluetooth: Store address information in L2CAP channel structure
With the effort of abstracting the L2CAP socket from the underlying
L2CAP channel it is important to store the source and destination
address information directly in the L2CAP channel structure.
Direct access to the HCI connection address information is not
possible since they might not be avaiable at L2CAP channel
creation time. The address information will be updated when
the underlying BR/EDR or LE connection status changes.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 13 Oct 2013 12:56:37 +0000 (05:56 -0700)]
Bluetooth: Update L2CAP socket source address from HCI connection
When having LE connections, the source address is not always the
public address of the controller. So update the socket address
based on the actual used source address of the HCI connection.
This also remove the pointless source address pointer and adds
a proper lock around the socket structure.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 13 Oct 2013 12:24:02 +0000 (05:24 -0700)]
Bluetooth: Fix input address type for SMP C1 function
The smp_c1() so far always assumed public addresses as input for its
operation. However it should provide actually the source address type
of the actual connection.
Finally the source address type is tracked in hci_conn->src_type and
so use that one as input.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 13 Oct 2013 14:25:18 +0000 (07:25 -0700)]
Bluetooth: Update source address and type for incoming LE connections
The incoming LE connections do not have a proper source address and
address type set. The connection needs to be set with the same values
as used for advertising parameters.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 13 Oct 2013 12:23:59 +0000 (05:23 -0700)]
Bluetooth: Store source address of HCI connections
The source addressed was based on the public address of the HCI device,
but with LE connections this not always the case. For example single
mode LE-only controllers would use a static random address. And this
address is configured by userspace.
To not complicate the lookup of what kind of address is in use, store
the correct source address for each HCI connection.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 13 Oct 2013 10:57:39 +0000 (03:57 -0700)]
Bluetooth: Store the source address type of LE connections
When establishing LE connections, it is possible to use a public
address (if available) or a random address. The type of address
is only known when creating connections, so make sure it is
stored in hci_conn structure.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 13 Oct 2013 10:57:38 +0000 (03:57 -0700)]
Bluetooth: Remove pointless bdaddr_to_le() helper function
The bdaddr_to_le() function tries to convert the internal address
type to one that matches the HCI address type for LE. It does not
handle any address types not used by LE and in the end just make
the code a lot harder to read.
So instead of just hiding behind a magic function, just convert
the internal address type where it needs to be converted. And it
turns out that these are only two cases anyway. One when creating
new LE connections and the other when loading the long term keys.
In both cases this makes it more clear on what it going on.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 13 Oct 2013 09:23:40 +0000 (02:23 -0700)]
Bluetooth: Remove l2cap_conn->src and l2cap_conn->dst usage from L2CAP
The l2cap_conn->src and l2cap_conn->dst addresses are just a pointers
to hci_conn structure. Use hci_conn->hdev->bdaddr and hci_conn->dst
directly instead.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 13 Oct 2013 09:23:39 +0000 (02:23 -0700)]
Bluetooth: Remove l2cap_conn->src and l2cap_conn->dst usage from SMP
The l2cap_conn->src and l2cap_conn->dst addresses are just a pointer
to hci_conn->hdev->bdaddr and hci_conn->dst structures. Use the data
provided by hci_conn directly. This is done for hci_conn->dst_type
already anyway and with this change it makes it a lot clearer were
the address information comes from.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sat, 12 Oct 2013 15:18:19 +0000 (08:18 -0700)]
Bluetooth: Unicast connectionless data reception is supported
The unicast connectionless data reception feature is actually support
and has been supported all along. Mark it as supported in the L2CAP
features bitmask.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The exception for certain PSM channels when it comes to security
mode 4 level 0 should only be checked when actually a connection
oriented channel is established.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Fri, 11 Oct 2013 23:42:07 +0000 (16:42 -0700)]
Bluetooth: Fix HCI init for 1st generation BlueFRITZ! devices
The 1st generation of BlueFRITZ! devices from AVM Berlin pretend
to be HCI version 1.2 controllers, but they are not. They are simple
Bluetooth 1.1 devices.
Since this company never created any newer controllers, it is safe
to use the manufacturer ID instead of an USB quirk.
Marcel Holtmann [Fri, 11 Oct 2013 21:44:58 +0000 (14:44 -0700)]
Bluetooth: Add MGMT_OP_SET_SCAN_PARAMS to supported commands list
When adding support for MGMT_OP_SET_SCAN_PARAMS command the addition
to the supported commands list has been forgotten. This is needed
for userspace to detect if the command is supported or not.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Fri, 11 Oct 2013 16:48:47 +0000 (09:48 -0700)]
Bluetooth: Don't advertise high speed support without SSP
It is not allowed to enable high speed support when Secure Simple
Pairing is not available or disabled.
However the support for high speed gets advertised on a controller
that does not even support Secure Simple Pairing. Since there is
no way to enable high speed support on such a controller, do not
even advertise its support.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Fri, 11 Oct 2013 16:44:12 +0000 (09:44 -0700)]
Bluetooth: Fix endless loop with HCI_QUIRK_RESET_ON_CLOSE
Really early versions of the Bluetooth specification were unclear
with the behavior of HCI Reset for USB devices. They assumed that
also an USB reset needs to be issued. Later Bluetooth specifications
cleared this out and it is safe to call HCI Reset without affecting
the transport.
For old devices that misbehave, the HCI_QUIRK_RESET_ON_CLOSE quirk
was introduced to postpone the HCI Reset until the device was no
longer in use.
One of these devices is the Digianswer BPA-105 Bluetooth Protocol
Analyzer. The only problem now is that with the quirk set, the
HCI Reset is also executed at the end of the setup phase. So the
controller gets configured and then it disconnects from the USB
bus, connects again, gets configured and of course disconnects
again. This game goes on forever.
For devices that need HCI_QUIRK_RESET_ON_CLOSE it is important
that the HCI Reset is not executed after the setup phase. In
specific when HCI_AUTO_OFF is set, do not call HCI Reset when
closing the device.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Fri, 11 Oct 2013 15:23:20 +0000 (08:23 -0700)]
Bluetooth: Add management command for setting LE scan parameters
The scan interval and window parameters are used for LE passive
background scanning and connection establishment. This allows
userspace to change the values.
These two values should be kept in sync with whatever is used for
the scan parameters service on remote devices. And it puts the
controlling daemon (for example bluetoothd) in charge of setting
the values.
Main use case would be to switch between two sets of values. One
for foreground applications and one for background applications.
At this moment, the values are only used for manual connection
establishment, but soon that should be extended to background
scanning and automatic connection establishment.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Fri, 11 Oct 2013 15:23:19 +0000 (08:23 -0700)]
Bluetooth: Make LE scan interval and window a controller option
The scan interval and window for LE passive scanning and connection
establishment should be configurable on a per controller basis. So
introduce a setting that later on will allow modifying it.
This setting does not affect LE active scanning during device
discovery phase. As long as that phase uses interleaved discovery,
it will continuously scan.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Fri, 11 Oct 2013 13:19:18 +0000 (06:19 -0700)]
Bluetooth: Add hdev parameter to hdev->send driver callback
Instead of masking hdev inside the skb->dev parameter, hand it
directly to the driver as a parameter to hdev->send. This makes
the driver interface more clear and simpler.
This patch fixes all drivers to accept and handle the new parameter
of hdev->send callback. Special care has been taken for bpa10x
and btusb drivers that require having skb->dev set to hdev for
the URB transmit complete handlers.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Thu, 10 Oct 2013 21:54:19 +0000 (14:54 -0700)]
Bluetooth: Remove return value from hci_send_frame() function
The return value of hci_send_frame() is never checked. So just make
this function void and print an error when the hdev->send driver
callback returns a negative value.
Having the error printed is actually an improvement over the
current situation where any driver error just gets ignored.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Thu, 10 Oct 2013 21:54:18 +0000 (14:54 -0700)]
Bluetooth: Remove pointless check of hci_send_frame parameter
The hdev parameter of hci_send_frame must be always valid. If the hdev
is not valid, it would not even make it to this stage. The callers
will have already accessed hdev at that point many times.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Thu, 10 Oct 2013 21:54:17 +0000 (14:54 -0700)]
Bluetooth: Move skb->dev assignment for hdev->send into central place
The assignement of skb->dev is done all over the place. So it makes it
hard to eventually get rid of it. Move it all in one central place so
it gets assigned right before calling hdev->send driver callback.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Thu, 10 Oct 2013 17:02:08 +0000 (10:02 -0700)]
Bluetooth: AMP contollers do not support the legacy ioctls
The legacy ioctls for device specific commands including inquiry are
not support by AMP controllers. So just reject them right away instead
of trying to send the HCI command and wait for failure from the
actual hardware.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Thu, 10 Oct 2013 16:47:55 +0000 (09:47 -0700)]
Bluetooth: Use hci_conn_num() instead of direct connection hash access
When changing the alternate setting for the ISOC endpoints, use the
hci_conn_num() helper function to count currently established SCO
and eSCO connections and store the the value. This avoids direct
access to the connection hash.
In addition use the stored value instead accessing the connection
hash over and over again.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Thu, 10 Oct 2013 16:47:54 +0000 (09:47 -0700)]
Bluetooth: Use hci_conn_num() for checking number of LE connections
When checking for the current number of LE connections, use
hci_conn_num() function instead of a full blown lookup within
the connection hash or direct access of the counters.
In the case of re-enabling advertising, it is more useful to
check for any connection attempt or existing connection.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Johan Hedberg [Thu, 10 Oct 2013 16:06:04 +0000 (18:06 +0200)]
Bluetooth: Fix checking for HCI_SETUP flag when receiving mgmt commands
When the HCI_SETUP flag is set the controller has not yet been announced
over mgmt and therefore doesn't exist from that perspective. If we
nevertheless get a mgmt command for it we should respond with the
appropriate INVALID_INDEX error.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Thu, 10 Oct 2013 11:33:37 +0000 (13:33 +0200)]
Bluetooth: Fix potential double-frees of L2CAP skbs
The l2cap_recv_frame function is expected to take ownership and
eventually free the skb passed to it. We need to ensure that the
conn->rx_skb pointer is no longer reachable when calling
l2cap_recv_frame so that no other function, such as l2cap_conn_del, may
think that it can free conn->rx_skb.
An actual situation when this can happen is when smp_sig_channel (called
from l2cap_recv_frame) fails and l2cap_conn_del gets called as a
consequence. The l2cap_conn_del function would then try to free
conn->rx_skb, but as the same skb was just passed to smp_sig_channel and
freed we get a double-free.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Marcel Holtmann [Thu, 10 Oct 2013 10:08:11 +0000 (03:08 -0700)]
Bluetooth: Restrict high speed support to SSP enabled controllers
The support for Bluetooth High Speed can only be enabled on controllers
where also Secure Simple Pairing has been enabled. Trying to enable
high speed when SSP is disabled will result into an error. Disabling
SSP will at the same time disable high speed as well.
It is required to enforce this dependency on SSP since high speed
support is only defined for authenticated, unauthenticated and
debug link keys. These link key types require SSP.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Thu, 10 Oct 2013 10:08:10 +0000 (03:08 -0700)]
Bluetooth: Remove unneeded val variable when setting SSP
The variable val in the set_ssp() function of the management interface
is not needed. Just use cp->val directly since its input values have
already been validated.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Andre Guedes [Tue, 8 Oct 2013 11:21:18 +0000 (08:21 -0300)]
Bluetooth: Refactor hci_connect_le
This patch does some code refactoring in hci_connect_le() by moving
the exception code into if statements and letting the main flow in
first level of function scope. It also adds extra comments to improve
the code readability.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Andre Guedes [Tue, 8 Oct 2013 11:21:17 +0000 (08:21 -0300)]
Bluetooth: Use HCI request for LE connection
This patch introduces a new helper, which uses the HCI request
framework, for creating LE connectons. All the handling is now
done by this function so we can remove the hci_cs_le_create_conn()
event handler.
This patch also removes the old hci_le_create_connection() since
it is not used anymore.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Tue, 8 Oct 2013 13:52:18 +0000 (15:52 +0200)]
Bluetooth: Fix changing advertising setting while LE is connected
We only (re)enable advertising when LE is disconnected. Trying to enable
advertising using mgmt_set_advertising while connected should simply
change the flag but not do anything else (until the connection gets
dropped). This patch fixes this by making an LE connection lookup to
determine whether there are any connected devices or not.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Marcel Holtmann [Mon, 7 Oct 2013 09:31:39 +0000 (02:31 -0700)]
Bluetooth: Read supported features and commands on AMP controllers
The commands for reading supported features and commands are both
supported by AMP controllers. Issue them during controller init
phase so their values are known.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Mon, 7 Oct 2013 07:58:33 +0000 (00:58 -0700)]
Bluetooth: Make mgmt power down notification for BR/EDR explicit
The management interface only operates on BR/EDR controllers. The check
for the power down notification is a bit intermixed with the check if
controller auto power off is active. Since there are more than just
BR/EDR controllers supported, make this check explicit since the auto
power off check also applies to AMP controllers and it has to happen
in this exact order. Otherwise the bit will not be cleared.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Mon, 7 Oct 2013 07:58:32 +0000 (00:58 -0700)]
Bluetooth: Power off AMP controllers after setup phase
Even AMP controllers should be powered off after the setup phase. It
is not a good idea to keep AMP controllers powered on all the time
if they are not in use.
Power on of the AMP controller can either be done manually via
command line commands or directly via A2MP. Especially since there
is an indication in A2MP for powered down controllers that can
be activated.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Mon, 7 Oct 2013 06:55:45 +0000 (23:55 -0700)]
Bluetooth: Make mgmt_index_added() and mgmt_index_removed() return void
The return value from mgmt_index_added() and mgmt_index_removed()
functions is never used. So do not pretend that returning an error
would actually be handled and just make both functions return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 6 Oct 2013 23:11:57 +0000 (16:11 -0700)]
Bluetooth: Send new settings only when pairable changes
In case the current value of pairable is already configured, do not
send a new settings event indicating that something has changed while
in reality everything is the same.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
projects / linux-beck.git / log