From owner-cvs-all Tue Jun 13 4: 2:25 2000 Delivered-To: cvs-all@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 3E0ED37B9B5; Tue, 13 Jun 2000 04:02:20 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id NAA09723; Tue, 13 Jun 2000 13:02:03 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Nick Hibma Cc: Doug Rabson , cvs-committers@freebsd.org, cvs-all@freebsd.org, Mike Smith Subject: Re: PCI attach ordering In-reply-to: Your message of "Tue, 13 Jun 2000 11:39:39 BST." Date: Tue, 13 Jun 2000 13:02:03 +0200 Message-ID: <9721.960894123@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , 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