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.
