Re: Fwd: ICP Vortex driver fails
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
Reply to: