Hello Hauke,
[...]
> +
> +static int xway_gphy_ack_interrupt(struct phy_device *phydev)
> +{
> + int reg;
> +
> + /**
> + * Possible IRQ numbers:
> + * - IM3_IRL18 for GPHY0
> + * - IM3_IRL17 for GPHY1
These are references to the SoC interrupts.
> + *
> + * Due to a silicon bug IRQ lines are not really independent from
> + * each other. Sometimes the two lines are driven at the same time
> + * if only one GPHY core raises the interrupt.
So this errata sounds like a SoC errata, not an errata for the PHY.
> + */
> + reg = phy_read(phydev, XWAY_MDIO_ISTAT);
> +
> + return (reg < 0) ? reg : 0;
> +}
> +
[...]
> +
> +static struct phy_driver xway_gphy[] = {
> + {
> + .phy_id = PHY_ID_PHY11G_1_3,
> + .phy_id_mask = 0xffffffff,
> + .name = "Intel XWAY PHY11G (PEF 7071/PEF 7072)
> v1.3",
> + .features = (PHY_GBIT_FEATURES |
> SUPPORTED_Pause |
> + SUPPORTED_Asym_Pause),
> + /* there is an errata regarding irqs in this rev */
And then this is comment is also now valid.
What about a system with a single external phy connected,
on a non-Lantiq/Intel SoC?
I think the feasibility of using interrupts is not related to the phy version,
but indirectly by the version of the SoC it is integrated.
So maybe he use of interrupts (on these SoCs) should be controlled by devicetree or
network driver, where the SoC type and version can be handled?
> + .flags = 0,
> + .config_init = xway_gphy_config_init,
> + .config_aneg = xway_gphy14_config_aneg,
> + .read_status = genphy_read_status,
> + .ack_interrupt = xway_gphy_ack_interrupt,
> + .did_interrupt = xway_gphy_did_interrupt,
> + .config_intr = xway_gphy_config_intr,
> + .suspend = genphy_suspend,
> + .resume = genphy_resume,
> + }, {
[...]
Regards,
Thomas
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
