<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/phy/phylink.c, branch v5.10.264</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.264</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.264'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2023-11-28T16:55:00+00:00</updated>
<entry>
<title>net: phylink: initialize carrier state at creation</title>
<updated>2023-11-28T16:55:00+00:00</updated>
<author>
<name>Klaus Kudielka</name>
<email>klaus.kudielka@gmail.com</email>
</author>
<published>2023-11-07T17:44:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=430603f6de337bd47369d0e6922088bf83442d79'/>
<id>urn:sha1:430603f6de337bd47369d0e6922088bf83442d79</id>
<content type='text'>
commit 02d5fdbf4f2b8c406f7a4c98fa52aa181a11d733 upstream.

Background: Turris Omnia (Armada 385); eth2 (mvneta) connected to SFP bus;
SFP module is present, but no fiber connected, so definitely no carrier.

After booting, eth2 is down, but netdev LED trigger surprisingly reports
link active. Then, after "ip link set eth2 up", the link indicator goes
away - as I would have expected it from the beginning.

It turns out, that the default carrier state after netdev creation is
"carrier ok". Some ethernet drivers explicitly call netif_carrier_off
during probing, others (like mvneta) don't - which explains the current
behaviour: only when the device is brought up, phylink_start calls
netif_carrier_off.

Fix this for all drivers using phylink, by calling netif_carrier_off in
phylink_create.

Fixes: 089381b27abe ("leds: initial support for Turris Omnia LEDs")
Cc: stable@vger.kernel.org
Suggested-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: Klaus Kudielka &lt;klaus.kudielka@gmail.com&gt;
Reviewed-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: phylink: Force retrigger in case of latched link-fail indicator</title>
<updated>2021-12-01T08:19:07+00:00</updated>
<author>
<name>Russell King (Oracle)</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2021-11-23T15:44:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3d4937c6a328947f980ba0e7a7f03901a2ec2aa0'/>
<id>urn:sha1:3d4937c6a328947f980ba0e7a7f03901a2ec2aa0</id>
<content type='text'>
[ Upstream commit dbae3388ea9ca33bd1d5eabc3b0ef17e69c74677 ]

On mv88e6xxx 1G/2.5G PCS, the SerDes register 4.2001.2 has the following
description:
  This register bit indicates when link was lost since the last
  read. For the current link status, read this register
  back-to-back.

Thus to get current link state, we need to read the register twice.

But doing that in the link change interrupt handler would lead to
potentially ignoring link down events, which we really want to avoid.

Thus this needs to be solved in phylink's resolve, by retriggering
another resolve in the event when PCS reports link down and previous
link was up, and by re-reading PCS state if the previous link was down.

The wrong value is read when phylink requests change from sgmii to
2500base-x mode, and link won't come up. This fixes the bug.

Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
Signed-off-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Marek Behún &lt;kabel@kernel.org&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phylink: Force link down and retrigger resolve on interface change</title>
<updated>2021-12-01T08:19:06+00:00</updated>
<author>
<name>Russell King (Oracle)</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2021-11-23T15:44:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=50162ff3c80fe8db7cfff76ecf54b9e80c5923a3'/>
<id>urn:sha1:50162ff3c80fe8db7cfff76ecf54b9e80c5923a3</id>
<content type='text'>
[ Upstream commit 80662f4fd4771bc9c7cc4abdfbe866ebd1179621 ]

On PHY state change the phylink_resolve() function can read stale
information from the MAC and report incorrect link speed and duplex to
the kernel message log.

Example with a Marvell 88X3310 PHY connected to a SerDes port on Marvell
88E6393X switch:
- PHY driver triggers state change due to PHY interface mode being
  changed from 10gbase-r to 2500base-x due to copper change in speed
  from 10Gbps to 2.5Gbps, but the PHY itself either hasn't yet changed
  its interface to the host, or the interrupt about loss of SerDes link
  hadn't arrived yet (there can be a delay of several milliseconds for
  this), so we still think that the 10gbase-r mode is up
- phylink_resolve()
  - phylink_mac_pcs_get_state()
    - this fills in speed=10g link=up
  - interface mode is updated to 2500base-x but speed is left at 10Gbps
  - phylink_major_config()
    - interface is changed to 2500base-x
  - phylink_link_up()
    - mv88e6xxx_mac_link_up()
      - .port_set_speed_duplex()
        - speed is set to 10Gbps
    - reports "Link is Up - 10Gbps/Full" to dmesg

Afterwards when the interrupt finally arrives for mv88e6xxx, another
resolve is forced in which we get the correct speed from
phylink_mac_pcs_get_state(), but since the interface is not being
changed anymore, we don't call phylink_major_config() but only
phylink_mac_config(), which does not set speed/duplex anymore.

To fix this, we need to force the link down and trigger another resolve
on PHY interface change event.

Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
Signed-off-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Marek Behún &lt;kabel@kernel.org&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phylink: avoid mvneta warning when setting pause parameters</title>
<updated>2021-11-18T13:04:12+00:00</updated>
<author>
<name>Russell King (Oracle)</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2021-10-28T14:55:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fb41b8f5e855794f180f0f8a118abeb662436a07'/>
<id>urn:sha1:fb41b8f5e855794f180f0f8a118abeb662436a07</id>
<content type='text'>
[ Upstream commit fd8d9731bcdfb22d28e45bce789bcb211c868c78 ]

mvneta does not support asymetric pause modes, and it flags this by the
lack of AsymPause in the supported field. When setting pause modes, we
check that pause-&gt;rx_pause == pause-&gt;tx_pause, but only when pause
autoneg is enabled. When pause autoneg is disabled, we still allow
pause-&gt;rx_pause != pause-&gt;tx_pause, which is incorrect when the MAC
does not support asymetric pause, and causes mvneta to issue a warning.

Fix this by removing the test for pause-&gt;autoneg, so we always check
that pause-&gt;rx_pause == pause-&gt;tx_pause for network devices that do not
support AsymPause.

Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
Signed-off-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phylink: Update SFP selected interface on advertising changes</title>
<updated>2021-09-30T08:11:05+00:00</updated>
<author>
<name>Nathan Rossi</name>
<email>nathan.rossi@digi.com</email>
</author>
<published>2021-09-02T05:14:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a632288053b7a00e08f12ea69507bc07922331c8'/>
<id>urn:sha1:a632288053b7a00e08f12ea69507bc07922331c8</id>
<content type='text'>
[ Upstream commit ea269a6f720782ed94171fb962b14ce07c372138 ]

Currently changes to the advertising state via ethtool do not cause any
reselection of the configured interface mode after the SFP is already
inserted and initially configured.

While it is not typical to change the advertised link modes for an
interface using an SFP in certain use cases it is desirable. In the case
of a SFP port that is capable of handling both SFP and SFP+ modules it
will automatically select between 1G and 10G modes depending on the
supported mode of the SFP. However if the SFP module is capable of
working in multiple modes (e.g. a SFP+ DAC that can operate at 1G or
10G), one end of the cable may be attached to a SFP 1000base-x port thus
the SFP+ end must be manually configured to the 1000base-x mode in order
for the link to be established.

This change causes the ethtool setting of advertised mode changes to
reselect the interface mode so that the link can be established.
Additionally when a module is inserted the advertising mode is reset to
match the supported modes of the module.

Signed-off-by: Nathan Rossi &lt;nathan.rossi@digi.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phylink: Fix phylink_err() function name error in phylink_major_config</title>
<updated>2021-03-30T12:31:59+00:00</updated>
<author>
<name>Ong Boon Leong</name>
<email>boon.leong.ong@intel.com</email>
</author>
<published>2021-03-15T04:33:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ddeba5b39ccadaac9abce231ead451a4baaff77c'/>
<id>urn:sha1:ddeba5b39ccadaac9abce231ead451a4baaff77c</id>
<content type='text'>
[ Upstream commit d82c6c1aaccd2877b6082cebcb1746a13648a16d ]

if pl-&gt;mac_ops-&gt;mac_finish() failed, phylink_err should use
"mac_finish" instead of "mac_prepare".

Fixes: b7ad14c2fe2d4 ("net: phylink: re-implement interface configuration with PCS")
Signed-off-by: Ong Boon Leong &lt;boon.leong.ong@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net</title>
<updated>2020-09-05T04:28:59+00:00</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2020-09-05T04:18:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=44a8c4f33c0073ca614db79f22e023811bdd0f3c'/>
<id>urn:sha1:44a8c4f33c0073ca614db79f22e023811bdd0f3c</id>
<content type='text'>
We got slightly different patches removing a double word
in a comment in net/ipv4/raw.c - picked the version from net.

Simple conflict in drivers/net/ethernet/ibm/ibmvnic.c. Use cached
values instead of VNIC login response buffer (following what
commit 507ebe6444a4 ("ibmvnic: Fix use-after-free of VNIC login
response buffer") did).

Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phylink: consider QSGMII interface mode in phylink_mii_c22_pcs_get_state</title>
<updated>2020-08-31T19:52:33+00:00</updated>
<author>
<name>Ioana Ciornei</name>
<email>ioana.ciornei@nxp.com</email>
</author>
<published>2020-08-30T08:33:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=29f02ee47764f6f62642ecf583266bb3538495c8'/>
<id>urn:sha1:29f02ee47764f6f62642ecf583266bb3538495c8</id>
<content type='text'>
The same link partner advertisement word is used for both QSGMII and
SGMII, thus treat both interface modes using the same
phylink_decode_sgmii_word() function.

Signed-off-by: Ioana Ciornei &lt;ioana.ciornei@nxp.com&gt;
Reviewed-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: phylink: add helper function to decode USXGMII word</title>
<updated>2020-08-31T19:52:33+00:00</updated>
<author>
<name>Ioana Ciornei</name>
<email>ioana.ciornei@nxp.com</email>
</author>
<published>2020-08-30T08:33:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=afd6220999d4932616322f8a893371f8d0567a2a'/>
<id>urn:sha1:afd6220999d4932616322f8a893371f8d0567a2a</id>
<content type='text'>
With the new addition of the USXGMII link partner ability constants we
can now introduce a phylink helper that decodes the USXGMII word and
populates the appropriate fields in the phylink_link_state structure
based on them.

Signed-off-by: Ioana Ciornei &lt;ioana.ciornei@nxp.com&gt;
Reviewed-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: phylink: avoid oops during initialisation</title>
<updated>2020-08-31T19:23:16+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2020-08-28T10:53:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e859a60add1dd3f844c94c7a782c1a16610bd192'/>
<id>urn:sha1:e859a60add1dd3f844c94c7a782c1a16610bd192</id>
<content type='text'>
If we intend to use PCS operations, mac_pcs_get_state() will not be
implemented, so will be NULL. If we also intend to register the PCS
operations in mac_prepare() or mac_config(), then this leads to an
attempt to call NULL function pointer during phylink_start(). Avoid
this, but we must report the link is down.

Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
