Received-SPF: pass (google.com: domain of linux-kernel+bounces-185764-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
From: Larry Chiu <larry.chiu@realtek.com>
To: Andrew Lunn <andrew@lunn.ch>
CC: Justin Lai <justinlai0215@realtek.com>,
        "kuba@kernel.org"
	<kuba@kernel.org>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "edumazet@google.com" <edumazet@google.com>,
        "pabeni@redhat.com"
	<pabeni@redhat.com>,
        "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>,
        "netdev@vger.kernel.org"
	<netdev@vger.kernel.org>,
        "jiri@resnulli.us" <jiri@resnulli.us>,
        "horms@kernel.org" <horms@kernel.org>,
        Ping-Ke Shih <pkshih@realtek.com>
Subject: RE: [PATCH net-next v19 01/13] rtase: Add pci table supported in this module
Thread-Topic: [PATCH net-next v19 01/13] rtase: Add pci table supported in
 this module
Thread-Index: AQHaqC9Rjgvgl8xidUGsWwGzPtgZ5LGa66SAgAZDQWCAAA0PoP//58SAgAGQINA=
Date: Wed, 22 May 2024 04:43:11 +0000
Message-ID: <f9133a36bbae41138c3080f8f6282bfd@realtek.com>
References: <20240517075302.7653-1-justinlai0215@realtek.com>
 <20240517075302.7653-2-justinlai0215@realtek.com>
 <d840e007-c819-42df-bc71-536328d4f5d7@lunn.ch>
 <e5d7a77511f746bdb0b38b6174ef5de4@realtek.com>
 <97e30c5f-1656-46d0-b06c-3607a90ec96f@lunn.ch>
In-Reply-To: <97e30c5f-1656-46d0-b06c-3607a90ec96f@lunn.ch>
Accept-Language: zh-TW, en-US
Content-Language: zh-TW
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
MIME-Version: 1.0


> On Tue, May 21, 2024 at 06:20:04AM +0000, Larry Chiu wrote:
> >
> > >> + *  Below is a simplified block diagram of the chip and its relevan=
t
> interfaces.
> > >> + *
> > >> + *               *************************
> > >> + *               *                       *
> > >> + *               *  CPU network device   *
> > >> + *               *                       *
> > >> + *               *   +-------------+     *
> > >> + *               *   |  PCIE Host  |     *
> > >> + *               ***********++************
> > >> + *                          ||
> > >> + *                         PCIE
> > >> + *                          ||
> > >> + *      ********************++**********************
> > >> + *      *            | PCIE Endpoint |             *
> > >> + *      *            +---------------+             *
> > >> + *      *                | GMAC |                  *
> > >> + *      *                +--++--+  Realtek         *
> > >> + *      *                   ||     RTL90xx Series  *
> > >> + *      *                   ||                     *
> > >> + *      *     +-------------++----------------+    *
> > >> + *      *     |           | MAC |             |    *
> > >> + *      *     |           +-----+             |    *
> > >> + *      *     |                               |    *
> > >> + *      *     |     Ethernet Switch Core      |    *
> > >> + *      *     |                               |    *
> > >> + *      *     |   +-----+           +-----+   |    *
> > >> + *      *     |   | MAC |...........| MAC |   |    *
> > >> + *      *     +---+-----+-----------+-----+---+    *
> > >> + *      *         | PHY |...........| PHY |        *
> > >> + *      *         +--++-+           +--++-+        *
> > >> + *      *************||****************||***********
> > >> + *
> > >> + *  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 i=
n
> between.
> > >
> > >Given this architecture, this driver cannot be used unless there is a =
switch
> > >driver as well. This driver is nearly ready to be merged. So what are =
your
> > >plans for the switch driver? Do you have a first version you can post?=
 That
> > >will reassure us you do plan to release a switch driver, and not use a=
 SDK in
> > >userspace.
> > >
> > >        Andrew
> >
> > Hi Andrew,
> > This GMAC is configured after the switch is boot-up and does not requir=
e a
> > switch driver to work.
>=20
> But if you cannot configure the switch, it is pointless passing the switc=
h
> packets. The Linux architecture is that Linux needs to be able to control=
 the
> switch somehow. There needs to be a driver with the switchdev API on its
> upper side which connects it to the Linux network stack. Ideally the lowe=
r
> side of this driver can directly write switch registers. Alternatively it=
 can make
> some sort of RPC to firmware which configures the switch.
>=20
> Before committing this MAC driver, we will want to be convinced there is =
a
> switchdev driver for the switch.
>=20
>         Andrew


I know what you mean.
But actually this GMAC works like a NIC connected to an Ethernet Switch not=
 a=20
management port, its packets communicating with other ports.

The PCIe Endpoint is a multi-function device, the other function is used to=
=20
control the switch register, we are still working on where to put this driv=
er in=20
Linux. We thought it should be separated into different device drivers, or =
you=20
think we should register two pcie functions in this driver.

Larry