On Wed, Oct 29, 2008 at 12:18:47PM -0700, David Daney wrote: > Christoph Hellwig wrote: > >On Mon, Oct 27, 2008 at 05:02:38PM -0700, David Daney wrote: > >>Signed-off-by: Tomaso Paoletti <tpaoletti@xxxxxxxxxxxxxxxxxx> > >>Signed-off-by: David Daney <ddaney@xxxxxxxxxxxxxxxxxx> > >>--- > >> .../cavium-octeon/executive/cvmx-csr-addresses.h | 8391 ++++++ > >> arch/mips/cavium-octeon/executive/cvmx-csr-enums.h | 86 + > >> .../cavium-octeon/executive/cvmx-csr-typedefs.h |27517 > >> ++++++++++++++++++++ > > > >27517 lines in a header and it's all junk? > > > > I'm glad you asked. No it is not all junk. > > That file contains the bit definitions for all on-chip registers. > > We are interested in transforming this information into a form suitable > for inclusion in the kernel. Any specific suggestions as to improve the > patch will be considered. > > Several possibilities are: > > 1) Don't typedef all the unions in cvmx-csr-typedefs.h. An rename the > file so it doesn't contain the reprehensible word 'typedef' > > 2) Break cvmx-csr-addresses.h and cvmx-csr-typedefs.h into several > parts, one for each functional block in the processor. The two are very good ideas, but not really the important part. Adding a massive inline for every single bit somewhere in a register just doesn't make sense. Take a look at normal hardware defintion headers in the tree. Have a simple define for each _register_ (applied relative to a bank/chip or whatever is appropriate) and if the individual bits in it are important add bit defintions, too - leaving the arithmetics for it to the caller. Also please don't add defintions for those blocks of the chip that aren't actually used in your submission. That's best done with one header per block that can be added with the driver supporting that block. And yes, we had this a few times. Eventually I'll make a fortune by selling a perl script generating proper headers out of common HDLs..
