From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.tipi-net.de (mail.tipi-net.de [194.13.80.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D65F1F192E; Mon, 6 Apr 2026 13:33:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=194.13.80.246 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775482433; cv=none; b=JPwU8VP0XLBfaRpCznn9rtl/WXEqGPaxfnvhRJTcbJBddNMP3+I4CxopRdj6l90wIF7Oewa4gL+7pXvnkHnFplAmI8r36pOsnXGTlA71jQpHDJSEVJ/7Yze5Q/TGegUV0Uv4+Qh2+rgHGJWU/lSoXzfUH71qGuS0NFtWVH8ySa4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775482433; c=relaxed/simple; bh=rby7I+8Zk1SNZO7WH40Wj1O8cmV/OD8smQdiIDeejsw=; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:Content-Type; b=RLv9wRd/8UK8RDIEifDMkXFJR7X9w4a+uVv2Uq8vYOk4J0D64FYfnFs0YJscWrZdlNxDuePveNcuFnsvE2og7iZMonaMTV/KKxKi3zSdxgGgHqvFeNFuYS+3TtkrTz2UIPnFt+Mc7Kaf6nzpMaxhimUZPa+N1EenfjtTKYbCDj4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tipi-net.de; spf=pass smtp.mailfrom=tipi-net.de; dkim=pass (2048-bit key) header.d=tipi-net.de header.i=@tipi-net.de header.b=vhLkpoeT; arc=none smtp.client-ip=194.13.80.246 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tipi-net.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=tipi-net.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=tipi-net.de header.i=@tipi-net.de header.b="vhLkpoeT" Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 16353A5888; Mon, 6 Apr 2026 15:33:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tipi-net.de; s=dkim; t=1775482424; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=yEwxY8e/7wqrX1mbmXoSy1MbXgqbAyCZJyVMeKm7HOQ=; b=vhLkpoeTEriohvJIdBFXLtzWp9zgDaYiSvXMvuBGaRxmw+JG1D1qTBn4PjsYcA5jazGWNP 3F1/AYi2K1mj7SdgIOenpL8rObxF0J4Fc3LCDuTVq4xXBNqObaJ4bRUsagooItUdE9+vgt XpTxF5gu/odEkUPvhdz+qVnWQglKCT3T+8M9uKGd7Vsp5FfZm1JYWlRrxwCWeggZAJCdQw OyTYPNd3uRdRkbPlETt6Lda13ZmdAxbLvSJ7Yirpao7Rgkh0vxAd7ea+6YX9fv0dZ5Pv52 HuiThUvXwyUPq/REhZDqseaTczoxw65geTMdaesVhxfRqGj8a45wyx4uxbYxVQ== Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Mon, 06 Apr 2026 15:33:40 +0200 From: Nicolai Buchwitz To: Andrew Lunn Cc: Heiner Kallweit , Russell King , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Florian Fainelli , Broadcom internal kernel review list , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 0/3] net: phy: add support for disabling autonomous EEE In-Reply-To: References: <20260406-devel-autonomous-eee-v1-0-b335e7143711@tipi-net.de> Message-ID: <9272c5dd653039b3def8caaea3e631c5@tipi-net.de> X-Sender: nb@tipi-net.de Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Last-TLS-Session-Version: TLSv1.3 On 6.4.2026 15:17, Andrew Lunn wrote: > On Mon, Apr 06, 2026 at 09:13:06AM +0200, Nicolai Buchwitz wrote: >> Some PHYs implement autonomous EEE where the PHY manages EEE >> independently > > I suppose we should discuss naming. As far as i know, IEEE 802.3 does > not include this feature, so it does not provide a guide to how we > should name it. > > In the past we have used SmartEEE, but that is Atheros's vendor > name. Broadcom seem to call it AutoGrEEEn. > > Autonomous EEE seems like a reasonable name, and appears to be vendor > agnostic. Are we happy with this? "Autonomous EEE" works for me (obviously). It kinda describes what happens (the PHY acts autonomously) without being tied to a specific vendor's marketing name. That said, I feel Russell's argument that it doesn't type well. But even after some walks in the woods I wasn't able to come up with a better name yet. > > What i guess is unclear is what part of the network stack is acting > autonomously. In the context of a PHY driver op, > .disable_autonomous_eee is clear. But when we go further to actually > making use of it, do we need to report to user space if we are using > IEEE 802.3 EEE or "autonomous EEE". But i guess it is no worse than > SmartEEE or AutoGrEEEn which also make no indication where EEE is > happening. I think for now it's fine to not expose this. From the user's perspective, EEE is either on or off. Whether the PHY or MAC manages LPI is an implementation detail. ethtool --set-eee should just do the right thing: - MAC supports LPI: use MAC-managed EEE - MAC doesn't, but PHY has autonomous EEE: use that instead - Neither: EOPNOTSUPP I don't think there's a meaningful use case for letting users choose between the two. Or is there? > > Thoughts? > > Andrew Nicolai