On Mon, Sep 16, 2019 at 10:45:13AM +0200, Hans de Goede wrote: > > thinking more about this, since both modules will have the same > acpi_device_id table they will both get auto-loaded anyways. > > So how about the following: > > 1) We put a single struct platform_driver in the common bits > 2) We create a new shared struct cht_int33fe_data in intel_cht_int33fe_common.h > which has all the data members needed by both variants, e.g. just put the > intel_cht_int33fe_typec.c struct cht_int33fe_data definition in the common > header and rename max17047 to the more generic battery_fg used by the musb code. > And add an enum int33fe_hw_type hw_type field to this struct > 3) Have the typec and musb .c files export their probe + remove function > (make them non-static add prototypes to common.h) > 4) Add a new probe to the common.c file which does the usual checks and > figures out hw_type. It then devm_kzalloc-s the struct, sets hw_type in the > struct and calls the right actual probe function depending on the board. > 5) Add a new remove function to the common.c file which calls the right remove > function based on the hw_type in the data struct. > > And we build all 3 .c files into a single module (since if we have multiple > modules they will all get loaded anyways). I think this is the cleanest / best > approach and it also answers the question of what to name the Kconfig options, > since if we do as I suggest above we just stick with the single Kconfig option > we already have. Yes, maybe this is best approach. I sent v2 patch changed accordingly your proposal. -- Yauhen Kharuzhy
