From: Andrew Lunn <andrew@lunn.ch>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net,
vivien.didelot@savoirfairelinux.com,
jerome.oufella@savoirfairelinux.com, linux@roeck-us.net,
cphealy@gmail.com, mathieu@codeaurora.org, jonasj76@gmail.com,
andrey.volkov@nexvision.fr, Chris.Packham@alliedtelesis.co.nz
Subject: Re: [RFC PATCH net-next 3/8] net: phy: Allow PHY devices to identify themselves as Ethernet switches
Date: Thu, 30 Apr 2015 19:16:30 +0200 [thread overview]
Message-ID: <20150430171630.GE18874@lunn.ch> (raw)
In-Reply-To: <55425AB3.2040908@gmail.com>
> > Hi Florian
> >
> > I have another two use cases for fixed_phy which i'm thinking about
> > implementing soon. Both require putting a fixed_phy into DSA port
> > properties in DT.
> >
> > The first is when the CPU ethernet and the switch don't have the same
> > speed capabilities. At the moment, the switch driver configures the
> > CPU port to its maximum speed. But i know of a board coming soon with
> > gigabit switch ports, but the CPU Ethernet is only fast Ethernet.
>
> With the patch after, if your switch is MDIO connected to your host, you
> could make that happen easily, since the read_status() callback would
> only be invoked for the CPU port from the CPU Ethernet MAC driver
> (that's the theory).
I'm not sure i get what you are saying.
What we currently have is:
CPU ETH->fixed_phy Switch port CPU
| |
+---------------------------------------+
and what i'm thinking we want is:
CPU ETH->fixed_phy fixed_phy <-Switch port CPU
| |
+---------------------------------------+
So that when setting up the switch side of the link, i can read from
the switch ports fixed_phy how the port should be configured.
I'm also wondering if they could even share one fixed_phy?
But i suspect that will not work.
> > So in this respect, i'm wondering if is_switch is the best of names?
>
> Probably not, I agree, pseudo_fixed_link ;)?
Yes, something like that.
Andrew
next prev parent reply other threads:[~2015-04-30 17:21 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-30 1:57 [RFC PATCH net-next 0/8] net: dsa: New registration API Florian Fainelli
2015-04-30 1:57 ` [RFC PATCH net-next 1/8] net: dsa: Move dsa_switch_tree final setup in separate function Florian Fainelli
2015-05-04 2:01 ` David Miller
2015-04-30 1:57 ` [RFC PATCH net-next 2/8] net: phy: Check fixup lists in get_phy_device() Florian Fainelli
2015-05-04 2:02 ` David Miller
2015-04-30 1:57 ` [RFC PATCH net-next 3/8] net: phy: Allow PHY devices to identify themselves as Ethernet switches Florian Fainelli
2015-04-30 12:56 ` Andrew Lunn
2015-04-30 16:39 ` Florian Fainelli
2015-04-30 17:16 ` Andrew Lunn [this message]
2015-04-30 17:37 ` Florian Fainelli
2015-04-30 17:48 ` Andrew Lunn
2015-04-30 18:04 ` Florian Fainelli
2015-04-30 18:19 ` Andrew Lunn
2015-04-30 1:57 ` [RFC PATCH net-next 4/8] net: mv643xx_eth: Handle Ethernet switches as PHY devices Florian Fainelli
2015-05-04 2:06 ` David Miller
2015-04-30 1:57 ` [RFC PATCH net-next 5/8] net: dsa: add new API to register switch devices Florian Fainelli
2015-05-04 2:09 ` David Miller
2015-04-30 1:57 ` [RFC PATCH net-next 6/8] net: dsa: bcm_sf2: make it a real platform driver Florian Fainelli
2015-04-30 1:57 ` [RFC PATCH net-next 7/8] net: dsa: mv88e6060: make it a proper PHY driver Florian Fainelli
2015-04-30 12:46 ` Andrew Lunn
2015-04-30 13:49 ` Guenter Roeck
2015-04-30 16:46 ` Florian Fainelli
2015-04-30 17:02 ` Andrew Lunn
2015-04-30 17:13 ` Florian Fainelli
2015-05-01 2:28 ` Guenter Roeck
2015-05-01 6:41 ` Florian Fainelli
2015-04-30 1:57 ` [RFC PATCH net-next 8/8] net: dsa: mv88e6xxx: Allow them to be proper PHY drivers Florian Fainelli
2015-04-30 13:12 ` [RFC PATCH net-next 0/8] net: dsa: New registration API Andrew Lunn
2015-04-30 16:50 ` Florian Fainelli
2015-04-30 17:27 ` Andrew Lunn
2015-04-30 17:50 ` Florian Fainelli
2015-04-30 18:14 ` Andrew Lunn
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=20150430171630.GE18874@lunn.ch \
--to=andrew@lunn.ch \
--cc=Chris.Packham@alliedtelesis.co.nz \
--cc=andrey.volkov@nexvision.fr \
--cc=cphealy@gmail.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=jerome.oufella@savoirfairelinux.com \
--cc=jonasj76@gmail.com \
--cc=linux@roeck-us.net \
--cc=mathieu@codeaurora.org \
--cc=netdev@vger.kernel.org \
--cc=vivien.didelot@savoirfairelinux.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 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).