| ======================== | |
| 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). |