On Wed, Jul 17, 2019 at 09:49:42AM -0700, Stephen Boyd wrote: > Quoting Jason Gunthorpe (2019-07-17 05:25:58) > > On Wed, Jul 17, 2019 at 02:00:06PM +0200, Alexander Steffen wrote: > > > On 17.07.2019 00:45, Stephen Boyd wrote: > > > > diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig > > > > index 88a3c06fc153..b7028bfa6f87 100644 > > > > +++ b/drivers/char/tpm/Kconfig > > > > @@ -114,6 +114,22 @@ config TCG_ATMEL > > > > will be accessible from within Linux. To compile this driver > > > > as a module, choose M here; the module will be called tpm_atmel. > > > > +config TCG_CR50 > > > > + bool > > > > + ---help--- > > > > + Common routines shared by drivers for Cr50-based devices. > > > > + > > > > > > Is it a common pattern to add config options that are not useful on their > > > own? When would I ever enable TCG_CR50 without also enabling TCG_CR50_SPI? > > > Why can't you just use TCG_CR50_SPI for everything? > > > > This is an internal kconfig symbol, it isn't seen by the user, which > > is a pretty normal pattern. > > > > But I don't think the help should be included (since it cannot be > > seen), and I'm pretty sure it should be a tristate > > Good point. I'll fix it. > > > > > But overall, it might be better to just double link the little helper: > > > > obj-$(CONFIG_TCG_CR50_SPI) += cr50.o cr50_spi.o > > obj-$(CONFIG_TCG_CR50_I2C) += cr50.o cr50_i2c.o > > > > As we don't actually ever expect to load both modules into the same > > system > > > > Sometimes we have both drivers built-in. To maintain the tiny space > savings I'd prefer to just leave this as helpless and tristate. If it is builtin you only get one copy of cr50.o anyhow. The only differences is for modules, then the two modules will both be a bit bigger instead of a 3rd module being created Jason
