> > > 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
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. ;-)