Received-SPF: pass (google.com: domain of linux-kernel+bounces-86891-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Thu, 29 Feb 2024 16:06:23 +0100
From: Andrew Lunn <andrew@lunn.ch>
To: Raju.Lakkaraju@microchip.com
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
	linux-kernel@vger.kernel.org, Bryan.Whitehead@microchip.com,
	richardcochran@gmail.com, UNGLinuxDriver@microchip.com
Subject: Re: [PATCH net 3/3] net: lan743x: Address problems with wake option
 flags configuration sequences
Message-ID: <e038ec4e-c54d-4628-8997-90510c0d96ab@lunn.ch>
References: <20240226080934.46003-1-Raju.Lakkaraju@microchip.com>
 <20240226080934.46003-4-Raju.Lakkaraju@microchip.com>
 <b83b74b7-3221-4747-8b71-17738c18c042@lunn.ch>
 <LV8PR11MB8700C2F9461F4200431446D49F5F2@LV8PR11MB8700.namprd11.prod.outlook.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <LV8PR11MB8700C2F9461F4200431446D49F5F2@LV8PR11MB8700.namprd11.prod.outlook.com>

On Thu, Feb 29, 2024 at 08:59:20AM +0000, Raju.Lakkaraju@microchip.com wrote:
> Hi Andrew,
> 
> Thank you for review comments.
> 
> > -----Original Message-----
> > From: Andrew Lunn <andrew@lunn.ch>
> > Sent: Tuesday, February 27, 2024 7:28 AM
> > To: Raju Lakkaraju - I30499 <Raju.Lakkaraju@microchip.com>
> > Cc: netdev@vger.kernel.org; davem@davemloft.net; kuba@kernel.org; linux-
> > kernel@vger.kernel.org; Bryan Whitehead - C21958
> > <Bryan.Whitehead@microchip.com>; richardcochran@gmail.com;
> > UNGLinuxDriver <UNGLinuxDriver@microchip.com>
> > Subject: Re: [PATCH net 3/3] net: lan743x: Address problems with wake option
> > flags configuration sequences
> > 
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> > 
> > On Mon, Feb 26, 2024 at 01:39:34PM +0530, Raju Lakkaraju wrote:
> > > Wake options handling has been reworked as follows:
> > > a. We only enable secure on magic packet when both secure and magic wol
> > >    options are requested together.
> > > b. If secure-on magic packet had been previously enabled, and a
> > subsequent
> > >    command does not include it, we add it. This was done to workaround a
> > >    problem with the 'pm-suspend' application which is unaware of secure-on
> > >    magic packet being enabled and can unintentionally disable it prior to
> > >    putting the system into suspend.
> > 
> > This seems to be in a bit of a grey area. But ethtool says:
> > 
> >            wol p|u|m|b|a|g|s|f|d...
> >                   Sets  Wake-on-LAN  options.   Not  all devices support this.
> >                   The argument to this option is a string of characters speci‐
> >                   fying which options to enable.
> >                   p   Wake on PHY activity
> >                   u   Wake on unicast messages
> >                   m   Wake on multicast messages
> >                   b   Wake on broadcast messages
> >                   a   Wake on ARP
> >                   g   Wake on MagicPacket™
> >                   s   Enable SecureOn™ password for MagicPacket™
> >                   f   Wake on filter(s)
> >                   d   Disable (wake on  nothing).   This  option
> >                       clears all previous options.
> > 
> > d clears everything. All other things enable one option. There does not
> > appear to be a way to disable a single option, and i would say, adding options
> > is incremental.
> > 
> 
> Yes. "d" clears everything.
> But, if we enable "g" then enable "a", "g" option overwritten by "a"

This is where i say it is a bit of a grey area. For me, they are
incremental. You can enable a and then later enable g, and you should
have both enabled.

> Please find the attached log information 
> > So:
> > 
> > > a. We only enable secure on magic packet when both secure and magic wol
> > >    options are requested together.
> > 
> > I don't think they need to be requested together. I think you can first enable
> > Wake on MagicPacket and then in a second call to ethtool Enable SecureOn
> > password for MagicPacket. I also don't think it would unreasonable to accept
> > Enable SecureOn password for MagicPacket and have that imply Wake on
> > MagicPacket.
> > 
> 
> If we need to enable any 2 options, we have to provide both options together.
> i.e.
> sudo ethtool -s enp9s0 wol ga

which i think is wrong. A driver should allow incremental adding WoL
options.

> 
> > And:
> > 
> > > b. If secure-on magic packet had been previously enabled, and a
> > subsequent
> > >    command does not include it, we add it.
> > 
> > If there has not been a d, secure-on magic packet should remain enabled until
> > there is a d.
> > 
> 
> This is not happened with existing "Ethtool".
> Please find the log information in an attachment file.

That could just be a driver bug.

Take a step back. Is there any clear documentation about how ethtool
-s wol should really work? Any comments in the code? Any man page
documentation.

Lets first understand how it is expected to work. Then we can decided
if the driver is implementing it correctly.

   Andrew