On Tue, Jul 19, 2022 at 05:01:48PM +0200, Patrick Wildt wrote: > No, it's not inverted. If bwfm_pci_send_mb_data() fails we want to > re-init the device, that's what both Linux and OpenBSD are doing.
Right. I came to the same conclusion while taking a brief look. > Better questions are: why is bwfm_pci_send_mb_data() failing? Why is > there a pending mb command? Well, it looks like bwfm_pci_send_mb_data() does in fact succeed. The incorrect patch effectively treats success as failure, and thus demonstrates that our current code does not detect an error there. The failure is elsewhere: bwfm_fwvar_set_int() in bwfm_init() is failing. Probably because the device isn't resumed yet even though it should be. > And: why doesn't cleanup and reactivate work? As I understand the bug report, by treating bwfm_pci_send_mb_data() success as a failure case, we end up running bwfm_cleanup() and bwfm_pci_cleanup(), and now the device resumes just fine. So the Linux code we've ported does somehow manage to resume the device from a weird state. But we fail to do that. I don't know why, but is that not the real question we need to ask? Could we always do a full device reset as a workaround? Perhaps that is what we should be doing anyway? Maybe the Linux way of resuming this device is somehow incompatible with the way our system works?
