>> So I think its not a good place to insert this call. >> Its hard to find exact good place to insert it in qed. > > Is there a way to check if what happened was indeed a fw crash?
Our driver has two firmwares (slowpath and fastpath). For slowpath firmware the way to understand it crashed is to observe command response timeout. This is in qed_mcp.c, around "The MFW failed to respond to command" traceout. For fastpath this is tricky, think you may leave the above place as the only place to invoke module_firmware_crashed() > >> One more thing is that AFAIU taint flag gets permanent on kernel, but > for >> example our device can recover itself from some FW crashes, thus it'd be >> transparent for user. > > Similar things are *supposed* to recoverable with other device, however > this can also sometimes lead to a situation where devices are not usable > anymore, and require a full driver unload / load. > >> Whats the logical purpose of module_firmware_crashed? Does it mean fatal >> unrecoverable error on device? > > Its just to annotate on the module and kernel that this has happened. > > I take it you may agree that, firmware crashing *often* is not good > design, > and these issues should be reported to / fixed by vendors. In cases > where driver bugs are reported it is good to see if a firmware crash has > happened before, so that during analysis this is ruled out. Probably, but still I see some misalignment here, in sense that taint is about the kernel state, not about a hardware state indication. devlink health could really be a much better candidate for such things. Regards Igor
