<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/net/phy/micrel.c, branch v6.8</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>net: micrel: Fix PTP frame parsing for lan8814</title>
<updated>2024-01-22T11:02:23+00:00</updated>
<author>
<name>Horatiu Vultur</name>
<email>horatiu.vultur@microchip.com</email>
</author>
<published>2024-01-19T10:47:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=aaf632f7ab6dec57bc9329a438f94504fe8034b9'/>
<id>aaf632f7ab6dec57bc9329a438f94504fe8034b9</id>
<content type='text'>
The HW has the capability to check each frame if it is a PTP frame,
which domain it is, which ptp frame type it is, different ip address in
the frame. And if one of these checks fail then the frame is not
timestamp. Most of these checks were disabled except checking the field
minorVersionPTP inside the PTP header. Meaning that once a partner sends
a frame compliant to 8021AS which has minorVersionPTP set to 1, then the
frame was not timestamp because the HW expected by default a value of 0
in minorVersionPTP. This is exactly the same issue as on lan8841.
Fix this issue by removing this check so the userspace can decide on this.

Fixes: ece19502834d ("net: phy: micrel: 1588 support for LAN8814 phy")
Signed-off-by: Horatiu Vultur &lt;horatiu.vultur@microchip.com&gt;
Reviewed-by: Maxime Chevallier &lt;maxime.chevallier@bootlin.com&gt;
Reviewed-by: Divya Koppera &lt;divya.koppera@microchip.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The HW has the capability to check each frame if it is a PTP frame,
which domain it is, which ptp frame type it is, different ip address in
the frame. And if one of these checks fail then the frame is not
timestamp. Most of these checks were disabled except checking the field
minorVersionPTP inside the PTP header. Meaning that once a partner sends
a frame compliant to 8021AS which has minorVersionPTP set to 1, then the
frame was not timestamp because the HW expected by default a value of 0
in minorVersionPTP. This is exactly the same issue as on lan8841.
Fix this issue by removing this check so the userspace can decide on this.

Fixes: ece19502834d ("net: phy: micrel: 1588 support for LAN8814 phy")
Signed-off-by: Horatiu Vultur &lt;horatiu.vultur@microchip.com&gt;
Reviewed-by: Maxime Chevallier &lt;maxime.chevallier@bootlin.com&gt;
Reviewed-by: Divya Koppera &lt;divya.koppera@microchip.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: phy: micrel: populate .soft_reset for KSZ9131</title>
<updated>2024-01-12T11:09:12+00:00</updated>
<author>
<name>Claudiu Beznea</name>
<email>claudiu.beznea.uj@bp.renesas.com</email>
</author>
<published>2024-01-05T08:52:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e398822c4751017fe401f57409488f5948d12fb5'/>
<id>e398822c4751017fe401f57409488f5948d12fb5</id>
<content type='text'>
The RZ/G3S SMARC Module has 2 KSZ9131 PHYs. In this setup, the KSZ9131 PHY
is used with the ravb Ethernet driver. It has been discovered that when
bringing the Ethernet interface down/up continuously, e.g., with the
following sh script:

$ while :; do ifconfig eth0 down; ifconfig eth0 up; done

the link speed and duplex are wrong after interrupting the bring down/up
operation even though the Ethernet interface is up. To recover from this
state the following configuration sequence is necessary (executed
manually):

$ ifconfig eth0 down
$ ifconfig eth0 up

The behavior has been identified also on the Microchip SAMA7G5-EK board
which runs the macb driver and uses the same PHY.

The order of PHY-related operations in ravb_open() is as follows:
ravb_open() -&gt;
  ravb_phy_start() -&gt;
    ravb_phy_init() -&gt;
      of_phy_connect() -&gt;
        phy_connect_direct() -&gt;
	  phy_attach_direct() -&gt;
	    phy_init_hw() -&gt;
	      phydev-&gt;drv-&gt;soft_reset()
	      phydev-&gt;drv-&gt;config_init()
	      phydev-&gt;drv-&gt;config_intr()
	    phy_resume()
	      kszphy_resume()

The order of PHY-related operations in ravb_close is as follows:
ravb_close() -&gt;
  phy_stop() -&gt;
    phy_suspend() -&gt;
      kszphy_suspend() -&gt;
        genphy_suspend()
	  // set BMCR_PDOWN bit in MII_BMCR

In genphy_suspend() setting the BMCR_PDWN bit in MII_BMCR switches the PHY
to Software Power-Down (SPD) mode (according to the KSZ9131 datasheet).
Thus, when opening the interface after it has been  previously closed (via
ravb_close()), the phydev-&gt;drv-&gt;config_init() and
phydev-&gt;drv-&gt;config_intr() reach the KSZ9131 PHY driver via the
ksz9131_config_init() and kszphy_config_intr() functions.

KSZ9131 specifies that the MII management interface remains operational
during SPD (Software Power-Down), but (according to manual):
- Only access to the standard registers (0 through 31) is supported.
- Access to MMD address spaces other than MMD address space 1 is possible
  if the spd_clock_gate_override bit is set.
- Access to MMD address space 1 is not possible.

The spd_clock_gate_override bit is not used in the KSZ9131 driver.

ksz9131_config_init() configures RGMII delay, pad skews and LEDs by
accessesing MMD registers other than those in address space 1.

The datasheet for the KSZ9131 does not specify what happens if registers
from an unsupported address space are accessed while the PHY is in SPD.

To fix the issue the .soft_reset method has been instantiated for KSZ9131,
too. This resets the PHY to the default state before doing any
configurations to it, thus switching it out of SPD.

Fixes: bff5b4b37372 ("net: phy: micrel: add Microchip KSZ9131 initial driver")
Signed-off-by: Claudiu Beznea &lt;claudiu.beznea.uj@bp.renesas.com&gt;
Reviewed-by: Maxime Chevallier &lt;maxime.chevallier@bootlin.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The RZ/G3S SMARC Module has 2 KSZ9131 PHYs. In this setup, the KSZ9131 PHY
is used with the ravb Ethernet driver. It has been discovered that when
bringing the Ethernet interface down/up continuously, e.g., with the
following sh script:

$ while :; do ifconfig eth0 down; ifconfig eth0 up; done

the link speed and duplex are wrong after interrupting the bring down/up
operation even though the Ethernet interface is up. To recover from this
state the following configuration sequence is necessary (executed
manually):

$ ifconfig eth0 down
$ ifconfig eth0 up

The behavior has been identified also on the Microchip SAMA7G5-EK board
which runs the macb driver and uses the same PHY.

The order of PHY-related operations in ravb_open() is as follows:
ravb_open() -&gt;
  ravb_phy_start() -&gt;
    ravb_phy_init() -&gt;
      of_phy_connect() -&gt;
        phy_connect_direct() -&gt;
	  phy_attach_direct() -&gt;
	    phy_init_hw() -&gt;
	      phydev-&gt;drv-&gt;soft_reset()
	      phydev-&gt;drv-&gt;config_init()
	      phydev-&gt;drv-&gt;config_intr()
	    phy_resume()
	      kszphy_resume()

The order of PHY-related operations in ravb_close is as follows:
ravb_close() -&gt;
  phy_stop() -&gt;
    phy_suspend() -&gt;
      kszphy_suspend() -&gt;
        genphy_suspend()
	  // set BMCR_PDOWN bit in MII_BMCR

In genphy_suspend() setting the BMCR_PDWN bit in MII_BMCR switches the PHY
to Software Power-Down (SPD) mode (according to the KSZ9131 datasheet).
Thus, when opening the interface after it has been  previously closed (via
ravb_close()), the phydev-&gt;drv-&gt;config_init() and
phydev-&gt;drv-&gt;config_intr() reach the KSZ9131 PHY driver via the
ksz9131_config_init() and kszphy_config_intr() functions.

KSZ9131 specifies that the MII management interface remains operational
during SPD (Software Power-Down), but (according to manual):
- Only access to the standard registers (0 through 31) is supported.
- Access to MMD address spaces other than MMD address space 1 is possible
  if the spd_clock_gate_override bit is set.
- Access to MMD address space 1 is not possible.

The spd_clock_gate_override bit is not used in the KSZ9131 driver.

ksz9131_config_init() configures RGMII delay, pad skews and LEDs by
accessesing MMD registers other than those in address space 1.

The datasheet for the KSZ9131 does not specify what happens if registers
from an unsupported address space are accessed while the PHY is in SPD.

To fix the issue the .soft_reset method has been instantiated for KSZ9131,
too. This resets the PHY to the default state before doing any
configurations to it, thus switching it out of SPD.

Fixes: bff5b4b37372 ("net: phy: micrel: add Microchip KSZ9131 initial driver")
Signed-off-by: Claudiu Beznea &lt;claudiu.beznea.uj@bp.renesas.com&gt;
Reviewed-by: Maxime Chevallier &lt;maxime.chevallier@bootlin.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: micrel: Fix PTP frame parsing for lan8841</title>
<updated>2024-01-12T11:08:08+00:00</updated>
<author>
<name>Horatiu Vultur</name>
<email>horatiu.vultur@microchip.com</email>
</author>
<published>2024-01-10T11:37:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=acd66c2126eb9b5da2d89ae07dbcd73b909c2111'/>
<id>acd66c2126eb9b5da2d89ae07dbcd73b909c2111</id>
<content type='text'>
The HW has the capability to check each frame if it is a PTP frame,
which domain it is, which ptp frame type it is, different ip address in
the frame. And if one of these checks fail then the frame is not
timestamp. Most of these checks were disabled except checking the field
minorVersionPTP inside the PTP header. Meaning that once a partner sends
a frame compliant to 8021AS which has minorVersionPTP set to 1, then the
frame was not timestamp because the HW expected by default a value of 0
in minorVersionPTP.
Fix this issue by removing this check so the userspace can decide on this.

Fixes: cafc3662ee3f ("net: micrel: Add PHC support for lan8841")
Signed-off-by: Horatiu Vultur &lt;horatiu.vultur@microchip.com&gt;
Reviewed-by: Divya Koppera &lt;divya.koppera@microchip.com&gt;
Reviewed-by: Rahul Rameshbabu &lt;rrameshbabu@nvidia.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The HW has the capability to check each frame if it is a PTP frame,
which domain it is, which ptp frame type it is, different ip address in
the frame. And if one of these checks fail then the frame is not
timestamp. Most of these checks were disabled except checking the field
minorVersionPTP inside the PTP header. Meaning that once a partner sends
a frame compliant to 8021AS which has minorVersionPTP set to 1, then the
frame was not timestamp because the HW expected by default a value of 0
in minorVersionPTP.
Fix this issue by removing this check so the userspace can decide on this.

Fixes: cafc3662ee3f ("net: micrel: Add PHC support for lan8841")
Signed-off-by: Horatiu Vultur &lt;horatiu.vultur@microchip.com&gt;
Reviewed-by: Divya Koppera &lt;divya.koppera@microchip.com&gt;
Reviewed-by: Rahul Rameshbabu &lt;rrameshbabu@nvidia.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: phy: micrel: allow usage of generic ethernet-phy clock</title>
<updated>2023-12-04T22:43:55+00:00</updated>
<author>
<name>Heiko Stuebner</name>
<email>heiko.stuebner@cherry.de</email>
</author>
<published>2023-12-01T15:01:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=99ac4cbcc2a50ecc86ffacc7b4b42ba4259a90d4'/>
<id>99ac4cbcc2a50ecc86ffacc7b4b42ba4259a90d4</id>
<content type='text'>
The generic ethernet-phy binding allows describing an external clock since
commit 350b7a258f20 ("dt-bindings: net: phy: Document support for external PHY clk")
for cases where the phy is not supplied by an oscillator but instead
by a clock from the host system.

And the old named "rmii-ref" clock from 2014 is only specified for phys
of the KSZ8021, KSZ8031, KSZ8081, KSZ8091 types.

So allow retrieving and enabling the optional generic clock on phys that
do not provide a rmii-ref clock.

Signed-off-by: Heiko Stuebner &lt;heiko.stuebner@cherry.de&gt;
Reviewed-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lore.kernel.org/r/20231201150131.326766-3-heiko@sntech.de
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The generic ethernet-phy binding allows describing an external clock since
commit 350b7a258f20 ("dt-bindings: net: phy: Document support for external PHY clk")
for cases where the phy is not supplied by an oscillator but instead
by a clock from the host system.

And the old named "rmii-ref" clock from 2014 is only specified for phys
of the KSZ8021, KSZ8031, KSZ8081, KSZ8091 types.

So allow retrieving and enabling the optional generic clock on phys that
do not provide a rmii-ref clock.

Signed-off-by: Heiko Stuebner &lt;heiko.stuebner@cherry.de&gt;
Reviewed-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lore.kernel.org/r/20231201150131.326766-3-heiko@sntech.de
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: phy: micrel: use devm_clk_get_optional_enabled for the rmii-ref clock</title>
<updated>2023-12-04T22:43:54+00:00</updated>
<author>
<name>Heiko Stuebner</name>
<email>heiko.stuebner@cherry.de</email>
</author>
<published>2023-12-01T15:01:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9853294627237b73a6b765162d9c0485b0697db5'/>
<id>9853294627237b73a6b765162d9c0485b0697db5</id>
<content type='text'>
While the external clock input will most likely be enabled, it's not
guaranteed and clk_get_rate in some suppliers will even just return
valid results when the clock is running.

So use devm_clk_get_optional_enabled to retrieve and enable the clock
in one go.

Signed-off-by: Heiko Stuebner &lt;heiko.stuebner@cherry.de&gt;
Reviewed-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lore.kernel.org/r/20231201150131.326766-2-heiko@sntech.de
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While the external clock input will most likely be enabled, it's not
guaranteed and clk_get_rate in some suppliers will even just return
valid results when the clock is running.

So use devm_clk_get_optional_enabled to retrieve and enable the clock
in one go.

Signed-off-by: Heiko Stuebner &lt;heiko.stuebner@cherry.de&gt;
Reviewed-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lore.kernel.org/r/20231201150131.326766-2-heiko@sntech.de
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: partial revert of the "Make timestamping selectable: series</title>
<updated>2023-11-19T02:42:37+00:00</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2023-11-19T02:38:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=289354f21b2c3fac93e956efd45f256a88a4d997'/>
<id>289354f21b2c3fac93e956efd45f256a88a4d997</id>
<content type='text'>
Revert following commits:

commit acec05fb78ab ("net_tstamp: Add TIMESTAMPING SOFTWARE and HARDWARE mask")
commit 11d55be06df0 ("net: ethtool: Add a command to expose current time stamping layer")
commit bb8645b00ced ("netlink: specs: Introduce new netlink command to get current timestamp")
commit d905f9c75329 ("net: ethtool: Add a command to list available time stamping layers")
commit aed5004ee7a0 ("netlink: specs: Introduce new netlink command to list available time stamping layers")
commit 51bdf3165f01 ("net: Replace hwtstamp_source by timestamping layer")
commit 0f7f463d4821 ("net: Change the API of PHY default timestamp to MAC")
commit 091fab122869 ("net: ethtool: ts: Update GET_TS to reply the current selected timestamp")
commit 152c75e1d002 ("net: ethtool: ts: Let the active time stamping layer be selectable")
commit ee60ea6be0d3 ("netlink: specs: Introduce time stamping set command")

They need more time for reviews.

Link: https://lore.kernel.org/all/20231118183529.6e67100c@kernel.org/
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Revert following commits:

commit acec05fb78ab ("net_tstamp: Add TIMESTAMPING SOFTWARE and HARDWARE mask")
commit 11d55be06df0 ("net: ethtool: Add a command to expose current time stamping layer")
commit bb8645b00ced ("netlink: specs: Introduce new netlink command to get current timestamp")
commit d905f9c75329 ("net: ethtool: Add a command to list available time stamping layers")
commit aed5004ee7a0 ("netlink: specs: Introduce new netlink command to list available time stamping layers")
commit 51bdf3165f01 ("net: Replace hwtstamp_source by timestamping layer")
commit 0f7f463d4821 ("net: Change the API of PHY default timestamp to MAC")
commit 091fab122869 ("net: ethtool: ts: Update GET_TS to reply the current selected timestamp")
commit 152c75e1d002 ("net: ethtool: ts: Let the active time stamping layer be selectable")
commit ee60ea6be0d3 ("netlink: specs: Introduce time stamping set command")

They need more time for reviews.

Link: https://lore.kernel.org/all/20231118183529.6e67100c@kernel.org/
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: Change the API of PHY default timestamp to MAC</title>
<updated>2023-11-18T14:52:57+00:00</updated>
<author>
<name>Kory Maincent</name>
<email>kory.maincent@bootlin.com</email>
</author>
<published>2023-11-14T11:28:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0f7f463d4821a4f52fa5c0a961389e651d50c384'/>
<id>0f7f463d4821a4f52fa5c0a961389e651d50c384</id>
<content type='text'>
Change the API to select MAC default time stamping instead of the PHY.
Indeed the PHY is closer to the wire therefore theoretically it has less
delay than the MAC timestamping but the reality is different. Due to lower
time stamping clock frequency, latency in the MDIO bus and no PHC hardware
synchronization between different PHY, the PHY PTP is often less precise
than the MAC. The exception is for PHY designed specially for PTP case but
these devices are not very widespread. For not breaking the compatibility I
introduce a default_timestamp flag in phy_device that is set by the phy
driver to know we are using the old API behavior.

The phy_set_timestamp function is called at each call of phy_attach_direct.
In case of MAC driver using phylink this function is called when the
interface is turned up. Then if the interface goes down and up again the
last choice of timestamp will be overwritten by the default choice.
A solution could be to cache the timestamp status but it can bring other
issues. In case of SFP, if we change the module, it doesn't make sense to
blindly re-set the timestamp back to PHY, if the new module has a PHY with
mediocre timestamping capabilities.

Signed-off-by: Kory Maincent &lt;kory.maincent@bootlin.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Change the API to select MAC default time stamping instead of the PHY.
Indeed the PHY is closer to the wire therefore theoretically it has less
delay than the MAC timestamping but the reality is different. Due to lower
time stamping clock frequency, latency in the MDIO bus and no PHC hardware
synchronization between different PHY, the PHY PTP is often less precise
than the MAC. The exception is for PHY designed specially for PTP case but
these devices are not very widespread. For not breaking the compatibility I
introduce a default_timestamp flag in phy_device that is set by the phy
driver to know we are using the old API behavior.

The phy_set_timestamp function is called at each call of phy_attach_direct.
In case of MAC driver using phylink this function is called when the
interface is turned up. Then if the interface goes down and up again the
last choice of timestamp will be overwritten by the default choice.
A solution could be to cache the timestamp status but it can bring other
issues. In case of SFP, if we change the module, it doesn't make sense to
blindly re-set the timestamp back to PHY, if the new module has a PHY with
mediocre timestamping capabilities.

Signed-off-by: Kory Maincent &lt;kory.maincent@bootlin.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: phy: micrel: fix ts_info value in case of no phc</title>
<updated>2023-11-18T14:52:57+00:00</updated>
<author>
<name>Kory Maincent</name>
<email>kory.maincent@bootlin.com</email>
</author>
<published>2023-11-14T11:28:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=915d25a9d69be969c1cc6c1dd0c3861f6da7b55e'/>
<id>915d25a9d69be969c1cc6c1dd0c3861f6da7b55e</id>
<content type='text'>
In case of no phc we should not return SOFTWARE TIMESTAMPING flags as we do
not know whether the netdev supports of timestamping.
Remove it from the lan8841_ts_info and simply return 0.

Signed-off-by: Kory Maincent &lt;kory.maincent@bootlin.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In case of no phc we should not return SOFTWARE TIMESTAMPING flags as we do
not know whether the netdev supports of timestamping.
Remove it from the lan8841_ts_info and simply return 0.

Signed-off-by: Kory Maincent &lt;kory.maincent@bootlin.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: Convert PHYs hwtstamp callback to use kernel_hwtstamp_config</title>
<updated>2023-11-18T14:52:56+00:00</updated>
<author>
<name>Kory Maincent</name>
<email>kory.maincent@bootlin.com</email>
</author>
<published>2023-11-14T11:28:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=446e2305827b76e8081057ce56bbd2703b4da8a9'/>
<id>446e2305827b76e8081057ce56bbd2703b4da8a9</id>
<content type='text'>
The PHYs hwtstamp callback are still getting the timestamp config from
ifreq and using copy_from/to_user.
Get rid of these functions by using timestamp configuration in parameter.
This also allow to move on to kernel_hwtstamp_config and be similar to
net devices using the new ndo_hwstamp_get/set.

This adds the possibility to manipulate the timestamp configuration
from the kernel which was not possible with the copy_from/to_user.

Signed-off-by: Kory Maincent &lt;kory.maincent@bootlin.com&gt;
Reviewed-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The PHYs hwtstamp callback are still getting the timestamp config from
ifreq and using copy_from/to_user.
Get rid of these functions by using timestamp configuration in parameter.
This also allow to move on to kernel_hwtstamp_config and be similar to
net devices using the new ndo_hwstamp_get/set.

This adds the possibility to manipulate the timestamp configuration
from the kernel which was not possible with the copy_from/to_user.

Signed-off-by: Kory Maincent &lt;kory.maincent@bootlin.com&gt;
Reviewed-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: phy: micrel: Fix forced link mode for KSZ886X switches</title>
<updated>2023-10-20T10:50:46+00:00</updated>
<author>
<name>Oleksij Rempel</name>
<email>o.rempel@pengutronix.de</email>
</author>
<published>2023-10-19T11:14:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=510f02febb10259919a41926ab6bf9ec5c72ee48'/>
<id>510f02febb10259919a41926ab6bf9ec5c72ee48</id>
<content type='text'>
Address a link speed detection issue in KSZ886X PHY driver when in
forced link mode. Previously, link partners like "ASIX AX88772B"
with KSZ8873 could fall back to 10Mbit instead of configured 100Mbit.

The issue arises as KSZ886X PHY continues sending Fast Link Pulses (FLPs)
even with autonegotiation off, misleading link partners in autoneg mode,
leading to incorrect link speed detection.

Now, when autonegotiation is disabled, the driver sets the link state
forcefully using KSZ886X_CTRL_FORCE_LINK bit. This action, beyond just
disabling autonegotiation, makes the PHY state more reliably detected by
link partners using parallel detection, thus fixing the link speed
misconfiguration.

With autonegotiation enabled, link state is not forced, allowing proper
autonegotiation process participation.

Signed-off-by: Oleksij Rempel &lt;o.rempel@pengutronix.de&gt;
Reviewed-by: Vladimir Oltean &lt;vladimir.oltean@nxp.com&gt;
Reviewed-by: Divya Koppera &lt;divya.koppera@microchip.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Address a link speed detection issue in KSZ886X PHY driver when in
forced link mode. Previously, link partners like "ASIX AX88772B"
with KSZ8873 could fall back to 10Mbit instead of configured 100Mbit.

The issue arises as KSZ886X PHY continues sending Fast Link Pulses (FLPs)
even with autonegotiation off, misleading link partners in autoneg mode,
leading to incorrect link speed detection.

Now, when autonegotiation is disabled, the driver sets the link state
forcefully using KSZ886X_CTRL_FORCE_LINK bit. This action, beyond just
disabling autonegotiation, makes the PHY state more reliably detected by
link partners using parallel detection, thus fixing the link speed
misconfiguration.

With autonegotiation enabled, link state is not forced, allowing proper
autonegotiation process participation.

Signed-off-by: Oleksij Rempel &lt;o.rempel@pengutronix.de&gt;
Reviewed-by: Vladimir Oltean &lt;vladimir.oltean@nxp.com&gt;
Reviewed-by: Divya Koppera &lt;divya.koppera@microchip.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
