user/sven/linux.git/drivers/char, branch v3.18.31

hwmon: (dell-smm) Blacklist Dell Studio XPS 8100

2015-08-27T17:25:30Z

[ Upstream commit 25ab1617bf735b8a411104c60852651cae6769fd ] commit a4b45b25f18d1e798965efec429ba5fc01b9f0b6 upstream. CPU fan speed going up and down on Dell Studio XPS 8100 for unknown reasons. Without further debugging on the affected machine, it is not possible to find the problem. Link: https://bugzilla.kernel.org/show_bug.cgi?id=100121 Signed-off-by: Pali Rohár Tested-by: Jan C Peters [groeck: cleaned up description, comments] Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

hwrng: core - correct error check of kthread_run call

2015-08-27T17:25:26Z

[ Upstream commit 17fb874dee093139923af8ed36061faa92cc8e79 ] The kthread_run() function can return two different error values but the hwrng core only checks for -ENOMEM. If the other error value -EINTR is returned it is assigned to hwrng_fill and later used on a kthread_stop() call which naturally crashes. Cc: stable@vger.kernel.org Signed-off-by: Martin Schwidefsky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

agp/intel: Fix typo in needs_ilk_vtd_wa()

2015-07-05T14:12:53Z

[ Upstream commit 8b572a4200828b4e75cc22ed2f494b58d5372d65 ] In needs_ilk_vtd_wa(), we pass in the GPU device but compared it against the ids for the mobile GPU and the mobile host bridge. That latter is impossible and so likely was just a typo for the desktop GPU device id (which is also buggy). Fixes commit da88a5f7f7d434e2cde1b3e19d952e6d84533662 Author: Chris Wilson Date: Wed Feb 13 09:31:53 2013 +0000 drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK Reported-by: Ting-Wei Lan Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91127 References: https://bugzilla.freedesktop.org/show_bug.cgi?id=60391 Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin

vTPM: set virtual device before passing to ibmvtpm_reset_crq

2015-07-04T03:02:31Z

[ Upstream commit 9d75f08946e8485109458ccf16f714697c207f41 ] tpm_ibmvtpm_probe() calls ibmvtpm_reset_crq(ibmvtpm) without having yet set the virtual device in the ibmvtpm structure. So in ibmvtpm_reset_crq, the phype call contains empty unit addresses, ibmvtpm->vdev->unit_address. Signed-off-by: Hon Ching(Vicky) Lo Signed-off-by: Joy Latten Reviewed-by: Ashley Lai Cc: Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM vTPM") Signed-off-by: Peter Huewe Signed-off-by: Sasha Levin

tpm/tpm_i2c_stm_st33: Add status check when reading data on the FIFO

2015-03-28T13:43:13Z

[ Upstream commit c4eadfafb91d5501095c55ffadaa1168743f39d3 ] Add a return value check when reading data from the FIFO register. Cc: Reviewed-by: Jason Gunthorpe Signed-off-by: Christophe Ricard Reviewed-by: Peter Huewe Signed-off-by: Peter Huewe Signed-off-by: Sasha Levin

tpm/ibmvtpm: Additional LE support for tpm_ibmvtpm_send

2015-03-28T13:43:06Z

[ Upstream commit 62dfd912ab3b5405b6fe72d0135c37e9648071f1 ] Problem: When IMA and VTPM are both enabled in kernel config, kernel hangs during bootup on LE OS. Why?: IMA calls tpm_pcr_read() which results in tpm_ibmvtpm_send and tpm_ibmtpm_recv getting called. A trace showed that tpm_ibmtpm_recv was hanging. Resolution: tpm_ibmtpm_recv was hanging because tpm_ibmvtpm_send was sending CRQ message that probably did not make much sense to phype because of Endianness. The fix below sends correctly converted CRQ for LE. This was not caught before because it seems IMA is not enabled by default in kernel config and IMA exercises this particular code path in vtpm. Tested with IMA and VTPM enabled in kernel config and VTPM enabled on both a BE OS and a LE OS ppc64 lpar. This exercised CRQ and TPM command code paths in vtpm. Patch is against Peter's tpmdd tree on github which included Vicky's previous vtpm le patches. Signed-off-by: Joy Latten Cc: # eb71f8a5e33f: "Added Little Endian support to vtpm module" Cc: Reviewed-by: Ashley Lai Signed-off-by: Peter Huewe Signed-off-by: Sasha Levin

virtio_console: avoid config access from irq

2015-03-28T13:36:55Z

[ Upstream commit eeb8a7e8bb123e84daeef84f5a2eab99ad2839a2 ] when multiport is off, virtio console invokes config access from irq context, config access is blocking on s390. Fix this up by scheduling work from config irq - similar to what we do for multiport configs. Signed-off-by: Michael S. Tsirkin Reviewed-by: Amit Shah Signed-off-by: Rusty Russell Cc: stable@kernel.org Signed-off-by: Sasha Levin

virtio_console: init work unconditionally

2015-03-28T13:36:47Z

[ Upstream commit 4f6e24ed9de8634d6471ef86b382cba6d4e57ca8 ] when multiport is off, we don't initialize config work, but we then cancel uninitialized control_work on freeze. Signed-off-by: Michael S. Tsirkin Reviewed-by: Amit Shah Signed-off-by: Rusty Russell Cc: stable@kernel.org Signed-off-by: Sasha Levin

Added Little Endian support to vtpm module

2015-03-06T22:52:58Z

commit eb71f8a5e33fa1066fb92f0111ab366a341e1f6c upstream. The tpm_ibmvtpm module is affected by an unaligned access problem. ibmvtpm_crq_get_version failed with rc=-4 during boot when vTPM is enabled in Power partition, which supports both little endian and big endian modes. We added little endian support to fix this problem: 1) added cpu_to_be64 calls to ensure BE data is sent from an LE OS. 2) added be16_to_cpu and be32_to_cpu calls to make sure data received is in LE format on a LE OS. Signed-off-by: Hon Ching(Vicky) Lo Signed-off-by: Joy Latten [phuewe: manually applied the patch :( ] Reviewed-by: Ashley Lai Signed-off-by: Peter Huewe Signed-off-by: Greg Kroah-Hartman

tpm/tpm_i2c_stm_st33: Fix potential bug in tpm_stm_i2c_send

2015-03-06T22:52:57Z

commit 1ba3b0b6f218072afe8372d12f1b6bf26a26008e upstream. When sending data in tpm_stm_i2c_send, each loop iteration send buf. Send buf + i instead as the goal of this for loop is to send a number of byte from buf that fit in burstcnt. Once those byte are sent, we are supposed to send the next ones. The driver was working because the burstcount value returns always the maximum size for a TPM command or response. (0x800 for a command and 0x400 for a response). Reviewed-by: Jason Gunthorpe Signed-off-by: Christophe Ricard Signed-off-by: Peter Huewe Signed-off-by: Greg Kroah-Hartman