svn commit: r257883 - head/sys/dev/ppc

[Bruce Evans]

On Sat, 9 Nov 2013, Eitan Adler wrote:

> On Sat, Nov 9, 2013 at 2:55 PM, Sean Bruno <sean_bruno at yahoo.com> 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