From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 21:28:43 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BA6F16A4CE for ; Sun, 24 Oct 2004 21:28:43 +0000 (GMT) Received: from cydem.org (S0106000103ce4c9c.ed.shawcable.net [68.149.254.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E2B343D1D for ; Sun, 24 Oct 2004 21:28:42 +0000 (GMT) (envelope-from soralx@cydem.org) Received: from S01060020ed3972ba.ed.shawcable.net (S01060020ed3972ba.ed.shawcable.net [68.149.254.42]) by cydem.org (Postfix/FreeBSD) with ESMTP id 544D938A16 for ; Sun, 24 Oct 2004 15:28:42 -0600 (MDT) From: To: freebsd-hackers@freebsd.org Date: Sun, 24 Oct 2004 15:29:05 -0600 User-Agent: KMail/1.5.4 References: <200410132110.09915.soralx@cydem.org> <200410231047.44788.soralx@cydem.org> <417B08B5.8080208@error404.nls.net> In-Reply-To: <417B08B5.8080208@error404.nls.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410241529.05286.soralx@cydem.org> Subject: Re: [PATCH] Re: Linksys PCM200 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2004 21:28:43 -0000 > > <>I don't see a way how it could break other cards' functionality - > > should be no concerns here > D-Link isn't the only 0x00a8; The AboCom FE2500MX bears 0x13d1 0xab08. Are there any cards that have exactly the same 32-bit PCIID, and different/modified chipsets? I didn't think that something like that is possible... Anyway, the PCM200's PCIID doesn't seem to conflict with any other card's, so I'm sure it won't break anything. > >0. More info is _always_ better. In any case, the message will take 2 > > lines on console, so shortening the description will not gain anything > Yes, it does. It gains readability. compare: dc0: port 0x1000-0x10ff mem 0x88002000-0x880023ff irq 9 at device 0.0 on cardbus1 and dc0: port 0x1000-0x10ff mem 0x88002000 -0x880023ff irq 9 at device 0.0 on cardbus1 Is the latter more readable? I think they're the same. The former is even more readable for me, because the description is on one line, and all the I/O info is on the other. Also, if I will need to send dmesg to somebody (for example, the card could create a problem by conflicting with some other hardware), they will know _exactly_ what card is it (and even if they're not familiar with this card, they'll know the chipset). > Long descriptions should generally > be reserved for pciconf -lv and driver comments. for this card, `pciconf -lv` outputs not much useful info: dc0@pci2:0:0: class=0x020000 card=0xab091737 chip=0xab091737 rev=0x11 hdr=0x00 vendor = 'Linksys' device = 'PCM200 10/100 CardBus Ethernet Adapter' Even the chipID is changed. It also does not state card's version (one will need to figure that out from revID) - and, according to info in the INet, card's versions differ between each other noticeably. > > <>2. when PCI IDs for previous card versions will be added, the > > description will > > need to be changed anyway to include the version number > > Only because D-Link has a 'change everything except the model name' > fetish. Unless D-Link pulled the same crap they did with the DWL-520 and > DWL-650, personally I don't see any compelling reason to include chipset > and revision in the dev's desc. why not? there can never be too much info :) > Now, if D-Link pulled the same crap on > this as they did with the DWL-520, I'd say just slap Rev.D in there; > there's no need for chipset name chipset name makes the dmesg message separate nicely into 2 lines :p Anyway, enough on this. I'd personally prefer to see my long description commited, but seems like the FreeBSD developers know better what to do (as they were able to create such a great OS). I'll test the store-and-fwd patch later today. I thought however, that it has to swith to that mode because my notebook (and CardBus controller) isn't fast enough. Form `man 4 dc`: dc%d: TX underrun -- increasing TX threshold The device generated a transmit underrun error while attempting to DMA and transmit a packet. This happens if the host is not able to DMA the packet data into the NIC's FIFO fast enough. Timestamp: 0x417C1321 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2