Date: Tue, 13 Jun 2000 13:02:03 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Nick Hibma <n_hibma@calcaphon.com> Cc: Doug Rabson <dfr@calcaphon.com>, cvs-committers@freebsd.org, cvs-all@freebsd.org, Mike Smith <msmith@freebsd.org> Subject: Re: PCI attach ordering Message-ID: <9721.960894123@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 13 Jun 2000 11:39:39 BST." <Pine.BSF.4.20.0006130936080.10103-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.20.0006130936080.10103-100000@localhost>, Nick Hibma wri tes: > >> Right with the added twist that identification doesn't complete >> until I have had a chance to poke at function 1. In other words, >> I can't really claim function 0 when I see it, because I don't >> know if it is part of the card I'm looking for or another card >> and I will not know until I get to probe function 1. > >Are you saying that when you see the id 0x847x109e, you don't know >whether you are looking at the multifunction card or not (I assume below >that that is not the case and that the ID is sufficient). When I see that ID I know what chip I have, but there may be many different cards based on that chip, and with radical different "frontends". I can only tell what frontend I have after examining the bus bridged by function 1. >1) You need to claim both functions and they both represent different >devices, so they should be attached to by different drivers (call them >musycc-nc and musycc-eb). Assuming that there is no such thing as a card >with only one of the functions your driver attaches to, you then can >relate the two drivers by their unit numbering (hardwiring the device >would be a bit more cumbersome). Right, but the real issue is: How do I claim function 0 when I can only discover that I need to do so after having examined function 1 ? >The botch you have now, musycc0 being card A function 0, musycc1 being >card A function 1, musycc2 being card B function 0, etc. is really not a >good idea. It doesn't matter in practice, the driver will be a netgraph driver and there are four physical ports on each card. >2) Speaking to dfr this morning, he mentioned device_set_softc. I don't >particularly like this idea as it will be abused when porting drivers >from NetBSD. If you use the approach above you will not need to keep any >state as you can grab the softc for either of the device with I particular dislike the softc being allocated by newbus. It is just plain wrong to do so: The softc is driver data. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9721.960894123>