Messages in this thread | | | Date | Fri, 09 Dec 2011 15:17:04 -0800 | From | "H. Peter Anvin" <> | Subject | Re: [20/80] ALSA: lx6464es - fix device communication via command bus |
| |
Sorry for the late reply. With baby prep and everything going on I'm a bit ADD.
On 12/07/2011 10:09 AM, Linus Torvalds wrote: > On Wed, Dec 7, 2011 at 10:00 AM, H. Peter Anvin <hpa@zytor.com> wrote: >> >> I agree in principle, although I am really not happy about the idea of >> disallowing 64-bit writes from device drivers that haven't explicitly >> indicated they won't support it. > > I'd really prefer going in the other direction. Especially since > 64-bit writes would be optional *anyway* (ie impossible on 32-bit > hosts). So a driver should explicitly say "I can do 64-bit stuff" > rather than having to say "I cannot do it". > > And if a driver *has* to have 64-bit accesses, it had better do them > all by hand, using "writeq()" and being dependent on the architecture > actually having that support. No "memcpy_toio" and friends at all. > > So adding a "memcpy_toio64()" that defaults to the normal 32-bit max > but *might* do 64-bit copies sounds fine to me. But we really should > default to something that is consistent across architectures, and that > is not 64-bit accesses.
I feel a bit funny about memcpy_toio64() being able to *not* to 64-bit copies... it feels like it really violates the assumptions.
What I would suggest, technically is:
- memcpy_toio() becomes a legacy alias for memcpy_toio32(). - memcpy_toio32() and memcpy_toio64() are defined to do exactly those reference sizes. If the platform can't do 64-bit I/O then memcpy_toio64 is undefined (like readq/writeq). - we introduce memcpy_toio_fast() which is explicitly allowed to do any kind of references, including larger than 64 bits if supported in future CPUs.
However, I *also* found that we have a metric boatload of partially overlapping redundant aliases:
iowrite{8,16,32}_rep() [but iowrite64_rep() is missing]
__iowrite{32,64}_copy()
memcpy_toio()
What I have proposed to memcpy_toio{32,64}() pretty much matches __iowrite_{32,64}_copy() and those functions should probably be renamed... not sure what the sane thing to do with the iowrite functions is here.
-hpa
| |