netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bruno Thomsen <bruno.thomsen@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Bruno Thomsen <bth@kamstrup.com>,
	Fabio Estevam <festevam@gmail.com>,
	netdev <netdev@vger.kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Lars Alex Pedersen <laa@kamstrup.com>
Subject: Re: fec: micrel: Ethernet PHY type ID auto-detection issue
Date: Tue, 28 Jul 2020 10:51:19 +0200	[thread overview]
Message-ID: <CAH+2xPCyiE561XjgKvU6cM-AMm3ayJG7GYzvzGCOOe127wJwsg@mail.gmail.com> (raw)
In-Reply-To: <20200722132608.GX1339445@lunn.ch>

Hi Andrew,

Den ons. 22. jul. 2020 kl. 15.26 skrev Andrew Lunn <andrew@lunn.ch>:
> Is it held in reset, and the reset is released, or is the reset line
> toggled active and then inactive?

When the kernel boots PHY reset is not active (gpio level low).
The device needs a reset pulse.

> > if (d)
> >       if (d > 20000)
> >               msleep(d / 1000);
> >       else
> >               usleep_range(d, d + max_t(unsigned int, d / 10, 100));
>
> Patch welcome.

I will put together a patch with fsleep as suggested by Heiner.

> > So my current conclusion is that using generic mdio phy handling does
> > not work with Micrel PHYs unless 3 issues has been resolved.
> > - Reset PHY before auto type detection.
>
> This has been raised recently. Look back in the mail archive about a
> month. For GPIOs this is easier to solve. But regulators pose a
> problem.
>
> Part of the problem is the history of this code. It originated from a
> PHY which needed to be reset after probe and configuration to make its
> clock stable, if i remember correctly. So the PHY would already probe,
> without the reset. Something similar was needed for another PHY so the
> code got pulled out of the driver and into the PHY core. But the
> assumption remained, the PHY will probe, the reset is used after the
> probe. This code now needs to be made more generic.
>
> There is one other option, depending on your board design. The PHY
> core supports two different resets. There is a per PHY reset, which is
> what you are using. And then there is a reset for all devices on the
> bus. That is used when multiple PHYs are connected to one reset GPIO.
> You might be able to use that reset instead. But you might need to fix
> up the sleep code in that case as well.

Resetting all PHYs does not work out-of-the box for my case as there
is no delay after reset release. I have a small patch that fixes my case
by reusing the mdio reset-delay-us device tree property as both the
reset assert delay and reset deassert delay. That way we don't need
to rename or add more dt properties. Just update existing help text.
Otherwise I think the current reset-delay-us should be rename and
follow phy naming with reset-{assert,deassert}-us.

/Bruno

  reply	other threads:[~2020-07-28  8:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAH+2xPCzrBgngz5cY9DDDjnFUBNa=NSH3VMchFcnoVbjSm3rEw@mail.gmail.com>
2020-07-17 15:52 ` fec: micrel: Ethernet PHY type ID auto-detection issue Fabio Estevam
2020-07-17 16:34   ` Andrew Lunn
2020-07-22 10:59     ` Bruno Thomsen
2020-07-22 13:26       ` Andrew Lunn
2020-07-28  8:51         ` Bruno Thomsen [this message]
2020-07-22 13:42       ` Heiner Kallweit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH+2xPCyiE561XjgKvU6cM-AMm3ayJG7GYzvzGCOOe127wJwsg@mail.gmail.com \
    --to=bruno.thomsen@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=bth@kamstrup.com \
    --cc=f.fainelli@gmail.com \
    --cc=festevam@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=laa@kamstrup.com \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).