linux-mips
[Top] [All Lists]

Re: tx49 Ether problems

To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Subject: Re: tx49 Ether problems
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Date: Mon, 17 Apr 2006 20:07:21 +0400
Cc: linux-mips@linux-mips.org
In-reply-to: <20060418.000918.95064811.anemo@mba.ocn.ne.jp>
Organization: MontaVista Software Inc.
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <444291E9.2070407@ru.mvista.com> <20060417.110945.59031594.nemoto@toshiba-tops.co.jp> <444392CF.7070808@ru.mvista.com> <20060418.000918.95064811.anemo@mba.ocn.ne.jp>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803
Hello.

Atsushi Nemoto wrote:
On Mon, 17 Apr 2006 17:06:23 +0400, Sergei Shtylyov <sshtylyov@ru.mvista.com> 
wrote:

I agree with you.  Then how about something like
CONFIG_NE2000_RTL8019_BYTEMODE?

   Have you looked at the patch? RTL8019 is easily detectable at
runtime, so the limitation is easily enforcable w/o extra Kconfig
option, I think

Well, I meant something like:

#elif defined(CONFIG_NE2000_RTL8019_BYTEMODE)
#  define DCR_VAL 0x48
#else
#  define DCR_VAL 0x49

to avoid changing #elif line every time when we want to support a new
board with byte-mode RTL8019AS.  Of course, calculating DCR_VAL at
runtime would be much better but I'm not sure if we can do it ...

Hm, with only 3-4 known boards so far (all Toshiba RBTX49[23][78], RBTX4925 also has the chip but I see no 2.6 support for this board), I doubt that it's worth the effort. And the option sounds a bit "too specific", IMO. :-)

Also, setting 0xbad value to mem_end
can skip the Product-ID checking without inflating bad_clone_list.
Just a thought...

Er, calling RTL8019AS in 8-bit mode "NE2000" (as the driver would have done in case of RBTX49xx if we have used 0xbad), is not a correct thing. :-)

   0xbad in dev->mem_end currently skips 8390 reset which is not a
good thing for the clones for which it does work...

The 8390 reset will not skipped.  The difference is behavior _after_
detection of no reset ack, isn't it?

   Yes, I was too hasty and have overlooked this. :-)

---
Atsushi Nemoto

WBR, Sergei

<Prev in Thread] Current Thread [Next in Thread>