After writing this mail, looking at the code again I have a alternate proposal.
1. move the current pinmux drivers back into drivers with reasonable names.
2. remove the API support from all the drivers and move it to a quark_pinmux_dev driver that just provides the API if people really need runtime control of the pin configuration they can build the driver.
So all the replicated code moves to a single place where it is needed and the remaining pimux driver only do init() and are done.
I like it.
The only thing I am thinking about is polluting the drivers/pinmux/ directory when there are more than a couple of board variants. But this may not be a problem.
I would only propose to have a different directory for the 'pinmux_dev' driver. From what I understand, there would be no code shared between the pinmux "board" driver and the pinmux "dev" driver (the only information needed seems to be what is already provided by 'include/pinmux.h').
yeah better idea :-D when the quark_se gets more design wins things would get crowded.
Now the question is who is signing up to do the refactoring? :-)
And all concerns that were raised about the increases in ROM size and boot time overhead seems to be addressed.
