This patch fixes the TPM's pubek sysfs entry that is accessible as long
as the TPM doesn't have an owner. It was necessary to shift the access to the
data by -10 -- the first byte immediately follows the 10 byte header. The
line
data = tpm_cmd.params.readpubek_out_buffer;
sets it at the offset '10' in the packet, so we can read the data array
starting at offset '0'.
Before:
Algorithm: 00 0C 00 00
Encscheme: 08 00
Sigscheme: 00 00
Parameters: 00 00 00 00 01 00 AC E2 5E 3C A0 78
Modulus length: -563306801
Modulus:
28 21 08 0F 82 CD F2 B1 E7 49 F7 74 70 BE 59 8C
43 78 B1 24 EA 52 E2 FE 52 5C 3A 12 3B DC 61 71
[...]
After:
Algorithm: 00 00 00 01
Encscheme: 00 03
Sigscheme: 00 01
Parameters: 00 00 08 00 00 00 00 02 00 00 00 00
Modulus length: 256
Modulus:
AC E2 5E 3C A0 78 DE 6C 9E CF 28 21 08 0F 82 CD
F2 B1 E7 49 F7 74 70 BE 59 8C 43 78 B1 24 EA 52
[...]
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
Display the TPM's interface timeouts in a 'timeouts' sysfs entry. Display
the entries as having been adjusted when they were scaled due to their values
being reported in milliseconds rather than microseconds.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
Adjust the interface timeouts if they are found to be too small, i.e., if
they are returned in milliseconds rather than microseconds as we heared
from Infineon that some (old) Infineon TPMs do.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
The TPM driver currently discards the interface timeout values returned
from the TPM. The check of the response packet needs to consider that
the return_code field is 0 on success and the size of the expected
packet is equivalent to the header size + u32 length indicator for the
TPM_GetCapability() result + 4 interface timeout indicators of type u32.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
Display the TPM's command timeouts in a 'durations' sysfs entry. Display
the entries as having been adjusted when they were scaled due to their values
being reported in milliseconds rather than microseconds.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Tested-by: Guillaume Chazarain <guichaz@gmail.com>
Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
Adjust the durations if they are found to be too small, i.e., if they are
returned in milliseconds rather than microseconds as some Infineon TPMs are
reported to do.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
The TPM driver currently discards the durations values returned
from the TPM. The check of the response packet needs to consider that
the return_code field is 0 on success and the size of the expected
packet is equivalent to the header size + u32 length indicator for the
TPM_GetCapability() result + 3 timeout indicators of type u32.
v4:
- sysfs entry 'durations' is now a patch of its own
- the work-around for TPMs reporting durations in milliseconds is now in a
patch of its own
v3:
- sysfs entry now called 'durations' to resemble TPM-speak (previously
was called 'timeouts')
v2:
- adjusting all timeouts for TPM devices reporting timeouts in msec rather
than usec
- also displaying in sysfs whether the timeouts are 'original' or 'adjusted'
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Tested-by: Guillaume Chazarain <guichaz@gmail.com>
Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc/mm: Fix memory_block_size_bytes() for non-pseries
mm: Move definition of MIN_MEMORY_BLOCK_SIZE to a header
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6:
drm/i915/ringbuffer: Idling requires waiting for the ring to be empty
Revert "drm/i915: enable rc6 by default"
drm/i915: Clean up i915_driver_load failure path
drm/i915: Enable GPU reset on Ivybridge.
drm/i915/dp: manage sink power state if possible
drm/i915/dp: consolidate AUX retry code
drm/i915/dp: remove DPMS mode tracking from DP
drm/i915/dp: try to read receiver capabilities 3 times when detecting
drm/i915/dp: read more receiver capability bits on hotplug
drm/i915/dp: use DP DPCD defines when looking at DPCD values
drm/i915/dp: retry link status read 3 times on failure
Almost all of these have long outstayed their welcome.
And for every one of these macros, there are 10 features for which we
didn't add macros.
Let's just delete them all, and get out of habit of doing things this
way.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
...which is measured by the size and not the amount of space remaining.
Waiting upon size-8, did one of two things. In the common case with more
than 8 bytes available to write into the ring, it would return
immediately. Otherwise, it would timeout given the impossible condition
of waiting for more space than is available in the ring, leading to
warnings such as:
[drm:intel_cleanup_ring_buffer] *ERROR* failed to quiesce render ring
whilst cleaning up: -16
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
This reverts commit a51f7a66fb.
We still have a few Ironlake and Sandybridge machines which fail when
RC6 is enabled. Better luck next release?
Signed-off-by: Keith Packard <keithp@keithp.com>
i915_driver_load adds a write-combining MTRR region for the GTT
aperture to improve memory speeds through the aperture. If
i915_driver_load fails after this, it would not have cleaned up the
MTRR. This shouldn't cause any problems, except for consuming an MTRR
register. Still, it's best to clean up completely in the failure path,
which is easily done by calling mtrr_del if the mtrr was successfully
allocated.
i915_driver_load calls i915_gem_load which register
i915_gem_inactive_shrink. If i915_driver_load fails after calling
i915_gem_load, the shrinker will be left registered. When called, it
will access freed memory and crash. The fix is to unregister the shrinker in the
failure path using code duplicated from i915_driver_unload.
i915_driver_load also has some incorrect gotos in the error cleanup
paths:
* After failing to initialize the GTT (which cannot happen, btw,
intel_gtt_get returns a fixed (non-NULL) value), it tries to
free the uninitialized WC IO mapping. Fixed this by changing the
target from out_iomapfree to out_rmmap
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Lin Ming <ming.m.lin@intel.com>
The driver reads PCI subsystem IDs from the PCI configuration registers while
it is already stored by the PCI subsystem in the 'subsystem_device' field of
'struct pci_dev'...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Using integer variable types for register to data conversions can cause
overflows especially for power calculations, which are in microwatt.
Use long variables instead.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org # 2.6.39+
Microsoft comfort mouse 4500 report descriptor contains duplicate
usages for horizontal wheel. This patch fixes the wrong mapping
caused by that.
Signed-off-by: Ari Savolainen <ari.m.savolainen@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
BUS_CNTL reg and bits moved between pre-PCIE and PCIE asics.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Skip connectors that do not have an HPD pin.
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=39027
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Tested-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Make sure that the 'static' keywork is at the beginning of declaration
for drivers/net/usb/kalmia.c
This gets rid of warnings like
warning: ‘static’ is not at beginning of declaration
when building with -Wold-style-declaration (and/or -Wextra which also
enables it).
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
SLIP6 have nothing to do with CSLIP so placing a block of
SLIP6-related code within a CSLIP ifdef-endif block is incorrect.
Signed-off-by: Ilya Matvejchikov <matvejchikov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
struct e1000_queue_stats is not used, lets remove it
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It's been stagnant for a while with out much forward progress for a
variety of different reasons. So remove it for now. It can be reverted
at any time if development picks back up again.
Acked-by: David Cross <odc@cypress.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This fix makes it so that the fdir_perfect_lock is initialized in all
cases. This is necessary as the fdir_filter_exit routine will always
attempt to take the lock before inspecting the filter table.
Reported-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
This patch changes the serdes link code to support a forced mode for
some hardware, based on bit set in EEPROM.
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
This patch updates the copyright on the igb driver files to 2011.
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Register writes followed by a delay are required to have a flush
before the delay in order to commit the values to the register. Without
the flush, the code following the delay may not function correctly.
Reported-by: Tong Ho <tong.ho@ericsson.com>
Reported-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
The macro MIN_MEMORY_BLOCK_SIZE is currently defined twice in two .c
files, and I need it in a third one to fix a powerpc bug, so let's
first move it into a header
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Ingo Molnar <mingo@elte.hu>
The nuvoton-cir inherited an insanely low idle timeout value from the
mceusb driver. We're fixing mceusb, should fix this driver too.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This matches the typical timeout advertised by hardware, once we're
actually interpreting it correctly.
Signed-off-by: Rafi Rubin <rafi@seas.upenn.edu>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Unit missmatch in mceusb_handle_command. It should be converting to us,
not 1/10th of ms.
mceusb_dev_printdata 100us/ms -> 1000us/ms
Alter format of fix slightly and update comment to match proper reality.
Signed-off-by: Rafi Rubin <rafi@seas.upenn.edu>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This reverts commit e38030f3ff.
MSI flat-out doesn't work right on cx2388x devices yet. There are now
multiple reports of cards that hard-lock systems when MSI is enabled,
including my own HVR-1250 when trying to use its built-in IR receiver.
Disable MSI and it works just fine. Similar for another user's HVR-1270.
Issues have also been reported with the HVR-1850 when MSI is enabled,
and the 1850 behavior sounds similar to an as-yet-undiagnosed issue I've
seen with an 1800.
CC: stable@kernel.org
CC: Steven Toth <stoth@kernellabs.com>
CC: Kusanagi Kouichi <slash@ac.auone-net.jp>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6:
[media] msp3400: fill in v4l2_tuner based on vt->type field
[media] tuner-core.c: don't change type field in g_tuner or g_frequency
[media] cx18/ivtv: fix g_tuner support
[media] tuner-core: power up tuner when called with s_power(1)
[media] v4l2-ioctl.c: check for valid tuner type in S_HW_FREQ_SEEK
[media] tuner-core: simplify the standard fixup
[media] tuner-core/v4l2-subdev: document that the type field has to be filled in
[media] v4l2-subdev.h: remove unused s_mode tuner op
[media] feature-removal-schedule: change in how radio device nodes are handled
[media] bttv: fix s_tuner for radio
[media] pvrusb2: fix g/s_tuner support
[media] v4l2-ioctl.c: prefill tuner type for g_frequency and g/s_tuner
[media] tuner-core: fix tuner_resume: use t->mode instead of t->type
[media] tuner-core: fix s_std and s_tuner
In theory it is possible that pm_genpd_poweroff() for two different
subdomains of the same parent domain will attempt to queue up the
execution of pm_genpd_poweroff() for the parent twice in a row. This
would lead to unpleasant consequences, so prevent it from happening
by checking if genpd->power_off_work is pending before attempting to
queue it up.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Kevin points out that if there's a device that can wake up the system
from sleep states, but it doesn't generate wakeup signals by itself
(they are generated on its behalf by other parts of the system) and
it currently is not enabled to wake up the system (that is,
device_may_wakeup() returns "false" for it), we may need to change
its wakeup settings during system suspend (for example, the device
might have been configured to signal remote wakeup from the system's
working state, as needed by runtime PM). Therefore the generic PM
domains code should invoke the system suspend callbacks provided by
the device's driver, which it doesn't do if the PM domain is powered
off during the system suspend's "prepare" stage. This is a valid
point. Moreover, this code also should make sure that system wakeup
devices that are enabled to wake up the system from sleep states and
have to remain active for this purpose are not suspended while the
system is in a sleep state.
To avoid the above issues, make the generic PM domains' .prepare()
routine, pm_genpd_prepare(), force runtime resume of devices whose
system wakeup settings may need to be changed during system suspend
or that should remain active while the system is in a sleep state to
be able to wake it up from that state.
Reported-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Since every device in a PM domain has its own need_restore
flag, which is set by __pm_genpd_save_device(), there's no need to
walk the domain's device list and restore all devices on an error
from one of the drivers' .runtime_suspend() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
A deadlock may occur if one of the PM domains' .start_device() or
.stop_device() callbacks or a device driver's .runtime_suspend() or
.runtime_resume() callback executed by the core generic PM domain
code uses a "wrong" runtime PM helper function. This happens, for
example, if .runtime_resume() from one device's driver calls
pm_runtime_resume() for another device in the same PM domain.
A similar situation may take place if a device's parent is in the
same PM domain, in which case the runtime PM framework may execute
pm_genpd_runtime_resume() automatically for the parent (if it is
suspended at the moment). This, of course, is undesirable, so
the generic PM domains code should be modified to prevent it from
happening.
The runtime PM framework guarantees that pm_genpd_runtime_suspend()
and pm_genpd_runtime_resume() won't be executed in parallel for
the same device, so the generic PM domains code need not worry
about those cases. Still, it needs to prevent the other possible
race conditions between pm_genpd_runtime_suspend(),
pm_genpd_runtime_resume(), pm_genpd_poweron() and pm_genpd_poweroff()
from happening and it needs to avoid deadlocks at the same time.
To this end, modify the generic PM domains code to relax
synchronization rules so that:
* pm_genpd_poweron() doesn't wait for the PM domain status to
change from GPD_STATE_BUSY. If it finds that the status is
not GPD_STATE_POWER_OFF, it returns without powering the domain on
(it may modify the status depending on the circumstances).
* pm_genpd_poweroff() returns as soon as it finds that the PM
domain's status changed from GPD_STATE_BUSY after it's released
the PM domain's lock.
* pm_genpd_runtime_suspend() doesn't wait for the PM domain status
to change from GPD_STATE_BUSY after executing the domain's
.stop_device() callback and executes pm_genpd_poweroff() only
if pm_genpd_runtime_resume() is not executed in parallel.
* pm_genpd_runtime_resume() doesn't wait for the PM domain status
to change from GPD_STATE_BUSY after executing pm_genpd_poweron()
and sets the domain's status to GPD_STATE_BUSY and increments its
counter of resuming devices (introduced by this change) immediately
after acquiring the lock. The counter of resuming devices is then
decremented after executing __pm_genpd_runtime_resume() for the
device and the domain's status is reset to GPD_STATE_ACTIVE (unless
there are more resuming devices in the domain, in which case the
status remains GPD_STATE_BUSY).
This way, for example, if a device driver's .runtime_resume()
callback executes pm_runtime_resume() for another device in the same
PM domain, pm_genpd_poweron() called by pm_genpd_runtime_resume()
invoked by the runtime PM framework will not block and it will see
that there's nothing to do for it. Next, the PM domain's lock will
be acquired without waiting for its status to change from
GPD_STATE_BUSY and the device driver's .runtime_resume() callback
will be executed. In turn, if pm_runtime_suspend() is executed by
one device driver's .runtime_resume() callback for another device in
the same PM domain, pm_genpd_poweroff() executed by
pm_genpd_runtime_suspend() invoked by the runtime PM framework as a
result will notice that one of the devices in the domain is being
resumed, so it will return immediately.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Currently, the .start_device() and .stop_device() callbacks from
struct generic_pm_domain() as well as the device drivers' runtime PM
callbacks used by the generic PM domains code are executed under
the generic PM domain lock. This, unfortunately, is prone to
deadlocks, for example if a device and its parent are boths members
of the same PM domain. For this reason, it would be better if the
PM domains code didn't execute device callbacks under the lock.
Rework the locking in the generic PM domains code so that the lock
is dropped for the execution of device callbacks. To this end,
introduce PM domains states reflecting the current status of a PM
domain and such that the PM domain lock cannot be acquired if the
status is GPD_STATE_BUSY. Make threads attempting to acquire a PM
domain's lock wait until the status changes to either
GPD_STATE_ACTIVE or GPD_STATE_POWER_OFF.
This change by itself doesn't fix the deadlock problem mentioned
above, but the mechanism introduced by it will be used for for this
purpose by a subsequent patch.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
If pm_generic_prepare() in pm_genpd_prepare() returns error code,
the PM domains counter of "prepared" devices should be decremented
and its suspend_power_off flag should be reset if this counter drops
down to zero. Otherwise, the PM domain runtime PM code will not
handle the domain correctly (it will permanently think that system
suspend is in progress).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
The runtime PM status of devices in a power domain that is not
powered off in pm_genpd_complete() should be set to "active", because
those devices are operational at this point. Some of them may not be
in use, though, so make pm_genpd_complete() call pm_runtime_idle()
in addition to pm_runtime_set_active() for each of them.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86:
hp-wmi: fix use after free
dell-laptop - using buffer without mutex_lock
Revert: "dell-laptop: Toggle the unsupported hardware killswitch"
platform-drivers-x86: set backlight type to BACKLIGHT_PLATFORM
thinkpad-acpi: handle HKEY 0x4010, 0x4011 events
drivers/platform/x86: Fix memory leak
thinkpad-acpi: handle some new HKEY 0x60xx events
acer-wmi: fix bitwise bug when set device state
acer-wmi: Only update rfkill status for associated hotkey events
Fix the compile warning cause by [IWL_TM_ATTR_MAX - 1]
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
