Hi Jean, > > > i2c-foo.c is consistently used for i2c bus driver themselves so far. > > > It's somewhat confusing to see you name platform code that way. It's > > > also redundant, given that the file lives in the swarm platform > > > directory. May I suggest naming this file just > > > arch/mips/sibyte/swarm/i2c.c? Other architectures (cris, arm) are doing > > > this already. > > > > Is there any chance CONFIG_I2C_BOARDINFO could become tristate? > > If yes, it's problematic if you have multiple modules called i2c.ko. > > No, CONFIG_I2C_BOARDINFO is boolean by nature, it will never become > tristate. I can do that and I have considered it while preparing the change. What convinced me not to use a name that is already present elsewhere in the tree is the confusion that it sometimes causes. For example during a debugging session GDB only reports the file name and not the leading pathname (and some people do run GDB over the kernel). Of course the actual file can still be chased with some `find' and `grep' scriptery, but why to create a problem in the first place? I consider repeated file names throughout a tree of a single program a namespace pollution similar to one with repeated static symbol names. While syntactically valid and working, it asks for unnecessary confusion. This is my point of view, but I can see others may not necessarily follow it. I am fine with changing the name to i2c.c as it is unlikely I will run GDB over it. ;-) Maciej