As cpupowerutils is intended to be included into the kernel sources,
use the kernel versioning instead of a custom version.
The script utils/version-gen.sh is largely based on the script already
found in tools/perf/util/PERF-VERSION-GEN .
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Use the quiet/verbose mechanism found in kernel tools, without
relying on the special tool "ccdv"
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
CPU power consumption vs performance tuning is no longer
limited to CPU frequency switching anymore: deep sleep states,
traditional dynamic frequency scaling and hidden turbo/boost
frequencies are tied close together and depend on each other.
The first two exist on different architectures like PPC, Itanium and
ARM, the latter (so far) only on X86. On X86 the APU (CPU+GPU) will
only run most efficiently if CPU and GPU has proper power management
in place.
Users and Developers want to have *one* tool to get an overview what
their system supports and to monitor and debug CPU power management
in detail. The tool should compile and work on as many architectures
as possible.
Once this tool stabilizes a bit, it is intended to replace the
Intel-specific tools in tools/power/x86
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
On a recent compile, I got this warning:
CC [M] drivers/net/pcmcia/smc91c92_cs.o
drivers/net/pcmcia/smc91c92_cs.c: In function ‘smc91c92_probe’:
drivers/net/pcmcia/smc91c92_cs.c:812:12: warning: ‘j’ may be used uninitialized in this function
However, "j" is only used in a branch which has the same condition as
a previous branch, where j is set, e.g.
int j;
if (CONDITION)
j = VALUE
...
if (CONDITION)
printk(j)
Still, avoid this warning, as it is easy to circumvent.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Without CONFIG_HERMES_PRISM, only match cards that have "Version 01.01"
as the third product ID. Those have Agere firmware.
With CONFIG_HERMES_PRISM, match all 0x0156:0x0002 cards.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Cards with numeric ID 0x0156:0x0002 and third ID "Version 01.02" can be
assumed to have Intersil firmware. Cards with Agere firmware use
"Version 01.01".
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
This is needed to match wireless cards with Intersil firmware that have
ID 0x0156:0x0002 and the third ID "Version 01.02". Such cards are
currently matched by orinoco_cs, which doesn't support WPA. They should
be matched by hostap_cs.
The first and the second product ID vary widely, so there are few users
with some particular IDs. Of those, very few can submit a patch for
hostap_cs or write a useful bugreport. It's still important to support
their hardware properly.
With PCMCIA_DEVICE_MANF_CARD_PROD_ID3, it should be possible to cover
the remaining Intersil based designs that kept the numeric ID and the
"version" of the reference design.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Kill off the buff gpio as not used anywhere.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Now the are optional, let us get rid of the ones that don't have
any content.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
10 boards define these empty, probably indicating not everyone has a use for them.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
drivers/media/rc/ir-mce_kbd-decoder.c:446:16: error: expected declaration specifiers or '...' before string constant
drivers/media/rc/ir-mce_kbd-decoder.c:446:1: warning: data definition has no type or storage class
drivers/media/rc/ir-mce_kbd-decoder.c:446:1: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
drivers/media/rc/ir-mce_kbd-decoder.c:446:16: warning: function declaration isn't a prototype
drivers/media/rc/ir-mce_kbd-decoder.c:447:15: error: expected declaration specifiers or '...' before string constant
drivers/media/rc/ir-mce_kbd-decoder.c:447:1: warning: data definition has no type or storage class
drivers/media/rc/ir-mce_kbd-decoder.c:447:1: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
drivers/media/rc/ir-mce_kbd-decoder.c:447:15: warning: function declaration isn't a prototype
drivers/media/rc/ir-mce_kbd-decoder.c:448:20: error: expected declaration specifiers or '...' before string constant
drivers/media/rc/ir-mce_kbd-decoder.c:448:1: warning: data definition has no type or storage class
drivers/media/rc/ir-mce_kbd-decoder.c:448:1: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
drivers/media/rc/ir-mce_kbd-decoder.c:448:20: warning: function declaration isn't a prototype
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/video/ov5642.c:985:1: warning: data definition has no type or storage class
drivers/media/video/ov5642.c:985:1: warning: type defaults to 'int' in declaration of 'MODULE_DEVICE_TABLE'
drivers/media/video/ov5642.c:985:1: warning: parameter names (without types) in function declaration
drivers/media/video/ov5642.c: In function 'ov5642_mod_init':
drivers/media/video/ov5642.c:998:9: error: 'THIS_MODULE' undeclared (first use in this function)
drivers/media/video/ov5642.c:998:9: note: each undeclared identifier is reported only once for each function it appears in
drivers/media/video/ov5642.c: At top level:
drivers/media/video/ov5642.c:1009:20: error: expected declaration specifiers or '...' before string constant
drivers/media/video/ov5642.c:1009:1: warning: data definition has no type or storage class
drivers/media/video/ov5642.c:1009:1: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
drivers/media/video/ov5642.c:1009:20: warning: function declaration isn't a prototype
drivers/media/video/ov5642.c:1010:15: error: expected declaration specifiers or '...' before string constant
drivers/media/video/ov5642.c:1010:1: warning: data definition has no type or storage class
drivers/media/video/ov5642.c:1010:1: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
drivers/media/video/ov5642.c:1010:15: warning: function declaration isn't a prototype
drivers/media/video/ov5642.c:1011:16: error: expected declaration specifiers or '...' before string constant
drivers/media/video/ov5642.c:1011:1: warning: data definition has no type or storage class
drivers/media/video/ov5642.c:1011:1: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
drivers/media/video/ov5642.c:1011:16: warning: function declaration isn't a prototype
drivers/media/video/ov5642.c: In function 'ov5642_mod_init':
drivers/media/video/ov5642.c:999:1: warning: control reaches end of non-void function
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Only Sparc and PPC actually have the asm/prom.h include and as such they
can't be moved outside of the ifdefs.
Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Make the inode mapping bdi consistent with the superblock bdi so that
dirty pages are flushed properly.
Signed-off-by: Thieu Le <thieule@chromium.org>
Cc: <stable@kernel.org> [2.6.39+]
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Fixes a regression caused by b5695d0463
Kernel keyring keys containing eCryptfs authentication tokens should not
be write locked when calling out to ecryptfsd to wrap and unwrap file
encryption keys. The eCryptfs kernel code can not hold the key's write
lock because ecryptfsd needs to request the key after receiving such a
request from the kernel.
Without this fix, all file opens and creates will timeout and fail when
using the eCryptfs PKI infrastructure. This is not an issue when using
passphrase-based mount keys, which is the most widely deployed eCryptfs
configuration.
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Acked-by: Roberto Sassu <roberto.sassu@polito.it>
Tested-by: Roberto Sassu <roberto.sassu@polito.it>
Tested-by: Alexis Hafner1 <haf@zurich.ibm.com>
Cc: <stable@kernel.org> [2.6.39+]
Several vendors implement a second configuration register, which we
check during device detection. Refactor the code to avoid duplication.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Stijn Devriendt <sdevrien@cisco.com>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
With a device ID register value of 0, the SA56004 detection is rather
weak. Check several other register too to confirm the detection, as we
do for other supported devices.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Stijn Devriendt <sdevrien@cisco.com>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Stijn Devriendt <sdevrien@cisco.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
The optional extended local temperature register can never have
address 0, as this address is already used by another register. Thus
we can get rid of flag LM90_HAVE_LOCAL_EXT and simply rely on
reg_local_ext being non-zero to determine if a given chip has this
extension or not. This makes the code more simple.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Stijn Devriendt <sdevrien@cisco.com>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Add support for voltage, current, and temperature peak (historic maximum)
attributes.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Add support for voltage and temperature peak (historic maximum) attributes.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Add support for voltage and current peak (historic maximum) attributes.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Most PMBus devices provide manufacturer specific commands to read low and/or
high peak values for some or all of its sensors.
To support providing those values as lowest/highest attributes to the user,
introduce virtual PMBus commands. Those commands reside outside the normal
command set and have to be implemented in device specific code, which map the
virtual commands to device specific commands.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Add the following attributes to the sysfs ABI.
in[0-*]_average
in[0-*]_lowest
in[0-*]_highest
in[0-*]_reset_history
in_reset_history
curr[1-*]_average
curr[1-*]_lowest
curr[1-*]_highest
curr[1-*]_reset_history
curr_reset_history
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
With virtual register page support, it is now possible that the status register
on virtual pages does not exist or is itself virtual. To take this into account
when creating alarm attributes, generate those attributes only if the status
register on the respective page is known to exist.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Some PMBus chips have non-standard sensor registers. An easy way to
support such sensors is to introduce virtual pages and map the non-standard
registers into standard registers on an extra page.
For this to work, the code verifying if the configured number of pages exists
has to be removed. Since a wrong number of pages can only be configured in a
front-end driver, this should not have a practical impact since the resulting
errors should be found during development and testing.
Also, functions to read the chip status while checking if a command register
exists must be modified to no longer set the page register before reading the
status, since the physical page associated with the checked register may not
exist. This does not make a functional difference since the page was already set
when the attempt to read the register was made.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Some PMBus devices use non-standard registers for some of the sensors and/or
limits. To support such devices, add code to support reading and writing of word
size registers in device specific code.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Some hwmon sysfs attributes have a length of 20 bytes (plus terminating 0).
I2C_NAME_SIZE is defined as 20 and thus can not be used to define the length
of hwmon sysfs attributes. Replace it with PMBUS_NAME_SIZE, set to 24.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Add ADP4000, NCP4200 and NCP4208 to the list of devices supported by the generic
PMBus driver, and add device IDs to enable explicit instantiation.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
In VID mode, output voltages are measured and reported as VID values, and
have to be converted to voltages using VID conversion tables or functions.
Support is added for VR11 only at this time.
This patch enables support for PMBus devices supporting VID VR11 based output
voltage selection such as NCP4200 and NCP4208.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Since 43cc71eed1 (platform: prefix MODALIAS
with "platform:"), the platform modalias is prefixed with "platform:".
This patch changes the MODULE_ALIAS to "platform:ab8500-gpio".
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Allow GPIO drivers to use of_gpio_simple_xlate. This is useful for the
generic GPIO driver for example where gpio_chip is embedded in
bgpio_chip and doesn't need of_mm_gpio_chip but has a simple 1:1 GPIO
mapping.
Cc: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
The logic at em28xx_isoc_dvb_max_packetsize() sucks, at least for newer
the needed packet size. Yet, it is better than nothing.
Rewrite the code in order to change the default to 752 for em2884 and
newer chips and provide a better way to handle per-chipset specifics.
For em2874, the current default should be enough, as the only em2874
board is currently a 1-seg ISDB-T board, so, it needs only a limited
amount of bandwidth.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Currently, the driver assumes that all QAM carriers are spaced with
8MHz. This is wrong, and may decrease QoS on Countries like Brazil,
that have DVB-C carriers with 6MHz-spaced.
Fortunately, both ITU-T J-83 and EN 300 429 specifies a way to
associate the symbol rate with the bandwidth needed for it.
For ITU-T J-83 2007 annex A, the maximum symbol rate for 6 MHz is:
6 MHz / 1.15 = 5217391 Bauds
For ITU-T J-83 2007 annex C, the maximum symbol rate for 6 MHz is:
6 MHz / 1.13 = 5309735 Bauds.
As this tuner is currently used only for DRX-K, and it is currently
hard-coded to annex A, I've opted to use the roll-off factor of 0.15,
instead of 0.13.
If we ever support annex C, the better would be to add a DVB S2API
call to allow changing between Annex A and C, and add the 0.13 roll-off
factor to it.
This code is currently being used on other frontends, so I think we
should later add a core function with this code, to warrant that
it will be properly implemented everywhere.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Since the number of PMBus drivers is getting large, move them into
directory drivers/hwmon/pmbus to improve readability and scalability.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
My previous commit left the file empty and present in the
Makefile, which is a bit dirty and caused problems with
'make distclean', as pointed out by David Howells.
This hopefully cleans it up the right way.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: David Howells <dhowells@redhat.com>
Acked-by: John Linn <john.linn@xilinx.com>
instead of reading the registers everytime
the current implementation respect the following constrain:
- allow 1 to n soc to be enabled
- allow to have a virtual cpu type and subtype
- always detect the cpu type and subtype and report it
- detect if the soc support is enabled
- prepare for sysfs export support
- drop soc specific code via compiler when the soc not enabled
(via cpu_is_xxx)
Today if we read the exid we will have the same value for 9g35 and 9m11
and we will need to check the cidr too
with the new implementation we just need to check the soc subtype
this will also allow to have specific virtual subtype for rm9200 which the
board will have to specify via at91rm9200_set_type(int) as we have no way to
detect it.
this implementation is inspired by the SH cpu detection support
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Patrice Vilchez <patrice.vilchez@atmel.com>
Dominik Brodowski
Pavel Roskin
Jonathan Cameron
Stephen Rothwell
Jiri Kosina
Thieu Le
Tyler Hicks
Jean Delvare
Guenter Roeck
Axel Lin
Jamie Iles
Mauro Carvalho Chehab
Arnd Bergmann
Jean-Christophe PLAGNIOL-VILLARD