<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h, branch linux-6.18.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.18.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.18.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2024-12-03T18:11:53Z</updated>
<entry>
<title>ixgbe: Correct BASE-BX10 compliance code</title>
<updated>2024-12-03T18:11:53Z</updated>
<author>
<name>Tore Amundsen</name>
<email>tore@amundsen.org</email>
</author>
<published>2024-11-15T14:17:36Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f72ce14b231f7bf06088e4e50f1875f1e35f79d7'/>
<id>urn:sha1:f72ce14b231f7bf06088e4e50f1875f1e35f79d7</id>
<content type='text'>
SFF-8472 (section 5.4 Transceiver Compliance Codes) defines bit 6 as
BASE-BX10. Bit 6 means a value of 0x40 (decimal 64).

The current value in the source code is 0x64, which appears to be a
mix-up of hex and decimal values. A value of 0x64 (binary 01100100)
incorrectly sets bit 2 (1000BASE-CX) and bit 5 (100BASE-FX) as well.

Fixes: 1b43e0d20f2d ("ixgbe: Add 1000BASE-BX support")
Signed-off-by: Tore Amundsen &lt;tore@amundsen.org&gt;
Reviewed-by: Paul Menzel &lt;pmenzel@molgen.mpg.de&gt;
Acked-by: Ernesto Castellotti &lt;ernesto@castellotti.net&gt;
Tested-by: Pucha Himasekhar Reddy &lt;himasekharx.reddy.pucha@intel.com&gt; (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
<entry>
<title>ixgbe: Add 1000BASE-BX support</title>
<updated>2024-03-05T04:49:58Z</updated>
<author>
<name>Ernesto Castellotti</name>
<email>ernesto@castellotti.net</email>
</author>
<published>2024-03-01T18:48:03Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1b43e0d20f2d007ec4c124b0deaa848ff8d61f4a'/>
<id>urn:sha1:1b43e0d20f2d007ec4c124b0deaa848ff8d61f4a</id>
<content type='text'>
Added support for 1000BASE-BX, i.e. Gigabit Ethernet over single strand
of single-mode fiber.
The initialization of a 1000BASE-BX SFP is the same as 1000BASE-SX/LX
with the only difference that the Bit Rate Nominal Value must be
checked to make sure it is a Gigabit Ethernet transceiver, as described
by the SFF-8472 specification.

This was tested with the FS.com SFP-GE-BX 1310/1490nm 10km transceiver:
$ ethtool -m eth4
        Identifier                                : 0x03 (SFP)
        Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
        Connector                                 : 0x07 (LC)
        Transceiver codes                         : 0x00 0x00 0x00 0x40 0x00 0x00 0x00 0x00 0x00
        Transceiver type                          : Ethernet: BASE-BX10
        Encoding                                  : 0x01 (8B/10B)
        BR, Nominal                               : 1300MBd
        Rate identifier                           : 0x00 (unspecified)
        Length (SMF,km)                           : 10km
        Length (SMF)                              : 10000m
        Length (50um)                             : 0m
        Length (62.5um)                           : 0m
        Length (Copper)                           : 0m
        Length (OM3)                              : 0m
        Laser wavelength                          : 1310nm
        Vendor name                               : FS
        Vendor OUI                                : 64:9d:99
        Vendor PN                                 : SFP-GE-BX
        Vendor rev                                :
        Option values                             : 0x20 0x0a
        Option                                    : RX_LOS implemented
        Option                                    : TX_FAULT implemented
        Option                                    : Power level 3 requirement
        BR margin, max                            : 0%
        BR margin, min                            : 0%
        Vendor SN                                 : S2202359108
        Date code                                 : 220307
        Optical diagnostics support               : Yes
        Laser bias current                        : 17.650 mA
        Laser output power                        : 0.2132 mW / -6.71 dBm
        Receiver signal average optical power     : 0.2740 mW / -5.62 dBm
        Module temperature                        : 47.30 degrees C / 117.13 degrees F
        Module voltage                            : 3.2576 V
        Alarm/warning flags implemented           : Yes
        Laser bias current high alarm             : Off
        Laser bias current low alarm              : Off
        Laser bias current high warning           : Off
        Laser bias current low warning            : Off
        Laser output power high alarm             : Off
        Laser output power low alarm              : Off
        Laser output power high warning           : Off
        Laser output power low warning            : Off
        Module temperature high alarm             : Off
        Module temperature low alarm              : Off
        Module temperature high warning           : Off
        Module temperature low warning            : Off
        Module voltage high alarm                 : Off
        Module voltage low alarm                  : Off
        Module voltage high warning               : Off
        Module voltage low warning                : Off
        Laser rx power high alarm                 : Off
        Laser rx power low alarm                  : Off
        Laser rx power high warning               : Off
        Laser rx power low warning                : Off
        Laser bias current high alarm threshold   : 110.000 mA
        Laser bias current low alarm threshold    : 1.000 mA
        Laser bias current high warning threshold : 100.000 mA
        Laser bias current low warning threshold  : 1.000 mA
        Laser output power high alarm threshold   : 0.7079 mW / -1.50 dBm
        Laser output power low alarm threshold    : 0.0891 mW / -10.50 dBm
        Laser output power high warning threshold : 0.6310 mW / -2.00 dBm
        Laser output power low warning threshold  : 0.1000 mW / -10.00 dBm
        Module temperature high alarm threshold   : 90.00 degrees C / 194.00 degrees F
        Module temperature low alarm threshold    : -45.00 degrees C / -49.00 degrees F
        Module temperature high warning threshold : 85.00 degrees C / 185.00 degrees F
        Module temperature low warning threshold  : -40.00 degrees C / -40.00 degrees F
        Module voltage high alarm threshold       : 3.7950 V
        Module voltage low alarm threshold        : 2.8050 V
        Module voltage high warning threshold     : 3.4650 V
        Module voltage low warning threshold      : 3.1350 V
        Laser rx power high alarm threshold       : 0.7079 mW / -1.50 dBm
        Laser rx power low alarm threshold        : 0.0028 mW / -25.53 dBm
        Laser rx power high warning threshold     : 0.6310 mW / -2.00 dBm
        Laser rx power low warning threshold      : 0.0032 mW / -24.95 dBm

Signed-off-by: Ernesto Castellotti &lt;ernesto@castellotti.net&gt;
Reviewed-by: Przemek Kitszel &lt;przemyslaw.kitszel@intel.com&gt;
Tested-by: Sunitha Mekala &lt;sunithax.d.mekala@intel.com&gt; (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
Link: https://lore.kernel.org/r/20240301184806.2634508-3-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>ixgbe: Convert ret val type from s32 to int</title>
<updated>2024-02-06T21:17:14Z</updated>
<author>
<name>Jedrzej Jagielski</name>
<email>jedrzej.jagielski@intel.com</email>
</author>
<published>2024-01-31T11:04:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8f76c0f4c3ce489a7616f712fc08c032582145d9'/>
<id>urn:sha1:8f76c0f4c3ce489a7616f712fc08c032582145d9</id>
<content type='text'>
Currently big amount of the functions returning standard error codes
are of type s32. Convert them to regular ints as typdefs here are not
necessary to return standard error codes.

Fix incorrect args alignment in touched functions.

Suggested-by: Jacob Keller &lt;jacob.e.keller@intel.com&gt;
Reviewed-by: Jacob Keller &lt;jacob.e.keller@intel.com&gt;
Reviewed-by: Simon Horman &lt;horms@kernel.org&gt;
Signed-off-by: Jedrzej Jagielski &lt;jedrzej.jagielski@intel.com&gt;
Tested-by: Pucha Himasekhar Reddy &lt;himasekharx.reddy.pucha@intel.com&gt; (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
<entry>
<title>ixgbe: Refactor overtemp event handling</title>
<updated>2024-01-02T21:30:26Z</updated>
<author>
<name>Jedrzej Jagielski</name>
<email>jedrzej.jagielski@intel.com</email>
</author>
<published>2023-12-18T10:39:25Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6c1b4af8c1b20c70dde01e58381685d6a4a1d2c8'/>
<id>urn:sha1:6c1b4af8c1b20c70dde01e58381685d6a4a1d2c8</id>
<content type='text'>
Currently ixgbe driver is notified of overheating events
via internal IXGBE_ERR_OVERTEMP error code.

Change the approach for handle_lasi() to use freshly introduced
is_overtemp function parameter which set when such event occurs.
Change check_overtemp() to bool and return true if overtemp
event occurs.

Reviewed-by: Przemek Kitszel &lt;przemyslaw.kitszel@intel.com&gt;
Signed-off-by: Jedrzej Jagielski &lt;jedrzej.jagielski@intel.com&gt;
Reviewed-by: Jacob Keller &lt;jacob.e.keller@intel.com&gt;
Reviewed-by: Simon Horman &lt;horms@kernel.org&gt;
Tested-by: Sunitha Mekala &lt;sunithax.d.mekala@intel.com&gt; (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
<entry>
<title>ixgbe: Check DDM existence in transceiver before access</title>
<updated>2019-06-26T16:18:54Z</updated>
<author>
<name>Mauro S. M. Rodrigues</name>
<email>maurosr@linux.vnet.ibm.com</email>
</author>
<published>2019-05-23T19:11:12Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=655c91414579d7bb115a4f7898ee726fc18e0984'/>
<id>urn:sha1:655c91414579d7bb115a4f7898ee726fc18e0984</id>
<content type='text'>
Some transceivers may comply with SFF-8472 but not implement the Digital
Diagnostic Monitoring (DDM) interface described in it. The existence of
such area is specified by bit 6 of byte 92, set to 1 if implemented.

Currently, due to not checking this bit ixgbe fails trying to read SFP
module's eeprom with the follow message:

ethtool -m enP51p1s0f0
Cannot get Module EEPROM data: Input/output error

Because it fails to read the additional 256 bytes in which it was assumed
to exist the DDM data.

This issue was noticed using a Mellanox Passive DAC PN 01FT738. The eeprom
data was confirmed by Mellanox as correct and present in other Passive
DACs in from other manufacturers.

Signed-off-by: "Mauro S. M. Rodrigues" &lt;maurosr@linux.vnet.ibm.com&gt;
Reviewed-by: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
</entry>
<entry>
<title>ixgbe: register a mdiobus</title>
<updated>2018-12-20T20:19:11Z</updated>
<author>
<name>Steve Douthit</name>
<email>stephend@silicom-usa.com</email>
</author>
<published>2018-12-06T15:50:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8fa10ef01260937eb540b4e9bbc3efa023595993'/>
<id>urn:sha1:8fa10ef01260937eb540b4e9bbc3efa023595993</id>
<content type='text'>
Most dsa devices expect a 'struct mii_bus' pointer to talk to switches
via the MII interface.

While this works for dsa devices, it will not work safely with Linux
PHYs in all configurations since the firmware of the ixgbe device may
be polling some PHY addresses in the background.

Signed-off-by: Stephen Douthit &lt;stephend@silicom-usa.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
</entry>
<entry>
<title>net: intel: Cleanup the copyright/license headers</title>
<updated>2018-04-27T18:00:04Z</updated>
<author>
<name>Jeff Kirsher</name>
<email>jeffrey.t.kirsher@intel.com</email>
</author>
<published>2018-04-26T15:08:09Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=51dce24bcdbdc493a87a17bcaf898b1f1d2fa600'/>
<id>urn:sha1:51dce24bcdbdc493a87a17bcaf898b1f1d2fa600</id>
<content type='text'>
After many years of having a ~30 line copyright and license header to our
source files, we are finally able to reduce that to one line with the
advent of the SPDX identifier.

Also caught a few files missing the SPDX license identifier, so fixed
them up.

Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Acked-by: Shannon Nelson &lt;shannon.nelson@oracle.com&gt;
Acked-by: Richard Cochran &lt;richardcochran@gmail.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>intel: add SPDX identifiers to all the Intel drivers</title>
<updated>2018-03-23T16:18:21Z</updated>
<author>
<name>Jeff Kirsher</name>
<email>jeffrey.t.kirsher@intel.com</email>
</author>
<published>2018-03-22T17:08:48Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ae06c70b135886d7d6252f3090146f01a3f3b80c'/>
<id>urn:sha1:ae06c70b135886d7d6252f3090146f01a3f3b80c</id>
<content type='text'>
Add the SPDX identifiers to all the Intel wired LAN driver files, as
outlined in Documentation/process/license-rules.rst.

Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ixgbe: correct CS4223/7 PHY identification</title>
<updated>2017-05-31T11:48:19Z</updated>
<author>
<name>Emil Tantilov</name>
<email>emil.s.tantilov@intel.com</email>
</author>
<published>2017-05-17T22:17:41Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=cc1de78c2a3d936d733bc9bd3f6e0655d03c2fb7'/>
<id>urn:sha1:cc1de78c2a3d936d733bc9bd3f6e0655d03c2fb7</id>
<content type='text'>
Previous method was unreliable. Use a different register to
differentiate between the SKUs.

Signed-off-by: Emil Tantilov &lt;emil.s.tantilov@intel.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
</entry>
<entry>
<title>ixgbe: Remove unused firmware version functions and method</title>
<updated>2017-01-03T21:03:38Z</updated>
<author>
<name>Mark Rustad</name>
<email>mark.d.rustad@intel.com</email>
</author>
<published>2016-12-14T19:02:06Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d2a10ae72ed61759638ec06927bc9850c278d310'/>
<id>urn:sha1:d2a10ae72ed61759638ec06927bc9850c278d310</id>
<content type='text'>
The firmware version method and functions are not used anywhere, so
remove them all.

Signed-off-by: Mark Rustad &lt;mark.d.rustad@intel.com&gt;
Tested-by: Krishneil Singh &lt;krishneil.k.singh@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
</entry>
</feed>
