[PATCH] PPC4xx: ADMA separating SoC specific functions
Greg KH
greg at kroah.com
Sun Oct 3 05:49:57 EST 2010
On Thu, Sep 30, 2010 at 05:57:10PM -0700, Dan Williams wrote:
> [ adding Greg ]
>
> On Thu, Sep 30, 2010 at 5:16 PM, Tirumala Marri <tmarri at apm.com> 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?
Possibly, but I really don't like duplication if possible. What's
keeping this code from being fixed up now properly?
thanks,
greg k-h
More information about the Linuxppc-dev
mailing list