The only real difference I can see is that this change causes child devices to be detached in reverse order. Does the order matter for some reason?

In D50378#1150042, @markj wrote:

The only real difference I can see is that this change causes child devices to be detached in reverse order. Does the order matter for some reason?

Correct me if I'm wrong, but unlike bus_generic_detach() which just calls device_detach(), device_delete_children() seems to be calling device_delete_child(), which in turns calls device_detach(), and then does additional cleanup. In any case, this change does fix the bug. That's also how the rest of the HDA layers (hdacc, hdaa) cleanup.

In D50378#1150084, @christos wrote:

In D50378#1150042, @markj wrote:

The only real difference I can see is that this change causes child devices to be detached in reverse order. Does the order matter for some reason?

Correct me if I'm wrong, but unlike bus_generic_detach() which just calls device_detach(), device_delete_children() seems to be calling device_delete_child(), which in turns calls device_detach(), and then does additional cleanup. In any case, this change does fix the bug.

bus_generic_detach() calls device_detach() on each child, then calls device_delete_children(). With this patch we're just calling device_delete_children().

I believe you that the change fixes a problem, but it's not clear to me at least why it fixes it, so it's hard to say that the change is right. Maybe someone more familiar with newbus can chime in. Failing that, it'd be helpful to know what exactly is failing during detach such that the driver isn't cleaning up properly. Is one of hdacc_detach() or hdaa_detach() returning an error?

That's also how the rest of the HDA layers (hdacc, hdaa) cleanup.

I don't quite follow: hdacc_detach() and hdaa_detach() both call bus_generic_detach().