2016-07-22 11:38 GMT+02:00 Jon Hunter <jonathanh@xxxxxxxxxx>: >>> The driver should have a remove function given that we can build as a >>> module. >> >> At the moment I do not know what we would do in a remove function and >> hence me not adding one. > > Should just be the inverse of the probe (although there is no inverse > for the parsing DT bit). If you don't wish to add a remove, that is > fine, but make the driver a 'bool' and not 'tristate' in the Kconfig so > it cannot be configured as a module. I understand the concept of a remove function, but I use devm_ calls for all resources. These should be handled by the device core on a driver detach? One thing came to mind now that could be done in a remove method and that is clearing the CONFIG_GO bit, or I could just do that first on probe instead to make sure the controller is stopped. Ok, one more thing came to mind, and that is depopulating the child devices. Got it remove function it is then. >>>> +module_platform_driver_probe(nor_driver, nor_probe); >>> >>> I would use "tegra_nor" namespace for all the structs, functions, etc. >>> However, we may prefer to go with GMI and in which case tegra_gmi_probe, >>> etc. >> >> ACK. Who gets the last call on what we should call the driver? It >> seems that we both think GMI is a better name, do we need a third? :). > > The patches would have to go via Thierry and so ultimately, Thierry. > However, I can't imagine he would object to GMI ;-) Eagerly awaiting Thierry`s comments :). Best Regards, Mirza -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
