On Sun, Apr 06, 2003 at 09:37:41PM -0400, Peter Petrakis wrote: > > > >The patch is -not- supposed to be used against the one provided > >by the kernel. Go to their website and install that version and patch > >-that-. It should apply just fine.
I can only get http://www.icp-vortex.com/german/download/rprd/linux/linux_d.htm, the driver from that location is from 2002 (Version 2.0.3); if I apply your patch, it seems to fail at the same positions as the kernel driver. > >>That patch is very old. Version 1.28 is from August 1999 :-( > > > >That's not so bad. it looks like the same driver in 2.4.20. I was > >going out > >of my way when I fixed their kernel versioning for them. If you just > >want > >"the fix" (hack). To fix the rejects, I had only to fix some calls to KERNEL_VERSION, so I can do it. > >(from lxr.linux.no) > > > >501 #if LINUX_VERSION_CODE < 0x010300 > >502 static void *gdth_mmap(ulong paddr, ulong size) > >503 { > >504 if (paddr >= high_memory) > >505 return NULL; > >506 else > >507 return (void *)paddr; > >508 } I shouldn't change anything above, right? > >509 static void gdth_munmap(void *addr) > >510 { > >511 } > >512 inline ulong32 virt_to_phys(volatile void *addr) > >513 { > >514 return (ulong32)addr; > >515 } > >516 inline void *phys_to_virt(ulong32 addr) > >517 { > >518 return (void *)addr; > >519 } > > > >Change those instances from ulong32 to ulong. The kicker is if they > >had used the proper kernel versioning macros it wouldn't be evaluating > >this block and instead use the stock virt_to_phys & phys_to_virt > >functions. I don't know much about kernel interna (I prefer to compile a kernel without errors and warnings)... > >So this driver has been running with the OLD 2.1 API for years and any > >of their new changes are never accessed, so they're never tested. I > >wonder why they didn't use my patch... Hmmm.... Support costs? I installed a newer ICP-Controller in a x86 (also with a stock 2.4.18 woody kernel), and it simply worked. > >>Btw: Building a kernel fails with different messages (depends on the > >>configuration); sometimes seems to be error in the assembler, > >>sometimes > >>there are errors in the parser. Something known about this? > > > >I have no idea. It shouldn't. Please post the errors to the list. Maybe > >someone else could lend some insight. Something in the atm-drivers (ambassador.c). I try to compile it and send the errors to the list. J�rg -- Signature not available yet
