asmc: resource cleanup simplifications

[ngie]

Summary

This change makes asmc_detach(..) reentrant by setting freed resources
to known invalid values when done, and makes asmc_attach(..) call
asmc_detach(..) instead of attempting to the semi-equivalent way of
cleaning up the driver resources allocated in asmc_detach(..).

Test Plan

I've been using this particular diff for some time now on a variety of Macs without issue, but all paths that have been tested are happy paths.

I should verify the pathological scenarios function as needed as well.

[guest-seuros]

This works and has been stable in my testing for several weeks.

One issue remains: the sysctl context is not freed on teardown. The proper fix is the approach I implemented in:
https://github.com/freebsd/freebsd-src/commit/63eff205754c87d3f8e092c5f3a57a1ff2e3e2a2
(Note: I rebase often, so the SHA may change.)

I still reproduce a panic when unloading ASMC with an active Thunderbolt connection, so I havent updated D54615 yet. I need to trace the root cause.

That said, this can land as-is, the panic is reproducible with current code as well.

[ngie]

In D55413#1267515, @guest-seuros wrote:

...

One issue remains: the sysctl context is not freed on teardown. The proper fix is the approach I implemented in:
https://github.com/freebsd/freebsd-src/commit/63eff205754c87d3f8e092c5f3a57a1ff2e3e2a2
(Note: I rebase often, so the SHA may change.)

If I'm reading the code correctly, this should happen automatically as part of device_detach: https://cgit.freebsd.org/src/tree/sys/kern/subr_bus.c#n2728 .

I still reproduce a panic when unloading ASMC with an active Thunderbolt connection, so I havent updated D54615 yet. I need to trace the root cause.

Is the problem in the USB code or the asmc(4) code?