lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 26 Oct 2021 14:52:59 -0400
From:   Sean Anderson <sean.anderson@...o.com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Nicolas Ferre <nicolas.ferre@...rochip.com>,
        netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Claudiu Beznea <claudiu.beznea@...rochip.com>,
        Antoine Tenart <atenart@...nel.org>,
        Parshuram Thombare <pthombar@...ence.com>,
        Milind Parab <mparab@...ence.com>
Subject: Re: [PATCH v4] net: macb: Fix several edge cases in validate

On 10/26/21 2:28 PM, Russell King (Oracle) wrote:
> On Tue, Oct 26, 2021 at 01:49:03PM -0400, Sean Anderson wrote:
>> On 10/26/21 1:46 PM, Russell King (Oracle) wrote:
>> > On Tue, Oct 26, 2021 at 01:28:15PM -0400, Sean Anderson wrote:
>> > > Actually, according to the Zynq UltraScale+ Devices Register Reference
>> > > [1], the PCS does not support 10/100. So should SGMII even fall through
>> > > here?
>> > >
>> > > [1] https://www.xilinx.com/html_docs/registers/ug1087/gem___pcs_control.html
>> >
>> > Hmm. That brings with it fundamental question: if the PCS supports 1G
>> > only, does it _actually_ support Cisco SGMII, or does it only support
>> > 1000base-X?
>> >
>>
>> Of course, in the technical reference manual [1], they say
>>
>> > The line rate is 1 Gb/s as SGMII hardwired to function at 1 Gb/s only.
>> > However, the data transfer rate can be forced down to 100 Mb/s or 10
>> > Mb/s if the link partner is not capable.
>>
>> which sounds like the normal byte-repetition of SGMII...
>>
>> And they also talk about how the autonegotiation timeout and control words are different.
>
> This document looks a little comical. "GEM supports the serial gigabit
> media-independent interface (SGMII, 1000BASE-SX and 1000BASE-LX) at
> 1000 Gb/s using the PS-GTR interface."
>
> So:
> a) it supports terabyte speeds?
> b) it provides an optical connection direct from the SoC?
>     (the L and S in 1000BASE-X refer to the laser wavelength!)
>
> They really should just be saying "1000BASE-X" rather than specifying
> an optical standard, but lets ignore that fundamental mistake for now.
>
> In the section "SGMII, 1000BASE-SX, or 1000BASE-LX" it says:
>
> "When bit [27] (SGMII mode) in the network configuration register
> (GEM(0:3).network_config[sgmii_mode_enable]) is set, it changes the
> behavior of the auto-negotiation advertisement and link partner ability
> registers to meet the requirements of SGMII. Additionally, the time
> duration of the link timer is reduced from 10ms to 1.6ms."
>
> That bodes well for Cisco SGMII support, but it says nothing about how
> that affects the PCS registers themselves.
>
> As you say above, it goes on to say:
>
> "The line rate is 1 Gb/s as SGMII hardwired to function at 1 GB/s
> only."
>
> That statement is confused. Cisco SGMII and 1000Base-X actually operate
> at 1.25Gbaud line rate due to the 4B5B encoding on the Serdes. However,
> the underlying data rate is 1Gbps, with 100 and 10Mbps achieved by
> symbol replication of only the data portions of the packet transfer.
> This replication does not, however, apply to non-data symbols though.
>
> I suppose they _could_ have implemented Cisco SGMII by having the PCS
> fixed in 1G mode, and then replicate the data prior to the PCS. That
> would be rather peculiar though, and I'm not sure whether that could
> work for the non-data symbols. I suppose it depends whether they just
> slow down the transmission rate into the PCS, or do only data portion
> replication before the PCS.
>
> I've also just found the register listing in HTML form (so less
> searchable than a PDF),

Unfortunately, AFAIK this is the only listing they have :l

(OTOH it is easy to link to)

> and the PCS register listing only shows
> 1000base-X layout for the advertisement and link partner registers.
> It seems to make no mention of "SGMII" mode.

The autonegotiation registers [2, 3] both mention SGMII "non SGMII".

The mux to turn on SGMII is in the network_config register [3].

[1] https://www.xilinx.com/html_docs/registers/ug1087/gem___pcs_an_adv.html
[2] https://www.xilinx.com/html_docs/registers/ug1087/gem___pcs_an_lp_base.html
[3] https://www.xilinx.com/html_docs/registers/ug1087/gem___network_config.html

> So we have an open question: do 10 and 100M speeds actually work on
> GEM, and if they do, how does one program it to operate at these
> speeds. Currently, the driver seems to change bits in NCFGR to change
> speed, and also reconfigure the transmit clock rate.
>
> Going back to the first point I mentioned above, how much should we
> take from these documents as actually being correct? Should we not
> assume anything, but instead just experiment with the hardware and
> see what works.

> For example, are the two speed bits in the PCS control register
> really read-only when in Cisco SGMII mode, or can they be changed -
> and if they can be changed, does that have an effect on the ethernet
> link?

Keep in mind that it is not only Zynq(MP) parts with have GEMs, but
several other SoCs as well. I have not reviewed their datasheets (except
for SiFive's which just say "go read the Linux driver"). It is possible
that other SoCs may not have these limitations. So any experimental
program will need to also experiment with e.g. sama.

Perhaps someone from cadence could comment on what is actually supported
by gem/macb?

--Sean

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ