Date: Wed, 06 Dec 2000 19:31:13 +0000 From: Ian Dowse <iedowse@maths.tcd.ie> To: Warner Losh <imp@village.org> Cc: Scott Stegmiller <stegs@gblx.net>, freebsd-mobile@FreeBSD.ORG, iedowse@maths.tcd.ie Subject: Re: Netgear FA410TXC Message-ID: <200012061931.aa94035@salmon.maths.tcd.ie> In-Reply-To: Your message of "Wed, 06 Dec 2000 00:20:16 MST." <200012060720.AAA76694@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200012060720.AAA76694@harmony.village.org>, Warner Losh writes: >These patches look OK. Some refinement is likely necessary before Thanks for your suggestions. I've included a few comments below. >I'd be inclind to move the pccard specific into if_ed itself. I've >heard that there are some newer ISA parts that have this same problem. Sounds like a good idea, and it's easy to do. I did think a bit about where the best place would be for the bulk of the new code, but it does seem likely that ISA/PCI/cardbus ed-type devices with miibus PHYs will appear if they haven't already. Each .c file can just add the DEVMETHODs and call some kind of init function if it needs the mii support. >Does this require the ed driver to now specify miibus? What other doc >changes are necessary? Yes, the ed driver will have to be moved into the list of drivers that requires miibus, it needs a MODULE_DEPEND in -current, and there are probably other doc changes such as ed(4), supported hardware list and others. >Bruce likely would comment that some of your changes related to >callouts add too many blank lines. That's a nit. Easily fixed! >I'm not sure that I'd code fa410 into the miibus name, since there are >other cards (dlink makes one and I think linksys does too, but I've >been known to get them confused). The bits in the patch that have 'fa410' in symbol names are potentially specific to this card alone, though it is more likely that they are specific to a particular chipset that this card happens to use. Unfortunately I don't know which is the case. The only functions with fa410 in the name are ed_pccard_fa410_mii_reset ed_pccard_fa410_mii_readbits ed_pccard_fa410_mii_writebits and these are the only functions that use the ED_FA410* #defines; my intention was that to support other miibus cards, we would decide which chipset-specific function to use in the generic 'readreg' and 'writereg' functions, and call the correct one (a few other changes would be required to support this). As I understand the miibus, only the physical bus protocol is defined; implementations can choose their own mapping between software-visable registers and miibus signals, so there is a need for chipset-specific code. Since there are so many NE2000 clones out there, I don't think there is any hope that all of them will choose the same mapping :-) >I'm not too familiar with miibus, but there seems to be more code here >than in the other drivers that use the mii bus. Is that because the >stuff really is different, or is it a reflection of the fa-select >legacy? I have only looked at a handful of miibus drivers in the tree, but I got the opposite impression - I was expecting complaints that it was too terse :-) Which drivers were you looking at? One thing that I did do differently was to use a bus_child_detached method to ensure that the sc->miibus pointer was never left pointing to freed memory. Most of the PCI miibus drivers in the tree would free the miibus device_t twice if their detach method were to be called via device_delete_child() instead of via device_detach(). >Don't get me wrong, I'd love to see these problems corrected in >-current and -stable. I hope to have this into -current and -stable >way before 4.3 is out. Yes, me too. Doing a net install with an fa410 is rather tricky now! Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200012061931.aa94035>