netdev - Re: [net-next PATCH 11/15] eth: fbnic: Enable Ethernet link setup

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]

Message-ID: <CAKgT0UdaMtDtHevCX5cM+=4Z1krVCbQg56YJEiNX880H-+cxVg@mail.gmail.com>
Date: Sun, 21 Apr 2024 16:21:57 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, Alexander Duyck <alexanderduyck@...com>, kuba@...nel.org, 
	davem@...emloft.net, pabeni@...hat.com
Subject: Re: [net-next PATCH 11/15] eth: fbnic: Enable Ethernet link setup

On Fri, Apr 5, 2024 at 2:51 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> > +#define FBNIC_CSR_START_PCS          0x10000 /* CSR section delimiter */
> > +#define FBNIC_PCS_CONTROL1_0         0x10000         /* 0x40000 */
> > +#define FBNIC_PCS_CONTROL1_RESET             CSR_BIT(15)
> > +#define FBNIC_PCS_CONTROL1_LOOPBACK          CSR_BIT(14)
> > +#define FBNIC_PCS_CONTROL1_SPEED_SELECT_ALWAYS       CSR_BIT(13)
> > +#define FBNIC_PCS_CONTROL1_SPEED_ALWAYS              CSR_BIT(6)
>
> This appears to be PCS control register 1, define in 45.2.3.1. Since
> this is a standard register, please add it to mdio.h.

Actually all these bits are essentially there in the forms of:
MDIO_CTRL1_RESET, MDIO_PCS_CTRL1_LOOPBACK, and MDIO_CTRL1_SPEEDSELEXT.
I will base the driver on these values.

> > +#define FBNIC_PCS_VENDOR_VL_INTVL_0  0x10202         /* 0x40808 */
>
> Could you explain how these registers map to 802.3 clause 45? Would
> that be 3.1002? That would however put it in the reserved range 3.812
> through 3.1799. The vendor range is 3.32768 through 3.65535.

So from what I can tell the vendor specific registers are mapped into
the middle of the range starting at register 512 instead of starting
at 32768. So essentially offsets 512 - 612 and 1544 - 1639 appear to
be used for the vendor specific registers. In addition we have an
unused block of PCS registers that are unused from 1024 to 1536 as
they were there for an unsupported speed configuration.

> > +#define FBNIC_CSR_START_RSFEC                0x10800 /* CSR section delimiter */
> > +#define FBNIC_RSFEC_CONTROL(n)\
> > +                             (0x10800 + 8 * (n))     /* 0x42000 + 32*n */
> > +#define FBNIC_RSFEC_CONTROL_AM16_COPY_DIS    CSR_BIT(3)
> > +#define FBNIC_RSFEC_CONTROL_KP_ENABLE                CSR_BIT(8)
> > +#define FBNIC_RSFEC_CONTROL_TC_PAD_ALTER     CSR_BIT(10)
> > +#define FBNIC_RSFEC_MAX_LANES                        4
> > +#define FBNIC_RSFEC_CCW_LO(n) \
> > +                             (0x10802 + 8 * (n))     /* 0x42008 + 32*n */
> > +#define FBNIC_RSFEC_CCW_HI(n) \
> > +                             (0x10803 + 8 * (n))     /* 0x4200c + 32*n */
>
> Is this Corrected Code Words Lower/Upper? 1.202 and 1.203?

Yes and no, this is 3.802 and 3.803 which I assume is more or less the
same thing but the PCS variant.

> > +#define FBNIC_RSFEC_NCCW_LO(n) \
> > +                             (0x10804 + 8 * (n))     /* 0x42010 + 32*n */
> > +#define FBNIC_RSFEC_NCCW_HI(n) \
> > +                             (0x10805 + 8 * (n))     /* 0x42014 + 32*n */
>
> Which suggests this is Uncorrected code Words? 1.204, 1.205? I guess
> the N is for Not?

These are 3.804 and 3.805.

>From what I can tell the first 6 registers for the RSFEC are laid out
in the same order. However we have 4 of these blocks that we have to
work with and they are tightly packed such that the second block
starts at offset 8 following the start of the first block.

> > +#define FBNIC_RSFEC_SYMBLERR_LO(n) \
> > +                             (0x10880 + 8 * (n))     /* 0x42200 + 32*n */
> > +#define FBNIC_RSFEC_SYMBLERR_HI(n) \
> > +                             (0x10881 + 8 * (n))     /* 0x42204 + 32*n */
>
> And these are symbol count errors, 1.210 and 1.211?

I think this is 3.600 and 3.601.  However we only have 8 sets of
registers instead of 16.

> If there are other registers which follow 802.3 it would be good to
> add them to mdio.h, so others can share them.

I will try to see what I can do. I will try to sort out what is device
device specific such as our register layout versus what is shared such
as PCS register layouts and such.

Thanks,

- Alex