[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150430181946.GD1476@lunn.ch>
Date: Thu, 30 Apr 2015 20:19:46 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net,
vivien.didelot@...oirfairelinux.com,
jerome.oufella@...oirfairelinux.com, linux@...ck-us.net,
cphealy@...il.com, mathieu@...eaurora.org, jonasj76@...il.com,
andrey.volkov@...vision.fr, Chris.Packham@...iedtelesis.co.nz
Subject: Re: [RFC PATCH net-next 3/8] net: phy: Allow PHY devices to identify
themselves as Ethernet switches
> > Are you suggesting this phy driver sat in the middle effectively
> > performs auto negotiation in both directions? It sees what both sides
> > offer and then gives back the highest common setting?
>
> Yes, that's what I would be tempted to do.
O.K, i need to think about that for a while.
> So right now, for any port you can utilize standard PHY-related or
> fixed-PHY related properties, for instance this is what I use on a
> BCM7445 which has the following setup:
>
> - Port 0 has an internal gigabit PHY on dsa,mii-bus
> - Port 1 is connected to an external BCM53125 switch
> - Port 7 is connected to an internal MoCA PHY, whose link comes from a
> special interrupt
> - Port 8 is CPU
>
> So today, the only thing we are missing is giving the CPU port some link
> information, but we could probably utilize a 'fixed-link' property for
> that maybe?
The Marvell drivers don't look at this phy information. But i should
have good examples from the SF2 driver i can use :-)
I also think the core DSA code does not allow for a phy on CPU and DSA
ports. But that should not be too big a problem.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists