On Wed, Jul 11, 2018 at 7:38 AM, Federico Vaga <federico.vaga@xxxxxxx> wrote: Hi Federico, > 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. You're not the first to complain about this. I think I'll err on the side of consistency and implement your option 2 here. Alan -- 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
