linux-dev - Linux kernel development work

Age	Commit message (Collapse)	Author	Files	Lines
2007-05-22	parisc: convert /proc/gsc/pcxl_dma to seq_file	Alexey Dobriyan	1	-41/+53
	As side effect, remove one more ->get_info user and a novel approach of content generation: sprintf(buf, "%sfoo", buf, ...); sprintf(buf, "%sbar", buf, ...); ... Compile-tested. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2006-12-08	[PARISC] more sparse fixes	Matthew Wilcox	1	-1/+1
	0/NULL changes, __user annotations, __iomem annotations Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2006-01-10	[PARISC] Add __read_mostly section for parisc	Helge Deller	1	-3/+3
	Flag a whole bunch of things as __read_mostly on parisc. Also flag a few branches as unlikely() and cleanup a bit of code. Signed-off-by: Helge Deller <deller@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2005-10-29	[PATCH] mm: init_mm without ptlock	Hugh Dickins	1	-1/+1
	First step in pushing down the page_table_lock. init_mm.page_table_lock has been used throughout the architectures (usually for ioremap): not to serialize kernel address space allocation (that's usually vmlist_lock), but because pud_alloc,pmd_alloc,pte_alloc_kernel expect caller holds it. Reverse that: don't lock or unlock init_mm.page_table_lock in any of the architectures; instead rely on pud_alloc,pmd_alloc,pte_alloc_kernel to take and drop it when allocating a new one, to check lest a racing task already did. Similarly no page_table_lock in vmalloc's map_vm_area. Some temporary ugliness in __pud_alloc and __pmd_alloc: since they also handle user mms, which are converted only by a later patch, for now they have to lock differently according to whether or not it's init_mm. If sources get muddled, there's a danger that an arch source taking init_mm.page_table_lock will be mixed with common source also taking it (or neither take it). So break the rules and make another change, which should break the build for such a mismatch: remove the redundant mm arg from pte_alloc_kernel (ppc64 scrapped its distinct ioremap_mm in 2.6.13). Exceptions: arm26 used pte_alloc_kernel on user mm, now pte_alloc_map; ia64 used pte_alloc_map on init_mm, now pte_alloc_kernel; parisc had bad args to pmd_alloc and pte_alloc_kernel in unused USE_HPPA_IOREMAP code; ppc64 map_io_page forgot to unlock on failure; ppc mmu_mapin_ram and ppc64 im_free took page_table_lock for no good reason. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-28	Auto-update from upstream	Kyle McMartin	1	-3/+3

2005-10-28	[PATCH] gfp_t: dma-mapping (parisc)	Al Viro	1	-3/+3
	Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-21	[PARISC] Cleanup whitespace and handle proc_mkdir() failures in pci-dma.c	Grant Grundler	1	-18/+30
	1) cleanup whitespace and handle proc_mkdir() failures. From: Christophe Lucas <clucas@rotomalug.org> 2) rename "dino" entry to "pcxl_dma"...also seems like it's in the wrong location. 3) don't dump resource bitmap in /proc/pcxl_dma output 4) fixup compiler warning Signed-off-by: Grant Grundler <grundler@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2005-04-16	Linux-2.6.12-rc2	Linus Torvalds	1	-0/+578
	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!