From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 23 Jul 2012 08:24:17 -0700 Subject: [U-Boot] [PATCH 1/2] common.h: Introduce DEFINE_CACHE_ALIGN_BUFFER In-Reply-To: <201207211322.41728.vapier@gentoo.org> References: <1341716895-31089-1-git-send-email-marex@denx.de> <201207201747.47423.vapier@gentoo.org> <5009D2A9.3000706@ti.com> <201207211322.41728.vapier@gentoo.org> Message-ID: <20120723152417.GA22955@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Sat, Jul 21, 2012 at 01:22:40PM -0400, Mike Frysinger wrote: > 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 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. Er, between drivers/usb/host/ehci-hcd.c and drivers/usb/eth/smsc95xx.c the three new macros are used today. -- Tom