lkml.org 
[lkml]   [2022]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Clause 45 and Clause 22 PHYs on one MDIO bus
    Am 2022-03-21 21:36, schrieb Andrew Lunn:
    >> Actually, it looks like mdiobus_c45_read() is really c45 only and only
    >> used for PHYs which just support c45 and not c45-over-c22 (?). I was
    >> mistaken by the heavy use of the function in phy_device.c. All the
    >> methods in phy-c45.c use phy_*_mmd() functions. Thus it might only be
    >> the mxl-gpy doing something fishy in its probe function.
    >
    > Yes, there is something odd here. You should search back on the
    > mailing list.
    >
    > If i remember correctly, it is something like it responds to both c22
    > and c45. If it is found via c22, phylib does not set phydev->is_c45,
    > and everything ends up going indirect. So the probe additionally tries
    > to find it via c45? Or something like that.

    Yeah, found it: https://lore.kernel.org/netdev/YLaG9cdn6ewdffjV@lunn.ch/

    But that means that if the controller is not c45 capable, it will always
    fail to probe, no?

    I've added the "if (regnum & MII_ADDR_C45) return -EOPNOTSUPP" to the
    mdio driver and the gpy phy will then fail to probe - as expected.

    Should it check for -EOPNOTSUPP and just ignore that error and continue
    probing? Or make it a no-op if probe_capabilities say it has no c45
    access so it would take advantage of a quirk flag (derived from dt)?

    >> Nevertheless, I'd still need the opt-out of any c45 access. Otherwise,
    >> if someone will ever implement c45 support for the mdio-mscc-mdio
    >> driver, I'll run in the erratic behavior.
    >
    > Yah, i need to think about that. Are you purely in the DT world, or is
    > ACPI also an option?

    Just DT world.

    > Maybe extend of_mdiobus_register() to look for a DT property to limit
    > what values probe_capabilities can take?

    I'll have to give it a try. First I was thinking that we wouldn't need
    it because a broken PHY driver could just set a quirk
    "broken_c45_access"
    or similar. But that would mean it has to be probed before any c45 PHY.
    Dunno if that will be true for the future. And it sounds rather fragile.
    So yes, a dt property might be a better option.

    -michael

    \
     
     \ /
      Last update: 2022-03-21 23:48    [W:4.551 / U:0.840 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site