http://bugme.osdl.org/show_bug.cgi?id=3077 Some IRDA chipsets currently don't work on x86-64, because they're dependent on CONFIG_ISA and x86-64 doesn't set this. CONFIG_ISA means real ISA slots, and
I was because those driver were using isa_virt_to_bus. I think we can drop that now, but I don't have the problematic architecture. Well, I guess we will learn soon enough :-( Feel free to send that
I don't think so. I did most of the original CONFIG_ISA annotations and I only added it to real ISA devices. And the LPC devices in southbridges are normally not marked CONFIG_ISA. There is great val
Andi Kleen wrote: On Thu, Jul 15, 2004 at 12:48:07PM -0400, Jeff Garzik wrote: And with legacy ISA devices still around, I don't see a whole lot of value in differentiating between "I have ISA slots"
They should be already aware that most ISA drivers are just not maintained anymore and very likely broken. I doubt there is any bug hunter or maintainer who is not aware of this fact. There are no x8
Andy, I never said that, please quote me accurately. I personally don't have strong opinions on whether those drivers should be tagged with CONFIG_ISA or not, but those hardware are definitely mapped
Hmm, good point. !64BIT is not needed - apparently they are 64bit clean. The reason I want to drop the CONFIG_ISA depency is that they *should* be built on x86-64 too. -Andi
I think you are right - however, AFAICS this is not the point in this case. These drivers do DMA to legacy devices (call it ISA, LPC, whatever). The documented way for those devices without struct pc
More likely on LPC interface. And not on a ISA slot. Anyways, if you want them to work on x86-64 you will have to drop that bogus dependency. I have no plans to ever define CONFIG_ISA on x86-64. -And
There was at least one user report that at least one driver worked with CONFIG_ISA force defined. The old pci_alloc_coherent supported hwdev == NULL under x86-64. dma_alloc_consistent() should too. I
Andi Kleen wrote: http://bugme.osdl.org/show_bug.cgi?id=3077 Some IRDA chipsets currently don't work on x86-64, because they're dependent on CONFIG_ISA and x86-64 doesn't set this. CONFIG_ISA means r
Ok, so maybe the following is missing in addition to Andi's patch? Martin -- -- linux-2.6.8-rc1/net/irda/irda_device.c Tue Jul 13 00:31:34 2004 +++ v2.6.8-rc1-md/net/irda/irda_device.c Fri Jul 16 00:
Admittedly I haven't tried either, but I'm pretty sure this patch will break building those drivers because they are calling irda_setup_dma - which is CONFIG_ISA. Maybe this can be dropped but I don'
Ok, thanks. This sounds like the right solution. I think most/all functions in include/asm-generic/dma-mapping.h are not prepared to accept dev=NULL parameters, so it's a bit more than just dma_alloc
http://bugme.osdl.org/show_bug.cgi?id=3077 Some IRDA chipsets currently don't work on x86-64, because they're dependent on CONFIG_ISA and x86-64 doesn't set this. CONFIG_ISA means real ISA slots, and
I was because those driver were using isa_virt_to_bus. I think we can drop that now, but I don't have the problematic architecture. Well, I guess we will learn soon enough :-( Feel free to send that
I don't think so. I did most of the original CONFIG_ISA annotations and I only added it to real ISA devices. And the LPC devices in southbridges are normally not marked CONFIG_ISA. There is great val
Andi Kleen wrote: On Thu, Jul 15, 2004 at 12:48:07PM -0400, Jeff Garzik wrote: And with legacy ISA devices still around, I don't see a whole lot of value in differentiating between "I have ISA slots"
They should be already aware that most ISA drivers are just not maintained anymore and very likely broken. I doubt there is any bug hunter or maintainer who is not aware of this fact. There are no x8