Date: Tue, 28 Jul 1998 11:12:59 -0700 From: Ted Faber <faber@ISI.EDU> To: Frank McConnell <fmc@reanimators.org> Cc: Mike Smith <mike@smith.net.au>, Robert Swindells <swindellsr@genrad.co.uk>, hackers@FreeBSD.ORG Subject: Re: AMD PCNet/FAST cards; suppliers? Message-ID: <199807281812.LAA18644@tnt.isi.edu> In-Reply-To: Your message of "28 Jul 1998 10:51:02 PDT." <199807281751.KAA22144@daemonweed.reanimators.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Frank McConnell wrote: >Ted Faber <faber@ISI.EDU> wrote: >> So, if this is a known chip that works on other machines, what's so >> different about the Hitachi MX-133? I'm happy to run any diagnostics >> that you guys think will help find the differences. > >Funny, that's what I was thinking to ask you: what is it about the >Hitachi Mx133 (and apparently other Hitachi notebooks) that needs this >patch? The ethernet on the MX-133 is integrated into the case, i.e. it's not a PCMCIA card or an add-on. I haven't opened the thing up, but for all I know the controller's on the motherboard. Apparently they've made some interesting choices about the defaults for the PCNET chip they used. It seems to come up in ISA compatibility mode. If the chip *does* work in native PCI mode, maybe we should concentrate on bringing up the controller in direct PCI mode. I don't have the relevent chip specs, but if you can tell me anything I'll be happy to help. > I've looked at the original patch in the mailing list archives >and now I think I really don't get it -- does this thing satisfy two >different probes and so get attached twice? Here's what I sent Mike Smith about the patch. If other people are successfully using this chip as a pure PCI chip, my comments that there's no way to do so are obviously wrong. - --- Mike Smith said (among other things: >The ne2100_probe() function returns zero if pcnet_probe() fails. >However, you've patched this function to return nonzero, so you >shouldn't need this case. > >Comments? Are you still using this code? I'm still using this code, and here's my rationale behind it: (You'll probably want to open /sys/i386/isa/if_lnc.c up to follow this...) As far as I can tell, there's no support for using the Hitachi's internal PCI lance board in native PCI mode, so the card can only be used in ISA emulation mode. This means that pcnet_probe() is called *twice*, once when PCI cards are probed, and once when ISA cards are probed. When PCI cards are probed, lnc_attach_ne2100_pci() needs an indication that there is a PCI card around in emulation mode so that it doesn't call lnc_attach_sc() to attach the PCI card as a native PCI device. (This is somewhat obfuscated by putting it in a short circuit operator, but that construct was there when I showed up....) The zero from pcnet_probe() serves as a placeholder in lnc_attach_ne2100_pci(), but during ISA probing, lnc_probe() expects pcnet_probe() to return a non-zero value if there is a card in emulation mode. pcnet_probe() can't (easily :-)) tell which function's calling it, so it can't return different values. This patch was the first thing I submitted to the source tree, and as a new kid, I thought that keeping my changes as small as possible would make them more likely to be adopted (and smaller to mail!!). In retrospect, probably not the best parameter to optimize. :-) The problem seems to be that the various probe routines (or at least pcnet_probe()) are doung double duty as both ISA and PCI probe routines. Two answers suggest themselves: 1) Comment the hell out of this so it's not so confusing; 2) add a separate pcnet_probe_pci() routine that returns an appropriate value while reusing as much pcnet_probe() code as possible (all of it, I think). Of course, I could also be way off base, in which case, I hope you'll tell me. I'm happy to leave it as is, implement either of the above solutions, or be persuaded that there's another, better solution. - --- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNb4UqYb4eisfQ5rpAQF10AQAncU9SPLgvMZWVPt8/XYjhQOi4MLFd9of hVoyGzjHsGQ+2jJSajbeAwtJXXwe9QW42X64ReJFVpSxQd5FhthMapAMDFpYkUhA cCsiipT5PEs7REqOY4BDN5rTNnh+KYfP/s/vBdQKQOJVBg28DMqSvFUGVCfmfE8a OP3DDk8bzog= =z/yG -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807281812.LAA18644>