On Sat 18 Jul 2009 13:50, Wolfgang Denk pondered: > Dear Robin Getz, > > In message <200907181115.26404.rg...@blackfin.uclinux.org> you wrote: > > > > It would be nice to come up with some list of namespaces, and what they > > they should be used for... > > Agreed.
Excellent - a common goal :) > > For example, should it be: > > CONFIG_DRIVER_OMAP24XX_I2C > > or > > CONFIG_SYS_I2C_DRIVER_OMAP24XX > > or > > CONFIG_DRIVER_I2C_OMAP24XX > > Well, the difference between CONFIG_ and CONFIG_SYS_ is well-defined. > > And the "DRIVER_" part makes not much sense to me in any of the > examples above. It's a namespace - controls if a driver is compile in or not. Should only be used in .config files, and Makefiles. Some (very few) already use it.. ./drivers/serial/Makefile:COBJS-$(CONFIG_DRIVER_S3C4510_UART) += s3c4510b_uart.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_3C589) += 3c589.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_AX88180) += ax88180.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_CS8900) += cs8900.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_DM9000) += dm9000x.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_KS8695ETH) += ks8695eth.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_LAN91C96) += lan91c96.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_NE2000) += ne2000.o ne2000_base.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_AX88796L) += ax88796.o ne2000_base.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_NETARMETH) += netarm_eth.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_NS7520_ETHERNET) += ns7520_eth.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_NS9750_ETHERNET) += ns9750_eth.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_RTL8019) += rtl8019.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_S3C4510_ETH) += s3c4510b_eth.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_SMC91111) += smc91111.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_SMC911X) += smc911x.o ./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o ./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o ./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o ./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o ./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += omap24xx_i2c.o ./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_S3C24X0_I2C) += s3c24x0_i2c.o ./drivers/mtd/Makefile:COBJS-$(CONFIG_FLASH_CFI_DRIVER) += cfi_flash.o ./drivers/mtd/nand/Makefile:COBJS-$(CONFIG_DRIVER_NAND_BFIN) += bfin_nand.o ./board/micronas/vct/Makefile:COBJS-$(CONFIG_DRIVER_SMC911X) += ebi_smc911x.o smc_eeprom.o ./cpu/arm926ejs/davinci/Makefile:COBJS-$(CONFIG_DRIVER_TI_EMAC) += lxt972.o dp83848.o > My personal way of thinking about such options is usually CPU/archi- > tecture first, so I would probably chose CONFIG_OMAP24XX_I2C to en- > able/disable the I2C driver on a OMAP24XX based board, but I under- > stand that there are reasons to prefer CONFIG_I2C_OMAP24XX as well - > let's see if there is a clear majority of opiniions... If we are thinking of a "tree" type structure - it might make sense to start at the top? I guess the question is -- is it an I2C driver for the OMAP24xx or a OMAP24xx driver for I2C? Since the API is a I2C API - my thought it is an I2C driver, which happens to run on a specific SoC. The actual SoC doesn't really matter (and should be last) - so it is similar to the directory structure we have today. > > Again - which is only used in one place: > > drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o > > include/configs/omap2420h4.h:#define CONFIG_DRIVER_OMAP24XX_I2C > > > > Which is fine - since it is a driver, which I'm sure that people out of > > tree use. > > Well, if only out-of-tree ports use it, it probably should never have > been added in the first place. Then I can start sending patches for unused CONFIG_ from random config files, and no one will start complaining? >From what I can quickly tell - there seems to be about 472 different CONFIG_ options in ./include/config that are not actually used anywhere in the master tree. > > I would think should be CONFIG_DRIVERS_PATA_BFIN > > I dosagree, the "DRIVERS" part is just added line noise. It's a name space - making sure it is differentiated from an option. As you pointed out - this is what exists in the README today. (which I have read, but gained no clarity from it)... ======================= * Configuration _OPTIONS_: These are selectable by the user and have names beginning with "CONFIG_". * Configuration _SETTINGS_: These depend on the hardware etc. and should not be meddled with if you don't know what you're doing; they have names beginning with "CONFIG_SYS_". ======================= I think there needs to be more words - do you mean: - hardware, CPU level? or - hardware, SoC level? or - hardware, board level? Personally - I don't think board level things should be CONFIG_SYS_, as these need to be switched around by board porters. I guess we could back up a step and look at the users, and defined things as things that should be changed by: - arch maintainers (Core/CPU specific) - SoC maintainer (SoC specific) - Board maintainer (PCB specific) - End user of the above (changes options, but nothing from the above list?) ? I'm happy to write a patch - but I have a feeling what I think isn't what everyone else's opinion is... -Robin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
