| Message ID | 5eb8b25e-f646-ed3d-8572-9b6ef318ae9e@t2data.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net] net: phy: micrel: set soft_reset callback to genphy_soft_reset for KSZ8081 | expand |
| Context | Check | Description |
|---|---|---|
| netdev/apply | fail | Patch does not apply to net |
| netdev/tree_selection | success | Clearly marked for net |
On Thu, 18 Feb 2021 22:09:32 +0100 Christian Melki wrote: > Following a similar reinstate for the KSZ9031. > > Older kernels would use the genphy_soft_reset if the PHY did not > implement a .soft_reset. > > Bluntly removing that default may expose a lot of situations where > various PHYs/board implementations won't recover on various changes. > Like with implementation during a 4.9.x to 5.4.x LTS transition. > I think it's a good thing to remove unwanted soft resets but wonder if > it did open a can of worms? > > Atleast this fixes one iMX6 FEC/RMII/8081 combo. > > Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") > Signed-off-by: Christian Melki <christian.melki@t2data.com> Does not apply to net/master: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/ Please rebase and resend. Please make sure you CC maintainers and other relevant developers (you can use ./scripts/get_maintainers.pl $path_to_patch to find them).
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c index 54e0d75203da..57f8021b70af 100644 --- a/drivers/net/phy/micrel.c +++ b/drivers/net/phy/micrel.c @@ -1295,6 +1295,7 @@ static struct phy_driver ksphy_driver[] = { .driver_data = &ksz8081_type, .probe = kszphy_probe, .config_init = ksz8081_config_init, + .soft_reset = genphy_soft_reset, .config_intr = kszphy_config_intr, .handle_interrupt = kszphy_handle_interrupt, .get_sset_count = kszphy_get_sset_count,
Following a similar reinstate for the KSZ9031. Older kernels would use the genphy_soft_reset if the PHY did not implement a .soft_reset. Bluntly removing that default may expose a lot of situations where various PHYs/board implementations won't recover on various changes. Like with implementation during a 4.9.x to 5.4.x LTS transition. I think it's a good thing to remove unwanted soft resets but wonder if it did open a can of worms? Atleast this fixes one iMX6 FEC/RMII/8081 combo. Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") Signed-off-by: Christian Melki <christian.melki@t2data.com> ---