linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Matt Porter <mporter@kernel.crashing.org>
To: David Adair <dadair@ariodata.com>
Cc: linuxppc-dev@ozlabs.org, linuxppc-embedded@ozlabs.org
Subject: Re: Problems with MII mode operation on 440GP ethernet
Date: Wed, 10 Nov 2004 13:52:38 -0700	[thread overview]
Message-ID: <20041110135238.A22537@home.com> (raw)
In-Reply-To: <F152162DB1B0D2458EA395AD074DE1C48590CF@orion.ariodata.com>; from dadair@ariodata.com on Wed, Nov 10, 2004 at 11:48:31AM -0800

[Replies set to linuxppc-embedded]

On Wed, Nov 10, 2004 at 11:48:31AM -0800, David Adair wrote:
> Turns out that the problem is that MII mode is getting enabled
> in the ZMII FER register for both EMAC0 and EMAC1 as a result of
> the PHY probe operation on EMAC1.  The older versions do the PHY
> probe during the open while it now occurs earlier.
> 
> Would it be better to fix this by changing the OCP definitions to
> remove EMAC1 or by modifying the Ethernet driver to enforce the
> "only one channel in MII mode" restriction?
> 
> To me it seems like the latter is a better choice since the OCP
> really has more to do with the CPU than my board configuration
> which is defined by the initial values loaded into the ZMII
> FER register.
 
I have a custom board with the same configuration (on 2.6). The
driver in that tree works in this configuration. FWIW, the port
also uses ocp calls to remove the three unused interfaces. In
any case, the latter should be done, but most people would want
to do the port right and remove the second interface anyway.
No need to claim resources and a network interface for something
that can't be used.

> For instance the following works on my boards but contains
> an implicit assumption that emac_init_zmii() is only ever
> called with "AUTO" mode since it relies on valid initial data
> in the fer register.
 
I see. We would want something that handles explicit configuration
in the tree.

> (I also tweaked things so my version of mii-tool would work
> does anyone else have trouble with the wrong variable size?)

I haven't tried 2.4 in a long time...others would know. A lot
of fixes/features have gone into the 2.6 driver that haven't
been backported to 2.4.
 
-Matt

  reply	other threads:[~2004-11-10 21:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-10 19:48 Problems with MII mode operation on 440GP ethernet David Adair
2004-11-10 20:52 ` Matt Porter [this message]
2004-11-10 22:41   ` David Adair
2004-11-11  1:57     ` David Adair

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=20041110135238.A22537@home.com \
    --to=mporter@kernel.crashing.org \
    --cc=dadair@ariodata.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=linuxppc-embedded@ozlabs.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).