<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/net/phy, branch linux-5.12.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.12.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.12.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2021-07-19T08:00:57Z</updated>
<entry>
<title>net: phy: realtek: add delay to fix RXC generation issue</title>
<updated>2021-07-19T08:00:57Z</updated>
<author>
<name>Joakim Zhang</name>
<email>qiangqing.zhang@nxp.com</email>
</author>
<published>2021-06-08T03:15:35Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c5728331f2447fd1e1861e94ab1ee57f7d5cfab7'/>
<id>urn:sha1:c5728331f2447fd1e1861e94ab1ee57f7d5cfab7</id>
<content type='text'>
[ Upstream commit 6813cc8cfdaf401476e1a007cec8ae338cefa573 ]

PHY will delay about 11.5ms to generate RXC clock when switching from
power down to normal operation. Read/write registers would also cause RXC
become unstable and stop for a while during this process. Realtek engineer
suggests 15ms or more delay can workaround this issue.

Signed-off-by: Joakim Zhang &lt;qiangqing.zhang@nxp.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: phy: mscc: fix macsec key length</title>
<updated>2021-07-14T15:00:03Z</updated>
<author>
<name>Antoine Tenart</name>
<email>atenart@kernel.org</email>
</author>
<published>2021-06-24T09:38:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=653c6b2dfb239caaeb67986831b9bf5df1c55e37'/>
<id>urn:sha1:653c6b2dfb239caaeb67986831b9bf5df1c55e37</id>
<content type='text'>
[ Upstream commit c309217f91f2d2097c2a0a832d9bff50b88c81dc ]

The key length used to store the macsec key was set to MACSEC_KEYID_LEN
(16), which is an issue as:
- This was never meant to be the key length.
- The key length can be &gt; 16.

Fix this by using MACSEC_MAX_KEY_LEN instead (the max length accepted in
uAPI).

Fixes: 28c5107aa904 ("net: phy: mscc: macsec support")
Reported-by: Lior Nahmanson &lt;liorna@nvidia.com&gt;
Signed-off-by: Antoine Tenart &lt;atenart@kernel.org&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: phy: dp83867: perform soft reset and retain established link</title>
<updated>2021-06-30T12:46:59Z</updated>
<author>
<name>Praneeth Bajjuri</name>
<email>praneeth@ti.com</email>
</author>
<published>2021-06-10T00:43:42Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2ec33ddbc1203f9a57d374687ea15bf727068304'/>
<id>urn:sha1:2ec33ddbc1203f9a57d374687ea15bf727068304</id>
<content type='text'>
[ Upstream commit da9ef50f545f86ffe6ff786174d26500c4db737a ]

Current logic is performing hard reset and causing the programmed
registers to be wiped out.

as per datasheet: https://www.ti.com/lit/ds/symlink/dp83867cr.pdf
8.6.26 Control Register (CTRL)

do SW_RESTART to perform a reset not including the registers,
If performed when link is already present,
it will drop the link and trigger re-auto negotiation.

Signed-off-by: Praneeth Bajjuri &lt;praneeth@ti.com&gt;
Signed-off-by: Geet Modi &lt;geet.modi@ti.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&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: mdiobus: get rid of a BUG_ON()</title>
<updated>2021-06-16T10:05:01Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2021-05-17T09:04:13Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a244250207f5e4bacd38533a306e8a8d49f48685'/>
<id>urn:sha1:a244250207f5e4bacd38533a306e8a8d49f48685</id>
<content type='text'>
[ Upstream commit 1dde47a66d4fb181830d6fa000e5ea86907b639e ]

We spotted a bug recently during a review where a driver was
unregistering a bus that wasn't registered, which would trigger this
BUG_ON().  Let's handle that situation more gracefully, and just print
a warning and return.

Reported-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.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: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM</title>
<updated>2021-05-19T08:56:14Z</updated>
<author>
<name>Heiner Kallweit</name>
<email>hkallweit1@gmail.com</email>
</author>
<published>2021-04-07T15:51:56Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e782c60aa10c14a38085b032dbfc914973b9819b'/>
<id>urn:sha1:e782c60aa10c14a38085b032dbfc914973b9819b</id>
<content type='text'>
[ Upstream commit fba863b816049b03f3fbb07b10ebdcfe5c4141f7 ]

Resume callback of the PHY driver is called after the one for the MAC
driver. The PHY driver resume callback calls phy_init_hw(), and this is
potentially problematic if the MAC driver calls phy_start() in its resume
callback. One issue was reported with the fec driver and a KSZ8081 PHY
which seems to become unstable if a soft reset is triggered during aneg.

The new flag allows MAC drivers to indicate that they take care of
suspending/resuming the PHY. Then the MAC PM callbacks can handle
any dependency between MAC and PHY PM.

Signed-off-by: Heiner Kallweit &lt;hkallweit1@gmail.com&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: phy: marvell: fix m88e1111_set_downshift</title>
<updated>2021-05-14T08:53:02Z</updated>
<author>
<name>Maxim Kochetkov</name>
<email>fido_max@inbox.ru</email>
</author>
<published>2021-04-22T10:46:44Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=df9248ef56e654d9f421e3a05e8a77677df6d677'/>
<id>urn:sha1:df9248ef56e654d9f421e3a05e8a77677df6d677</id>
<content type='text'>
[ Upstream commit e7679c55a7249f1315256cfc672d53e84072e223 ]

Changing downshift params without software reset has no effect,
so call genphy_soft_reset() after change downshift params.

As the datasheet says:
Changes to these bits are disruptive to the normal operation therefore,
any changes to these registers must be followed by software reset
to take effect.

Fixes: 5c6bc5199b5d ("net: phy: marvell: add downshift support for M88E1111")
Signed-off-by: Maxim Kochetkov &lt;fido_max@inbox.ru&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&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: phy: marvell: fix m88e1011_set_downshift</title>
<updated>2021-05-14T08:53:02Z</updated>
<author>
<name>Maxim Kochetkov</name>
<email>fido_max@inbox.ru</email>
</author>
<published>2021-04-22T10:46:43Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=99ce66766bde51331a9bb3a3034abda140ee693a'/>
<id>urn:sha1:99ce66766bde51331a9bb3a3034abda140ee693a</id>
<content type='text'>
[ Upstream commit 990875b299b8612aeb85cb2e2751796f1add65ff ]

Changing downshift params without software reset has no effect,
so call genphy_soft_reset() after change downshift params.

As the datasheet says:
Changes to these bits are disruptive to the normal operation therefore,
any changes to these registers must be followed by software reset
to take effect.

Fixes: 911af5e149bb ("net: phy: marvell: fix downshift function naming")
Signed-off-by: Maxim Kochetkov &lt;fido_max@inbox.ru&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&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: phy: intel-xway: enable integrated led functions</title>
<updated>2021-05-14T08:53:01Z</updated>
<author>
<name>Martin Schiller</name>
<email>ms@dev.tdt.de</email>
</author>
<published>2021-04-21T05:50:47Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b2847bf30c4a9008630e7e741cca5677f68c4c21'/>
<id>urn:sha1:b2847bf30c4a9008630e7e741cca5677f68c4c21</id>
<content type='text'>
[ Upstream commit 357a07c26697a770d39d28b6b111f978deb4017d ]

The Intel xway phys offer the possibility to deactivate the integrated
LED function and to control the LEDs manually.
If this was set by the bootloader, it must be ensured that the
integrated LED function is enabled for all LEDs when loading the driver.

Before commit 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")
the LEDs were enabled by a soft-reset of the PHY (using
genphy_soft_reset). Initialize the XWAY_MDIO_LED with it's default
value (which is applied during a soft reset) instead of adding back
the soft reset. This brings back the default LED configuration while
still preventing an excessive amount of soft resets.

Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")
Signed-off-by: Martin Schiller &lt;ms@dev.tdt.de&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: phy: lan87xx: fix access to wrong register of LAN87xx</title>
<updated>2021-05-14T08:52:47Z</updated>
<author>
<name>Andre Edich</name>
<email>andre.edich@microchip.com</email>
</author>
<published>2021-03-29T09:45:36Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5b86b44b9a4d776a83abffaf8ad9a4ff147d8dc2'/>
<id>urn:sha1:5b86b44b9a4d776a83abffaf8ad9a4ff147d8dc2</id>
<content type='text'>
[ Upstream commit fdb5cc6ab3b6a1c0122d3644a63ef9dc7a610d35 ]

The function lan87xx_config_aneg_ext was introduced to configure
LAN95xxA but as well writes to undocumented register of LAN87xx.
This fix prevents that access.

The function lan87xx_config_aneg_ext gets more suitable for the new
behavior name.

Reported-by: Måns Rullgård &lt;mans@mansr.com&gt;
Fixes: 05b35e7eb9a1 ("smsc95xx: add phylib support")
Signed-off-by: Andre Edich &lt;andre.edich@microchip.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: phy: marvell: fix detection of PHY on Topaz switches</title>
<updated>2021-04-12T21:20:19Z</updated>
<author>
<name>Pali Rohár</name>
<email>pali@kernel.org</email>
</author>
<published>2021-04-12T16:57:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1fe976d308acb6374c899a4ee8025a0a016e453e'/>
<id>urn:sha1:1fe976d308acb6374c899a4ee8025a0a016e453e</id>
<content type='text'>
Since commit fee2d546414d ("net: phy: marvell: mv88e6390 temperature
sensor reading"), Linux reports the temperature of Topaz hwmon as
constant -75°C.

This is because switches from the Topaz family (88E6141 / 88E6341) have
the address of the temperature sensor register different from Peridot.

This address is instead compatible with 88E1510 PHYs, as was used for
Topaz before the above mentioned commit.

Create a new mapping table between switch family and PHY ID for families
which don't have a model number. And define PHY IDs for Topaz and Peridot
families.

Create a new PHY ID and a new PHY driver for Topaz's internal PHY.
The only difference from Peridot's PHY driver is the HWMON probing
method.

Prior this change Topaz's internal PHY is detected by kernel as:

  PHY [...] driver [Marvell 88E6390] (irq=63)

And afterwards as:

  PHY [...] driver [Marvell 88E6341 Family] (irq=63)

Signed-off-by: Pali Rohár &lt;pali@kernel.org&gt;
BugLink: https://github.com/globalscaletechnologies/linux/issues/1
Fixes: fee2d546414d ("net: phy: marvell: mv88e6390 temperature sensor reading")
Reviewed-by: Marek Behún &lt;kabel@kernel.org&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
