All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: M B <super.firetwister@googlemail.com>
Cc: netdev@vger.kernel.org, ppc-dev <linuxppc-dev@ozlabs.org>
Subject: Re: Phy read timeout in ibm_new_emac driver
Date: Wed, 16 Apr 2008 22:09:51 +1000	[thread overview]
Message-ID: <1208347791.6958.279.camel@pasglop> (raw)
In-Reply-To: <6a6049b80804160349q42120b4bs1c0db49ea5ad055d@mail.gmail.com>


> My Micrel/Kendin KSZ8721BT on my ppc405EP board needs one us longer to
> finish. I was able to reproduce this all the time. So I wonder if the
> timeout of 100us is defined by the MII standard, or by the author of
> the driver?
> If it's a standard I've still a bad feeling if we just correct the
> timeout to 100us, maybe 110 should be fine. If it's not defined by the
> standard, I would add 50% to the timeout. It won't slow down other
> phys, but a scan on the phy bus might get slowed down.
> Same applies for __emac_mdio_write.
> 
> Oh and we could save a us by putting the udelay(1) after the if section ;-)

Increasing the timeout is fine. In fact, EMAC specifically can sleep in
it's MDIO access routines (it already takes mutexes) so maybe a good
option here is to use longer sleeping delays and less iterations.

Somebody knows off hand what the standard says the timeout should be ? I
can check that tomorrow, I don't have it at hand right now and it's
getting late but feel free to beat me to it :-) 

Cheers,
Ben.

  reply	other threads:[~2008-04-16 12:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-16 10:49 Phy read timeout in ibm_new_emac driver M B
2008-04-16 10:49 ` M B
2008-04-16 12:09 ` Benjamin Herrenschmidt [this message]
2008-04-23  5:06   ` Markus Brunner
2008-04-23  5:18     ` Benjamin Herrenschmidt

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=1208347791.6958.279.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=super.firetwister@googlemail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.