|  | ======================== | 
|  | Linux Switchtec Support | 
|  | ======================== | 
|  |  | 
|  | Microsemi's "Switchtec" line of PCI switch devices is already | 
|  | supported by the kernel with standard PCI switch drivers. However, the | 
|  | Switchtec device advertises a special management endpoint which | 
|  | enables some additional functionality. This includes: | 
|  |  | 
|  | * Packet and Byte Counters | 
|  | * Firmware Upgrades | 
|  | * Event and Error logs | 
|  | * Querying port link status | 
|  | * Custom user firmware commands | 
|  |  | 
|  | The switchtec kernel module implements this functionality. | 
|  |  | 
|  |  | 
|  | Interface | 
|  | ========= | 
|  |  | 
|  | The primary means of communicating with the Switchtec management firmware is | 
|  | through the Memory-mapped Remote Procedure Call (MRPC) interface. | 
|  | Commands are submitted to the interface with a 4-byte command | 
|  | identifier and up to 1KB of command specific data. The firmware will | 
|  | respond with a 4 bytes return code and up to 1KB of command specific | 
|  | data. The interface only processes a single command at a time. | 
|  |  | 
|  |  | 
|  | Userspace Interface | 
|  | =================== | 
|  |  | 
|  | The MRPC interface will be exposed to userspace through a simple char | 
|  | device: /dev/switchtec#, one for each management endpoint in the system. | 
|  |  | 
|  | The char device has the following semantics: | 
|  |  | 
|  | * A write must consist of at least 4 bytes and no more than 1028 bytes. | 
|  | The first four bytes will be interpreted as the command to run and | 
|  | the remainder will be used as the input data. A write will send the | 
|  | command to the firmware to begin processing. | 
|  |  | 
|  | * Each write must be followed by exactly one read. Any double write will | 
|  | produce an error and any read that doesn't follow a write will | 
|  | produce an error. | 
|  |  | 
|  | * A read will block until the firmware completes the command and return | 
|  | the four bytes of status plus up to 1024 bytes of output data. (The | 
|  | length will be specified by the size parameter of the read call -- | 
|  | reading less than 4 bytes will produce an error. | 
|  |  | 
|  | * The poll call will also be supported for userspace applications that | 
|  | need to do other things while waiting for the command to complete. | 
|  |  | 
|  | The following IOCTLs are also supported by the device: | 
|  |  | 
|  | * SWITCHTEC_IOCTL_FLASH_INFO - Retrieve firmware length and number | 
|  | of partitions in the device. | 
|  |  | 
|  | * SWITCHTEC_IOCTL_FLASH_PART_INFO - Retrieve address and lengeth for | 
|  | any specified partition in flash. | 
|  |  | 
|  | * SWITCHTEC_IOCTL_EVENT_SUMMARY - Read a structure of bitmaps | 
|  | indicating all uncleared events. | 
|  |  | 
|  | * SWITCHTEC_IOCTL_EVENT_CTL - Get the current count, clear and set flags | 
|  | for any event. This ioctl takes in a switchtec_ioctl_event_ctl struct | 
|  | with the event_id, index and flags set (index being the partition or PFF | 
|  | number for non-global events). It returns whether the event has | 
|  | occurred, the number of times and any event specific data. The flags | 
|  | can be used to clear the count or enable and disable actions to | 
|  | happen when the event occurs. | 
|  | By using the SWITCHTEC_IOCTL_EVENT_FLAG_EN_POLL flag, | 
|  | you can set an event to trigger a poll command to return with | 
|  | POLLPRI. In this way, userspace can wait for events to occur. | 
|  |  | 
|  | * SWITCHTEC_IOCTL_PFF_TO_PORT and SWITCHTEC_IOCTL_PORT_TO_PFF convert | 
|  | between PCI Function Framework number (used by the event system) | 
|  | and Switchtec Logic Port ID and Partition number (which is more | 
|  | user friendly). |