netdev - [PATCH] CAN, sja1000, plx_pci.c : some device ID's for Advantech hardware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <4DF793DB.6863.5434F06B@Frantisek.Rysanek.post.cz>
Date:	Tue, 14 Jun 2011 17:01:15 +0200
From:	"Frantisek Rysanek" <Frantisek.Rysanek@...t.cz>
To:	netdev@...r.kernel.org
CC:	P.B.Cheblakov@....nsk.su, urs@...ogud.escape.de
Subject: [PATCH] CAN, sja1000, plx_pci.c : some device ID's for Advantech hardware

Dear Everyone,

attached you'll find a patch that adds support for the following 
hardware by Advantech:
PCI-1680 = dual-port PCI card
UNO-2052 = fanless PC (Geode-based) with 2x SJA1000 onboard via PCI

The patch consists of just some added PCI ID's, plus a one-liner 
bugfix (?): an added delay in plx_pci_check_sja1000() between the PLX 
reset and the SJA reset, giving the SJA more time to become ready for 
the switch to Pelican mode.

Tested using cansend+candump in Debian 6.
I was amazed that all the necessary bits are included "out of the 
box" in Sarge: support for CAN in "ip", libc headers etc.

Thanks for your excellent work, and for including the CAN subsystem 
in the vanilla mainline :-) It's a relief to have an official CAN 
stack in the vanilla kernel - no need to work out of tree anymore.

Frank Rysanek

P.S.: A quick Google survey of PCI-based CAN hardware (boards) from 
various vendors has revealed that
1) Advantech has some new models (PCI-1682 and PCM-3680*I*) 
    that use a Xilinx FPGA instead of the trusty old PLX bridges,
    and for which there is no register-level documentation
2) similarly, I've found a neat dual-port MiniPCI board from 
   Peak System Technik, apparently using a Lattice chip for the 
   same purpose... (likely with an open-source "character device" 
   driver from Peak, along with an additional user-space SDK)
I assume these general-purpose FPGA-based bridge devices are cheaper 
than the dedicated PLX silicon, but the change sadly does away with a 
great deal of homogenity that used to come with the slave bridges by 
PLX. I haven't put my hands on either of that new hardware, but I 
expect that the two SJA chips will still be visible as BAR's on the 
PCI bus. Hopefully there isn't much to get wrong in this kind of 
design...

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  2.6.39_adv-pci-can.patch
     Date:  14 Jun 2011, 11:39
     Size:  2703 bytes.
     Type:  Unknown

Download attachment "2.6.39_adv-pci-can.patch" of type "Application/Octet-stream" (2703 bytes)