If this is going to be in t4_sge.c (vs. t4_hw.c) then it can follow FreeBSD style like the rest of the file. So no -ve errnos, return (foo) instead of return foo, etc.

Is it ok to try to carry on after a WRERR? I think we should panic the system at least for fatal errors, if not for all errors.

What about printf(9) vs. log(9) given that the CPL handlers are running in an ithread?

In D6950#145783, @np wrote:

If this is going to be in t4_sge.c (vs. t4_hw.c) then it can follow FreeBSD style like the rest of the file. So no -ve errnos, return (foo) instead of return foo, etc.

One of my questions actually was if this should go in t4_hw.c (that is, do you think the Linux driver would take this upstream as well?)

Is it ok to try to carry on after a WRERR? I think we should panic the system at least for fatal errors, if not for all errors.

In the case of the errors I saw with the VF driver the EQ just died (which did break trying to kldunload as quiescing hung forever), but the system was otherwise fine. Those were non-fatal though. We could panic for fatal ones I guess and maybe mark the EQ as "dead" for non-fatal errors.

What about printf(9) vs. log(9) given that the CPL handlers are running in an ithread?

printf is certainly fine in an ithread. Would you prefer log(9)?