From owner-svn-src-all@FreeBSD.ORG Sun Nov 10 04:47:08 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 101DF388; Sun, 10 Nov 2013 04:47:08 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 3683D25A8; Sun, 10 Nov 2013 04:47:07 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id 318C9D49C84; Sun, 10 Nov 2013 15:46:56 +1100 (EST) Date: Sun, 10 Nov 2013 15:46:55 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Eitan Adler Subject: Re: svn commit: r257883 - head/sys/dev/ppc In-Reply-To: Message-ID: <20131110133214.G952@besplex.bde.org> References: <201311090827.rA98RuYj082760@svn.freebsd.org> <20131109194526.O1128@besplex.bde.org> <1384026950.1819.0.camel@powernoodle.corp.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=bpB1Wiqi c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=v_ry3Y7z3OsA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=Z5zpL04VkhMA:10 a=CjxXgO3LAAAA:8 a=DCTfLQXK6GAY49CROpwA:9 a=CjuIK1q_8ugA:10 a=rC2wZJ5BpNYA:10 Cc: "svn-src-head@freebsd.org" , Sean Bruno , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , Bruce Evans X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 04:47:08 -0000 On Sat, 9 Nov 2013, Eitan Adler wrote: > On Sat, Nov 9, 2013 at 2:55 PM, Sean Bruno wrote: >> On Sat, 2013-11-09 at 03:58 -0500, Eitan Adler wrote: >>>>> { 0x95131415, "Oxford Semiconductor OX16PCI954 Parallel >>> port", >>>>> 0x10 }, >>>>> + { 0xc1101415, "Oxford Semiconductor OXPCIe952 Parallel >>> port", 0x10 >>>>> }, >>>>> { 0x98059710, "NetMos NM9805 1284 Printer port", 0x10 }, >>>>> { 0x98659710, "MosChip MCS9865 1284 Printer port", 0x10 }, >>>>> { 0x99019710, "MosChip MCS9901 PCIe to Peripheral >>> Controller", >>>>> 0x10 }, >>>> >>>> Any chance of keeping sorted lists sorted? >>> >>> Sure. Shall I sort by ID or English text? >> >> Looks like its sorted by ID, so there ya go. > > 0x05111407 comes after 0x1020131f but Lava comes after SIIG. I don't > care either way. It has been broken before. Most or all tables of pci ids in FreeBSD are sorted by id, following /usr/share/misc/pci_vendors. This one was no exception until it was broken. The previous breakage was more complete. It unsorts by both id and name (Lava was placed near Lava, but Lava SP was unsorted before Lava Computers). It has the following "order": - first sort on the first word of the name ("Lava") - next sort on the id The order is then uniquely determined in this case. The ordering by id is more complicated and thus has more potential for bitrot in puc/pucdata.c. There the ids are split into 2 parts and there are sub-ids, giving 4 16-bit numbers instead of 1 32-bit one, exactly as in pci_vendors for the first 2 numbers. The 32-bit numbers are in little-endian order, so when split, sorting by id sorts on the vendor id first, unlike in tables with 1 32-bit number like the above. This ordering is better would group the Oxford devices in the above together (but not sorted by name relative to other vendors). But it would be too painful to maintain with 32-bit numbers. This splitting I sorted the pucdata.c declaration lines and got the following: % --- pucdata 2013-11-10 03:10:31.661338000 +0000 % +++ pucdata.sorted 2013-11-10 03:10:45.615559000 +0000 % @@ -1,2 +1,4 @@ % + { % { 0x0009, 0x7168, 0xffff, 0, % + { 0x1014, 0x0297, 0xffff, 0, % { 0x103c, 0x1048, 0x103c, 0x1049, % @@ -25,3 +27,2 @@ % { 0x11fe, 0x8019, 0xffff, 0, % - { 0x1014, 0x0297, 0xffff, 0, % { 0x131f, 0x1010, 0xffff, 0, % @@ -94,5 +95,4 @@ % { 0x1407, 0x0181, 0xffff, 0, % - { 0x1409, 0x7268, 0xffff, 0, % { 0x1409, 0x7168, 0xffff, 0, % - { % + { 0x1409, 0x7268, 0xffff, 0, % { 0x1415, 0x9501, 0x131f, 0x2050, % @@ -108,7 +108,2 @@ % { 0x1415, 0x9538, 0xffff, 0, % - { 0x155f, 0x0331, 0xffff, 0, % - { 0x155f, 0xB012, 0xffff, 0, % - { 0x155f, 0xB022, 0xffff, 0, % - { 0x155f, 0xB004, 0xffff, 0, % - { 0x155f, 0xB008, 0xffff, 0, % { 0x1415, 0xc138, 0xffff, 0, % @@ -127,5 +122,5 @@ % { 0x14d2, 0xa005, 0xffff, 0, % - { 0x14d2, 0xe020, 0xffff, 0, % { 0x14d2, 0xa007, 0xffff, 0, % { 0x14d2, 0xa008, 0xffff, 0, % + { 0x14d2, 0xe020, 0xffff, 0, % { 0x14db, 0x2130, 0xffff, 0, % @@ -133,2 +128,7 @@ % { 0x14db, 0x2152, 0xffff, 0, % + { 0x155f, 0x0331, 0xffff, 0, % + { 0x155f, 0xB004, 0xffff, 0, % + { 0x155f, 0xB008, 0xffff, 0, % + { 0x155f, 0xB012, 0xffff, 0, % + { 0x155f, 0xB022, 0xffff, 0, % { 0x1592, 0x0781, 0xffff, 0, Not too bad. The brace on a line by itself is just another style bug in Oxford data. All the 0x155f's are Perle cards unsorted into the middle of Oxford cards because they use Oxford chips. The sorting is not quite on the device id within the Oxford chips. The vendor id 0x1415 is supposed to be for Oxford, but it is used by many manufacturers. (I think Oxford was both a chip and card manufacturer but this was an abuse of the vendor id by other manuacturers.) Perle is perhaps more recent and uses its own id 0x155f. We shouldn't try to untangle this in our data. pci_vendors is out of data and doesn't have an Perle cards. 0x0297 is for IBM SurePOS. This is preceded by a formatting style bug (comment detached from its code). Elsewhere there is a reason to detach the comment from the code (because the comment is about multiple blocks of code). It is hard to delimit the scope of such comments clearly, and attached to only the first block. 0x7268 is for Sunix SUN1888. 0xe020 is for Titan VScom PCI-200HV2. I broke this back in 2003 :-(. BTW, this device needs memory-mapped i/o to work efficiently. I didn't commit that part, and the support for memory-mapped i/o in puc is now almost completely broken. It was replaced by automatic configuration that depends on never using the memory-mapped case (for this card and others) to avoid the lost regshft support being fatal. Bruce