netdev - Re: [PATCH net-next v3 1/2] net/ethernet/realtek: Add Realtek automotive PCIe driver code

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: <eb245c85-0909-4a75-830d-afb96ccd5d38@lunn.ch>
Date: Thu, 17 Aug 2023 14:22:58 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Justin Lai <justinlai0215@...ltek.com>
Cc: "kuba@...nel.org" <kuba@...nel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v3 1/2] net/ethernet/realtek: Add Realtek
 automotive PCIe driver code

On Thu, Aug 17, 2023 at 07:32:07AM +0000, Justin Lai wrote:
> > On Tue, Aug 15, 2023 at 10:37:55PM +0800, Justin Lai wrote:
> > > This patch is to add the ethernet device driver for the PCIe interface
> > > of Realtek Automotive Ethernet Switch, applicable to RTL9054, RTL9068,
> > RTL9072, RTL9075, RTL9068, RTL9071.
> > >
> > > Below is a simplified block diagram of the chip and its relevant interfaces.
> > >
> > >           *************************
> > >           *                       *
> > >           *  CPU network device   *
> > >           *    ____________       *
> > >           *   |            |      *
> > >           *   |  PCIE Host |      *
> > >           *************************
> > >                     ||
> > >                    PCIE
> > >                     ||
> > >   ****************************************
> > >   *          | PCIE Endpoint |           *
> > >   *          |---------------|           *
> > >   *              | GMAC |                *
> > >   *              |------|  Realtek       *
> > >   *                 ||   RTL90xx Series  *
> > >   *                 ||                   *
> > >   *    _____________||______________     *
> > >   *   |            |MAC|            |    *
> > >   *   |            |---|            |    *
> > >   *   |                             |    *
> > >   *   |     Ethernet Switch Core    |    *
> > >   *   |                             |    *
> > >   *   |  -----             -----    |    *
> > >   *   |  |MAC| ............|MAC|    |    *
> > >   *   |__|___|_____________|___|____|    *
> > >   *      |PHY| ............|PHY|         *
> > >   *      -----             -----         *
> > >   *********||****************||***********
> > > This driver is mainly used to control GMAC, but does not control the switch
> > core, so it is not the same as DSA.
> > > In addition, the GMAC is not directly connected to the PHY, but
> > > directly connected to the mac of the switch core, so there is no need for PHY
> > handing.
> > 
> > So this describes your board? Is the MAC and the swtich two separate chips? Is
> > it however possible to connect the GMAC to a PHY? Could some OEM purchase
> > the chipset and build a board with a PHY? We write MAC drivers around what
> > the MAC can do, not what one specific board allows.
> > 
> > What MAC drivers do to support being connected to a switch like this is use a
> > fixed-link PHY, via phylink. This gives a virtual PHY, which supports one speed.
> > The MAC driver then just uses the phylink API as normal.
> > 
> > On your board, how is the switch controlled? Is there an MDIO bus as part of
> > the MAC? If so, you should add an MDIO bus master driver.
>  
> 
> Hi, Andrew
>
> The block of the Realtek RTL90xx series is our entire chip
> architecture, the GMAC is connected to the switch core, and there is
> no PHY in between. So customers don't need to consider that.

O.K. It would of been helpful if you had said this right at the
beginning. It is good to point out anything unusual with your
hardware, otherwise reviewers are going to make wrong assumptions, and
then ask lots of questions.

Is the 'line' speed of the MAC fixed? It operates at one speed, and
that is it? What about pause? You cannot negotiate pause, but can it
be forced?

> We have some externally controlled interfaces to control switch
> core, such as I2C, MDIO, SPI, etc., but these are not controlled by
> GMAC .

And just for conformation, there is no extra fields in the DMA
descriptors, etc, to help the switch? You will at some point write a
DSA driver for the switch, and there will be a tagging protocol, extra
headers added to the frame, in order to direct frames out the correct
port of the switch?

Are the I2C, MDIO and SPI bus masters also hanging off a PCIE
endpoint? Can they probe independently? I'm just want to check this
should not be part of an MFD driver.

Is there a public data sheet for this device?

	Andrew