On Friday 20 July 2012 17:50:33 Tom Rini wrote: > On 07/20/2012 02:47 PM, Mike Frysinger wrote: > > On Friday 20 July 2012 07:31:47 Marek Vasut wrote: > >> Dear Mike Frysinger, > >> > >>> On Saturday 07 July 2012 23:08:14 Marek Vasut wrote: > >>>> +/* DEFINE_CACHE_ALIGN_BUFFER() is similar to > >>>> ALLOC_CACHE_ALIGN_BUFFER, but it's purpose is to allow > >>>> allocating aligned buffers outside of function scope. Usage > >>>> of this macro shall be avoided or used with extreme care! */ > >>>> +#define DEFINE_CACHE_ALIGN_BUFFER(type, name, size) + static > >>>> char __##name[roundup(size * sizeof(type), > >>>> ARCH_DMA_MINALIGN)] + __aligned(ARCH_DMA_MINALIGN); + > >>>> static type *name = (type *)__##name; > >>> > >>> how is this any different from doing: static __u8 foo[1234] > >>> __aligned(ARCH_DMA_MINALIGN); > >> > >> Does __aligned() align both start of the buffer downwards and end > >> of it upwards ? > > > > it guarantees the start is aligned. i don't believe it does any > > tail padding. > > > > that said, you've added just 1 consumer, but it uses in function > > scope, so i don't see why you had to define a new helper in the > > first place. the existing one would work fine shouldn't it ? > > The rough outline of the problems are: > - We need to have buffers that are multiple of cache size, for clearing. > - Today we know ehci-hcd had a problem. We also know other drivers / > layers have problems, but they aren't as readily breakable. > > That's why we put the macro in <common.h> rather than a USB header.
that wasn't the question. no one in the tree needs the new macro at all, regardless of what header it lives in. i guess the answer is that some code in the future (which hasn't been merged) might use it. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
