Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 06 Dec 2000 13:11:39 -0700
From:      Warner Losh <imp@village.org>
To:        Ian Dowse <iedowse@maths.tcd.ie>
Cc:        Scott Stegmiller <stegs@gblx.net>, freebsd-mobile@FreeBSD.ORG
Subject:   Re: Netgear FA410TXC 
Message-ID:  <200012062011.NAA80675@harmony.village.org>
In-Reply-To: Your message of "Wed, 06 Dec 2000 19:31:13 GMT." <200012061931.aa94035@salmon.maths.tcd.ie> 
References:  <200012061931.aa94035@salmon.maths.tcd.ie>  

next in thread | previous in thread | raw e-mail | index | archive | help
In message <200012061931.aa94035@salmon.maths.tcd.ie> Ian Dowse writes:
: 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.

Right.

: >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.

OK.

: >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.

Actually, they are specific to the chipset that the card uses, which
has appeared in at least two other cards that I'm aware of.  It is a
Dlink part iirc, but I don't have the part number handy.

: 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 :-)

Well, that is true.

: 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?

Just general impressions from looking in the past.  Maybe these
impressions were wrong.

: 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().

Ah, maybe we should fix them too :-)

: >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!

Agreed.

The whole pcic polling business may also need to be reexamined since
it is causing more grief than joy, but that's a different topic.

Warner



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?200012062011.NAA80675>