| MAC_CAPAB_TRANSCEIVER(9E) | Driver Entry Points | MAC_CAPAB_TRANSCEIVER(9E) |
mac_capab_transceiver, mct_info,
mct_read —
#include <sys/mac_provider.h>
typedef struct mac_capab_transceiver mac_capab_transceiver_t;
int
mct_info(void *driver,
uint_t id, mac_transceiver_info_t
*infop);
int
mct_read(void *driver,
uint_t id, uint_t page,
void *buf, size_t nbytes,
off_t offset, size_t
*nread);
This capability should be implemented if the device in question supports a Small Form Factor (SFF) transceiver. These are more commonly known by names such as SFP, SFP+, SFP28, QSFP+, and QSFP28. This interface does not apply to traditional copper Ethernet phys. These transceivers provide standardized information over the i2c bus at specific pages.
The following table summarizes the above information.
| Standard | Speeds | Size | i2c pages |
| INF-8074 | 1 Gb/s, 10 Gb/s | 128 bytes | 0xa0 |
| SFF-8472 | 1 Gb/s, 10 Gb/s, 25 GB/s | 512 bytes | 0xa0, 0xa2 |
| SFF-8436 | 40 Gb/s | 256 bytes | 0xa0 |
| SFF-8636 | 100 Gb/s | 256 bytes | 0xa0 |
typedef struct mac_capab_transceiver {
uint_t mct_flags;
uint_t mct_ntransceivers;
int (*mct_info)(void *driver, uint_t id,
mac_transceiver_info_t *infop),
int (*mct_read)(void *driver, uint_t id, uint_t page,
void *buf, size_t nbytes, off_t offset,
size_t *nread)
} mac_capab_transceiver_t;
If the device driver supports the MAC_CAPAB_TRANSCEIVER capability, it should fill in this structure, based on the following rules:
It is expected that this value will not change across the lifetime of the device being attached. It is important to remember that this represents the total possible number of transceivers in the device, not how many are currently present and powered on.
The number of transceivers will influence the
id argument used in the
mct_info() and
mct_read() entry points. The transceiver IDs
will start at zero and go to the value of
mct_ntransceivers - 1. It is up to the driver to
keep the mapping between actual transceivers and the transceiver
identifiers consistent.
mct_info() entry point is used to set basic
information about the transceiver. This entry point is
required. If the device driver cannot implement this
entry point, then it should not indicate that it supports the capability.
The mct_info() entry point should fill
in information about the transceiver with an identifier of
id. See the description above of
mct_ntransceivers for more information on how the IDs
are determined.
The driver should then proceed to fill in basic information by calling the functions described in the section Information Functions. After successfully calling all of the functions, the driver should return 0. Otherwise, it should return the appropriate error number. For a full list of error numbers, see Intro(2). Common values are:
EINVALENOTSUPEIOmct_read() function is used to read
information from a transceiver's i2c bus. The
mct_read() entry point is an
optional entry point.
The transceiver should first check the value of id, which indicates which transceiver information is being requested. See the description above of mct_ntransceivers for more information on how the IDs are determined.
The driver should try to read up to nbytes of data from the i2c bus at page page. The driver should start reading at offset offset. Finally, it should update the value in nread with the number of bytes written to the buffer buf.
If for some reason the driver cannot read all of the requested bytes, that is acceptable. Instead it should perform a short read. This may occur because the transceiver does not allow reads at a requested region or the region is shorter than is common for most devices.
Upon successful completion, the driver should ensure that nread has been updated and then return 0. Otherwise, the driver should return the appropriate error number. For a full list of error numbers, see Intro(2). Common values are:
EINVALEIOmct_info() entry point is the primary required entry
point for a device driver which supports this capability. The information
structure is opaque to the device driver. Instead, a series of informational
functions is available to the device driver to call on the transceiver. The
device drivers should try to call and fill in as many of these as possible.
There are two different properties that a driver can set:
To set whether or not the transceiver is present, the driver
should call mac_transceiver_info_set_present(9F). This is
used to indicate whether the transceiver is plugged in or not. If the
transceiver is a part of the NIC, then this function should always be called
with the value set to B_TRUE.
Finally, the driver has the ability to provide information about whether or not the transceiver is usable or not. A transceiver may be present, but not usable, if the hardware and firmware support a limited number of transceivers. To set this information, the driver should call mac_transceiver_info_set_usable(9F). If the transceiver is not present, then the driver should not call this function.
mct_info() entry point.
On some devices, reading from the transceiver's i2c bus might cause a disruption of service to the device. For example, on some devices a phy reset may be required or come about as a side effect of trying to read the device. If any kind of disruption would be caused, then the driver must not implement the mct_read entry point.
SFP (Small Formfactor Pluggable) Interface, INF-8074i, SFF Committee, May 12, 2001, Revision 1.0.
Diagnostic Monitoring Interface for Optical Transceivers, SFF-8472, November 21, 2014, Revision 12.2.
QSFP+ 10 Gbs 4X PLUGGABLE TRANSCEIVER, SFF-8436, October 31, 2013, Revision 4.8.
Management Interface for Cabled Environments, SFF-8636, January 26, 2016, Revision 2.7.
| February 15, 2020 | illumos |