This patch implements a new state machine for struct btd_adapter.
The adapter_set_state() function was completely rewritten since its
logic does not apply anymore. The whole logic of interleaved discovery
procedure before implemented in adapter_set_state() should be
implemented at hciops and mgmtops layers.
At the adapter layer, it is not important to track what is the current
state (inquiring or scanning) during the discovery session. All the
adapter layer cares about is if it is performing the discovery or not.
Therefore, the adapter states STATE_STDINQ, STATE_PINQ and
STATE_LE_SCAN were replaced by a new state called STATE_DISCOV.
Additionally, because there is no point in implementing states
as a bitmask, all adapter states were implemented using integers
instead of a bitmask.
This patch adds a timeout parameter to start_scanning callback in
btd_adapter. The parameter should be used to stop scanning after
'timeout' milliseconds.
Periodic Inquiry is no longer supported in hciops since the discovery
procedure will use Standard Inquiry only.
External tools which request Periodic Inquiry will not change the
adapter's state.
We need to track the current discovering state (HALTED, INQUIRY or SCAN)
of the adapter in hciops layer during the discovery procedure. This will
help us to properly update the state of btd_adapter and emit the property
"Discovering" correctly.
This patch adds start_discovery and stop_discovery callbacks to
struct btd_adapter_ops. These callbacks are responsible for starting
and stoping the discovery procedure. It also creates dummy functions
in hciops and mgmtops which implements those callbacks.
Instead of having static handles, use attrib_db_find_avail() to find
available handle ranges.
Also split the big register_attributes() into one function per service.
This patch changes type of the "pending" variable to uint32_t. A pointer
to this variable is passed to the hci_clear_bit function as void * and
then cast to uint32_t * again.
Previously the unsigned long type could cause some unexpected behavior
due to violating strict aliasing rules. This patch fixes this problem by
making sure that the same integer type is used in all places.
This solution is simpler than the other option of changing the types of
all other places (from uint32_t to unsigned long, including changing
type for casting in hci_*_bit function family). Also, not all places can
be changed, like the hci_dev_info struct, since it would violate
compatibility rules between the kernel and user space.
With some kernels and the right timing it is possible to get into the
state where we get the local name but haven't yet gotten a DEVUP event.
In such a case it is *not* ok to call init_adapter.
This patch adds a new set_local_name command as well as a
local_name_changed event to the management interface. Instead of 248
bytes (like in the HCI spec) 249 bytes are always reserved for the name
in the messages so that there's a guarantee of it being nul-terminated
(this is not guaranteed on the HCI level).
The maemo6 MCE plugin should be used with the flag InitiallyPowered
in main.conf set to 'true' so that BlueZ powers on the adapter
and leaves it in that state when the daemon is started. The plugin
will read the radio state from the MCE and set the state
accordingly. The maemo6 plugin is a btd_adapter_driver and those
drivers are loaded after BlueZ has read the BD address etc from the
adapter.
This patch adds a boolean flag in the callback to ignore the initial
powering on of the adapter by BlueZ, since it shouldn't be
propagated to the MCE. With InitiallyPowered set to 'false' the
adapter_powered callback is not called when the adapter is turned
on at BlueZ startup, which is why this wasn't implemented before.
In the current implementation of le_advertising_report(), the variable
'info' has an invalid memory address after the 'for' loop. If 'info'
is dereferenced it will access invalid memory.
This patch fixes this potential bug and improves the code's readability.
In some (rare) circumstances it is possible for the mgmt_pair_device
command to complete without there being any other indication of
completion of the procedure. Therefore, the bonding_complete event needs
to be notified to the core daemon also in this situation.
There's no need to expose the auto-accept case to the core daemon so
move it to hciops. For the management interface this will all be handled
on the kernel side.
There is no need for HCIDEVUP/fork in such cases it will just consume
more resources for no reason.
To fix this HCI_DEV_REG is no longer generate for adapter already up
instead init_device is called directly which simplify the code path.
The kernel seems to have some state tracking issues if we close the
bonding socket before it gets into connected state. This needs to be
investigated on the kernel side but a simple fix is to let the socket be
closed in its BtIO callback instead of through some HCI event (for the
successful case).
