summaryrefslogtreecommitdiffstats
path: root/drivers/char/rio/riocmd.c
AgeCommit message (Collapse)Author
2006-05-27[PATCH] missing readb/readw in rioAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2006-05-27[PATCH] handling rio MEMDUMPAl Viro
it copies data _from_ iomem, so it should be rio_memcpy_fromio(), not ->Copy(). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2006-05-27[PATCH] trivial annotations in rioAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2006-03-24[PATCH] Yet more rio cleaning (2 of 2)Alan Cox
- Remove more unused headers - Remove various typedefs - Correct type of PaddrP (physical addresses should be ulong) - Kill use of bcopy - More printk cleanups - Kill true/false - Clean up direct access to pci BARs Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-24[PATCH] rio driver rework continued #3Alan Cox
Second large chunk of code cleanup. The split between this and #3 and #4 is fairly arbitary and due to the message length limit on the list. These patches continue the process of ripping out macros and typedefs while cleaning up lots of 32bit assumptions. Several inlines for compatibility also get removed and that causes a lot of noise. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-16[PATCH] Remove unused CHECK code from riocmd.cAlan Cox
Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-11[PATCH] lindent rio driversAndrew Morton
Run all rio files through indent -kr -i8 -bri0 -l255, as requested by Alan. rioboot.c and rioinit.c were skipped due to worrisome lindent warnings. Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!