Netdev List
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
	Linus Walleij <linus.walleij@linaro.org>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org
Subject: Re: [PATCH net-next] net: dsa: mark parsed interface mode for legacy switch drivers
Date: Thu, 17 Aug 2023 22:17:54 +0300	[thread overview]
Message-ID: <20230817191754.vopvjus6gjkojyjz@skbuf> (raw)
In-Reply-To: <65657a0e-0b54-4af4-8a38-988b7393a9f5@lunn.ch>

On Thu, Aug 17, 2023 at 08:52:12PM +0200, Andrew Lunn wrote:
> > Andrew, I'd argue that the MAC-PHY relationship between the DSA master
> > and the CPU port is equally clear as between 2 arbitrary cascade ports.
> > Which is: not clear at all. The RGMII standard does not talk about the
> > existence of a MAC role and a PHY role, to my knowledge.
> 
> The standard does talk about an optional in band status, placed onto
> the RXD pins during the inter packet gap. For that to work, there
> needs to be some notion of MAC and PHY side.

Well, opening the RGMII standard, it was quite stupid of myself to say
that. It says that the purpose of RGMII is to interconnect the MAC and
the PHY right from the first phrase.

You're also completely right in pointing out that the optional in-band
status is provided by the PHY on RXD[3:0].

Actually, MAC-to-MAC is not explicitly supported anywhere in the standard
(RGMII 2.0, 4/1/2002) that I can find. It simply seems to be a case of:
"whatever the PHY is required by the standard to do is specified in such
a way that when another MAC is put in its place (with RX and TX signals
inverted), the protocol still makes sense".

But, with that stretching of the standard considered, I'm still not
necessarily seeing which side is the MAC and which side is the PHY in a
MAC-to-MAC scenario.

With a bit of imagination, I could actually see 2 back-to-back MAC IPs
which both have logic to provide the optional in-band status (with
hardcoded information) to the link partner's RXD[3:0]. No theory seems
to be broken by this (though I can't point to any real implementation).

So a MAC role would be the side that expects the in-band status to be
present on its RXD[3:0], and a PHY role would be the side that provides
it, and being in the MAC role does not preclude being in the PHY role?

  reply	other threads:[~2023-08-17 19:17 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-08 11:12 [PATCH net-next] net: dsa: mark parsed interface mode for legacy switch drivers Russell King (Oracle)
2023-08-08 12:06 ` Vladimir Oltean
2023-08-08 12:30   ` Russell King (Oracle)
2023-08-08 12:39     ` Vladimir Oltean
2023-08-08 12:57       ` Russell King (Oracle)
2023-08-08 13:52         ` Vladimir Oltean
2023-08-08 14:19           ` Russell King (Oracle)
2023-08-10 15:16             ` Vladimir Oltean
2023-08-12 12:16               ` Russell King (Oracle)
2023-08-13 10:50                 ` Vladimir Oltean
2023-08-13 21:56                 ` Linus Walleij
2023-08-13 22:17                   ` Russell King (Oracle)
2023-08-15  6:41                   ` Linus Walleij
2023-08-14 14:59                 ` Vladimir Oltean
2023-08-14 15:12                   ` Russell King (Oracle)
2023-08-14 15:46                     ` Andrew Lunn
2023-08-14 16:27                       ` Russell King (Oracle)
2023-08-14 17:05                         ` Andrew Lunn
2023-08-14 22:03                           ` Russell King (Oracle)
2023-08-14 23:33                             ` Andrew Lunn
2023-08-15 10:13                             ` Russell King (Oracle)
2023-08-17 18:01                               ` Vladimir Oltean
2023-08-17 18:19                             ` Vladimir Oltean
2023-08-17 18:27                           ` Vladimir Oltean
2023-08-17 18:52                             ` Andrew Lunn
2023-08-17 19:17                               ` Vladimir Oltean [this message]
2023-08-18 11:11                                 ` Russell King (Oracle)
2023-08-18 11:40                                   ` Vladimir Oltean
2023-08-18 13:08                                     ` Linus Walleij
2023-08-18 13:29                                       ` Russell King (Oracle)
2023-08-18 16:06                                         ` Linus Walleij
2023-08-18 13:44                                       ` Vladimir Oltean
2023-08-18 13:10                                     ` Russell King (Oracle)
2023-08-18 14:21                                       ` Vladimir Oltean
2023-08-18 16:49                                         ` Vladimir Oltean
2023-08-14 22:21                         ` Linus Walleij
2023-08-14 15:47                     ` Vladimir Oltean
2023-08-08 16:35         ` Andrew Lunn
2023-08-08 12:39 ` Vladimir Oltean
2023-08-09 20:20 ` patchwork-bot+netdevbpf

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=20230817191754.vopvjus6gjkojyjz@skbuf \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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