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;
From:   Jose Abreu <Jose.Abreu@synopsys.com>
To:     "Voon, Weifeng" <weifeng.voon@intel.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: AQHWAE03JZEV2gP9CkiKXaQcDq7OzahVzGeAgAAJs4CAAAleQA==
Date:   Mon, 23 Mar 2020 08:53:28 +0000
Message-ID: <BN8PR12MB326606DE1FEB055B7361A939D3F00@BN8PR12MB3266.namprd12.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>
In-Reply-To: <BYAPR11MB27575EF05D65A8AA9AF4128488F00@BYAPR11MB2757.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: synopsys.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fef1f1f5-0a01-45c2-0e2e-08d7cf07a803
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2020 08:53:28.4898
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c33c9f88-1eb7-4099-9700-16013fd9e8aa
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: eDclYXwqLQRFkq+js8T0VqQSRvJLP+kfCtZC5GvR0rBYlLVFSv48bZb0SHoaUUAg+wEW5WGb2ZJDcyZxQ0Ee1g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR12MB3588
X-OriginatorOrg: synopsys.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

From: Voon, Weifeng <weifeng.voon@intel.com>
Date: Mar/23/2020, 08:16:29 (UTC+00:00)

> > > 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 o=
f
> > > 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.
> >=20
> > I don't think this is the right approach.
> >=20
> > 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 fold=
er
> as a generic mdio-intel-serdes as this is a specific Intel serdes archite=
cture which
> would only pair with DW EQos and DW xPCS HW. Since this serdes will not a=
ble to
> pair other MAC or other non-Intel platform, I would like you to reconside=
r this
> approach. I am open for discussion.=20
> Thanks Jose for the fast response.

OK, then I think we should use the BSP init/exit functions that are=20
already available for platform setups (.init and .exit callback of=20
plat_stmmacenet_data struct). We just need to extend this to PCI based=20
setups.

You can take a look at stmmac_platform.c and check what's done.=20
Basically:
	- Call priv->plat->init() at probe() and resume()
	- Call priv->plat->exit() at remove() and suspend()

---
Thanks,
Jose Miguel Abreu