Hi Jakub, On Thu, Dec 11, 2014, Jakub Pawlowski wrote: > This patch introduces new lock, that need to be acquired if you want > to use HCI_OP_SCAN_ENABLE in a series of request. Next patch introduces > le restarting that would have race condition without that. This is not really the way that locks are typically used and will likely result in bugs in the long run. Each lock should have a well defined piece of data that it protects and the lock/unlock pair should cover a clear and contiguous section of code. Neither one of these principles seems to fulfilled by your design. As an example, your code would be stuck with the lock if you powered off the adapter while holding it (since the HCI request callbacks would not get called). So you'll need to find a different kind of solution here. It seems to me like you're looking for some sort of state tracking, which is something locking shouldn't be mixed with. Johan. -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
