Hi Alan, I have another point that I would like to discuss. It is about the usage of 'fpga_mgr_free()' which does not look like consistent. This function, according to the current implementation, can be used by an FPGA manager user and it is used by the FPGA manager itself on device release. This means that the user can only use this function if fpga_mgr_register() fails (to clean up), otherwise the user must NOT use this function, otherwise we most likely get an oops (NULL or invalid pointer). The example here is correct, this is what we should do: https://www.kernel.org/doc/html/latest/driver-api/fpga/fpga-mgr.html But I suggest to document it better or prevent this type of mistakes from happening. Following a couple of proposals ------ 1. Document it better. This is easy, in the fpga_mgr_free() kernel-doc comment we explain that the use of this function must be limited to clean up the memory on a registration failure. If an FPGA manager has been successfully registered then it will be freed by the framework itself. But still, this does not prevent an oops from happening. ------ 2. Remove the fpga_mgr_free() from fpga_mgr_dev_release() and ask the user to free the manager when necessary. This makes the usage consistent: the user creates and destroy its own objects. This is also consistent with our other discussion where we said, among the other things, that the module that uses the FPGA manager can the owner of the fpga_manager data structure. ------ 3. Not sure how, but perhaps we can be able to understand if we can safely continue to run fpga_mgr_free() or we should stop. ------ -- To unsubscribe from this list: send the line "unsubscribe linux-fpga" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html