All of lore.kernel.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Andy Fleming <afleming@freescale.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 1/4 v2] powerpc: document max-speed and interface-type properties
Date: Tue, 17 Apr 2007 01:25:45 +0200	[thread overview]
Message-ID: <9f68fb3023e258ad0fbe314099a9ffbf@kernel.crashing.org> (raw)
In-Reply-To: <98DB6E05-1869-47E9-882E-17B4F574581F@freescale.com>

>> Yep.  The whole reason why any property is wanted here is
>> to say what type the PHY is, as the enet controller can
>> be attached to several kinds.  And what type the PHY is
>> belongs in the PHY node, obviously.  In its "compatible"
>> property to be exact.
>
> It's not saying what type the PHY is, though.  It's describing the 
> connection.  The PHY is just as flexible wrt connection type as the 
> ethernet controller.

Huh, I've never seen that.  I'll take your word for it.

> This is actually a property of the board.  In some cases its a fixed 
> property of the board.  In some cases it's changeable through dip 
> switches, or even through software.

In such a case you cannot describe this with a fixed
flat device tree *at all*.

> Ethernet controllers need to know what the connection is so they can 
> establish a data connection with the PHYs

Can't you probe for PHYs?

> The reason for choosing the ethernet controller in this case has to do 
> with the flow of information.
>
> 1) The driver tells the PHY what interface to use

The device tree is not structured after how Linux device
drivers want to use the information; instead, it describes
the hardware.

> 2) The ethernet controller is the endpoint of this connection which is 
> accessible by everyone else.  IE data is not sent through PHYs by any 
> means but through the ethernet controller, and data is not received 
> from PHYs by any means but through the ethernet controller.

So?

> 3) The UCC needs to be told the connection type, because it does not 
> have logic to detect it on its own.

Just try all possible kinds, see if you can see a PHY
connected?

> The truth is, this is a somewhat intractable problem because of the 
> myriad possibilities for how board designers can hook up ethernet 
> controllers to PHYs.  One can envision scenarios where controllers can 
> hook up to multiple PHYs, each of one fixed type.

Yeah, seen that.  Quite a common scenario.

> One can envision scenarios where multiple controllers are hooked up to 
> one PHY, and each of the controllers can use different connections.

How would that work at all, except when only one controller
is active and the rest are shut down?

> If we put the information in the PHY node, we allow for the first 
> scenario, but not the second.  If we put it in the ethernet node, we 
> reverse that situation.  In either case, we'd currently have to modify 
> our dts to specify which PHY we want to use.

Which brings me back to, can't you just probe for it?


Segher

  reply	other threads:[~2007-04-16 23:25 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-13  6:25 [PATCH 1/4 v2] powerpc: document max-speed and interface-type properties Kim Phillips
2007-04-13 17:00 ` Kumar Gala
2007-04-13 17:36   ` Kim Phillips
2007-04-13 17:42     ` Kumar Gala
2007-04-13 17:52       ` Kim Phillips
2007-04-13 17:59         ` Kumar Gala
2007-04-13 19:02 ` Segher Boessenkool
2007-04-16 15:25   ` Kim Phillips
2007-04-16 15:34     ` Kumar Gala
2007-04-16 15:47       ` Segher Boessenkool
2007-04-16 16:57         ` Kim Phillips
2007-04-16 23:18           ` Segher Boessenkool
2007-04-17  0:31             ` Kim Phillips
2007-04-17 10:25               ` Segher Boessenkool
2007-04-17 20:27                 ` Kim Phillips
2007-04-17 23:18                   ` Segher Boessenkool
2007-04-18  1:13                     ` Kim Phillips
2007-04-18 10:34                       ` Segher Boessenkool
2007-04-18 21:48                         ` Kim Phillips
2007-04-20  8:34                           ` Segher Boessenkool
2007-04-20 19:13                             ` Andy Fleming
2007-04-21 17:22                               ` Segher Boessenkool
2007-04-23 16:58                                 ` Andy Fleming
2007-04-23 21:24                                   ` Segher Boessenkool
2007-04-16 18:40         ` Andy Fleming
2007-04-16 23:25           ` Segher Boessenkool [this message]
2007-04-17  7:04             ` Andy Fleming
2007-04-17 10:40               ` Segher Boessenkool

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=9f68fb3023e258ad0fbe314099a9ffbf@kernel.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=afleming@freescale.com \
    --cc=linuxppc-dev@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 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.