Received-SPF: pass (google.com: domain of linux-kernel+bounces-158454-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: <Raju.Lakkaraju@microchip.com>
To: <andrew@lunn.ch>
CC: <netdev@vger.kernel.org>, <davem@davemloft.net>, <kuba@kernel.org>,
	<pabeni@redhat.com>, <edumazet@google.com>, <linux-kernel@vger.kernel.org>,
	<Bryan.Whitehead@microchip.com>, <UNGLinuxDriver@microchip.com>
Subject: RE: [PATCH net V2 2/2] net: lan743x: support WOL in MAC even when PHY
 does not
Thread-Topic: [PATCH net V2 2/2] net: lan743x: support WOL in MAC even when
 PHY does not
Thread-Index: AQHaen5pA5HIVZmbdE+YwqVuzvYGF7FBPcYAgBgZppCAAKxcAIAbyhwwgAChCICAAqOYgA==
Date: Thu, 25 Apr 2024 11:37:12 +0000
Message-ID: <LV8PR11MB8700D54F5E03440681BF0D449F172@LV8PR11MB8700.namprd11.prod.outlook.com>
References: <20240320042107.903051-1-Raju.Lakkaraju@microchip.com>
 <20240320042107.903051-3-Raju.Lakkaraju@microchip.com>
 <22089299-a3e2-4cbd-942a-65ea070657b8@lunn.ch>
 <LV8PR11MB87003ABBCA98F00F3EEA9AB09F032@LV8PR11MB8700.namprd11.prod.outlook.com>
 <fb5a6f19-ae4c-443e-babb-cbbcf6ba5fc6@lunn.ch>
 <LV8PR11MB8700A34520EA2521BC5F59EF9F112@LV8PR11MB8700.namprd11.prod.outlook.com>
 <9c4f8fcd-ae95-4874-b829-d381928c5f13@lunn.ch>
In-Reply-To: <9c4f8fcd-ae95-4874-b829-d381928c5f13@lunn.ch>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?yky+1aVQKPtNLyqMO3s5t07Rx6thLx6LVZsXJznM67MznxbCi2/rKOCHTzSN?=
 =?us-ascii?Q?/MQ/YGK2JOZWOu25WuH7TIG8okm3WtX62PPVJkhKFKGkYlR75l+0bL5oZ2a2?=
 =?us-ascii?Q?5ZoGPPtE6gC2XzK6o6iikqo96Rayf6349yXtuocMKOKkOhshwoRFNN6Qlb5w?=
 =?us-ascii?Q?bcz+NZQgZXkUf+atLWVBQcmp2FzoKwVbEU5rXufMrFOYoF7mLZY9qxPYMC5m?=
 =?us-ascii?Q?u3/YgxfEsbgrWIzNFCeOPMDjg/r92wT7VXuYt/cu8CWfTfwvQYVy6lLH06bH?=
 =?us-ascii?Q?Knl9fKBg2gXnXGhDbae8T1SVbFvARdlNUMz7gFltxO/z5Ns1VKGRKy6mahc/?=
 =?us-ascii?Q?GlBaOLEiOCjOQNT61wms4BVFfx7t/ikfu5Aope7vpAogrp37GrL8cKAi2aty?=
 =?us-ascii?Q?d9EWWY+/fKaTyn84u6PUsQBsJmU3X5nf1JXYAAF7hq5b710FpDIHCV7Mh95S?=
 =?us-ascii?Q?dUba41p9VLFhN9l5Ggj8EmcNmqp9RhlgxbSdNViGJQBkDrqVLfckgM0jL/ai?=
 =?us-ascii?Q?BxZYmG9/rqPhDwnlY2Bx1qaelg5TREoO5q1/nSK4uY90LNSzLQwIjSpNJNbQ?=
 =?us-ascii?Q?lkYgr5opyRYCq+FqxaHOh/imipaKnhfaeVNxZo7/Evmp7hQZTXVdt8t4EbuR?=
 =?us-ascii?Q?hrPL9z8w/7bOfehNOLwNk92V/Mlo2vSjWTE2eSfRhu5wiAniFhcOIuL/4Cie?=
 =?us-ascii?Q?jjjkIvQLFMQ+O3E+ypMdXAWa132EQeZo7tckZsKtzQ8+TmD93pZvz7sVDBkv?=
 =?us-ascii?Q?CLypZX09jEmpX8oOLkrD/p2xbA1jz/6XOou4jv6tYgmYzSIh1UPXpD73OYzw?=
 =?us-ascii?Q?Ky4DpQl6re71YgEkAkjpohi8dblEAZfeX5YeMrcUpayYD1qEnzrxv5Azzpmc?=
 =?us-ascii?Q?Ia1VmYmnCaBaMi3Ikioh5xhIgnWkCG6Sr9pjUciffo4sqJuOcyjOsmkyLE3y?=
 =?us-ascii?Q?GA3gBgwZ0TO4XKZk1u+h1dbulsMJY2l55nUSkQ+RJHhXR9tyygn6odRLloGV?=
 =?us-ascii?Q?zV8koEvuHgwNGKNwZbmoRa/ASEgUISaVNpkwWLrXuW7H/h1TIOZNLibbVF2W?=
 =?us-ascii?Q?tYqDMX9XhgveAEEMMd4C93aDkNUz1LHYgFN8WJb0kyquVcCC9NePai1V5cwU?=
 =?us-ascii?Q?blVoJ83i6m27+0CpyGBKxngQ66EG325x4Go3466eHmgWkocL9C5ugHWR86ou?=
 =?us-ascii?Q?DGZXqE/+euzRcivL/AhWkUhPLTPYfsPwPbP812Z02MrPr7knGlCziJtLWSxV?=
 =?us-ascii?Q?zPMdVDu5QUlvTS10fHCRjFWr2c8Vac5xnigIRNWVs0dMB0kjY38KgUWqbvMn?=
 =?us-ascii?Q?dFH3Whi1K6Xn5UNm1pZTK+fjzmn5Kc119CWIUkzIVw1HACUdTYfflo3NpHVC?=
 =?us-ascii?Q?5mVX0nEgiZrYUmimixj5PCqvAL8JCe6knptQ7yLbKxwI7vW/DwCTBj/XdD/E?=
 =?us-ascii?Q?IEjfDi20v6VQuQAnfE3jmCJz16OJ3rfIQAlzGT7HwzncHcy7BoUmpIPtZhbn?=
 =?us-ascii?Q?dlw+MvVLHB8VUTzlyXCb1UM2E2iDn8/lMV1jRXy7PQLvsfmWlMvK53U3B8kK?=
 =?us-ascii?Q?jZy//GXRia1LWw0+OKux7/nHlQqy/Ot9KRbaneImPj3UMDjF+h0H+P19pAxE?=
 =?us-ascii?Q?mg=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LV8PR11MB8700.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d2841c66-1888-401a-fb7d-08dc651c0ca6
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2024 11:37:12.5173
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: EVRiW7XpySkuIYg0pgx0+vtSg3faMiCThnr1IOQL4PXaeCvXiwn+QEPPKKq+UammplA6LuxfYanBCwMjfwG6WOR8Q1Z/ahbEK0Ka3S+Xd/k=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7133

Hi Andrew,

Thank you for quick response and valuable suggestions.

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Wednesday, April 24, 2024 12:41 AM
> To: Raju Lakkaraju - I30499 <Raju.Lakkaraju@microchip.com>
> Cc: netdev@vger.kernel.org; davem@davemloft.net; kuba@kernel.org;
> pabeni@redhat.com; edumazet@google.com; linux-kernel@vger.kernel.org;
> Bryan Whitehead - C21958 <Bryan.Whitehead@microchip.com>;
> UNGLinuxDriver <UNGLinuxDriver@microchip.com>
> Subject: Re: [PATCH net V2 2/2] net: lan743x: support WOL in MAC even whe=
n
> PHY does not
>=20
> EXTERNAL EMAIL: Do not click links or open attachments unless you know th=
e
> content is safe
>=20
> > If we don't enable/register the PCI11x1x's ethernet device in wake
> > list by calling " device_set_wakeup_enable( )" function, device power
> > state shows as disable.
>=20
> > PHY (GPY211C)'s interrupt pin (MDINT) connect to PCI11x1x's ethernet
> device.
>=20
> > When I configure the WAKE_PHY or WAKE_MAGIC on GPY211C PHY,
> Interrupt
> > generation observed when magic packet or link activity (link down or
> > link up).  If wakeup enable in PCI11x1x's ethernet device, System
> > resumes from sleep.
>=20
> This is the bit that is missing from your commit message, and maybe it sh=
ould
> be in a comment. The interrupt controller is part of the MAC. So you need=
 to
> leave MAC burning power, maybe even processing packets, because you
> cannot disable the MAC but leave the interrupt controller functioning, so=
 that
> it can trigger a wake up via PCIe.
>=20
> There are a few things you should consider:
>=20
> Call phy_speed_down().  This will renegotiate the link, dropping it to th=
e
> slowest speed both link partners support. So hopefully down to 10Mbps.
> Your MAC will then only need to pointlessly process 10Mbps of packets,
> rather than 1Gbps.
>=20

If PHY handles the magic packet or phy activity (i.e. WAKE_MAGIC or WAKE_PH=
Y), our PCI11x1x's MAC will handle only interrupt (MDINT from PHY). Not MAC=
's magic packet.
In this case do we really call phy_speed_down( ) ?

In case of WAKE_PHY enable and put system in suspend mode,  I'm seeing issu=
es with calling phy_speed_down().=20
When speed change occurs, Link interrupt occurs by Link partner which inter=
nally system resume from sleep.

Do we need to call phy_speed_down( ) for only magic packet (WAKE_MAGIC) cas=
e only ?

> See if you can disable parts of the MAC, in particularly the receive engi=
ne, in
> order to save power.
>=20
> Talk to your hardware engineer and see if the next generation of the
> hardware can separate the interrupt controller from the MAC, so you can
> disable the MAC and leave the interrupt controller functioning.
>=20
> > Please find the attached prototype code change (Temporary patch)for
> reference.
> > I will submit this patch separately.
>=20

Sure. I will do.

> Please just submit it in the normal way for review.
>=20
>        Andrew

Thanks,
Raju