Am 2022-12-02 19:42, schrieb Andrew Lunn:
On Fri, Dec 02, 2022 at 04:12:04PM +0100, Michael Walle wrote:
The interrupts on the GPY215B and GPY215C are broken and the only
viable
fix is to disable them altogether. There is still the possibilty to
opt-in via the device tree.
Signed-off-by: Michael Walle <michael@xxxxxxxx>
---
drivers/net/phy/mxl-gpy.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/phy/mxl-gpy.c b/drivers/net/phy/mxl-gpy.c
index 20e610dda891..edb8cd8313b0 100644
--- a/drivers/net/phy/mxl-gpy.c
+++ b/drivers/net/phy/mxl-gpy.c
@@ -12,6 +12,7 @@
#include <linux/mutex.h>
#include <linux/phy.h>
#include <linux/polynomial.h>
+#include <linux/property.h>
#include <linux/netdevice.h>
/* PHY ID */
@@ -290,6 +291,10 @@ static int gpy_probe(struct phy_device *phydev)
phydev->priv = priv;
mutex_init(&priv->mbox_lock);
+ if (gpy_has_broken_mdint(phydev) &&
+ !device_property_present(dev,
"maxlinear,use-broken-interrupts"))
+ phydev->irq = PHY_POLL;
+
I'm not sure of ordering here. It could be phydev->irq is set after
probe. The IRQ is requested as part of phy_connect_direct(), which is
much later.
I've did it that way, because phy_probe() also sets phydev->irq =
PHY_POLL
in some cases and the phy driver .probe() is called right after it.
I think a better place for this test is in gpy_config_intr(), return
-EOPNOTSUPP. phy_enable_interrupts() failing should then cause
phy_request_interrupt() to use polling.
Which will then print a warning, which might be misleading.
Or we disable the warning if -EOPNOTSUPP is returned?
-michael
