All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Jiawen Wu <jiawenwu@trustnetic.com>
Cc: netdev@vger.kernel.org, andrew@lunn.ch, hkallweit1@gmail.com,
	Jose.Abreu@synopsys.com, mengyuanlou@net-swift.com
Subject: Re: [PATCH net-next 4/7] net: pcs: xpcs: adapt Wangxun NICs for SGMII mode
Date: Thu, 3 Aug 2023 12:10:33 +0100	[thread overview]
Message-ID: <ZMuLKa2HX9/LiCPn@shell.armlinux.org.uk> (raw)
In-Reply-To: <068501d9c5b1$0e263ad0$2a72b070$@trustnetic.com>

On Thu, Aug 03, 2023 at 10:20:22AM +0800, Jiawen Wu wrote:
> > No there isn't, and it conforms with the above.
> > 
> > A read looks like this:
> > 
> >       Address  Data                   Address  Data     Data
> > Start 10101100 000yyyyy RepeatedStart 10101101 DDDDDDDD DDDDDDDD Stop
> >                       or Stop followed
> > 		          by Start
> > 
> > The terms "Address" and "Data" here are as per the I²C specification.
> > You will notice that the first part has one byte of address and *one*
> > byte of data to convey the register address. This is what the "1" you
> > are referring to above is for.
> > 
> > For completness, a write looks like this:
> > 
> >       Address  Data     Data     Data
> > Start 10101100 000yyyyy DDDDDDDD DDDDDDDD Stop
> > 
> > Essentially, in all cases, when 0x56 is addressed with the data
> > direction in write mode, the very first byte is _always_ the register
> > address and the remainder contain the data. When the data direction is
> > in read mode, the bytes are always data.
> > 
> > The description you quote above is poor because it doesn't make it
> > clear whether "read" and "write" apply to the bus transactions or to
> > the device operations. However, I can assure you that what is
> > implemented is correct, since this is the standard small 24xx memory
> > device protocol, and I've been programming that on various
> > microcontrollers and such like for the last 30 years.
> > 
> > Are you seeing a problem with the data read or written to the PHY?
> 
> Hi Russell,
> 
> I really don't know how to deal with "MAC side SGMII", could you please
> help me?
> 
> From the test results, when I config PCS in "PHY side SGMII", the link status
> of PHY in copper SFP is read by I2C after AN complete. Then PHY's link up
> status is informed to PHYLINK, then PCS will check its status. But when I just
> change PCS to "MAC side SGMII", I2C will keep reading timeouts since AN
> complete. I checked the register of PCS to confirm AN complete, but PHY's
> link status would never be updated in PHYLINK.

I don't understand what is going on here either - but what I do know
is that there is _zero_ difference as far as the network link is
concerned between an on-board PHY using SGMII to the MAC/PCS and a SFP
with a PHY using SGMII.

In both situations the PHY behaves the same - it presents a PHY-side
SGMII interface, so it sends to the MAC/PCS the speed and duplex
settings, and expects the MAC/PCS to acknowledge them.

The name "MAC side SGMII" suggests that this mode provides the
acknowledgement, whereas "PHY side SGMII" suggests that this mode
provides a speed and duplex.

Given all this, using "PHY side SGMII" with a SFP, and "MAC side
SGMII" for an on-board PHY just seems utterly wrong - and I can't
make head nor tail of it.

> It's kind of weird to me, how does the configuration of PCS relate to I2C?

I2C is just the access method for PHYs on SFPs - because there are
no MDIO bus pins on SFP modules, only I2C pins mainly for accessing
the identification EEPROM and diagnostics, but many copper SFPs have
a way to access the PHY.

I2C is transparent as far as phylib is concerned - the mdio-i2c
driver makes the PHY "appear" as if it is on a conventional MDIO
bus.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

  reply	other threads:[~2023-08-03 11:10 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-24 10:23 [PATCH net-next 0/7] support more link mode for TXGBE Jiawen Wu
2023-07-24 10:23 ` [PATCH net-next 1/7] net: pcs: xpcs: add specific vendor supoprt for Wangxun 10Gb NICs Jiawen Wu
2023-07-25 17:24   ` Andrew Lunn
2023-07-24 10:23 ` [PATCH net-next 2/7] net: pcs: xpcs: support to switch mode for Wangxun NICs Jiawen Wu
2023-07-25 17:32   ` Andrew Lunn
2023-07-26  2:40     ` Jiawen Wu
2023-07-24 10:23 ` [PATCH net-next 3/7] net: pcs: xpcs: add 1000BASE-X AN interrupt support Jiawen Wu
2023-07-24 10:23 ` [PATCH net-next 4/7] net: pcs: xpcs: adapt Wangxun NICs for SGMII mode Jiawen Wu
2023-07-24 10:34   ` Russell King (Oracle)
2023-07-25  2:05     ` Jiawen Wu
2023-07-25  7:48       ` Russell King (Oracle)
2023-07-25  9:50         ` Jiawen Wu
2023-07-25  9:58           ` Russell King (Oracle)
2023-07-25 10:08             ` Russell King (Oracle)
2023-07-25 10:45               ` Jiawen Wu
2023-07-28 10:11               ` Jiawen Wu
2023-07-28 10:24                 ` Andrew Lunn
2023-07-31  1:47                   ` Jiawen Wu
2023-07-28 10:33                 ` Russell King (Oracle)
2023-07-31  1:58                   ` Jiawen Wu
2023-08-03  2:20                   ` Jiawen Wu
2023-08-03 11:10                     ` Russell King (Oracle) [this message]
2023-08-04  5:56                       ` Jiawen Wu
2023-07-25 17:37   ` Andrew Lunn
2023-07-26 12:14   ` Simon Horman
2023-07-24 10:23 ` [PATCH net-next 5/7] net: txgbe: support switching mode to 1000BASE-X and SGMII Jiawen Wu
2023-07-24 10:40   ` Russell King (Oracle)
2023-07-25  2:29     ` Jiawen Wu
2023-07-24 10:23 ` [PATCH net-next 6/7] net: txgbe: support copper NIC with external PHY Jiawen Wu
2023-07-24 10:43   ` Russell King (Oracle)
2023-07-25  2:41     ` Jiawen Wu
2023-07-25  8:02       ` Russell King (Oracle)
2023-07-25 10:04         ` Jiawen Wu
2023-07-25 10:38           ` Russell King (Oracle)
2023-07-26 12:15   ` Simon Horman
2023-07-24 10:23 ` [PATCH net-next 7/7] net: ngbe: move mdio access registers to libwx Jiawen Wu

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=ZMuLKa2HX9/LiCPn@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=Jose.Abreu@synopsys.com \
    --cc=andrew@lunn.ch \
    --cc=hkallweit1@gmail.com \
    --cc=jiawenwu@trustnetic.com \
    --cc=mengyuanlou@net-swift.com \
    --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.