netdev - Re: [PATCH] ethtool: Add reset operation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20091007.012902.165265462.davem@davemloft.net>
Date:	Wed, 07 Oct 2009 01:29:02 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	bhutchings@...arflare.com
Cc:	netdev@...r.kernel.org, linux-net-drivers@...arflare.com
Subject: Re: [PATCH] ethtool: Add reset operation

From: Ben Hutchings <bhutchings@...arflare.com>
Date: Mon, 05 Oct 2009 21:59:58 +0100

> After updating firmware stored in flash, users may wish to reset the
> relevant hardware and start the new firmware immediately.  This should
> not be completely automatic as it may be disruptive.
> 
> A selective reset may also be useful for debugging or diagnostics.
> 
> This adds a separate reset operation which takes flags indicating the
> components to be reset.  Drivers are allowed to reset only a subset of
> those requested, and must indicate the actual subset.  This allows the
> use of generic component masks and some future expansion.
> 
> Signed-off-by: Ben Hutchings <bhutchings@...arflare.com>
> ---
> This differs from the previous (RFC) version only in the semantics of
> the output value of the reset flags: they should indicate the components
> which were *not* reset.  This should be slightly less error-prone as it
> means implementations do not need to maintain the input and output flags
> separately.

Just so my previous reply doesn't confuse, I did apply this version
of the patch.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html