Because I don't have something better to replace them with.
We need names for irqs, currently the kernel/user space interface
is a unsigned number.
.../...
Ok, as long as it's strictly a userspace issue, I understand.
The model can be made to work if you force it but it isn't really
a
Except for the what appears to be instability of the irq numbers on
simpler configurations I don't have a problem with it.
I agree that's a bit annoying and I beleive it can be fixed. In
additionm I'd like to look into exposing the domain/HW number - virq
mapping somewhere in sysfs maybe.
On Sun, 2007-02-18 at 22:24 +0100, Arjan van de Ven wrote:
On Fri, 2007-02-16 at 13:41 +0100, Ingo Molnar wrote:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
So I propose we remove all assumptions from the code that we actually
have an array of irqs. That will allow for irq_desc to
If I make the root device a basic struct device, it can't be part of
ibmebus any
longer. If we could create a busless device, we wouldn't have a problem,
but I
doubt that is possible.
Do you have any creative ideas?
Well, I think PCI does just that for PCI busses ... (a busless device)
!!! This is a first cut, and there are still cleanups to be done in various
areas touched by that code. I also haven't done descriptions yet for the
individual patches.
The current get_unmapped_area code calls the f_ops-get_unmapped_area or
the arch one (via the mm) only when MAP_FIXED is not
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/alpha/kernel/osf_sys.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/alpha/kernel/osf_sys.c
===
--- linux-cell.orig/arch/alpha/kernel/osf_sys.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/arm/mm/mmap.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-cell/arch/arm/mm/mmap.c
===
--- linux-cell.orig/arch/arm/mm/mmap.c 2007-03-22
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/frv/mm/elf-fdpic.c |4
1 file changed, 4 insertions(+)
Index: linux-cell/arch/frv/mm/elf-fdpic.c
===
--- linux-cell.orig/arch/frv/mm/elf-fdpic.c 2007-03
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/i386/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/i386/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/i386/mm/hugetlbpage.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/powerpc/mm/hugetlbpage.c | 21 +
1 file changed, 21 insertions(+)
Index: linux-cell/arch/powerpc/mm/hugetlbpage.c
===
--- linux-cell.orig/arch
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/ia64/kernel/sys_ia64.c |7 +++
arch/ia64/mm/hugetlbpage.c |8
2 files changed, 15 insertions(+)
Index: linux-cell/arch/ia64/kernel/sys_ia64.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/parisc/kernel/sys_parisc.c |5 +
1 file changed, 5 insertions(+)
Index: linux-cell/arch/parisc/kernel/sys_parisc.c
===
--- linux-cell.orig/arch/parisc/kernel
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/x86_64/kernel/sys_x86_64.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/x86_64/kernel/sys_x86_64.c
===
--- linux-cell.orig/arch/x86_64/kernel
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
fs/ramfs/file-nommu.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/fs/ramfs/file-nommu.c
===
--- linux-cell.orig/fs/ramfs/file-nommu.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/sparc64/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/sparc64/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/sparc64/mm
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
fs/hugetlbfs/inode.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/fs/hugetlbfs/inode.c
===
--- linux-cell.orig/fs/hugetlbfs/inode.c2007-03-22
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
mm/mmap.c | 16
1 file changed, 16 deletions(-)
Index: linux-cell/mm/mmap.c
===
--- linux-cell.orig/mm/mmap.c 2007-03-22 16:30:24.0 +1100
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
mm/mmap.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
Index: linux-cell/mm/mmap.c
===
--- linux-cell.orig/mm/mmap.c 2007-03-22 16
This also fixes a bug, I think, it used to return a pgoff (pfn)
instead of an address. (To split ?)
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/char/mem.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/drivers/char/mem.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/char/drm/ffb_drv.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/drivers/char/drm/ffb_drv.c
===
--- linux-cell.orig/drivers/char/drm/ffb_drv.c
Great, this is long overdue for a cleanup.
Indeed... lots of redundant checks, dead code, etc...
I haven't looked at all users of this, but does it make sense to switch
to an API that takes an address range and modifies / filters it? Perhaps
also filling in some other annotations (eg.
Well if we use a set of valid ranges, then we can start with generic code
that will set up ranges allowed by the syscall semantics.
Then the arch code could be called with that set of ranges, and perform
its modifications to that set.
A bit complicated in practice... set of ranges can be
i.e. First the simple bug fixes that should purely be restructure of
msi.c with no affect on anything outside of it.
And then get into the architecture enhancements.
I agree, care to break these down into a smaller series of patches that
can go into -mm for testing?
I don't see the
Ok, then which patches in the series should be acceptable to take right
now for 2.6.22? The clean up the BUG ones?
I'd say 1...8 (BUG cleanups and removing msi_cache) looks to be on the
safe side to me, though of course, some review by Eric a bit of
testing would be welcome regardless :-)
-#ifdef HAVE_ARCH_HUGETLB_UNMAPPED_AREA
-unsigned long hugetlb_get_unmapped_area(struct file *file, unsigned long
addr,
- unsigned long len, unsigned long pgoff, unsigned long flags);
-#else
-static unsigned long
+unsigned long
hugetlb_get_unmapped_area(struct file *file,
On Fri, 2007-03-23 at 13:43 +, David Howells wrote:
[Resend - this time with a comma in the addresses, not a dot]
Lennert Buytenhek [EMAIL PROTECTED] wrote:
[ background: On ARM, SMP synchronisation does need barriers but device
synchronisation does not. The question is that given
On Fri, 2007-02-16 at 17:59 +, Linux Kernel Mailing List wrote:
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=76d2160147f43f982dfe881404cfde9fd0a9da21
Commit: 76d2160147f43f982dfe881404cfde9fd0a9da21
Parent:
I missed that one ... thanks for not telling/CC'ing me and not fixing
powerpc :-( (I know, everybody is supposed to have the bandwidth to read
all of lkml... I don't).
We need to audit all of our PICs to make sure they can deal with
disabling an already ack'ed interrupt, which isn't
On Tue, 2007-03-27 at 09:32 +0200, Ingo Molnar wrote:
* Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
Note that I'm not opposed to the change at all, I think it's a good
idea, I'm just worried I'm discovering it a bit late and I've seen
PICs broken in some many colorful ways that I'm
On Thu, 2007-04-05 at 14:55 -0500, Kevin Corry wrote:
Hello,
Carl Love and I have been working on getting the latest perfmon2 patches
(http://perfmon2.sourceforge.net/) working on Cell, and on powerpc in
general. We've come up with some powerpc-specific questions and we're hoping
to get
On Sat, 2007-04-07 at 07:21 +0300, Mikhail Zolotaryov wrote:
On PPC4xx embedded we often have UART0 on IRQ0 but 8250 UART driver
uses IRQ0 as no irq hack. It's suggested that platforms with UART
on IRQ0 will redefine is_real_interrupt(irq) macro but 8250 code
anyway overrides that. As the
On Mon, 2007-04-09 at 11:25 -0700, Christoph Lameter wrote:
Quicklists for page table pages V5
Looks interesting, but unfortunately not very useful at this point for
powerpc unless you remove the assumption that quicklists contain
pages...
On powerpc, we currently use kmem cache slabs (though
On Tue, 2007-04-10 at 21:04 -0700, Christoph Lameter wrote:
On Tue, 10 Apr 2007, Benjamin Herrenschmidt wrote:
On Mon, 2007-04-09 at 11:25 -0700, Christoph Lameter wrote:
Quicklists for page table pages V5
Looks interesting, but unfortunately not very useful at this point
On Wed, 2007-04-11 at 15:41 +1000, Paul Mackerras wrote:
Benjamin Herrenschmidt writes:
For a 64K page size kernel, we have 3 level page tables and we use 3
caches: a PGD pages are 128 bytes (yeah, not big heh...), our pmd
pages are 32K (half a page) and PTE pages are PAGE_SIZE (64K
While digging through my MAP_FIXED changes, I found that rather obvious
bug in /dev/mem mmap implementation for nommu archs. get_unmapped_area()
is expected to return an address, not a pfn.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
I suppose that can go in anytime, and probably
Handle MAP_FIXED in powerpc's arch_get_unmapped_area() in all 3
implementations of it.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
arch/powerpc/mm/hugetlbpage.c | 21 +
1 file changed, 21 insertions(+)
Index: linux-cell/arch/powerpc/mm/hugetlbpage.c
This is a first step as there are still cleanups to be done in various
areas touched by that code but I think it's probably good to go as is and
at least enables me to implement what I need for PowerPC.
(Andrew, this is also candidate for 2.6.22 since I haven't had any real
objection, mostly
Handle MAP_FIXED in alpha's arch_get_unmapped_area(), simple case, just
return the address as passed in
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
arch/alpha/kernel/osf_sys.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/alpha/kernel/osf_sys.c
ARM already had a case for MAP_FIXED in arch_get_unmapped_area() though
it was not called before. Fix the comment to reflect that it will now
be called.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
arch/arm/mm/mmap.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index
Remove the hugetlbfs specific hacks in toplevel get_unmapped_area() now
that all archs and hugetlbfs itself do the right thing for both cases.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
mm/mmap.c | 16
1 file changed, 16 deletions(-)
Index: linux-cell/mm/mmap.c
Generic hugetlb_get_unmapped_area() now handles MAP_FIXED by just
calling prepare_hugepage_range()
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
fs/hugetlbfs/inode.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/fs/hugetlbfs/inode.c
generic arch_get_unmapped_area() now handles MAP_FIXED. Now that
all implementations have been fixed, change the toplevel
get_unmapped_area() to call into arch or drivers for the MAP_FIXED
case.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
mm/mmap.c | 25
Handle MAP_FIXED in arch_get_unmapped_area on frv. Trivial case, just
return the address.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
arch/frv/mm/elf-fdpic.c |4
1 file changed, 4 insertions(+)
Index: linux-cell/arch/frv/mm/elf-fdpic.c
Handle MAP_FIXED in x86_64 arch_get_unmapped_area(), simple case, just
return the address as passed in
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
arch/x86_64/kernel/sys_x86_64.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/x86_64/kernel/sys_x86_64.c
Handle MAP_FIXED in hugetlb_get_unmapped_area on sparc64
by just using prepare_hugepage_range()
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
arch/sparc64/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/sparc64/mm/hugetlbpage.c
Handle MAP_FIXED in parisc arch_get_unmapped_area(), just return the
address. We might want to also check for possible cache aliasing
issues now that we get called in that case (like ARM or MIPS),
leave a comment for the maintainers to pick up.
Signed-off-by: Benjamin Herrenschmidt [EMAIL
Handle MAP_FIXED in ia64 arch_get_unmapped_area and
hugetlb_get_unmapped_area(), just call prepare_hugepage_range
in the later and is_hugepage_only_range() in the former.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
arch/ia64/kernel/sys_ia64.c |7 +++
arch/ia64/mm
Handle MAP_FIXED in i386 hugetlb_get_unmapped_area(), just call
prepare_hugepage_range.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
arch/i386/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/i386/mm/hugetlbpage.c
Is there any support consideration for nommu arch such as blackfin which
is in the -mm tree now?
It is very kind of you to point out some idea about MAP_FIXED for
Blackfin arch, I will do some help for this.
Right now, my understanding is that nommu archs just reject MAP_FIXED
outright...
On Mon, 2007-02-19 at 19:43 +0100, Arjan van de Ven wrote:
On Mon, 2007-02-19 at 10:31 -0800, Adam Litke wrote:
The page tables for hugetlb mappings are handled differently than page
tables
for normal pages. Rather than integrating multiple page size support into
the
main VM (which
maybe. I'm not entirely convinced... (I like the cleanup potential a lot
code wise.. but if it costs performance, then... well I'd hate to see
linux get slower for hugetlbfs)
If not, then I definitely wouldn't
mind creating a default_pagetable_ops and calling into that.
... but
Actually, Ben did you determine if this scheme works for your device
which has a single interrupt source yet multiple queues? There is one
driver that, during the conversion, I noticed has a similar issue.
One driver, netxen, has multiple channels, so it just passes in
bugdet / NUM_CHANNELS
On Sun, 2007-02-25 at 20:17 -0500, David Woodhouse wrote:
On Sun, 2007-02-25 at 16:24 -0800, Linus Torvalds wrote:
Hmm. No, I don't think that should be a problem. free_initmem() only
happens at the very, after do_basic_setup() has been run, which
includes all the initcall stuff.
I'm
On Sun, 2007-02-25 at 23:01 -0500, David Woodhouse wrote:
Yeah, I did that before giving up on it for the day and going in search
of dinner. It changes the failure mode to a BUG() in
cache_free_debugcheck(), at line 2876 of mm/slab.c
It smells like the pages weren't actually reserved in the
USB controller issues? We used to have these really hard-to-debug problems
with the USB controller being active and having had the BIOS set up the
command queues etc. Really subtle. It's why we now have PCI quirks for
shutting up (most) USB controllers very early.
On powermacs or
the new fault hander made the memory manager code a lot cleaner and
very less hacky in a lot of cases. so I'd rather merge the clean code
than have to fight with the current code...
Note that you can probably get away with NOPFN_REFAULT etc... like I did
for the SPEs in the meantime.
Ben.
I've not been able to reproduce it since, but I know others (BCC'ed on
this note) have seen it and might prod them to come forth with details
(and broken .config files)
In my case, disabling CPU_FREQ_PMAC made the failure go away.
After reverting this patch, CPU_FREQ_PMAC is once again
On Mon, 2007-02-26 at 17:00 +0100, Jan-Bernd Themann wrote:
Hi!
This patch replaces the former posted patch
([PATCH] ehea: Optional TX/RX path optimized for SMP) and provides
a functionality that allows parallel RX processing on multiple RX
queues by using dummy netdevices as proposed by
It's most likely a red herring, lots of config changes
make the bug go away on some kernel versions (but not
on others); the problem is very sensitive to changes in
memory layout.
I wouldn't be that sure ... I've had problems in the past with PMU based
cpufreq... looks like flushing all
What I really object to is not the irq numbers. As an arbitrary number
does not impose limits. What I object to is drivers that can't handle the
full range of numbers, and the limits imposed upon those numbers when
you require them to be indexes into an array.
For talking to user space I
Similarly, in a pci device, one could imagine that the
struct pci_driver contains a irq_handler_t member that
is registered from the pci_device_probe() function
if present.
Yes. There is some potential there. Although we would have to go
through an extra hoop to make it a pci
On Sat, 2007-03-03 at 04:06 +0100, Andi Kleen wrote:
Jan-Bernd Themann [EMAIL PROTECTED] writes:
Are there any concerns about this approach?
Yes. You should fix the NAPI code instead of trying to work
around it.
NAPI is being fixed but the fix will take time to get in. In the
meantime,
Ok, maybe I have lots of shit in my eyes but it looks like get_order
in asm-generic/page.h is broken.
AFAIK, get_order() should round up (and we have code here or there
assuming such).
However, it seems to assume that ilog2 rounds up, which it doesn't. It
rounds down. At least the generic
NOPAGE_REFAULT is removed. This should be implemented with -fault, and
no users have hit mainline yet.
Did benh agree with that?
I won't use NOPAGE_REFAULT, I use NOPFN_REFAULT and that has hit
mainline. I will switch to -fault when I have time to adapt the code,
in the meantime,
On Wed, 2007-03-07 at 10:16 +0100, Ingo Molnar wrote:
* Tsutomu OWA [EMAIL PROTECTED] wrote:
@@ -342,6 +342,7 @@ static int xmon_core(struct pt_regs *reg
msr = mfmsr();
mtmsr(msr ~MSR_EE); /* disable interrupts */
+ preempt_disable();
i'm not an xmon expert, but
On Tue, 2007-03-06 at 20:59 -0800, Linus Torvalds wrote:
Linus Torvalds (2):
Revert [PATCH] LOG2: Alter get_order() so that it can make use of
ilog2() on a constant
Linux 2.6.21-rc3
Greg, I think we should revert that patch in 2.6.20.x stable serie too
as get_order is broken
On Wed, 2007-03-07 at 11:17 +0100, Nick Piggin wrote:
On Wed, Mar 07, 2007 at 11:05:48AM +0100, Benjamin Herrenschmidt wrote:
NOPAGE_REFAULT is removed. This should be implemented with -fault, and
no users have hit mainline yet.
Did benh agree with that?
I won't use
On Wed, 2007-03-07 at 17:53 +1300, Paul Collins wrote:
David Woodhouse [EMAIL PROTECTED] writes:
On Tue, 2007-03-06 at 14:53 +1300, Paul Collins wrote:
In case it's of interest, 2.6.20 has been running fine on my
PowerBook5,4.
How much memory? What if you boot with mem=512M or
On Wed, 2007-03-07 at 17:38 +0300, Sergei Shtylyov wrote:
Hello.
Tsutomu OWA wrote:
--- linux-rt8/arch/powerpc/kernel/irq.c 2007-02-20 14:30:38.0
+0900
+++ rt/arch/powerpc/kernel/irq.c2007-03-05 18:54:34.0 +0900
@@ -392,7 +392,7 @@ EXPORT_SYMBOL(do_softirq);
On Wed, 2007-03-07 at 07:39 -0800, Linus Torvalds wrote:
On Wed, 7 Mar 2007, Benjamin Herrenschmidt wrote:
On Tue, 2007-03-06 at 20:59 -0800, Linus Torvalds wrote:
Linus Torvalds (2):
Revert [PATCH] LOG2: Alter get_order() so that it can make use of
ilog2() on a constant
On Wed, 2007-03-07 at 21:52 +0100, Arnd Bergmann wrote:
On Wednesday 07 March 2007 16:39:00 Linus Torvalds wrote:
So did you hunt it down to a particular cases where it triggers?
IIRC, it crashed on boot in the powerpc iommu code when slab
debugging is enabled. Not sure if it was on Cell or
On Tue, 2007-04-03 at 20:12 -0400, David Woodhouse wrote:
On Tue, 2007-04-03 at 17:02 -0700, David Miller wrote:
Sparc does the same thing, it's a common convention and you really
should not break it.
I thought that argument was lost many years ago. It _used_ to be a
common convention; we
On Tue, 2007-04-03 at 16:56 -0700, David Miller wrote:
From: David Woodhouse [EMAIL PROTECTED]
Date: Tue, 03 Apr 2007 19:28:36 -0400
Abusing the 8250 device numbers prevents the 8250 module from being
loaded at the same time as pmac_zilog, and means you can't have both
internal port and
On Tue, 2007-04-03 at 18:17 -0700, David Miller wrote:
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Wed, 04 Apr 2007 11:13:12 +1000
It worked before the new serial core, we had a tweak in the old 8250
driver to be able to share minors, but that got busted when Russell
rewrote
This is a first step as there are still cleanups to be done in various
areas touched by that code but I think it's probably good to go as is and
at least enables me to implement what I need for PowerPC.
The current get_unmapped_area code calls the f_ops-get_unmapped_area or
the arch one (via the
This also fixes a bug, I think, it used to return a pgoff (pfn)
instead of an address. (To split ?)
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/char/mem.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/drivers/char/mem.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
mm/mmap.c | 16
1 file changed, 16 deletions(-)
Index: linux-cell/mm/mmap.c
===
--- linux-cell.orig/mm/mmap.c 2007-03-22 16:30:24.0 +1100
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
fs/hugetlbfs/inode.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/fs/hugetlbfs/inode.c
===
--- linux-cell.orig/fs/hugetlbfs/inode.c2007-03-22
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
fs/ramfs/file-nommu.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/fs/ramfs/file-nommu.c
===
--- linux-cell.orig/fs/ramfs/file-nommu.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/frv/mm/elf-fdpic.c |4
1 file changed, 4 insertions(+)
Index: linux-cell/arch/frv/mm/elf-fdpic.c
===
--- linux-cell.orig/arch/frv/mm/elf-fdpic.c 2007-03
This also fixes a bug, I think, it used to return a pgoff (pfn)
instead of an address. (To split ?)
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/char/mem.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/drivers/char/mem.c
and change the caller now that everybody can handle it.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
mm/mmap.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
Index: linux-cell/mm/mmap.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/x86_64/kernel/sys_x86_64.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/x86_64/kernel/sys_x86_64.c
===
--- linux-cell.orig/arch/x86_64/kernel
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/parisc/kernel/sys_parisc.c |5 +
1 file changed, 5 insertions(+)
Index: linux-cell/arch/parisc/kernel/sys_parisc.c
===
--- linux-cell.orig/arch/parisc/kernel
On Wed, 2007-04-04 at 14:01 +1000, Benjamin Herrenschmidt wrote:
This is a first step as there are still cleanups to be done in various
areas touched by that code but I think it's probably good to go as is and
at least enables me to implement what I need for PowerPC.
.../...
And sorry
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/sparc64/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/sparc64/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/sparc64/mm
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/ia64/kernel/sys_ia64.c |7 +++
arch/ia64/mm/hugetlbpage.c |8
2 files changed, 15 insertions(+)
Index: linux-cell/arch/ia64/kernel/sys_ia64.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/i386/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/i386/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/i386/mm/hugetlbpage.c
This is a first step as there are still cleanups to be done in various
areas touched by that code but I think it's probably good to go as is and
at least enables me to implement what I need for PowerPC.
The current get_unmapped_area code calls the f_ops-get_unmapped_area or
the arch one (via the
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/powerpc/mm/hugetlbpage.c | 21 +
1 file changed, 21 insertions(+)
Index: linux-cell/arch/powerpc/mm/hugetlbpage.c
===
--- linux-cell.orig/arch
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/alpha/kernel/osf_sys.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/alpha/kernel/osf_sys.c
===
--- linux-cell.orig/arch/alpha/kernel/osf_sys.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/arm/mm/mmap.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-cell/arch/arm/mm/mmap.c
===
--- linux-cell.orig/arch/arm/mm/mmap.c 2007-03-22
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/frv/mm/elf-fdpic.c |4
1 file changed, 4 insertions(+)
Index: linux-cell/arch/frv/mm/elf-fdpic.c
===
--- linux-cell.orig/arch/frv/mm/elf-fdpic.c 2007-03
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/alpha/kernel/osf_sys.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/alpha/kernel/osf_sys.c
===
--- linux-cell.orig/arch/alpha/kernel/osf_sys.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/arm/mm/mmap.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-cell/arch/arm/mm/mmap.c
===
--- linux-cell.orig/arch/arm/mm/mmap.c 2007-03-22
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/powerpc/mm/hugetlbpage.c | 21 +
1 file changed, 21 insertions(+)
Index: linux-cell/arch/powerpc/mm/hugetlbpage.c
===
--- linux-cell.orig/arch
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
fs/ramfs/file-nommu.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/fs/ramfs/file-nommu.c
===
--- linux-cell.orig/fs/ramfs/file-nommu.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
fs/hugetlbfs/inode.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/fs/hugetlbfs/inode.c
===
--- linux-cell.orig/fs/hugetlbfs/inode.c2007-03-22
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/x86_64/kernel/sys_x86_64.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/x86_64/kernel/sys_x86_64.c
===
--- linux-cell.orig/arch/x86_64/kernel
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/parisc/kernel/sys_parisc.c |5 +
1 file changed, 5 insertions(+)
Index: linux-cell/arch/parisc/kernel/sys_parisc.c
===
--- linux-cell.orig/arch/parisc/kernel
101 - 200 of 5350 matches
Mail list logo
