Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
I disagree on the alert. in this case, the receiving PMA knows it requested the return to normal idle, and doesn’t need the alert. the far end doesn’t have the option of not complying. As far as the upper layers – we agree – we DON’T specify what they do, but we do specify what is signaled. Internally to the phy, the sublayers we do specify - as far as the decoder, the PCS and the XGMII, a regular transition requires that we send those signals.
Beyond the XGMII, what we’re doing locks us into whatever action the rest of the system takes in a return to normal data, since we don’t provide any signaling. There is no specified interface to provide MAC on the other side of the XGMII
the fact that the PHY requested this temporary transition - it has to treat the alert as a return to normal data mode. the LPI client doesn’t get any information that this isn’t a real return to data. how will it make any other decision if we don’t specify
way for it to know the difference? better to hide the whole thing. From: Jim Graba <james.graba@xxxxxxxxxxxx> The transmitter needs to send an ALERT on the MDI to signal the receiving PMA to wake up. Otherwise the receiving PMA will be expecting Quiet/Refresh and will drop the MDI link if it receives anything else. I claim it's simplest for the transmitting PHY to perform a Wake sequence including sending Alert. After that the transmitting PHY should send Idles until: a) The requesting PHY indicates it's OK to enter LPI via OAM or b) The transmitting PHY's MAC sends data. I believe we need not specify or dictate the requesting PHY's upper layers' response to this temporary LPI departure. Each vendor can develop their own. Jim On Wed, Dec 18, 2019 at 4:30 PM George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> wrote:
To unsubscribe from the STDS-802-3-NGAUTO list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGAUTO&A=1 |