[PATCH] csstoh.sh shell script fixes cross compiling issues
by Thomas Waldecker
From: Thomas Waldecker <thomas.waldecker(a)tqs.de>
Added the csstoh.sh shell script from Igor Zhbanov found here:
http://lists.01.org/pipermail/powertop/2012-July/000151.html
also patched the Makefile.am to use the csstoh.sh script.
The compiled csstoh binary doesn't work for cross compiling,
however Igors Patch never got applied upstream.
---
src/Makefile.am | 8 +++-----
src/csstoh.sh | 45 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+), 5 deletions(-)
create mode 100755 src/csstoh.sh
diff --git a/src/Makefile.am b/src/Makefile.am
index f60426a..a53d942 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1,9 +1,6 @@
AUTOMAKE_OPTIONS = subdir-objects
ACLOCAL_AMFLAGS = -I ../m4
-noinst_PROGRAMS = csstoh
-csstoh_SOURCES = csstoh.c
-
sbin_PROGRAMS = powertop
nodist_powertop_SOURCES = css.h
@@ -48,6 +45,7 @@ AM_LDFLAGS = $(LIBS) $(NCURSES_LIBS) $(PCIUTILS_LIBS) $(LIBNL_LIBS) $(LIBZ_LIBS)
BUILT_SOURCES = css.h
CLEANFILES = css.h
-css.h: csstoh powertop.css
- ./csstoh "$(srcdir)"/powertop.css css.h
+css.h: powertop.css
+ chmod +x ./csstoh.sh
+ ./csstoh.sh "$(srcdir)"/powertop.css css.h
diff --git a/src/csstoh.sh b/src/csstoh.sh
new file mode 100755
index 0000000..5918d12
--- /dev/null
+++ b/src/csstoh.sh
@@ -0,0 +1,45 @@
+#!/bin/bash
+#
+# This program file is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by the
+# Free Software Foundation; version 2 of the License.
+#
+# This program is distributed in the hope that it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+# for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program in a file named COPYING; if not, write to the
+# Free Software Foundation, Inc,
+# 51 Franklin Street, Fifth Floor,
+# Boston, MA 02110-1301 USA
+# or just google for it.
+#
+# Written by Igor Zhbanov<i.zhbanov at samsung.com>
+
+
+if [ $# -lt 2 ]; then
+ echo "Usage: csstoh.sh cssfile header.h"
+ exit 1
+fi
+
+if [ ! -r $1 ]; then
+ echo "Can't find file $1"
+ exit 1
+fi
+
+if ! echo -n>$2; then
+ echo "Can't open file $2 for writing."
+ exit 1
+fi
+
+echo "#ifndef __INCLUDE_GUARD_CCS_H">> $2
+echo "#define __INCLUDE_GUARD_CCS_H">> $2
+echo>> $2
+echo "const char css[] = ">> $2
+
+sed -r 's/^(.*)$/\t\"\1\\n\"/' $1>> $2
+
+echo ";">> $2
+echo "#endif">> $2
--
1.7.9.5
9 years, 7 months
[PATCH 1/3] Suppress compiler warnings on write()
by Namhyung Kim
Modern linux distribution forces to check result of write() call.
It emits following warnings:
CXX calibrate/powertop-calibrate.o
calibrate/calibrate.cpp: In function ‘void* burn_disk(void*)’:
calibrate/calibrate.cpp:297: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result
...
CXX measurement/powertop-extech.o
measurement/extech.cpp: In member function ‘void extech_power_meter::measure()’:
measurement/extech.cpp:290: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result
Signed-off-by: Namhyung Kim <namhyung(a)gmail.com>
---
src/calibrate/calibrate.cpp | 3 ++-
src/measurement/extech.cpp | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/calibrate/calibrate.cpp b/src/calibrate/calibrate.cpp
index 5457cf8..2d4c1af 100644
--- a/src/calibrate/calibrate.cpp
+++ b/src/calibrate/calibrate.cpp
@@ -294,7 +294,8 @@ static void *burn_disk(void *dummy)
while (!stop_measurement) {
lseek(fd, 0, SEEK_SET);
- write(fd, buffer, 64*1024);
+ if (write(fd, buffer, 64*1024))
+ /* make gcc silent */;
fdatasync(fd);
}
close(fd);
diff --git a/src/measurement/extech.cpp b/src/measurement/extech.cpp
index 4e8bf8a..b9e95ca 100644
--- a/src/measurement/extech.cpp
+++ b/src/measurement/extech.cpp
@@ -287,7 +287,8 @@ extech_power_meter::extech_power_meter(const char *extech_name)
void extech_power_meter::measure(void)
{
/* trigger the extech to send data */
- write(fd, " ", 1);
+ if (write(fd, " ", 1) < 0)
+ return;
rate = extech_read(fd);
--
1.7.9.2
9 years, 7 months
[PATCH] tab_window: null members on construction
by Sergey Senozhatsky
introduce tab_window ctor and null memebers during construction. show_tab() may be
called before window_refresh() [which sets ypad_pos and xpad_pos to 0], causing prefresh()
call with uninit win->ypad_pos, win->xpad_pos args.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
---
src/display.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/src/display.h b/src/display.h
index b450f8b..9af3ec0 100644
--- a/src/display.h
+++ b/src/display.h
@@ -53,6 +53,14 @@ public:
short int xpad_pos, ypad_pos;
WINDOW *win;
+ tab_window() {
+ cursor_pos = 0;
+ cursor_max = 0;
+ xpad_pos =0;
+ ypad_pos = 0;
+ win = NULL;
+ }
+
virtual void cursor_down(void) {
if (cursor_pos < cursor_max ) cursor_pos++; repaint();
} ;
9 years, 7 months
[PATCH 2/2] runtime_pm: register parameters
by Sergey Senozhatsky
register parameter during runtime_pmdevice() construction, making
call to get_parameter_value() in power_usage() valid.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
---
src/devices/runtime_pm.cpp | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/devices/runtime_pm.cpp b/src/devices/runtime_pm.cpp
index 0d13cab..bbc3bf0 100644
--- a/src/devices/runtime_pm.cpp
+++ b/src/devices/runtime_pm.cpp
@@ -49,11 +49,11 @@ runtime_pmdevice::runtime_pmdevice(const char *_name, const char *path) : device
before_suspended_time = 0;
before_active_time = 0;
- after_suspended_time = 0;
+ after_suspended_time = 0;
after_active_time = 0;
-}
-
+ register_parameter(humanname);
+}
void runtime_pmdevice::start_measurement(void)
{
@@ -237,4 +237,4 @@ void create_all_runtime_pm_devices(void)
do_bus("spi");
do_bus("platform");
do_bus("i2c");
-}
\ No newline at end of file
+}
9 years, 7 months
[PATCH 1/2] parameters: fix uninitialized values in param/result getters
by Sergey Senozhatsky
-- get_param_index()/get_result_index() may be called for unknown parameter,
causing new map entry creation via operator[] access. it's not safe to check
returned pair->second value for newly created map entry, since there is no default
ctor for int type. use map::find() instead.
-- get_parameter_value(char *) now uses get_parameter_value(uint), which performs
parameters overflow detection and prevents illegal read. this one was affecting
power_device_sort(), returning garbage to compare function.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
---
src/parameters/parameters.cpp | 40 ++++++++++++++++++++++++----------------
src/parameters/parameters.h | 2 +-
2 files changed, 25 insertions(+), 17 deletions(-)
diff --git a/src/parameters/parameters.cpp b/src/parameters/parameters.cpp
index 1a89b14..936d789 100644
--- a/src/parameters/parameters.cpp
+++ b/src/parameters/parameters.cpp
@@ -44,11 +44,15 @@ static int maxresindex = 1;
int get_param_index(const char *name)
{
- int index;
- index = param_index[name];
- if (index == 0) {
- index = param_index[name] = ++maxindex;
- }
+ std::map<string, int>::iterator it;
+ int index = 0;
+
+ it = param_index.find(name);
+ if (it == param_index.end()) {
+ param_index[name] = ++maxindex;
+ index = maxindex;
+ } else
+ index = it->second;
if (index == 0)
printf("OH BLA\n");
@@ -57,11 +61,15 @@ int get_param_index(const char *name)
int get_result_index(const char *name)
{
- int index;
- index = result_index[name];
- if (index == 0) {
- index = result_index[name] = ++maxresindex;
- }
+ std::map<string, int>::iterator it;
+ int index = 0;
+
+ it = result_index.find(name);
+ if (it == result_index.end()) {
+ result_index[name] = ++maxresindex;
+ index = maxresindex;
+ } else
+ index = it->second;
return index;
}
@@ -101,16 +109,16 @@ void set_parameter_value(const char *name, double value, struct parameter_bundle
double get_parameter_value(const char *name, struct parameter_bundle *the_bundle)
{
unsigned int index;
-
index = get_param_index(name);
- if (index >= the_bundle->parameters.size()) {
- fprintf(stderr, "BUG: requesting unregistered parameter %s\n", name);
- }
- return the_bundle->parameters[index];
+ return get_parameter_value(index, the_bundle);
}
-double get_parameter_value(int index, struct parameter_bundle *the_bundle)
+double get_parameter_value(unsigned int index, struct parameter_bundle *the_bundle)
{
+ if (index >= the_bundle->parameters.size()) {
+ fprintf(stderr, "BUG: requesting unregistered parameter %d\n", index);
+ return 0;
+ }
return the_bundle->parameters[index];
}
diff --git a/src/parameters/parameters.h b/src/parameters/parameters.h
index a8c1154..bd9fee8 100644
--- a/src/parameters/parameters.h
+++ b/src/parameters/parameters.h
@@ -60,7 +60,7 @@ extern int get_result_index(const char *param);
extern void register_parameter(const char *name, double default_value = 0.00, double weight = 1.0);
extern double get_parameter_value(const char *name, struct parameter_bundle *bundle = &all_parameters);
-extern double get_parameter_value(int index, struct parameter_bundle *bundle = &all_parameters);
+extern double get_parameter_value(unsigned int index, struct parameter_bundle *bundle = &all_parameters);
extern void set_parameter_value(const char *name, double value, struct parameter_bundle *bundle = &all_parameters);
9 years, 7 months
[RFC] [PATCHv2 00/10] Code deduplication in cpu/*
by Ivan Shapovalov
This is a resend (unchanged but rebased) of the patch series about refactoring code
in cpu/* by deduplication. From this series, only the last bugfix patch has been applied
so far due to a code freeze.
Ivan Shapovalov (10):
Fix includes: do not include intel_cpus.h inside cpu.h
Deduplication: move is_turbo() function to lib
Deduplication: move all instances of account_freq() to abstract_cpu::account_freq()
Deduplication: remove nhm_cpu::account_freq() almost identical to abstract_cpu::account_freq()
Deduplication: remove nhm_{cpu,core,package}::change_effective_frequency() identical to cpu_{linux,core,package}::change_effective_frequency()
Deduplication: merge cpu_{core,linux,package}::change_effective_frequency() into abstract_cpu::change_effective_frequency()
Deduplication: remove {cpu,nhm}_core::calculate_freq() identical to abstract_cpu::calculate_freq()
Deduplication: remove nhm_package::calculate_freq() identical to cpu_package::calculate_freq()
Deduplication: properly merge cpu_package::calculate_freq() into abstract_cpu::calculate_freq()
Deduplication: merge go_idle()/go_unidle()/change_freq() overrides into abstract_cpu() class
9 years, 7 months
Project request
by kernel kernel
Hi,
I'd like to contribute to powertop as part of my PhD research on energy
efficient heterogeneous hpc. I've been looking through the TODO file in the
git repo. Is there any particular task which you can recommend for a
newcomer to the project?
Thanks,
Ken
--
Ken O'Brien
PhD Researcher
Simulation Science and Extreme Events Cluster,
3B1, UCD CASL,
8 Belfield Business Park,
Dublin 4,
Ireland.
9 years, 8 months
[FYI][RFC][PATCH 0/2] MALI GPU profiling support
by Igor Zhbanov
This patch-set adds the ability of profiling MALI GPU in Powertop.
Disclaimer:
This patch-set is far from perfect and I know it. ;-)
It is just an initial review attempt.
Tha MALI GPU profiling patch is written in C-style because initially
there was a C-program. Yes, it is possible to rewrite is in C++ if needed.
But now I would know whether it fits into the Powertop at all?
And here is some explanation of what inside the box.
*** MALI GPU profiling with PowerTOP ***
** MALI GPU **
Mali GPU consists of several Geometry Processor units (GP) and Pixel Processor
units (PP). For example, MALI 400 MP GPU has one Geometry Processor (GP0) and
four Pixel Processors (PP0, PP1, PP2 and PP3). Also MALI GPU may contain other
units such as L2 cache. But now I don't know how to profile them.
* PseudoWatt definition *
Consumed power approximately can be computed as this [1]:
2
P = CV f, /* P = C*V*V*f */
(where C is capacitance, V is voltage and f is frequency).
We don't need exact Watts so we consider that 1 PW (PseudoWatt) is consumed
running one GPU unit (GPx or PPx) on 266 MHz and 1 Volt. So I consider
capacitance equal to 1 / 266 000 000.
** Event types **
There are two types of profiling events visible from user-space applications:
performance counters and trace events.
* Performance counters *
There are two performance counter registers per each GPx, PPx or L2 unit in
the MALI GPU. Each register can count events of specified type. One can
specify the type of interesting event by writing a value in the corresponding
performance counter source register. Event types can be found in technical
reference manual for MALI GPU.
Such events are counted on per GPU basis because GPU has no information what
process runs specified task. So we cannot use these performance counters to
measure per-process activity. Also only two types of events can be counted
simultaneously for any GPU unit because there are only two counter registers
per unit.
* Trace events *
MALI GPU kernel module provide events information by the means of pseudo-files
in /sys filesystem (actual for r3p0 driver version). There are two exclusive
ways to get profiling events from kernel module -- Linux trace points and
internal profiling format. The way which will be used is defined at the
compile time. In the file drivers/media/video/samsung/mali_r3p0/Makefile there
is variable USING_INTERNAL_PROFILING that is set to 1 when internal profiling
mode is used and is set to 0 when trace points are used. By default it is set
to 1 (internal profiling mode).
* Trace points *
In trace points mode MALI GPU events are available through the standard
mechanism of Linux kernel trace points. To grab MALI trace events one should
write mali_timeline_event string to the file /sys/kernel/debug/tracing/set
event. Then it is possible to read events from the file
/sys/kernel/debug/tracing/trace_pipe.
This trace point is defined in the file
drivers/media/video/samsung/mali_r3p0/linux/mali_linux.trace.h in Linux kernel
source tree [2]. As you may see each event has event identifier (event_id)
meaning the type of event and five event parameters (d0 through d4) containing
additional information. Not all parameters are required for all types of
events. For that events these parameters are set to zero.
As you may see by the next line only event identifier provided to user space
by the means of trace points:
TP_printk("event=%d", __entry->event_id)
It is not suitable because we need to know more information for proper event
handling.
The other way of getting trace events information is the sys_perf_event_open
system call. But MALI GPU driver doesn't provide all needed events in this
way. In particular such events as voltage and frequency change are available
only by using internal profiling method.
So we have to use internal profiling method in PowerTOP (or we could enhance
MALI GPU driver written by ARM to provide all needed events via trace points).
* Internal profiling *
Internal profiling is the method provided by MALI GPU kernel module allowing
to collect more information about events (although there are no restrictions
preventing sending this information via trace points). This facility is
controlled by pseudo-files in /sys file-system.
To enable this facility to work one should write character 1 to the file
/sys/kernel/debug/mali/profiling/proc/default/enable. To disable profiling
write character 0.
When profiling is turned on it is possible to enable or disable events
recording by writing characters 1 or 0, respectively, to the file
/sys/kernel/debug/mali/profiling/record.
When event recording is on events information is collected in driver's
internal buffer. And when event recording is off this information is available
in the file /sys/kernel/debug/mali/profiling/events. When event recording
is on this file is empty.
* Event format *
Each event is reported as a text line consisting of seven decimal numbers like
this:
1329701288752682877 34013184 0 0 4294967295 0 0
First number is the UNIX time with nanosecond resolution (number of
nanoseconds since Jan 1-st of 1970).
Second number is the event identifier in the following format:
Bit number: 31 - 28 27 - 24 23 - 16 15 - 00
Type of field: Reserved Type Channel Data
The Type field denotes event type. This field can accept the following values:
Value Type Description
0 SINGLE Single event
1 START Start rendering job
2 STOP Stop rendering job
3 SUSPEND
4 RESUME
The Channel field denotes event channel or source. This field can accept the
following values:
Value Channel Description
00 SOFTWARE Events came from user-space
01 GP0 Geometry Processor
05 PP0 Pixel Processors
06 PP1
07 PP2
08 PP3
09 PP4
10 PP5
11 PP6
12 PP7
21 GPU GPU Core
The Data field contains event subtype which can be used to concretize
particular event type. The meaning of this field depends on the value of Type
field.
For events of type SINGLE from SOFTWARE channel this field can accept the
following values:
Value Type Description
0 NONE (Unused?)
1 EGL_NEW_FRAME (Unused?)
2 FLUSH (Unused?)
3 EGL_SWAP_BUFFERS (Unused?)
4 GPU_FREQ GPU frequency was changed
5 GPU_VOLTS GPU voltage was changed
6 GLOBAL_TRY_LOCK
7 GLOBAL_LOCK
8 GLOBAL_UNLOCK
9 VBLANK_VSYNC
For events of type SINGLE from GP0 and PP0 through PP7 channels this field can
accept the following values:
Value Type
0 NONE
1 INTERRUPT
2 FLUSH
And for events of type SINGLE from GPU channel this field can accept following
value:
Value Type Description
10 FREQ_VOLT_CHANGE GPU frequency and voltage was changed
Data fields d0 through d4 contains data specific to particular event. If some
fields are not used it's set to zero.
** Computing the power consumption **
* Useful events *
There are several types of events that are used to calculate power
consumption. First of all it is rendering job starting and stopping events.
For START event PowerTop records PID of the process started the job, the time
of start and GPU unit name the job is running on (PP0, PP1,... PP7). PID of
the process can be found in the field d0.
When PowerTOP receives the STOP event, this mean that rendering job was
stopped and it is possible to calculate its duration. This duration will be
used to calculate power consumption.
Also there are three types of events related to GPU core frequency and/or
voltage change. PowerTOP tracks current values of frequency and voltage.
* Power consumption *
Power consumption of the GPU depends on frequency and voltage the GPU core is
operating on. When voltage and/or frequency was changed PowerTOP split current
running tasks if any into two (one with old values and another with new
values). So for each rendering task PowerTOP knows its duration, frequency and
voltage of the GPU core and the PID of the process started this task. That is
power consumed for particular task rendering can be computed using the formula
above. By adding together power consumed by individual tasks PowerTOP can
calculate total power consumption for each process.
The MALI GPU power consumption information can be found in a table named
"Overview of MALI GPU power consumers" in PowerTOP HTML-report.
** Deficiencies **
* Process names *
Sometimes PowerTOP cannot properly display process name when it was started
after PowerTOP start and was terminated before PowerTOP finished to work. This
can happen because process could generate only GPU-related events (and none of
scheduler-related events) and GPU-related events contains only PID of process
(not the command line or application name). And since the process was
terminated early, PowerTOP cannot resolve process name through the /proc
file-system because at that time there will be no entry for terminated
process.
This happen because of PowerTOP design. After start it asks the kernel to
collect events, then sleeps some seconds and reads events from the kernel and
process it. Some events (scheduler-related) contains process name and its
command line, and others not (e.g. GPU-related). So if some process doesn't
generated scheduler-related events and terminated before PowerTOP wakes after
sleep, then the PowerTOP can nowhere get information about process.
To solve this problem I have modified PowerTOP so it constantly monitors
/proc file-system for the new processes. And when it sees the new one it
collects process' information. PowerTOP monitors it once in a second. I think
it is a good compromise between CPU load and frequent information collecting.
The probability that some process (living less than a second) escapes
monitoring still exist, but it is much lower than in current version. At the
worst case (when process generate only GPU-related events during its very
short life) PowerTOP will display only PID for that process.
Anyway such an elusive process will not generate enough power consumption
to worry about.
* Voltage/frequency independent change *
There are three type of events from MALI kernel module related to frequency or
voltage changing:
the voltage was changed,
the frequency was changed,
both of the voltage and the frequency was changed.
It is impossible to change only the frequency or only the voltage of CPU core.
Both parameters are changed at the same time. But the driver can report any
set of these events in any order. Having a table with pairs of allowed
frequency/voltage values it is possible to deduce one value from another. But
that table will be GPU dependent and we don't have an information about all of
MALI GPU chips.
Now it is possible a situation when PowerTOP sees an event of frequency or
voltage change after some job was started. PowerTOP will split the running
task, and the second half of the task will have slightly incorrect value of
frequency or voltage (old frequency with new voltage or vice verse). This may
lead to tiny computational errors.
* Initial voltage and frequency values *
When PowerTOP starts on system with display turned on and some graphical
applications already running, there is a possibility for situation where some
rendering job will be started before PowerTOP grabs the first voltage or
frequency setting event. So PowerTOP will be unaware of current frequency
and/or voltage value. Because of this it is impossible to correctly calculate
power consumption for that task because it is impossible to ask the driver
about current frequency and voltage. And in the current version PowerTOP drops
jobs before first voltage or frequency change event (such events are frequent
enough, so it's not a problem). It is possible to use some default value but
it will be GPU-dependent and we don't know what value to use.
Links:
[1] http://en.wikipedia.org/wiki/CPU_power_dissipation
[2] You can study MALI GPU driver for example in kernel for
Galaxy SIII phone found in archive named
GT-I9300_JB_Opensource_Update6.zip
on the site http://opensource.samsung.com/
Igor Zhbanov (2):
Introducing process scanner facility
MALI GPU profiling support
src/Makefile.am | 2 +
src/main.cpp | 17 +-
src/mali-internal-events/mali-events.h | 143 +++
src/mali-internal-events/mali-internal-events.cpp | 1279 +++++++++++++++++++++
src/mali-internal-events/proc-scan.cpp | 316 +++++
src/mali-internal-events/proc-scan.h | 59 +
src/process/process.cpp | 43 +
7 files changed, 1857 insertions(+), 2 deletions(-)
create mode 100644 src/mali-internal-events/mali-events.h
create mode 100644 src/mali-internal-events/mali-internal-events.cpp
create mode 100644 src/mali-internal-events/proc-scan.cpp
create mode 100644 src/mali-internal-events/proc-scan.h
--
1.7.5.4
9 years, 9 months
Libnl in Powertop
by Ganapati Bhat
Hello All,
I am new to using powertop and development in opensource as a whole. When I
went through the earlier versions I found that libnl was not needed in the
older versions. Can anyone please tell me what is functionality that libnl
adds to powertop? Is it possible to build v2.1 without using libnl?
--
Best Regards,
Ganapati Bhat
9 years, 9 months
[PATCH] Correct script for tuning wifi power_save with iw
by Daniel Kahn Gillmor
The logic for the script to run to fix the power_save state of a
wireless device was inverted.
Signed-off-by: Daniel Kahn Gillmor <dkg(a)fifthhorseman.net>
---
src/tuning/wifi.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/tuning/wifi.cpp b/src/tuning/wifi.cpp
index 38d9be6..77cdfcc 100644
--- a/src/tuning/wifi.cpp
+++ b/src/tuning/wifi.cpp
@@ -47,8 +47,8 @@ wifi_tunable::wifi_tunable(const char *_iface) : tunable("", 1.5, _("Good"), _("
strcpy(iface, _iface);
sprintf(desc, _("Wireless Power Saving for interface %s"), iface);
- sprintf(toggle_good, "iw dev %s set power_save off", iface);
- sprintf(toggle_bad, "iw dev %s set power_save on", iface);
+ sprintf(toggle_good, "iw dev %s set power_save on", iface);
+ sprintf(toggle_bad, "iw dev %s set power_save off", iface);
}
int wifi_tunable::good_bad(void)
--
1.7.10.4
9 years, 9 months
