Hi !
I've read the discussion about the truncate() problem and tried to
understand ;) However, there's somethign I don't catch in your code (typo
? bug ? misunderstanding on my side ?)
Linus wrote:
There's a really simple way to avoid this: compare the thing you're going
to zero out against
Can somebody please tell me, who is currently maintaining
arch/ppc?
The link
http://www.ppc.kernel.org/
in the MAINTAINERS file is dead.
Cort Dougan ([EMAIL PROTECTED]) and Paul Mackerras ([EMAIL PROTECTED])
There's also a SourceForge site recently created to gather pending
patches and bug
Hmm, good idea, but how does this work on, say, non-x86 architectures
which don't have a VGA text frame buffer, or whose VGA text frame buffer
is not mapped in, or whose VGA text frame buffer is not initialised.
You will still end up with those "my kernel hangs during boot" messages.
A lot of
2.4 and 2.2 PPC have progress() for writing progress messages to the
screen. They're setup in a per-board very early in the boot so we can see
what's going on as soon as the MMU is turned on and lets us get around.
Ben, can you just make your changes talk through that? I used to use it
with
Hi !
Is any arch other than PPC using include/linux/openpic.h ?
I'm doing some cleanup work on various parts of the PPC arch, and it's
now time for the openpic driver to suffer. That file exports to everybody
all the functions data structures of the driver, which is wrong with
the way the
2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) :
extern void __bad_udelay(void);
#define udelay(n) (__builtin_constant_p(n) ? \
((n) 2 ? __bad_udelay() : __const_udelay((n) *
0x10c6ul)) : \
__udelay(n))
...
It seems __bad_udelay is not defined
Well, at first, I wanted to implement it the same way on PPC. However, it
dies on all occurences where udelay is called with a non-constant expression.
I spotted this case in a few PPC specific stuffs (fixable), but also in
the sys_nanosleep code, and in the de4x5 driver.
Hrm... looks like I
Well, at first, I wanted to implement it the same way on PPC. However, it
dies on all occurences where udelay is called with a non-constant
expression.
__builtin_constant_p means non constant expressions will always call udelay
I spotted this case in a few PPC specific stuffs (fixable),
Yep. This is a huge release patch anyway so resynching the stuff is fine.
What I wont take is stuff touching core code
I do have a 2 lines patch to the common ide code that fix a problem when
revalidating a CD-ROM after sleep, but it was ack'ed by Andre Hedrick. I
also have a two-liners to
Hi !
Sorry if this have already been the cause of a flamewar on the list, but...
I need to compile an app with the 2.4 kernel headers glibc (our stable
glibc on PPC is based on 2.1.3). However, the compiler is barking on a
change done in 2.4 version of include/linux/fs.h:
The 2.2.x version
- I mean, it's legal to include linux/fs.h from userland,
Everybody who thinks so will be severely disappointed.
Ok, so if it's not, then I have to fix that app. Thanks.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Note to linux-kenrel readers: This discussion is the Nth attempt to find
a solution to handle both legacy IOs and PCI IOs on machines with several
IO busses memory mapped at different locations in the CPU space.
No please, is there anybody bloat-conscious on this damned list ? Burying
more and
. (There might still be
problems with VGA vs. parallell, I don't know x86 world well enough to be
sure).
Ben.
-- RFC822 Header Follows --
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
To: Gabriel Paubert [EMAIL PROTECTED], Linux/PowerPC Devel List
[EMAIL PROTEC
Apple sells a computer with dual AGP slots. I just was looking for a intel
box like this. Since AGP is a port on the PCI bus it is possible to have
more than one AGP port on a/each PCI bus but this requires the PCI chipset
to support this.
Well, I don't know of such a Mac. To my knowledge, the
Here's the return of an ld problem for which we really need a
solution asap since it's now biting us in real life configurations...
So the problem happens when you have a machine with more than one PCI
host bridge. This is typically the case of all new Apple machines as they
have 3 host
If we want to go a bit further, and allow ISA drivers that don't have a
pci_dev structure to work on legacy devices on any bus, we could provide
a set of function of the type
int isa_get_bus_count();
unsigned long isa_get_bus_io_offset(int busno);
I would add that I'd prefer to keep it
As a side note, Alpha has a special PCI syscall to get the "PCI
controller number" a given PCI device is behind. We could add
another ioctl number which does the same thing on /proc/bus/pci/*/*
nodes. This way sparc64 and Alpha could have the same user visible
API for this as well.
And on PPC
I'm, of course open to any comments about this (in fact, I'd really like
some feedback). One thing is that we also need to find a way to pass
those infos to userland. Currently, we implement an arch-specific syscall
that allow to retreive the IO physical base of a given PCI bus. That may
I do not want an interface where the user still has to do
grotty stuff like mmap() on /dev/{mem,kmem}, this was the
core of the problem I had with the syscall idea, don't bring
it back.
Make mmap()'s on a PCI--ISA bridge do something special, for
example.
The user doesn't need to know anything
Here are my comments directly responding to your mail.
Hi ! Thanks for taking the time to respond in details.
Large systems have problems with I/O port space and legacy devices.
There just isn't enough I/O port space to support large configs
and ISA aliasing and all the other crud. That's why
No, don't do this, it is evil. Use mappings, specify the device
related info somehow when creating the mapping (in the userspace
variant you do this by openning a specific device to mmap, in the
kernel variant you can encode the bus/dev/etc. info in the device's
resource and decode this at
Hi Linus !
I've some questions regarding the behaviour of arch/i386/kernel/irq.c
regarding IRQ_PENDING and IRQ_REPLAY.
Especially, my question is about the code in enable_irq() which checks
for IRQ_PENDING, and then
"replays" the interrupt by asking the APIC to issue it again.
I don't have a
I/O is not supposed to be fast, that's what MMIO is for. :) Just do
void outb (u8 val, u16 addr)
{
void *addr = ioremap (ISA_IO_BASE + addr);
if (addr) {
writeb (val, addr);
iounmap (addr);
}
}
You can map and unmap for each call :) Ugly and
In particular, if an edge-triggered interrupt comes in on an x86 IO-APIC
while that interrupt is disabled, enabling the interrupt will have caused
that irq to get dropped. And if it gets dropped, it will never ever happen
again: the interrupt line is now active, and there will never be another
So once again I vote for the introduction of
isa_{request,release}_mem_region(), just like we already have isa_readb() and
friends.
Well, it's the same problem as the IO, there may be more than one ISA mem
region,
especially when you put 2 video cards on 2 different PCI hosts (even without a
We do have broken interrupt controllers in this respect. We already have a
way of handling it. Ben, take a look at set_lost().
Heh, I know, thanks ;)
However, our current scheme implies a hack to __sti() that I'd like to get
rid of since it adds an overhead allover the place that could
More generic in terms of using irq_desc[] and some similar structures I can
see. Making do_IRQ() and enable/disable use the same names and structures
as x86 isn't sensible. They're different ports, with different design
philosophies.
I don't believe that the plan is a common irq.c - lets stay
handled correctly, does nothing more than what we need (well it does, but
those parts,
mostly the irq locking, got already removed), etc...
Sorry, I meant mostly the irq probing
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
And I seriously doubt that PPC SMP irq handling has gotten _nearly_ the
amount of testing and hard work that the x86 counterpart has. Things
like support for CPU affinity, per-irq spinlocks, etc etc.
Some of those are the reason I moved part of the x86 irq.c code to PPC
indeed.
Now, I'm not
We have about 12 interrupt controllers we end up using on PPC. I'm
suspicious of any effort to base Linux/PPC generic interrupt control code
paths on a software architecture that's been tested with 3. More to the
point, we get ASIC's that roll in a standard interrupt controller and add
some
I'm working on improving some aspects of Power Management on the
PowerBooks, and among other things, I have a problem with fbdevs.
Currently, each fbdev registers a power management callback to sleep/
wakeup the device. We handle HW related things (shutting the backlight
off, putting the chip to
I think registering fbcon as a PM client and doing the above when the
fbdev suspend/resume hooks are called should work. A memory backup is
worked on until the resume is run and the backup is restored to the
display.
So the fbdev drivers would register PM with fbcon, not PCI, correct?
Either
Now for fbcon its simpler. Things get writing to the shadow buffer
(vc_screenbuf). When the console gets woken up update_screen is called.
While power down the shadow buffer can be written to which is much faster
than saving a image of the framebuffer. Of course if you still want to do
this
Have a look at:
http://www.scs.ch/~frey/linux/kernelthreads.html
I have an example there that starts and stops kernel threads
from init_module and never produced a zombie.
I use the same code also to start threads from ioctl and it
works for me. I tested it on UP and SMP, Intel and Alpha,
2.2.18
The stuff done in daemonize() and the exit_files could need
the kernel lock. At least on some 2.2.x version it does,
I did not check whether it is still needed on 2.4.
Well, I don't really plan to backport this to 2.2.x. I'll
try to see if my problem is related to the lack of kernel
lock, or
No, pci_read_bridge_bases() is obsoleted by new pci setup code. ;-)
You have to set up bus resources properly in pcibios_fixup_bus().
For a single root bus configuration, you don't need to do anything
with the root bus itself - its resources already point to ioport_resource
and iomem_resource,
Begin Forwarded Message
Subject: kernel oops with rm in hfs - hit BUG() in line 236 of dcache.h
Date Sent: Sunday, December 10, 2000 12:56 AM
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
PowerCenter Pro 210mhz 604e,
--- atyfb.cMon Dec 11 14:28:19 2000
+++ atyfb.c.orig Wed Oct 4 22:22:28 2000
@@ -2796,7 +2796,7 @@
* works on iMacs as well as the G3 powerbooks. - paulus
*/
if (default_vmode == VMODE_CHOOSE) {
- if ((Gx == LG_CHIP_ID)||(Gx == LI_CHIP_ID)||(Gx == LP_CHIP_ID))
+
I have a 29160N card in a PowerMac G4. It used to work fine with an old
UW SCSI disk I had there. Today, I flipped this drive with a real
Ultra160 one , and now, the kernel won't boot. It's giving me an endless
stream of SCSI reset timeouts on bus 0.
Any clue ? I don't really need this disk in
Anything I can do to help tracking the problem ? It's difficult to get
the actual output of the driver in verbose mode as it is scrolling quite
fast and I have nothing like a serial console on this box. The kernel
won't boot without noprobe so I can't dump dmesg output.
I was wrong, even
Ben.
-- RFC822 Header Follows --
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
To: Martin Mares [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI
resourcecollisions (fwd)
Date: Thu, 26 Oct 2000 14:3
On Wed, 8 Nov 2000, Andre Hedrick wrote:
What is your chipset, CMD646 rev 5 Ultra DMA 33 ???
Yep. I've tried building with the CMD64x driver, and that didn't help
matters, if you were wondering. Any thoughts?
Did you try the bitkeeper PPC kernel ? (or Paul Mackerras rsync tree ?)
Not all PPC
One way to do this is to treat PCI IO and ISA IO as two separate
address spaces. The PCI IO address space is a 14-bit address space
(bits 9:8 are always zero) ranging from 0x1000 to 0xFCFF. ISA IO is a
10-bit space (bits 15:10 are available for the card to use) ranging
from 0x100 to 0x3FF.
Hi ! Glad to see things moving around Power Management ;)
This was originally a private reply to Patrick Mochel, but the e-mail
kept getting longer and longer :)
Note: we have setup a list for PM issues
http://lists.sourceforge.net/lists/listinfo/linux-pm-devel
Not very much used yet, but I,
Hi ! Glad to see things moving around Power Management ;)
This was originally a private reply to Patrick Mochel, but the e-mail
kept getting longer and longer :)
Note: we have setup a list for PM issues
http://lists.sourceforge.net/lists/listinfo/linux-pm-devel
Not very much used yet, but I,
On Thu, Apr 19, 2001 at 11:19:31AM +0100, Benjamin Herrenschmidt wrote:
Hi ! Glad to see things moving around Power Management ;)
This was originally a private reply to Patrick Mochel, but the e-mail
kept getting longer and longer :)
Note: we have setup a list for PM issues
http
- Some devices just can't be brought back to life from D3 state without
a PCI reset (ATI Rage M3 for example) and that require some arch specific
support (when it's possible at all).
Putting on a driver author hat what I want is
pci_power_on_generic
pci_power_off_generic
null = 'do absolutely nothing'
generic = 'do D3 as per the specification'
The idea being the PM layer would go around calling
dev-power_off(dev);
as a default notifier for PCI devices.
Ok, I see. I didn't understand that the functions you were talking about
would be defaults to put
All devices should handle having power removed from them. And, all of the
drivers should as well, since that is the only way we're going to get
power management out of legacy devices and other things on the board. This
involves saving the current context on suspend, and reinitializing the
device,
Some devices (bad bad HW designers ;) just can't do it themselves. The
Rage M3 requires the host to assert PCI RST#, and some motherboards
provide no documented facility for that (it might be possible with Apple
ASICs for example, it's just not documented).
Why should we support such a
I would suggest the opposite approach instead: make the PPC just support
isa_readx/isa_writex instead.
We can certainly do that, no problem.
BUT that won't get a token ring pcmcia card working in the newer
powerbooks, such as the titanium G4 powerbook, because the PCI host
bridge doesn't map
Hi !
Would it make sense to add a
pcibios_disable_device(pci_dev*) called from the end of
pci_disable_device() ?
I'm adding a call to it to sungem along with other pmac stuffs
so that the chip can be properly power down (actually it's not
really powered down but unclocked) after module
It's funny you mention this because I have been working on something
similar recently. Basically making xfree86 int10 and VGA poking happy
on sparc64.
Heh, world is small ;)
But this has no real use in the kernel. (actually I take this back,
read below)
yup, fbcon at least...
You have a
Its not clutter -- what you are doing is hiding pieces of the driver
from the driver maintainer. pcibios_enable_device should not be
cluttered up with such mess, too.
Well... pcibios_enable_device() has to at least make sure the device
gets powered up as it's powered down after PCI probe.
I've had a deadlock twice with 2.4.6pre6 today. It's an SMP kernel
running on an UP box (a PowerBook Pismo).
The deadlock happen in the HFS filesystem in hfs_cat_put(), apparently
(quickly looking at addresses) in spin_lock().
I don't have the complete backtrace at hand right now, but it
Last time I checked, ioremap didn't work for inb() and outb().
It should :)
it doesnt need to.
pci_find_device returns the io address and can return a cookie, ditto
isapnp etc
Yes, but doing that require 2 annoying things:
- Parsing of this cookie on each inx/outx access, which can
Last time I checked, ioremap didn't work for inb() and outb().
ioremap itself cannot work for inb/outb as they are different
address spaces with potentially overlapping addresses, I don't
see how a single function would handle both... except if we
pass it a struct resource instead of the
Nope.
I do not want to maintain two interfaces. If we make user space the way to
do these things, then we will do pretty much most of the driver setup etc
in user space. We'd have to: we'd enter user space before drivers have had
a chance to initialize, exactly because features like these can
Hi Andre !
Any reason other than usual programmer "too many things to remember" for
2.4 lacking the small ide_revalidate_disk() fix we did recently in 2.2 to
keep the blocksize of the device intact ? (Just diff the 2 functions,
it's pretty obvious)
I'd be glad to send Linus a patch, but I
I have RTFM but on the matter of enabling DRI for the
ATI Mobility video chipset, which on that notebook is
a PCI model, there is practically nil information. The
DRI website mentions using PCI GART, but there is no
option for that in the kernel. How do I enable this?
You need to get
daemonize() makes calls that are all protected with the
big kernel lock in do_exit(). All usages of daemonize have
the big kernel lock held. So I guess it just needs it.
Please let me know whether you have success if it makes
a difference with having it held.
With a bit more experiments, I have
There is a problem with the power management code for console.c
The current code calls do_blank_screen(0); on PM_SUSPEND, and
unblank_screen() on PM_RESUME.
The problem happens when X is the current display while putting the
machine to sleep. The do_blank_screen(0) code will do nothing as
the
Hi Linus !
Enclosed is a (not big ;) patch against 2.4.4pre1 that does a few
inter-dependant things, one beeing a bug fix for everybody, the other
is a mix of bug fix cleanup on PPC:
- binfmt_elf.c : fix DLINFO_ITEMS so that final alignement on the
stack takes into account the AT_NULL
Hi Linus !
Enclosed is a (not big ;) patch against 2.4.4pre1 that does a few
inter-dependant things, one beeing a bug fix for everybody, the other
is a mix of bug fix cleanup on PPC:
- binfmt_elf.c : fix DLINFO_ITEMS so that final alignement on the
stack takes into account the AT_NULL
Looks OK - there's no way of stopping the kernel thread anyway.
It appears that nobody has tried to use this driver at the same time as
software-suspend. At least, not successfully. A strategic try_to_freeze()
should fix it.
This will become (a little) more serious when cpu hotplug is
On Thu, 2007-04-19 at 16:37 -0700, Andrew Morton wrote:
On Thu, 19 Apr 2007 01:58:48 -0600
Eric W. Biederman [EMAIL PROTECTED] wrote:
Start the g4fand using kthread_run not a combination
of kernel_thread and deamonize. This makes the code
a little simpler and more maintainable.
I had
The only reason for using threads here is to get the error recovery
out of an interrupt context (where errors may be detected), and then,
an hour later, decrement a counter (which is how we limit these to
6 per hour). Thread reaping is trivial, the thread just exits
after an hour.
In
On Mon, 2007-04-23 at 20:08 -0600, Eric W. Biederman wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
The only reason for using threads here is to get the error recovery
out of an interrupt context (where errors may be detected), and then,
an hour later, decrement a counter (which
Further in general it doesn't make sense to grab a module reference
and call that sufficient because we would like to request that the
module exits.
Which is, btw, I think a total misdesign of our module stuff, but heh, I
remember that lead to some flamewars back then...
Like anything else,
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 powerpc's arch_get_unmapped_area() in all 3
implementations of it.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Acked-by: William Irwin [EMAIL PROTECTED]
arch/powerpc/mm/hugetlbpage.c | 21 +
1 file changed, 21 insertions(+)
Index: linux
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
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
Generic hugetlb_get_unmapped_area() now handles MAP_FIXED by just
calling prepare_hugepage_range()
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Acked-by: William Irwin [EMAIL PROTECTED]
fs/hugetlbfs/inode.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/fs
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]
Acked-by: William Irwin [EMAIL PROTECTED]
mm/mmap.c | 16
1 file changed, 16
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]
Acked-by: William Irwin [EMAIL PROTECTED]
arch/sparc64/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch
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]
Acked-by: William Irwin [EMAIL PROTECTED]
arch/ia64/kernel/sys_ia64
Handle MAP_FIXED in i386 hugetlb_get_unmapped_area(), just call
prepare_hugepage_range.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Acked-by: William Irwin [EMAIL PROTECTED]
arch/i386/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/i386/mm
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
- radeonfb_pm_init(rinfo, rinfo-is_mobility ? 1 : -1,
ignore_devlist, force_sleep);
+ radeonfb_pm_init(rinfo, rinfo-is_mobility rinfo-family !=
CHIP_FAMILY_RS480 ? 1 : -1, ignore_devlist, force_sleep);
I'd rather you add a check for RS480 inside radeonfb_pm_*
Ben.
.../...
Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Nice catch !
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -476,8 +476,13 @@ void flush_thread(void)
#ifdef CONFIG_PPC64
struct thread_info
On Fri, 2007-03-09 at 17:11 +0100, Andi Kleen wrote:
David Woodhouse [EMAIL PROTECTED] writes:
Most system calls seem to get added to i386 first. This patch
automatically generates a warning for any new system call which is
implemented on i386 but not the architecture currently being
Hmm. The crash came back after I booted into Mac OS X and back. It was however
a different crash, I believe it was coming from the USB modules (as it would
keep going when it happened, and get another crash, which tended to scroll
away
too fast for me to capture) but I believe it was still
On Thu, 2007-03-15 at 17:30 +0300, Sergei Shtylyov wrote:
Hello.
Akira Iguchi wrote:
It's bool and it depends on BLK_DEV_IDE
= should depend on BLK_DEV_IDE=y
Hm, why I'm seeing module_init() in the driver? :-)
And move it to if BLK_DEV_IDEDMA_PCI block because it depends on
On Sat, 2007-02-10 at 20:16 +0100, Stefan Richter wrote:
[ohci1394_early]
Some remarks to the September 2006 version at
http://www.suse.de/~bk/firewire/ :
- Seems its .remove won't work properly if more than one OHCI-1394
controller is installed. And it's .probe isn't reentrant,
really need to be done -that- early.
Applogies for not catching the breakage earlier, Roland _did_ CC me on
his patches a while ago, I got busy with other things and forgot to test
them.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Index: linux-work/arch/powerpc/kernel/vdso.c
On Mon, 2007-02-12 at 07:49 +0100, Andi Kleen wrote:
On Sunday 11 February 2007 22:35, Benjamin Herrenschmidt wrote:
I'd like to have that on ppc as well, so I'd rather keep it in drivers/
This will need some abstraction at least -- there are some early mapping hacks
that are x86 specific
On Wed, 2007-02-14 at 19:17 +0900, Paul Mundt wrote:
On Wed, Feb 14, 2007 at 11:02:06AM +0100, Geert Uytterhoeven wrote:
On Wed, 14 Feb 2007, Paul Mundt wrote:
This would seem like a reasonable candidate for a 'depends on' instead of
a select..
That's what we originally had. But for
On Fri, 2007-02-16 at 05:10 -0700, Eric W. Biederman wrote:
Getting the drivers changed actually looks to be pretty straight
forward it will just be a very large mechanical change. We change the
type where of variables where appropriate and every once in a while
introduce an irq_nr(irq) to
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 be dynamically
allocated instead of statically allocated
Rather than having the job of rewriting this code during 2.6, I'd much
prefer to get something sorted, even if it is ARM only before 2.6.
I believe that there are some common problems with the existing API
which have been hinted at over the last few days, such as large
NR_IRQS. As
On Sat, 2007-02-17 at 02:37 +0100, Arnd Bergmann wrote:
On Friday 16 February 2007 23:37, Benjamin Herrenschmidt wrote:
You might want to have a look at the powerpc API with it's remaping
capabilities. It's very nice for handling multiple domain spaces. It
might be of some use for you.
I
No. I don't think we should make your irq_hwnumber_t thingy general
because it is not general. I don't understand why you need it to be
an unsigned long, that still puzzles me. But for the rest it actually
appears that ppc has a simpler model to deal with.
I think you might have
On Sat, 2007-02-17 at 02:06 -0700, Eric W. Biederman wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
In addition, if we remove the numbers, archs will need basically the
exact same services provided by the powerpc irq core for reverse mapping
(going from a HW irq number on a given
#define NO_IRQ architecture-defined-int-constant
When did you need a magic constant NO_IRQ in generic code.
One of the reasons I want to convert the drivers is so we can
kill the NO_IRQ nonsense.
As for struct irq. Instead of struct irq_desc I really don't
care, although the C++
On Sat, 2007-02-17 at 17:28 +0100, Hoang-Nam Nguyen wrote:
ibmebus has a fake root device that's not associated with an ofdt node.
Filter out any such devices in of_device_uevent().
Doh ! You are creating an of_device with no attached device-node ? That
is totally evil ! Why do you need that ?
On Sat, 2007-02-17 at 19:21 -0500, Joachim Fenkes wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote on 17.02.2007
16:56:39:
On Sat, 2007-02-17 at 17:28 +0100, Hoang-Nam Nguyen wrote:
ibmebus has a fake root device that's not associated with an ofdt
node.
Filter out any
1 - 100 of 5350 matches
Mail list logo
