Hi Tomas, > > > A Bluetooth device experiencing hardware failure may issue > > > a HARDWARE_ERROR hci event. The reaction to this event is device > > > reset flow implemented in following sequence. > > > > > > 1. Notify: HCI_DEV_DOWN > > > 2. Reinitialize internal structures. > > > 3. Call driver flush function > > > 4. Send HCI reset request to the device. > > > 5. Send HCI init sequence reset to the device. > > > 6. Notify HCI_DEV_UP. > > > > I prefer if we create a generic per controller workqueue first before > > having a workqueue for every task. Something similar to what the > > mac80211 layer offers right now. > > That would be good approach but we are using default kernel workqueue in this solution so there is no workqueue for every task. > I'm not sure if this effort should block this patch. I have an initial patch that I have to dig out. It is actually not that complicated. And I would prefer to get that one first before we apply this patch. The reason why I really wanna solve this is because of potential race conditions between the workqueue and a device removal. I have a bad feeling that even with the current sysfs workqueue we have a race condition hiding somewhere. So if going forward we have to shift more and more code into workqueues we need a single point where this can be fixed. > > Also in a second step we might wanna move the HCI event processing > > completely into a workqueue. If we get no performance hit with that, > > then sysfs handling and device reset becomes a lot simpler and less > > prone to race conditions with device removal. > > Looks good to me. So when this is ready we can move also the reset also to per controller queue. I haven't done any performance testing with this approach. So I hope we are not shooting ourselves in the foot with it. Regards Marcel -- 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
