Hi Jarkko, Am Samstag, 7. September 2019, 19:04:15 CEST schrieb Jarkko Sakkinen: > On Tue, 2019-09-03 at 09:52 -0700, Stephen Boyd wrote: > > That's fair. I'll put the Kconfig option back. There's still the small > > issue of what to do about the module name. Should I rename the > > tpm_tis_spi.c file to something else so that the module can keep the > > same name? Or was the tpm_tis_spi_mod.ko trick from v5 good enough? > > Not sure I understood the question correctly but how I think > this should be deployed is: > > - A boolean CONFIG_TCG_TIS_SPI_CR50. > - tpm_tis_spi_cr50.c that gets compiled in as part of tpm_tis_spi > when the config option is selected. > > I think this would best follow the conventions that are in place > already. Please tell if I got something wrong or if there is some > bottleneck in this framework but this is anyway what I would prefer > with the knowledge I have... There is an implementation detail to iron out: Doing obj-$(CONFIG_TCG_TIS_SPI) += tpm_tis_spi.o cr50_spi.o as in this patch results in it failing to build as a module, due to them getting compiled to separate modules, yt sharing code. So I guess doing obj-$(CONFIG_TCG_TIS_SPI) += tpm_tis_spi.o obj-$(CONFIG_TCG_TIS_SPI_CR50) += cr50_spi.o will result in the same error, hence the question of doing something like obj-$(CONFIG_TCG_TIS_SPI) += tpm_tis_spi_mod.o tpm_tis_spi_mod-y := tpm_tis_spi.o tpm_tis_spi_mod-$(CONFIG_TCG_TIS_SPI_CR50) += cr50_spi.o so that sources get compiled and the module getting build from the result. Heiko
