[ adding Greg ] On Thu, Sep 30, 2010 at 5:16 PM, Tirumala Marri <tmarri@xxxxxxx> wrote: >> Where iop_adma_alloc_slots() is implemented differently between >> iop13xx and iop3xx. In this case why does ppc440spe-adma.h exist? If >> it has code specific to ppe440spe it should just live in the ppe440spe >> C file. If it is truly generic it should move to the base adma.c >> implementation. If you want to reuse a ppe440spe routine just link to >> it. > [Marri]That is how I started changing the code. And I see tons of warnings > Saying "Used but not defined" or "Defined but not used". How should I > suppress > Some functions from adma.c are used in ppc440spe-adma.c and some from > ppc440spe-adma.c > Are used in adma.c. This is part of defining a common interface. Maybe look at the linkages of how the common ioat_probe() routine is used to support all three versions of its dma hardware. > So I created intermediate file ppc440spe-adma.h with > inlined > Functions. In future this will be converted into ppc4xx_adma.h and move > existing > SoC specific stuff to ppc440spe-adma.c file. You definitely need to be able to resolve "used but not defined" and "defined but not used" warnings before tackling a driver conversion like this. In light of this comment I wonder if it would be appropriate to submit your original driver, that just duplicated routines from the ppc440spe driver, to the -staging tree. Then it would be available for someone familiar with driver conversions to take a shot at unifying. Greg, is this an appropriate use of -staging? -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
