RE: [bluetooth-next V2] Bluetooth: handle device reset event

[Marcel Holtmann <marcel@holtmann.org>]

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