The function did two things: set device_info_valid to -1 and called
device_free() for each device in the hashmap. Setting
device_info_valid to -1 was unnecessary. The main purpose of that was
to fire DEVICE_CONNECTION_CHANGED as a side effect, but that hook is
fired anyway in device_free(), as a
On 2 October 2013 15:28, Tanu Kaskinen tanu.kaski...@linux.intel.com wrote:
On Tue, 2013-10-01 at 10:43 -0300, João Paulo Rechi Vita wrote:
Ack. Same question about testing applies here, and I should have made
it more generic, actually: Do you have audio devices to be able to
test these
On Wed, Oct 2, 2013 at 11:28 AM, Tanu Kaskinen
tanu.kaski...@linux.intel.com wrote:
On Tue, 2013-10-01 at 10:43 -0300, João Paulo Rechi Vita wrote:
Ack. Same question about testing applies here, and I should have made
it more generic, actually: Do you have audio devices to be able to
test
On Tue, 2013-10-01 at 10:43 -0300, João Paulo Rechi Vita wrote:
Ack. Same question about testing applies here, and I should have made
it more generic, actually: Do you have audio devices to be able to
test these changes?
Devices aren't a problem (I have two A2DP/HFP headsets and one HFP-only
On Sun, Sep 29, 2013 at 12:49 PM, Tanu Kaskinen
tanu.kaski...@linux.intel.com wrote:
The function did two things: set device_info_valid to -1 and called
device_free() for each device in the hashmap. Setting
device_info_valid to -1 was unnecessary. The main purpose of that was
to fire
The function did two things: set device_info_valid to -1 and called
device_free() for each device in the hashmap. Setting
device_info_valid to -1 was unnecessary. The main purpose of that was
to fire DEVICE_CONNECTION_CHANGED as a side effect, but that hook is
fired anyway in device_free(), as a
