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: <20090601.024834.119882380.davem@davemloft.net>
Date:	Mon, 01 Jun 2009 02:48:34 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	eswierk@...stanetworks.com
Cc:	netdev@...r.kernel.org, aabdulla@...dia.com
Subject: Re: [PATCH] forcedeth: add phy_power_down parameter, leave phy
 powered up by default

From: Ed Swierk <eswierk@...stanetworks.com>
Date: Sat, 30 May 2009 15:59:46 -0700

> Add a phy_power_down parameter to forcedeth: set to 1 to power down the
> phy and disable the link when an interface goes down; set to 0 to always
> leave the phy powered up.
> 
> The phy power state persists across reboots; Windows, some BIOSes, and
> older versions of Linux don't bother to power up the phy again, forcing
> users to remove all power to get the interface working (see
> http://bugzilla.kernel.org/show_bug.cgi?id=13072).  Leaving the phy
> powered on is the safest default behavior.  Users accustomed to seeing
> the link state reflect the interface state and/or wanting to minimize
> power consumption can set phy_power_down=1 if compatibility with other
> OSes is not an issue.
> 
> Signed-off-by: Ed Swierk <eswierk@...stanetworks.com>

Yes, this is probably the thing to do, but...

+enum {
+	NV_PHY_POWER_DOWN_NEVER,
+	NV_PHY_POWER_DOWN_ON_INTF_DOWN
+};
+static int phy_power_down = NV_PHY_POWER_DOWN_NEVER;
...
+module_param(phy_power_down, int, 0);
+MODULE_PARM_DESC(phy_power_down, "Power down phy and disable link when interface is down (1), or always leave phy powered up (0).");

Using an enum is gratuitous, and if you want to guarentee the
enum values start at zero you have to explicitly assign the
first enum value at zero.

But again it's gratuitous, and it's better to just explicitly
use '0' and '1 in this kind of situation.

Please fix this up and resubmit, thanks.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ