lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 11 Nov 2007 15:18:35 +0000 From: Alan Cox <alan@...rguk.ukuu.org.uk> To: David Howells <dhowells@...hat.com> Cc: dhowells@...hat.com, Andrew Morton <akpm@...ux-foundation.org>, torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org, linux-am33-list@...hat.com Subject: Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5] > So you would say change the global h/w register variables[*] to be addresses > instead, and change all the references to be readX and writeX? I'm wary of Ok so these are not addresses but magic registers in the processor ? Then I guess volatile makes complete sense. > > Similarly spin_lock/unlock are store barriers so for ring buffers should > > be sufficient unless you have cache management requirements in which case > > the dma_* APIs will handle those bits. > > I don't actually need locks, but sticking smp_rmb()/smp_wmb() is probably the > right thing to do now that I know how to use them. This code was written five > or six years ago and I haven't really thought about changing that since. > > I don't see how the dma_* APIs would help. The buffer is filled by a higher > priority interrupt routine that does 'virtual DMA'. It's not actually done by > real DMA. Normal interrupt disablement doesn't really disable interrupts, it > justs excludes normal priority interrupts. For real DMA the dma_ APIs keep coherency > The virtual DMA is done is ASM as it has to be really quick. It's unfortunate, > but, the on-chip serial ports don't have a FIFO. For PIO (virtual DMA or otherwise) the locking does that. Because spin_unlock and spin_lock are compiler barriers the need to use volatile shouldn't normally be there. If you are doing it via asm without locks then I would expect atomic_t because the sematics of volatile are horribly vague on their own ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists