summaryrefslogtreecommitdiffstats
path: root/crypto/cast6.c
diff options
context:
space:
mode:
authorThomas Renninger <trenn@suse.de>2010-10-21 18:24:57 +0200
committerLen Brown <len.brown@intel.com>2010-10-22 01:21:30 -0400
commit7a18e96dcbdec3c96876444ae2c7e36ce458e151 (patch)
treec4a8ed0442eba1035fb7420f8598c955b1735032 /crypto/cast6.c
parentf6f94e2ab1b33f0082ac22d71f66385a60d8157f (diff)
downloadop-kernel-dev-7a18e96dcbdec3c96876444ae2c7e36ce458e151.zip
op-kernel-dev-7a18e96dcbdec3c96876444ae2c7e36ce458e151.tar.gz
ACPI: Make Embedded Controller command timeout delay configurable
Here and then there show up machines which need higher timeout values. Finding this on affected machines can be cumbersome, because ACPI_EC_DELAY is a compile option -> make it configurable via boot param. This can even be provided writable at runtime via: /sys/modules/acpi/parameters/ec_delay Known machines where this helps: Some HP machines where for whatever reasons specific EC accesses take very long at resume from S3 (in _WAK function). The AE_TIME error is passed upwards and the ACPI interpreter will not execute the rest of the _WAK function which results in not properly initialized devices/variables with different side-effects. Afaik, on some MSI machines this helped as well. If this param is needed there probably are underlying problems like: - EC firmware bug - A kernel EC driver bug - An ACPI interpreter behavior (e.g. timings when specific EC accesses happen and how) which the EC does not like - ... which should get evaluated further, but often are nasty or impossible to fix from OS side. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
Diffstat (limited to 'crypto/cast6.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud