Messages in this thread | | | From | akepner@sgi ... | Date | Wed, 30 Jan 2008 11:45:28 -0800 | Subject | Re: [PATCH 2/4] dma/ia64: update ia64 machvecs |
| |
On Wed, Jan 30, 2008 at 11:25:58AM -0600, James Bottomley wrote: > In general, the patches look reasonable to me. Just an observation: > > On Tue, 2008-01-29 at 21:52 -0800, akepner@sgi.com wrote: > > diff --git a/include/linux/dma-attrs.h b/include/linux/dma-attrs.h > > index e69de29..31af292 100644 > > --- a/include/linux/dma-attrs.h > > +++ b/include/linux/dma-attrs.h > > @@ -0,0 +1,48 @@ > > +#ifndef _DMA_ATTR_H > > +#define _DMA_ATTR_H > > +#ifdef ARCH_USES_DMA_ATTRS > > + > > +enum dma_attr { > > + DMA_ATTR_BARRIER, > > + DMA_ATTR_FOO, > > + DMA_ATTR_GOO, > > + DMA_ATTR_MAX, > > +}; > > + > > > The attribute names (DMA_ATTR_...) are going to have to live somewhere > outside of the #ifdef ARCH_USES_DMA_ATTRS otherwise we'll get compile > failures of drivers using attributes on architectures that don't support > them.
Right. Thanks for catching that.
> > Secondly, DMA_ATTR_BARRIER doesn't quite sound right. What you're > actually doing is trying to prescribe strict ordering, so shouldn't this > be something like DMA_ATTR_STRICT_ORDERING (and perhaps with a > corresponding DMA_ATTR_RELAXED_ORDERING for the PCIe case).
OK, I'll reconsider the names here.
> ... also, > strike the DMA_ATTR_FOO and DMA_ATTR_GOO since they have no plausible > meaning. >
Yeah, I realized only after sending that I'd forgotten to remove these.
-- Arthur
| |