Fix ifconfig(8) compiler warnings regarding variable "name" reuse.
Call the global variable with the name of the interface "ifname".
Do not pass it around, just use it globally. Do not use "ifname"
for anything else.
OK deraadt@

Fix some compiler warings in ifconfig(8). Move all prototypes and
variables used in multiple .c files into common ifconfig.h. Basically
this renames brconfig.h to ifconfig.h and also uses it for sff.c.
Fix missing prototypes. Global variable name s is bad as it shadows
local variables. Call it sock and use it everywhere.
OK deraadt@

whitespace, found while pondering improvements to sffdump

fix a comparison which generated a warning on sparc64.

found by deraadt@

make the list of OM fibre distances go OM1, OM2, OM3, not OM2, OM1, OM3

s/No separable connector/No connector/

shrinks some QSFP+ DAC output a bit.

remove some cruft

try to factor media information out and use it for qsfp as well as sfp.

qsfp and xfp have remarkably similar layouts, so we can use the
same code to print media for both. sfp and xfp/qsfp generally have
the same fields, just in different register locations and with some
different scales/factors for some values. this change provides a
map of these differences as structs for the sfp and qsfp/xfp layouts.

the big difference between sfp, xfp, and qsfp that still remains
is how they interpret the wavelength field. qsfp stores either optic
wavelength in units of 0.05nm, or a couple of copper cable attenuation
values in dB at different frequencies. sfp stores wavelength in nm
units, but has magic values to blacklist copper cables with. xfp
stores wavelength in 0.05 nm units, so more like like qsfp. right
now the code uses the sfp behaviour, which means qsfp will show a
weird wavelength for copper cables when it shouldnt. i'm still
trying to figure out the least worst way to handle that, but at
least it looks right for optics now.

print more qsfp temperature information

this shows the maximum case temperature reported by the chip, and
the low and high alarm ranges for temp and vcc when page 3 is
available and working.

this will hopefully give deraadt@ a better idea about how much
headroom one of his 100g optics has.

have a go at printing more monitoring information.

this is a bit rough, but a good start. apart from the media types
and length, qsfp support should be on par with sfp modules now.

make a start at reporting qsfp monitor values.

i have some qsfp DACs and a couple of optics, and they're all
terrible, so this is about as far as i can go for now. at least the
code will be robust in the face of terrible modules though.

the DACs are pretty dumb and basically report that they're DACs
with some strings. this code just prints that they're DACs with
strings now.

modules are supposed to be able to report overall temperature and
voltage, and optics can report tx and rx values for the 4 different
signal lanes they're supposed to provide. interestingly the current
values are always reported in the lower page, but thresholds are
reported in page 3, but not all modules support page switching.
devices are supposed to say whether they can switch pages, but i
have one that does say it can switch but then doesn't. anyway, the
take away is that it is therefore possible for a module to report
values without also
reporting thresholds.

this sets the code up to report the values on their own if we can't
query page 3 for any reason.

if the temp sensor value looks bogus (ie, 0x0000 or 0xffff), assume
the monitor values are bogus and bail early.

hopefully i can find a module soon that supports multiple signal
lanes and actually reports their values and thresholds for them.

Fix a missing carriage return.

OK deraadt@

restore some missing error handling

ethtool indicates that QSFP, QSFP+ and QSFP28 are all SFF-8636 compat.

follow the basic xfp support with basic qsfp+ support

qsfp was originally defined in SFF-8436, but the management interface
now seems to be managed in SFF-8636, so this uses sff8636 as a
prefix for qsfp things. the same spec applies to qsfp+ and probably
qsfp28.

XFP and QSFP share a bunch of offsets for where strings are located,
so this factors out the printing of those strings from the xfp code
and uses it from both the xfp and qsfp handling.

i have a qsfp+ to 4x sfp+ cable that looks like this with the new
code:

transceiver: QSFP+
model: Amphenol 601110005 rev A
serial: CN0HVVVFxxxxxxx date: 2013-04-18

if i ever get a pair of optics i can work on the diags

basic support for dumping xfp info

xfp uses a different page layout compared to sfp. xfp uses info in
INF-8077, not SFF-8472, and by default provides the info at page
1, not 0.

myx(4) supports xfp modules, but doesn't support i2c writes so it
cannot change the page the chip is looking at. it appears that myx
defaults to page 1 for xfp, so if the first read of page 0 fails
with ENXIO, try to read page 1 instead.

a 10G-PCIE-8A-R myx with the only xfp module i could find lying
around looks like this:

transceiver: XFP
model: Intel Corp TXN181070850X1J rev B3
serial: USC2048M95 date: 2005-04-13

im not sure if it's worth spending much more time on these though..

print transceiver supported distances, ok deraadt

print transceiver information inline with standard interface details
(like media/joinlist do) rather than totally separate; this also allows
"ifconfig -a sff" or "ifconfig ix sff".

tweak display format to make it look closer to the standard lines.

ok deraadt

use AOC and DAC instead of standard's names "optical / copper pigtail"
because these are the commonly used terminology
ok claudio sthen

MPO cable names were swapped

use correct printf format for current dBm values
problem spotted by Hrvoje, thank you!

ok deraadt

Tweak transceiver information printing, adding a bit more information
in less space. Adds wavelength, printing alarm low/high thresholds, and
prints a flag for warning or alarm indications. "i like it" deraadt@

add support for fetching and parsing SFF module info and diags

this is very basic, and will get cut up a lot by sthen@ soon, but
it was enough to get us started with. at the moment it shows the
type of module, some vendor and products strings, and detects if
the device supports diag and then shows it. qsfp info is structured
very differently, but i'll let sfp support settle before trying to
make it look the same.

so far only ix(4) and some ixl(4) with up to date firmware implement
the backend ioctl for this. no em(4) yet :(

suggestions from mikeb@
ok deraadt@ sthen@

this was started because of a question from rachel roch

Fix some compiler warings in ifconfig(8). Move all prototypes and
variables used in multiple .c files into common ifconfig.h. Basically
this renames brconfig.h to ifconfig.h and also uses it for sff.c.
Fix missing prototypes. Global variable name s is bad as it shadows
local variables. Call it sock and use it everywhere.
OK deraadt@

whitespace, found while pondering improvements to sffdump

fix a comparison which generated a warning on sparc64.

found by deraadt@

make the list of OM fibre distances go OM1, OM2, OM3, not OM2, OM1, OM3

s/No separable connector/No connector/

shrinks some QSFP+ DAC output a bit.

remove some cruft

try to factor media information out and use it for qsfp as well as sfp.

qsfp and xfp have remarkably similar layouts, so we can use the
same code to print media for both. sfp and xfp/qsfp generally have
the same fields, just in different register locations and with some
different scales/factors for some values. this change provides a
map of these differences as structs for the sfp and qsfp/xfp layouts.

the big difference between sfp, xfp, and qsfp that still remains
is how they interpret the wavelength field. qsfp stores either optic
wavelength in units of 0.05nm, or a couple of copper cable attenuation
values in dB at different frequencies. sfp stores wavelength in nm
units, but has magic values to blacklist copper cables with. xfp
stores wavelength in 0.05 nm units, so more like like qsfp. right
now the code uses the sfp behaviour, which means qsfp will show a
weird wavelength for copper cables when it shouldnt. i'm still
trying to figure out the least worst way to handle that, but at
least it looks right for optics now.

print more qsfp temperature information

this shows the maximum case temperature reported by the chip, and
the low and high alarm ranges for temp and vcc when page 3 is
available and working.

this will hopefully give deraadt@ a better idea about how much
headroom one of his 100g optics has.

have a go at printing more monitoring information.

this is a bit rough, but a good start. apart from the media types
and length, qsfp support should be on par with sfp modules now.

make a start at reporting qsfp monitor values.

i have some qsfp DACs and a couple of optics, and they're all
terrible, so this is about as far as i can go for now. at least the
code will be robust in the face of terrible modules though.

the DACs are pretty dumb and basically report that they're DACs
with some strings. this code just prints that they're DACs with
strings now.

modules are supposed to be able to report overall temperature and
voltage, and optics can report tx and rx values for the 4 different
signal lanes they're supposed to provide. interestingly the current
values are always reported in the lower page, but thresholds are
reported in page 3, but not all modules support page switching.
devices are supposed to say whether they can switch pages, but i
have one that does say it can switch but then doesn't. anyway, the
take away is that it is therefore possible for a module to report
values without also
reporting thresholds.

this sets the code up to report the values on their own if we can't
query page 3 for any reason.

if the temp sensor value looks bogus (ie, 0x0000 or 0xffff), assume
the monitor values are bogus and bail early.

hopefully i can find a module soon that supports multiple signal
lanes and actually reports their values and thresholds for them.

Fix a missing carriage return.

OK deraadt@

restore some missing error handling

ethtool indicates that QSFP, QSFP+ and QSFP28 are all SFF-8636 compat.

follow the basic xfp support with basic qsfp+ support

qsfp was originally defined in SFF-8436, but the management interface
now seems to be managed in SFF-8636, so this uses sff8636 as a
prefix for qsfp things. the same spec applies to qsfp+ and probably
qsfp28.

XFP and QSFP share a bunch of offsets for where strings are located,
so this factors out the printing of those strings from the xfp code
and uses it from both the xfp and qsfp handling.

i have a qsfp+ to 4x sfp+ cable that looks like this with the new
code:

transceiver: QSFP+
model: Amphenol 601110005 rev A
serial: CN0HVVVFxxxxxxx date: 2013-04-18

if i ever get a pair of optics i can work on the diags

basic support for dumping xfp info

xfp uses a different page layout compared to sfp. xfp uses info in
INF-8077, not SFF-8472, and by default provides the info at page
1, not 0.

myx(4) supports xfp modules, but doesn't support i2c writes so it
cannot change the page the chip is looking at. it appears that myx
defaults to page 1 for xfp, so if the first read of page 0 fails
with ENXIO, try to read page 1 instead.

a 10G-PCIE-8A-R myx with the only xfp module i could find lying
around looks like this:

transceiver: XFP
model: Intel Corp TXN181070850X1J rev B3
serial: USC2048M95 date: 2005-04-13

im not sure if it's worth spending much more time on these though..

print transceiver supported distances, ok deraadt

print transceiver information inline with standard interface details
(like media/joinlist do) rather than totally separate; this also allows
"ifconfig -a sff" or "ifconfig ix sff".

tweak display format to make it look closer to the standard lines.

ok deraadt

use AOC and DAC instead of standard's names "optical / copper pigtail"
because these are the commonly used terminology
ok claudio sthen

MPO cable names were swapped

use correct printf format for current dBm values
problem spotted by Hrvoje, thank you!

ok deraadt

Tweak transceiver information printing, adding a bit more information
in less space. Adds wavelength, printing alarm low/high thresholds, and
prints a flag for warning or alarm indications. "i like it" deraadt@

add support for fetching and parsing SFF module info and diags

this is very basic, and will get cut up a lot by sthen@ soon, but
it was enough to get us started with. at the moment it shows the
type of module, some vendor and products strings, and detects if
the device supports diag and then shows it. qsfp info is structured
very differently, but i'll let sfp support settle before trying to
make it look the same.

so far only ix(4) and some ixl(4) with up to date firmware implement
the backend ioctl for this. no em(4) yet :(

suggestions from mikeb@
ok deraadt@ sthen@

this was started because of a question from rachel roch

whitespace, found while pondering improvements to sffdump

fix a comparison which generated a warning on sparc64.

found by deraadt@

make the list of OM fibre distances go OM1, OM2, OM3, not OM2, OM1, OM3

s/No separable connector/No connector/

shrinks some QSFP+ DAC output a bit.

remove some cruft

try to factor media information out and use it for qsfp as well as sfp.

qsfp and xfp have remarkably similar layouts, so we can use the
same code to print media for both. sfp and xfp/qsfp generally have
the same fields, just in different register locations and with some
different scales/factors for some values. this change provides a
map of these differences as structs for the sfp and qsfp/xfp layouts.

the big difference between sfp, xfp, and qsfp that still remains
is how they interpret the wavelength field. qsfp stores either optic
wavelength in units of 0.05nm, or a couple of copper cable attenuation
values in dB at different frequencies. sfp stores wavelength in nm
units, but has magic values to blacklist copper cables with. xfp
stores wavelength in 0.05 nm units, so more like like qsfp. right
now the code uses the sfp behaviour, which means qsfp will show a
weird wavelength for copper cables when it shouldnt. i'm still
trying to figure out the least worst way to handle that, but at
least it looks right for optics now.

print more qsfp temperature information

this shows the maximum case temperature reported by the chip, and
the low and high alarm ranges for temp and vcc when page 3 is
available and working.

this will hopefully give deraadt@ a better idea about how much
headroom one of his 100g optics has.

have a go at printing more monitoring information.

this is a bit rough, but a good start. apart from the media types
and length, qsfp support should be on par with sfp modules now.

make a start at reporting qsfp monitor values.

i have some qsfp DACs and a couple of optics, and they're all
terrible, so this is about as far as i can go for now. at least the
code will be robust in the face of terrible modules though.

the DACs are pretty dumb and basically report that they're DACs
with some strings. this code just prints that they're DACs with
strings now.

modules are supposed to be able to report overall temperature and
voltage, and optics can report tx and rx values for the 4 different
signal lanes they're supposed to provide. interestingly the current
values are always reported in the lower page, but thresholds are
reported in page 3, but not all modules support page switching.
devices are supposed to say whether they can switch pages, but i
have one that does say it can switch but then doesn't. anyway, the
take away is that it is therefore possible for a module to report
values without also
reporting thresholds.

this sets the code up to report the values on their own if we can't
query page 3 for any reason.

if the temp sensor value looks bogus (ie, 0x0000 or 0xffff), assume
the monitor values are bogus and bail early.

hopefully i can find a module soon that supports multiple signal
lanes and actually reports their values and thresholds for them.

Fix a missing carriage return.

OK deraadt@

restore some missing error handling

ethtool indicates that QSFP, QSFP+ and QSFP28 are all SFF-8636 compat.

follow the basic xfp support with basic qsfp+ support

qsfp was originally defined in SFF-8436, but the management interface
now seems to be managed in SFF-8636, so this uses sff8636 as a
prefix for qsfp things. the same spec applies to qsfp+ and probably
qsfp28.

XFP and QSFP share a bunch of offsets for where strings are located,
so this factors out the printing of those strings from the xfp code
and uses it from both the xfp and qsfp handling.

i have a qsfp+ to 4x sfp+ cable that looks like this with the new
code:

transceiver: QSFP+
model: Amphenol 601110005 rev A
serial: CN0HVVVFxxxxxxx date: 2013-04-18

if i ever get a pair of optics i can work on the diags

basic support for dumping xfp info

xfp uses a different page layout compared to sfp. xfp uses info in
INF-8077, not SFF-8472, and by default provides the info at page
1, not 0.

myx(4) supports xfp modules, but doesn't support i2c writes so it
cannot change the page the chip is looking at. it appears that myx
defaults to page 1 for xfp, so if the first read of page 0 fails
with ENXIO, try to read page 1 instead.

a 10G-PCIE-8A-R myx with the only xfp module i could find lying
around looks like this:

transceiver: XFP
model: Intel Corp TXN181070850X1J rev B3
serial: USC2048M95 date: 2005-04-13

im not sure if it's worth spending much more time on these though..

print transceiver supported distances, ok deraadt

print transceiver information inline with standard interface details
(like media/joinlist do) rather than totally separate; this also allows
"ifconfig -a sff" or "ifconfig ix sff".

tweak display format to make it look closer to the standard lines.

ok deraadt

use AOC and DAC instead of standard's names "optical / copper pigtail"
because these are the commonly used terminology
ok claudio sthen

MPO cable names were swapped

use correct printf format for current dBm values
problem spotted by Hrvoje, thank you!

ok deraadt

Tweak transceiver information printing, adding a bit more information
in less space. Adds wavelength, printing alarm low/high thresholds, and
prints a flag for warning or alarm indications. "i like it" deraadt@

add support for fetching and parsing SFF module info and diags

this is very basic, and will get cut up a lot by sthen@ soon, but
it was enough to get us started with. at the moment it shows the
type of module, some vendor and products strings, and detects if
the device supports diag and then shows it. qsfp info is structured
very differently, but i'll let sfp support settle before trying to
make it look the same.

so far only ix(4) and some ixl(4) with up to date firmware implement
the backend ioctl for this. no em(4) yet :(

suggestions from mikeb@
ok deraadt@ sthen@

this was started because of a question from rachel roch

fix a comparison which generated a warning on sparc64.

found by deraadt@

make the list of OM fibre distances go OM1, OM2, OM3, not OM2, OM1, OM3

s/No separable connector/No connector/

shrinks some QSFP+ DAC output a bit.

remove some cruft

try to factor media information out and use it for qsfp as well as sfp.

qsfp and xfp have remarkably similar layouts, so we can use the
same code to print media for both. sfp and xfp/qsfp generally have
the same fields, just in different register locations and with some
different scales/factors for some values. this change provides a
map of these differences as structs for the sfp and qsfp/xfp layouts.

the big difference between sfp, xfp, and qsfp that still remains
is how they interpret the wavelength field. qsfp stores either optic
wavelength in units of 0.05nm, or a couple of copper cable attenuation
values in dB at different frequencies. sfp stores wavelength in nm
units, but has magic values to blacklist copper cables with. xfp
stores wavelength in 0.05 nm units, so more like like qsfp. right
now the code uses the sfp behaviour, which means qsfp will show a
weird wavelength for copper cables when it shouldnt. i'm still
trying to figure out the least worst way to handle that, but at
least it looks right for optics now.

print more qsfp temperature information

this shows the maximum case temperature reported by the chip, and
the low and high alarm ranges for temp and vcc when page 3 is
available and working.

this will hopefully give deraadt@ a better idea about how much
headroom one of his 100g optics has.

have a go at printing more monitoring information.

this is a bit rough, but a good start. apart from the media types
and length, qsfp support should be on par with sfp modules now.

make a start at reporting qsfp monitor values.

i have some qsfp DACs and a couple of optics, and they're all
terrible, so this is about as far as i can go for now. at least the
code will be robust in the face of terrible modules though.

the DACs are pretty dumb and basically report that they're DACs
with some strings. this code just prints that they're DACs with
strings now.

modules are supposed to be able to report overall temperature and
voltage, and optics can report tx and rx values for the 4 different
signal lanes they're supposed to provide. interestingly the current
values are always reported in the lower page, but thresholds are
reported in page 3, but not all modules support page switching.
devices are supposed to say whether they can switch pages, but i
have one that does say it can switch but then doesn't. anyway, the
take away is that it is therefore possible for a module to report
values without also
reporting thresholds.

this sets the code up to report the values on their own if we can't
query page 3 for any reason.

if the temp sensor value looks bogus (ie, 0x0000 or 0xffff), assume
the monitor values are bogus and bail early.

hopefully i can find a module soon that supports multiple signal
lanes and actually reports their values and thresholds for them.

Fix a missing carriage return.

OK deraadt@

restore some missing error handling

ethtool indicates that QSFP, QSFP+ and QSFP28 are all SFF-8636 compat.

follow the basic xfp support with basic qsfp+ support

qsfp was originally defined in SFF-8436, but the management interface
now seems to be managed in SFF-8636, so this uses sff8636 as a
prefix for qsfp things. the same spec applies to qsfp+ and probably
qsfp28.

XFP and QSFP share a bunch of offsets for where strings are located,
so this factors out the printing of those strings from the xfp code
and uses it from both the xfp and qsfp handling.

i have a qsfp+ to 4x sfp+ cable that looks like this with the new
code:

transceiver: QSFP+
model: Amphenol 601110005 rev A
serial: CN0HVVVFxxxxxxx date: 2013-04-18

if i ever get a pair of optics i can work on the diags

basic support for dumping xfp info

xfp uses a different page layout compared to sfp. xfp uses info in
INF-8077, not SFF-8472, and by default provides the info at page
1, not 0.

myx(4) supports xfp modules, but doesn't support i2c writes so it
cannot change the page the chip is looking at. it appears that myx
defaults to page 1 for xfp, so if the first read of page 0 fails
with ENXIO, try to read page 1 instead.

a 10G-PCIE-8A-R myx with the only xfp module i could find lying
around looks like this:

transceiver: XFP
model: Intel Corp TXN181070850X1J rev B3
serial: USC2048M95 date: 2005-04-13

im not sure if it's worth spending much more time on these though..

print transceiver supported distances, ok deraadt

print transceiver information inline with standard interface details
(like media/joinlist do) rather than totally separate; this also allows
"ifconfig -a sff" or "ifconfig ix sff".

tweak display format to make it look closer to the standard lines.

ok deraadt

use AOC and DAC instead of standard's names "optical / copper pigtail"
because these are the commonly used terminology
ok claudio sthen

MPO cable names were swapped

use correct printf format for current dBm values
problem spotted by Hrvoje, thank you!

ok deraadt

Tweak transceiver information printing, adding a bit more information
in less space. Adds wavelength, printing alarm low/high thresholds, and
prints a flag for warning or alarm indications. "i like it" deraadt@

add support for fetching and parsing SFF module info and diags

this is very basic, and will get cut up a lot by sthen@ soon, but
it was enough to get us started with. at the moment it shows the
type of module, some vendor and products strings, and detects if
the device supports diag and then shows it. qsfp info is structured
very differently, but i'll let sfp support settle before trying to
make it look the same.

so far only ix(4) and some ixl(4) with up to date firmware implement
the backend ioctl for this. no em(4) yet :(

suggestions from mikeb@
ok deraadt@ sthen@

this was started because of a question from rachel roch

s/No separable connector/No connector/

shrinks some QSFP+ DAC output a bit.

remove some cruft

try to factor media information out and use it for qsfp as well as sfp.

qsfp and xfp have remarkably similar layouts, so we can use the
same code to print media for both. sfp and xfp/qsfp generally have
the same fields, just in different register locations and with some
different scales/factors for some values. this change provides a
map of these differences as structs for the sfp and qsfp/xfp layouts.

the big difference between sfp, xfp, and qsfp that still remains
is how they interpret the wavelength field. qsfp stores either optic
wavelength in units of 0.05nm, or a couple of copper cable attenuation
values in dB at different frequencies. sfp stores wavelength in nm
units, but has magic values to blacklist copper cables with. xfp
stores wavelength in 0.05 nm units, so more like like qsfp. right
now the code uses the sfp behaviour, which means qsfp will show a
weird wavelength for copper cables when it shouldnt. i'm still
trying to figure out the least worst way to handle that, but at
least it looks right for optics now.

print more qsfp temperature information

this shows the maximum case temperature reported by the chip, and
the low and high alarm ranges for temp and vcc when page 3 is
available and working.

this will hopefully give deraadt@ a better idea about how much
headroom one of his 100g optics has.

have a go at printing more monitoring information.

this is a bit rough, but a good start. apart from the media types
and length, qsfp support should be on par with sfp modules now.

make a start at reporting qsfp monitor values.

i have some qsfp DACs and a couple of optics, and they're all
terrible, so this is about as far as i can go for now. at least the
code will be robust in the face of terrible modules though.

the DACs are pretty dumb and basically report that they're DACs
with some strings. this code just prints that they're DACs with
strings now.

modules are supposed to be able to report overall temperature and
voltage, and optics can report tx and rx values for the 4 different
signal lanes they're supposed to provide. interestingly the current
values are always reported in the lower page, but thresholds are
reported in page 3, but not all modules support page switching.
devices are supposed to say whether they can switch pages, but i
have one that does say it can switch but then doesn't. anyway, the
take away is that it is therefore possible for a module to report
values without also
reporting thresholds.

this sets the code up to report the values on their own if we can't
query page 3 for any reason.

if the temp sensor value looks bogus (ie, 0x0000 or 0xffff), assume
the monitor values are bogus and bail early.

hopefully i can find a module soon that supports multiple signal
lanes and actually reports their values and thresholds for them.

Fix a missing carriage return.

OK deraadt@

restore some missing error handling

ethtool indicates that QSFP, QSFP+ and QSFP28 are all SFF-8636 compat.

follow the basic xfp support with basic qsfp+ support

qsfp was originally defined in SFF-8436, but the management interface
now seems to be managed in SFF-8636, so this uses sff8636 as a
prefix for qsfp things. the same spec applies to qsfp+ and probably
qsfp28.

XFP and QSFP share a bunch of offsets for where strings are located,
so this factors out the printing of those strings from the xfp code
and uses it from both the xfp and qsfp handling.

i have a qsfp+ to 4x sfp+ cable that looks like this with the new
code:

transceiver: QSFP+
model: Amphenol 601110005 rev A
serial: CN0HVVVFxxxxxxx date: 2013-04-18

if i ever get a pair of optics i can work on the diags

basic support for dumping xfp info

xfp uses a different page layout compared to sfp. xfp uses info in
INF-8077, not SFF-8472, and by default provides the info at page
1, not 0.

myx(4) supports xfp modules, but doesn't support i2c writes so it
cannot change the page the chip is looking at. it appears that myx
defaults to page 1 for xfp, so if the first read of page 0 fails
with ENXIO, try to read page 1 instead.

a 10G-PCIE-8A-R myx with the only xfp module i could find lying
around looks like this:

transceiver: XFP
model: Intel Corp TXN181070850X1J rev B3
serial: USC2048M95 date: 2005-04-13

im not sure if it's worth spending much more time on these though..

print transceiver supported distances, ok deraadt

print transceiver information inline with standard interface details
(like media/joinlist do) rather than totally separate; this also allows
"ifconfig -a sff" or "ifconfig ix sff".

tweak display format to make it look closer to the standard lines.

ok deraadt

use AOC and DAC instead of standard's names "optical / copper pigtail"
because these are the commonly used terminology
ok claudio sthen

MPO cable names were swapped

use correct printf format for current dBm values
problem spotted by Hrvoje, thank you!

ok deraadt

Tweak transceiver information printing, adding a bit more information
in less space. Adds wavelength, printing alarm low/high thresholds, and
prints a flag for warning or alarm indications. "i like it" deraadt@

add support for fetching and parsing SFF module info and diags

this is very basic, and will get cut up a lot by sthen@ soon, but
it was enough to get us started with. at the moment it shows the
type of module, some vendor and products strings, and detects if
the device supports diag and then shows it. qsfp info is structured
very differently, but i'll let sfp support settle before trying to
make it look the same.

so far only ix(4) and some ixl(4) with up to date firmware implement
the backend ioctl for this. no em(4) yet :(

suggestions from mikeb@
ok deraadt@ sthen@

this was started because of a question from rachel roch

make a start at reporting qsfp monitor values.

i have some qsfp DACs and a couple of optics, and they're all
terrible, so this is about as far as i can go for now. at least the
code will be robust in the face of terrible modules though.

the DACs are pretty dumb and basically report that they're DACs
with some strings. this code just prints that they're DACs with
strings now.

modules are supposed to be able to report overall temperature and
voltage, and optics can report tx and rx values for the 4 different
signal lanes they're supposed to provide. interestingly the current
values are always reported in the lower page, but thresholds are
reported in page 3, but not all modules support page switching.
devices are supposed to say whether they can switch pages, but i
have one that does say it can switch but then doesn't. anyway, the
take away is that it is therefore possible for a module to report
values without also
reporting thresholds.

this sets the code up to report the values on their own if we can't
query page 3 for any reason.

if the temp sensor value looks bogus (ie, 0x0000 or 0xffff), assume
the monitor values are bogus and bail early.

hopefully i can find a module soon that supports multiple signal
lanes and actually reports their values and thresholds for them.

Fix a missing carriage return.

OK deraadt@

restore some missing error handling

ethtool indicates that QSFP, QSFP+ and QSFP28 are all SFF-8636 compat.

follow the basic xfp support with basic qsfp+ support

qsfp was originally defined in SFF-8436, but the management interface
now seems to be managed in SFF-8636, so this uses sff8636 as a
prefix for qsfp things. the same spec applies to qsfp+ and probably
qsfp28.

XFP and QSFP share a bunch of offsets for where strings are located,
so this factors out the printing of those strings from the xfp code
and uses it from both the xfp and qsfp handling.

i have a qsfp+ to 4x sfp+ cable that looks like this with the new
code:

transceiver: QSFP+
model: Amphenol 601110005 rev A
serial: CN0HVVVFxxxxxxx date: 2013-04-18

if i ever get a pair of optics i can work on the diags

basic support for dumping xfp info

xfp uses a different page layout compared to sfp. xfp uses info in
INF-8077, not SFF-8472, and by default provides the info at page
1, not 0.

myx(4) supports xfp modules, but doesn't support i2c writes so it
cannot change the page the chip is looking at. it appears that myx
defaults to page 1 for xfp, so if the first read of page 0 fails
with ENXIO, try to read page 1 instead.

a 10G-PCIE-8A-R myx with the only xfp module i could find lying
around looks like this:

transceiver: XFP
model: Intel Corp TXN181070850X1J rev B3
serial: USC2048M95 date: 2005-04-13

im not sure if it's worth spending much more time on these though..

print transceiver supported distances, ok deraadt

print transceiver information inline with standard interface details
(like media/joinlist do) rather than totally separate; this also allows
"ifconfig -a sff" or "ifconfig ix sff".

tweak display format to make it look closer to the standard lines.

ok deraadt

use AOC and DAC instead of standard's names "optical / copper pigtail"
because these are the commonly used terminology
ok claudio sthen

MPO cable names were swapped

use correct printf format for current dBm values
problem spotted by Hrvoje, thank you!

ok deraadt

Tweak transceiver information printing, adding a bit more information
in less space. Adds wavelength, printing alarm low/high thresholds, and
prints a flag for warning or alarm indications. "i like it" deraadt@

add support for fetching and parsing SFF module info and diags

this is very basic, and will get cut up a lot by sthen@ soon, but
it was enough to get us started with. at the moment it shows the
type of module, some vendor and products strings, and detects if
the device supports diag and then shows it. qsfp info is structured
very differently, but i'll let sfp support settle before trying to
make it look the same.

so far only ix(4) and some ixl(4) with up to date firmware implement
the backend ioctl for this. no em(4) yet :(

suggestions from mikeb@
ok deraadt@ sthen@

this was started because of a question from rachel roch

Fix a missing carriage return.

OK deraadt@

restore some missing error handling

ethtool indicates that QSFP, QSFP+ and QSFP28 are all SFF-8636 compat.

follow the basic xfp support with basic qsfp+ support

qsfp was originally defined in SFF-8436, but the management interface
now seems to be managed in SFF-8636, so this uses sff8636 as a
prefix for qsfp things. the same spec applies to qsfp+ and probably
qsfp28.

XFP and QSFP share a bunch of offsets for where strings are located,
so this factors out the printing of those strings from the xfp code
and uses it from both the xfp and qsfp handling.

i have a qsfp+ to 4x sfp+ cable that looks like this with the new
code:

transceiver: QSFP+
model: Amphenol 601110005 rev A
serial: CN0HVVVFxxxxxxx date: 2013-04-18

if i ever get a pair of optics i can work on the diags

basic support for dumping xfp info

xfp uses a different page layout compared to sfp. xfp uses info in
INF-8077, not SFF-8472, and by default provides the info at page
1, not 0.

myx(4) supports xfp modules, but doesn't support i2c writes so it
cannot change the page the chip is looking at. it appears that myx
defaults to page 1 for xfp, so if the first read of page 0 fails
with ENXIO, try to read page 1 instead.

a 10G-PCIE-8A-R myx with the only xfp module i could find lying
around looks like this:

transceiver: XFP
model: Intel Corp TXN181070850X1J rev B3
serial: USC2048M95 date: 2005-04-13

im not sure if it's worth spending much more time on these though..

print transceiver supported distances, ok deraadt

print transceiver information inline with standard interface details
(like media/joinlist do) rather than totally separate; this also allows
"ifconfig -a sff" or "ifconfig ix sff".

tweak display format to make it look closer to the standard lines.

ok deraadt

use AOC and DAC instead of standard's names "optical / copper pigtail"
because these are the commonly used terminology
ok claudio sthen

MPO cable names were swapped

use correct printf format for current dBm values
problem spotted by Hrvoje, thank you!

ok deraadt

Tweak transceiver information printing, adding a bit more information
in less space. Adds wavelength, printing alarm low/high thresholds, and
prints a flag for warning or alarm indications. "i like it" deraadt@

add support for fetching and parsing SFF module info and diags

this is very basic, and will get cut up a lot by sthen@ soon, but
it was enough to get us started with. at the moment it shows the
type of module, some vendor and products strings, and detects if
the device supports diag and then shows it. qsfp info is structured
very differently, but i'll let sfp support settle before trying to
make it look the same.

so far only ix(4) and some ixl(4) with up to date firmware implement
the backend ioctl for this. no em(4) yet :(

suggestions from mikeb@
ok deraadt@ sthen@

this was started because of a question from rachel roch