Hello. Atsushi Nemoto wrote:
On Mon, 17 Apr 2006 17:06:23 +0400, Sergei Shtylyov <sshtylyov@xxxxxxxxxxxxx> 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
