<feed xmlns='http://www.w3.org/2005/Atom'>
<title>blaster4385/linux-IllusionX/drivers/net/phy, branch v6.12.10</title>
<subtitle>Linux kernel with personal config changes for arch linux</subtitle>
<id>http://git.tablaster.dev/blaster4385/linux-IllusionX/atom?h=v6.12.10</id>
<link rel='self' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/atom?h=v6.12.10'/>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/'/>
<updated>2025-01-09T12:33:36Z</updated>
<entry>
<title>net: phy: micrel: Dynamically control external clock of KSZ PHY</title>
<updated>2025-01-09T12:33:36Z</updated>
<author>
<name>Wei Fang</name>
<email>wei.fang@nxp.com</email>
</author>
<published>2024-12-17T06:35:00Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=45ece2a4e3f2b5b03d945e9c31802e5029288aba'/>
<id>urn:sha1:45ece2a4e3f2b5b03d945e9c31802e5029288aba</id>
<content type='text'>
[ Upstream commit 25c6a5ab151fb9c886552bf5aa7cbf2a5c6e96af ]

On the i.MX6ULL-14x14-EVK board, enet1_ref and enet2_ref are used as the
clock sources for two external KSZ PHYs. However, after closing the two
FEC ports, the clk_enable_count of the enet1_ref and enet2_ref clocks is
not 0. The root cause is that since the commit 985329462723 ("net: phy:
micrel: use devm_clk_get_optional_enabled for the rmii-ref clock"), the
external clock of KSZ PHY has been enabled when the PHY driver probes,
and it can only be disabled when the PHY driver is removed. This causes
the clock to continue working when the system is suspended or the network
port is down.

Although Heiko explained in the commit message that the patch was because
some clock suppliers need to enable the clock to get the valid clock rate
, it seems that the simple fix is to disable the clock after getting the
clock rate to solve the current problem. This is indeed true, but we need
to admit that Heiko's patch has been applied for more than a year, and we
cannot guarantee whether there are platforms that only enable rmii-ref in
the KSZ PHY driver during this period. If this is the case, disabling
rmii-ref will cause RMII on these platforms to not work.

Secondly, commit 99ac4cbcc2a5 ("net: phy: micrel: allow usage of generic
ethernet-phy clock") just simply enables the generic clock permanently,
which seems like the generic clock may only be enabled in the PHY driver.
If we simply disable the generic clock, RMII may not work. If we keep it
as it is, the platform using the generic clock will have the same problem
as the i.MX6ULL platform.

To solve this problem, the clock is enabled when phy_driver::resume() is
called, and the clock is disabled when phy_driver::suspend() is called.
Since phy_driver::resume() and phy_driver::suspend() are not called in
pairs, an additional clk_enable flag is added. When phy_driver::suspend()
is called, the clock is disabled only if clk_enable is true. Conversely,
when phy_driver::resume() is called, the clock is enabled if clk_enable
is false.

The changes that introduced the problem were only a few lines, while the
current fix is about a hundred lines, which seems out of proportion, but
it is necessary because kszphy_probe() is used by multiple KSZ PHYs and
we need to fix all of them.

Fixes: 985329462723 ("net: phy: micrel: use devm_clk_get_optional_enabled for the rmii-ref clock")
Fixes: 99ac4cbcc2a5 ("net: phy: micrel: allow usage of generic ethernet-phy clock")
Signed-off-by: Wei Fang &lt;wei.fang@nxp.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Reviewed-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Link: https://patch.msgid.link/20241217063500.1424011-1-wei.fang@nxp.com
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: sfp: change quirks for Alcatel Lucent G-010S-P</title>
<updated>2024-12-14T19:03:50Z</updated>
<author>
<name>Shengyu Qu</name>
<email>wiagn233@outlook.com</email>
</author>
<published>2024-10-11T17:39:17Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=cdacfe413b6a4fbd8792f2c9c3d20132387458f3'/>
<id>urn:sha1:cdacfe413b6a4fbd8792f2c9c3d20132387458f3</id>
<content type='text'>
[ Upstream commit 90cb5f1776ba371478e2b08fbf7018c7bd781a8d ]

Seems Alcatel Lucent G-010S-P also have the same problem that it uses
TX_FAULT pin for SOC uart. So apply sfp_fixup_ignore_tx_fault to it.

Signed-off-by: Shengyu Qu &lt;wiagn233@outlook.com&gt;
Link: https://patch.msgid.link/TYCPR01MB84373677E45A7BFA5A28232C98792@TYCPR01MB8437.jpnprd01.prod.outlook.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: microchip: Reset LAN88xx PHY to ensure clean link state on LAN7800/7850</title>
<updated>2024-12-14T19:03:05Z</updated>
<author>
<name>Oleksij Rempel</name>
<email>o.rempel@pengutronix.de</email>
</author>
<published>2024-11-25T08:40:50Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=3027a9fe02eda2e7c08f46100456d10deb5940c0'/>
<id>urn:sha1:3027a9fe02eda2e7c08f46100456d10deb5940c0</id>
<content type='text'>
[ Upstream commit ccb989e4d1efe0dd81b28c437443532d80d9ecee ]

Fix outdated MII_LPA data in the LAN88xx PHY, which is used in LAN7800
and LAN7850 USB Ethernet controllers. Due to a hardware limitation, the
PHY cannot reliably update link status after parallel detection when the
link partner does not support auto-negotiation. To mitigate this, add a
PHY reset in `lan88xx_link_change_notify()` when `phydev-&gt;state` is
`PHY_NOLINK`, ensuring the PHY starts in a clean state and reports
accurate fixed link parallel detection results.

Fixes: 792aec47d59d9 ("add microchip LAN88xx phy driver")
Signed-off-by: Oleksij Rempel &lt;o.rempel@pengutronix.de&gt;
Link: https://patch.msgid.link/20241125084050.414352-1-o.rempel@pengutronix.de
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: phy: dp83869: fix status reporting for 1000base-x autonegotiation</title>
<updated>2024-12-09T09:40:59Z</updated>
<author>
<name>Romain Gantois</name>
<email>romain.gantois@bootlin.com</email>
</author>
<published>2024-11-12T14:06:08Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=6b29c887a63a30c769c15bddb6281abfa02e89c6'/>
<id>urn:sha1:6b29c887a63a30c769c15bddb6281abfa02e89c6</id>
<content type='text'>
commit 378e8feea9a70d37a5dc1678b7ec27df21099fa5 upstream.

The DP83869 PHY transceiver supports converting from RGMII to 1000base-x.
In this operation mode, autonegotiation can be performed, as described in
IEEE802.3.

The DP83869 has a set of fiber-specific registers located at offset 0xc00.
When the transceiver is configured in RGMII-to-1000base-x mode, these
registers are mapped onto offset 0, which should make reading the
autonegotiation status transparent.

However, the fiber registers at offset 0xc04 and 0xc05 follow the bit
layout specified in Clause 37, and genphy_read_status() assumes a Clause 22
layout. Thus, genphy_read_status() doesn't properly read the capabilities
advertised by the link partner, resulting in incorrect link parameters.

Similarly, genphy_config_aneg() doesn't properly write advertised
capabilities.

Fix the 1000base-x autonegotiation procedure by replacing
genphy_read_status() and genphy_config_aneg() with their Clause 37
equivalents.

Fixes: a29de52ba2a1 ("net: dp83869: Add ability to advertise Fiber connection")
Cc: stable@vger.kernel.org
Signed-off-by: Romain Gantois &lt;romain.gantois@bootlin.com&gt;
Link: https://patch.msgid.link/20241112-dp83869-1000base-x-v3-1-36005f4ab0d9@bootlin.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: phylink: ensure PHY momentary link-fails are handled</title>
<updated>2024-11-14T02:52:54Z</updated>
<author>
<name>Russell King (Oracle)</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2024-11-12T16:20:00Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=671154f174e0e7f242507cd074497661deb41bfd'/>
<id>urn:sha1:671154f174e0e7f242507cd074497661deb41bfd</id>
<content type='text'>
Normally, phylib won't notify changes in quick succession. However, as
a result of commit 3e43b903da04 ("net: phy: Immediately call
adjust_link if only tx_lpi_enabled changes") this is no longer true -
it is now possible that phy_link_down() and phy_link_up() will both
complete before phylink's resolver has run, which means it'll miss that
pl-&gt;phy_state.link momentarily became false.

Rename "mac_link_dropped" to be more generic "link_failed" since it will
cover more than the MAC/PCS end of the link failing, and arrange to set
this in phylink_phy_change() if we notice that the PHY reports that the
link is down.

This will ensure that we capture an EEE reconfiguration event.

Fixes: 3e43b903da04 ("net: phy: Immediately call adjust_link if only tx_lpi_enabled changes")
Signed-off-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt;
Reviewed-by: Oleksij Rempel &lt;o.rempel@pengutronix.de&gt;
Link: https://patch.msgid.link/E1tAtcW-002RBS-LB@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: ti: add PHY_RST_AFTER_CLK_EN flag</title>
<updated>2024-11-06T01:46:03Z</updated>
<author>
<name>Diogo Silva</name>
<email>diogompaissilva@gmail.com</email>
</author>
<published>2024-11-02T15:15:05Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=256748d5480bb3c4b731236c6d6fc86a8e2815d8'/>
<id>urn:sha1:256748d5480bb3c4b731236c6d6fc86a8e2815d8</id>
<content type='text'>
DP83848	datasheet (section 4.7.2) indicates that the reset pin should be
toggled after the clocks are running. Add the PHY_RST_AFTER_CLK_EN to
make sure that this indication is respected.

In my experience not having this flag enabled would lead to, on some
boots, the wrong MII mode being selected if the PHY was initialized on
the bootloader and was receiving data during Linux boot.

Signed-off-by: Diogo Silva &lt;diogompaissilva@gmail.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Fixes: 34e45ad9378c ("net: phy: dp83848: Add TI DP83848 Ethernet PHY")
Link: https://patch.msgid.link/20241102151504.811306-1-paissilva@ld-100007.ds1.internal
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: dp83822: Fix reset pin definitions</title>
<updated>2024-10-19T21:14:21Z</updated>
<author>
<name>Michel Alex</name>
<email>Alex.Michel@wiedemann-group.com</email>
</author>
<published>2024-10-16T12:11:15Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=de96f6a3003513c796bbe4e23210a446913f5c00'/>
<id>urn:sha1:de96f6a3003513c796bbe4e23210a446913f5c00</id>
<content type='text'>
This change fixes a rare issue where the PHY fails to detect a link
due to incorrect reset behavior.

The SW_RESET definition was incorrectly assigned to bit 14, which is the
Digital Restart bit according to the datasheet. This commit corrects
SW_RESET to bit 15 and assigns DIG_RESTART to bit 14 as per the
datasheet specifications.

The SW_RESET define is only used in the phy_reset function, which fully
re-initializes the PHY after the reset is performed. The change in the
bit definitions should not have any negative impact on the functionality
of the PHY.

v2:
- added Fixes tag
- improved commit message

Cc: stable@vger.kernel.org
Fixes: 5dc39fd5ef35 ("net: phy: DP83822: Add ability to advertise Fiber connection")
Signed-off-by: Alex Michel &lt;alex.michel@wiedemann-group.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Message-ID: &lt;AS1P250MB0608A798661549BF83C4B43EA9462@AS1P250MB0608.EURP250.PROD.OUTLOOK.COM&gt;
Signed-off-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
</content>
</entry>
<entry>
<title>net: phy: realtek: Fix MMD access on RTL8126A-integrated PHY</title>
<updated>2024-10-09T11:43:46Z</updated>
<author>
<name>Heiner Kallweit</name>
<email>hkallweit1@gmail.com</email>
</author>
<published>2024-10-07T09:57:41Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=a6ad589c1d118f9d5b1bc4c6888d42919f830340'/>
<id>urn:sha1:a6ad589c1d118f9d5b1bc4c6888d42919f830340</id>
<content type='text'>
All MMD reads return 0 for the RTL8126A-integrated PHY. Therefore phylib
assumes it doesn't support EEE, what results in higher power consumption,
and a significantly higher chip temperature in my case.
To fix this split out the PHY driver for the RTL8126A-integrated PHY
and set the read_mmd/write_mmd callbacks to read from vendor-specific
registers.

Fixes: 5befa3728b85 ("net: phy: realtek: add support for RTL8126A-integrated 5Gbps PHY")
Cc: stable@vger.kernel.org
Signed-off-by: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: phy: Remove LED entry from LEDs list on unregister</title>
<updated>2024-10-08T00:15:50Z</updated>
<author>
<name>Christian Marangi</name>
<email>ansuelsmth@gmail.com</email>
</author>
<published>2024-10-04T18:27:58Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=f50b5d74c68e551667e265123659b187a30fe3a5'/>
<id>urn:sha1:f50b5d74c68e551667e265123659b187a30fe3a5</id>
<content type='text'>
Commit c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct
ordering") correctly fixed a problem with using devm_ but missed
removing the LED entry from the LEDs list.

This cause kernel panic on specific scenario where the port for the PHY
is torn down and up and the kmod for the PHY is removed.

On setting the port down the first time, the assosiacted LEDs are
correctly unregistered. The associated kmod for the PHY is now removed.
The kmod is now added again and the port is now put up, the associated LED
are registered again.
On putting the port down again for the second time after these step, the
LED list now have 4 elements. With the first 2 already unregistered
previously and the 2 new one registered again.

This cause a kernel panic as the first 2 element should have been
removed.

Fix this by correctly removing the element when LED is unregistered.

Reported-by: Daniel Golle &lt;daniel@makrotopia.org&gt;
Tested-by: Daniel Golle &lt;daniel@makrotopia.org&gt;
Cc: stable@vger.kernel.org
Fixes: c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct ordering")
Signed-off-by: Christian Marangi &lt;ansuelsmth@gmail.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://patch.msgid.link/20241004182759.14032-1-ansuelsmth@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: bcm84881: Fix some error handling paths</title>
<updated>2024-10-04T23:19:00Z</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2024-10-03T19:03:21Z</published>
<link rel='alternate' type='text/html' href='http://git.tablaster.dev/blaster4385/linux-IllusionX/commit/?id=9234a2549cb6ac038bec36cc7c084218e9575513'/>
<id>urn:sha1:9234a2549cb6ac038bec36cc7c084218e9575513</id>
<content type='text'>
If phy_read_mmd() fails, the error code stored in 'bmsr' should be returned
instead of 'val' which is likely to be 0.

Fixes: 75f4d8d10e01 ("net: phy: add Broadcom BCM84881 PHY driver")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Link: https://patch.msgid.link/3e1755b0c40340d00e089d6adae5bca2f8c79e53.1727982168.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
</feed>
