Not suprising, as usually with most pieces of code for the SWARM and the
SiByte SOC. That can be done gradually, but mixing a driver overhaul with
functional changes usually only results in confusion later on.
Well, I decide whether or not to add one based on how important changes
are from the piece's of code point of view. In this case the change is
essential for new-style client drivers to work at all, which I think is
more important than e.g. a lot of cosmetical changes throughout would be.
But I do not insist on keeping it -- if you think I misjudged on this
occasion, I see no problem with discarding it.
This is mostly habitual -- this is what the GNU Coding Standard specifies
for comments and which is enforced for GNU software which I have dealt a
lot with. I think the idea is it improves readability and I tend to
agree. The same goes for using a capital at the beginning and a full stop
at the end of sentences in comments -- it improves readability and
(together with a good style of code itself) makes the result look more
professional. Certainly well-formatted code is easier to comprehend for
someone looking at it for the first time.
I do not insist on the extraneous space if you have a strong opinion
against though.
Andrew has spoken (thank you, Andrew) and I would only like to add an
explanation why I have not split this change further. Certainly it is
functionally consistent. Then adding i2c-swarm.c only breaks things as
the onchip buses suddenly get the numbers 2 and 3. On the other hand, if
adding the i2c-sibyte.c change only, it will take a while until it
propagates back to the MIPS tree and without that as it is there is no
single way to use the whole set of changes as the clock device will not be
seen.
If you are scared off by the MIPS-specific Makefile (lib vs obj) changes,
then I think they should be reasonably easy to sort out separately in a
couple of days as functionally not changing anything. The only other file
in the affected subdirectory that depends on a config option uses
CONFIG_KGDB which does not seem to rely on being pulled implicitly by the
linker. But such a mechanical change by itself would make little sense
(don't fix what isn't broken), so I have not pushed it without a
reasonable justification.
Ralf -- what do you think about the Makefile changes? I can send you a
separate patch which will reduce the span of this one.
Maciej
--
