* Kevin Hilman <khilman@xxxxxx> [110513 16:12]: > Tony Lindgren <tony@xxxxxxxxxxx> writes: > > > * Cousson, Benoit <b-cousson@xxxxxx> [110513 15:18]: > >> >>>Signed-off-by: Vladimir Zapolskiy<vzapolskiy@xxxxxxxxx> > >> >> > >> >Unfortunately I don't have an automated tool, but that would be great > >> >to have such a script. For this time I've checked the correctness of the > >> >change comparing the preprocessed output. > >> > >> In fact these files are already generated automatically, as written > >> in the header file. So changing the output format should > >> straightforward. At least for OMAP4... OMAP2 and OMAP3 were done > >> manually some time ago. > > > > Sounds like the important thing to consider here is how these macros > > should be set up considering the upcoming generic clock framework > > and device tree changes. > > > > So let's wait a few days for comments from Benoit and Paul on the > > format for the macros so we don't need to redo them again later. > > Of course there might be other things to consider too.. > > ... like readability. > > After seeing the patch (thanks Benoit), I think this is bad tradeoff > between readability and lines-of-code. > > Personally, I don't think we should be trading readability for diffstat > goodness. I have a strong dislike for these multi-line macros, but > it's up to Paul/Benoit to decide how this should look. Despite having few hard-to-read multi-line macros, this can be used to make the actual data entries more readable. The same way as REGULATOR_SUPPLY, OMAP3_MUX, etc. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
