Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
IronPort-SDR: b7SlJNjhIudv47BzUnscxsnsgEcoxd4elLqeOn0i7xSXaEO7IVMMu3jHM0UKw4flAi1j/AeaDc
 3iwOAVMgQkbQ==
IronPort-SDR: LmcL1CE6cW4D3pp6JEBGukpeTc+7I4iMCpK77ood2qgULsMxVrjJXCpPollYbT9cn6otDgzJne
 K9Xr2M2L4GIw==
From:   "Voon, Weifeng" <weifeng.voon@intel.com>
To:     Jose Abreu <Jose.Abreu@synopsys.com>,
        "David S . Miller" <davem@davemloft.net>,
        Maxime Coquelin <mcoquelin.stm32@gmail.com>
CC:     "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Giuseppe Cavallaro" <peppe.cavallaro@st.com>,
        Andrew Lunn <andrew@lunn.ch>,
        "Alexandre Torgue" <alexandre.torgue@st.com>,
        "Ong, Boon Leong" <boon.leong.ong@intel.com>
Subject: RE: [RFC,net-next,v1, 1/1] net: stmmac: Enable SERDES power up/down
 sequence
Thread-Topic: [RFC,net-next,v1, 1/1] net: stmmac: Enable SERDES power up/down
 sequence
Thread-Index: AQHWAE0vpBWvWDPaGkGozDEPMDm2A6hVzcSAgAAFr0CAAAz8AIAAbqEwgA4QMGA=
Date:   Wed, 1 Apr 2020 14:23:09 +0000
Message-ID: <BYAPR11MB3125359A86ECE3A845595E3888C90@BYAPR11MB3125.namprd11.prod.outlook.com>
References: <20200322132342.2687-1-weifeng.voon@intel.com>
 <20200322132342.2687-2-weifeng.voon@intel.com>
 <BN8PR12MB3266ACFFA4808A133BB72F9DD3F00@BN8PR12MB3266.namprd12.prod.outlook.com>
 <BYAPR11MB27575EF05D65A8AA9AF4128488F00@BYAPR11MB2757.namprd11.prod.outlook.com>
 <BN8PR12MB326606DE1FEB055B7361A939D3F00@BN8PR12MB3266.namprd12.prod.outlook.com>
 <BYAPR11MB2757B80101035B9A599E357B88F00@BYAPR11MB2757.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB2757B80101035B9A599E357B88F00@BYAPR11MB2757.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
dlp-version: 11.2.0.6
dlp-product: dlpe-windows
dlp-reaction: no-action
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fd9a9c2f-4101-40f1-a3fb-08d7d648344b
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2020 14:23:09.8207
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 5JTBYQlnP1lwo6bGM5lbBGXynEe1/E1fAhC3JUCgPGtFe4MG1wjJgNHPMj8Y8T9PIC1wVzmmUPrimhH1JHMqpA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3111
X-OriginatorOrg: intel.com
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> > > > > This patch is to enable Intel SERDES power up/down sequence. The
> > > > > SERDES converts 8/10 bits data to SGMII signal. Below is an
> > > > > example of HW configuration for SGMII mode. The SERDES is
> > > > > located in the PHY IF in the diagram below.
> > > > >
> > > > > <-----------------GBE Controller---------->|<--External PHY
> > > > > chip-->
> > > > > +----------+         +----+            +---+           +--------
> --
> > +
> > > > > |   EQoS   | <-GMII->| DW | < ------ > |PHY| <-SGMII-> |
> External
> > |
> > > > > |   MAC    |         |xPCS|            |IF |           | PHY
> > |
> > > > > +----------+         +----+            +---+           +--------
> --
> > +
> > > > >        ^               ^                 ^                ^
> > > > >        |               |                 |                |
> > > > >        +---------------------MDIO-------------------------+
> > > > >
> > > > > PHY IF configuration and status registers are accessible through
> > > > > mdio address 0x15 which is defined as intel_adhoc_addr. During
> > > > > D0, The driver will need to power up PHY IF by changing the
> > > > > power
> > state to P0.
> > > > > Likewise, for D3, the driver sets PHY IF power state to P3.
> > > >
> > > > I don't think this is the right approach.
> > > >
> > > > You could just add a new "mdio-intel-serdes" to phy/ folder just
> > > > like I did with XPCS because this is mostly related with PHY
> > > > settings rather than EQoS.
> > > I am taking this approach to put it in stmmac folder rather than phy
> > > folder as a generic mdio-intel-serdes as this is a specific Intel
> > > serdes architecture which would only pair with DW EQos and DW xPCS
> HW.
> > > Since this serdes will not able to pair other MAC or other non-Intel
> > > platform, I would like you to reconsider this approach. I am open
> > > for
> > discussion.
> > > Thanks Jose for the fast response.
> >
> > OK, then I think we should use the BSP init/exit functions that are
> > already available for platform setups (.init and .exit callback of
> > plat_stmmacenet_data struct). We just need to extend this to PCI based
> > setups.
> >
> > You can take a look at stmmac_platform.c and check what's done.
> > Basically:
> > 	- Call priv->plat->init() at probe() and resume()
> > 	- Call priv->plat->exit() at remove() and suspend()
> >
> I have 2 concern if using the suggested BSP init/exit function.
> 1. Serdes is configured through MDIO bus. But the mdio bus register only
> happens in stmmac_dvr_probe() in stmmac_main.c.
>=20
> 2. All tx/rx packets requires serdes to be in the correct power state.
> If the driver power-down before stopping all the dma, it will cause tx
> queue timeout as packets are not able to be transmitted out. Hence, the
> serdes cannot be power-down before calling the stmmac_dvr_remove(). The
> stmmac_dvr_remove() will unregister the mdio bus. So, the
> driver cannot powerdown the serdes after the stmmac_dvr_remove() too.

I went through the code again, I understand that your intention is to keep =
the
platform specific setup in its own file and keep the main dwmac logic clean=
.
But, I did not see any way to separate this SERDES configuration from the=20
stmmac_main logic cleanly.=20
Hope to get more ideas and discussion. Thanks.

Weifeng

>=20
> Regards,
> Weifeng
>=20
> > ---
> > Thanks,
> > Jose Miguel Abreu