All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: leoli@freescale.com, netdev@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, afleming@freescale.com,
	davem@davemloft.net
Subject: Re: [PATCH v2 0/4] net: Revive fixed link support
Date: Sat, 18 Jul 2009 22:04:48 +0400	[thread overview]
Message-ID: <20090718180448.GA3252@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <20090717065220.15652.93331.stgit@localhost.localdomain>

On Fri, Jul 17, 2009 at 01:31:25AM -0600, Grant Likely wrote:
[...]
> Part of the problem I think is that the phylib code merges two separate
> constructs; the construct of an MDIO bus (on which many device may
> reside, not all of them PHYs), and the construct of an MII link whose
> speed and configuration need to be manipulated.  I've run into problems
> myself on how best to handle things like Ethernet switches which
> definitely do not behave like PHYs and the phylib state machine cannot
> be used on them.  It seems to me that the whole 'dummy phy' approach
> is just an artifact of the phylib model not being quite right yet.

Yep. With a bit of phylib rework we can remove all the MDIO emulation
stuff from phy/fixed.c driver, and leave there just speed/duplex/pause
assignments.

Though, I still believe that we should avoid two code paths in the
drivers. One of the code paths will be constantly broken if we do so.

> I
> want to investigate the possibility of separating the two concepts, but
> that will require a fair bit of thought and experimentation.

That would be great indeed.

[...]
> Anton, once again I don't have hardware to test this, so I rely on you
> to tell be if I screwed it up.  It has been compile tested.

Works fine here, thanks!

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

WARNING: multiple messages have this Message-ID (diff)
From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: davem@davemloft.net, afleming@freescale.com,
	netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	leoli@freescale.com
Subject: Re: [PATCH v2 0/4] net: Revive fixed link support
Date: Sat, 18 Jul 2009 22:04:48 +0400	[thread overview]
Message-ID: <20090718180448.GA3252@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <20090717065220.15652.93331.stgit@localhost.localdomain>

On Fri, Jul 17, 2009 at 01:31:25AM -0600, Grant Likely wrote:
[...]
> Part of the problem I think is that the phylib code merges two separate
> constructs; the construct of an MDIO bus (on which many device may
> reside, not all of them PHYs), and the construct of an MII link whose
> speed and configuration need to be manipulated.  I've run into problems
> myself on how best to handle things like Ethernet switches which
> definitely do not behave like PHYs and the phylib state machine cannot
> be used on them.  It seems to me that the whole 'dummy phy' approach
> is just an artifact of the phylib model not being quite right yet.

Yep. With a bit of phylib rework we can remove all the MDIO emulation
stuff from phy/fixed.c driver, and leave there just speed/duplex/pause
assignments.

Though, I still believe that we should avoid two code paths in the
drivers. One of the code paths will be constantly broken if we do so.

> I
> want to investigate the possibility of separating the two concepts, but
> that will require a fair bit of thought and experimentation.

That would be great indeed.

[...]
> Anton, once again I don't have hardware to test this, so I rely on you
> to tell be if I screwed it up.  It has been compile tested.

Works fine here, thanks!

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

  parent reply	other threads:[~2009-07-18 18:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-17  7:31 [PATCH v2 0/4] net: Revive fixed link support Grant Likely
2009-07-17  7:31 ` [PATCH v2 1/4] of/mdio: Add support function for Ethernet fixed-link property Grant Likely
2009-07-17  7:31 ` [PATCH v2 2/4] fs_enet: Revive fixed link support Grant Likely
2009-07-17  7:31 ` [PATCH v2 3/4] gianfar: " Grant Likely
2009-07-17  7:31 ` [PATCH v2 4/4] ucc_geth: " Grant Likely
2009-07-18 18:04 ` Anton Vorontsov [this message]
2009-07-18 18:04   ` [PATCH v2 0/4] net: " Anton Vorontsov
2009-07-18 18:37   ` Grant Likely
2009-07-18 18:37     ` Grant Likely
2009-07-22 16:20     ` David Miller
2009-07-22 16:20       ` David Miller

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=20090718180448.GA3252@oksana.dev.rtsoft.ru \
    --to=avorontsov@ru.mvista.com \
    --cc=afleming@freescale.com \
    --cc=davem@davemloft.net \
    --cc=grant.likely@secretlab.ca \
    --cc=leoli@freescale.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --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 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.