linux-toradex.git/drivers, branch v3.2.42

efivars: pstore: Do not check size when erasing variable

2013-03-27T02:41:24+00:00

In 3.2, unlike mainline, efi_pstore_erase() calls efi_pstore_write()
with a size of 0, as the underlying EFI interface treats a size of 0
as meaning deletion.

This was not taken into account in my backport of commit d80a361d779a
'efi_pstore: Check remaining space with QueryVariableInfo() before
writing data'.  The size check should be omitted when erasing.

Signed-off-by: Ben Hutchings

KMS: fix EDID detailed timing frame rate

2013-03-27T02:41:24+00:00

commit c19b3b0f6eed552952845e4ad908dba2113d67b4 upstream.

When KMS has parsed an EDID "detailed timing", it leaves the frame rate
zeroed.  Consecutive (debug-) output of that mode thus yields 0 for
vsync.  This simple fix also speeds up future invocations of
drm_mode_vrefresh().

While it is debatable whether this qualifies as a -stable fix I'd apply
it for consistency's sake; drm_helper_probe_single_connector_modes()
does the same thing already for all probed modes.

Signed-off-by: Torsten Duwe 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

KMS: fix EDID detailed timing vsync parsing

2013-03-27T02:41:24+00:00

commit 16dad1d743d31a104a849c8944e6b9eb479f6cd7 upstream.

EDID spreads some values across multiple bytes; bit-fiddling is needed
to retrieve these.  The current code to parse "detailed timings" has a
cut&paste error that results in a vsync offset of at most 15 lines
instead of 63.

See

   http://en.wikipedia.org/wiki/EDID

and in the "EDID Detailed Timing Descriptor" see bytes 10+11 show why
that needs to be a left shift.

Signed-off-by: Torsten Duwe 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

i2c: tegra: check the clk_prepare_enable() return value

2013-03-27T02:41:23+00:00

commit 132c803f7b70b17322579f6f4f3f65cf68e55135 upstream.

NVIDIA's Tegra SoC allows read/write of controller register only
if controller clock is enabled. System hangs if read/write happens
to registers without enabling clock.

clk_prepare_enable() can be fail due to unknown reason and hence
adding check for return value of this function. If this function
success then only access register otherwise return to caller with
error.

Signed-off-by: Laxman Dewangan 
Reviewed-by: Stephen Warren 
Signed-off-by: Wolfram Sang 
[bwh: Backported to 3.2:
 - Adjust context
 - Keep calling clk_enable() directly]
Signed-off-by: Ben Hutchings

USB: serial: fix interface refcounting

2013-03-27T02:41:22+00:00

commit d7971051e4df825e0bc11b995e87bfe86355b8e5 upstream.

Make sure the interface is not released before our serial device.

Note that drivers are still not allowed to access the interface in
any way that may interfere with another driver that may have gotten
bound to the same interface after disconnect returns.

Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

USB: io_ti: fix get_icount for two port adapters

2013-03-27T02:41:22+00:00

commit 5492bf3d5655b4954164f69c02955a7fca267611 upstream.

Add missing get_icount field to two-port driver.

The two-port driver was not updated when switching to the new icount
interface in commit 0bca1b913aff ("tty: Convert the USB drivers to the
new icount interface").

Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

USB: garmin_gps: fix memory leak on disconnect

2013-03-27T02:41:22+00:00

commit 618aa1068df29c37a58045fe940f9106664153fd upstream.

Remove bogus disconnect test introduced by 95bef012e ("USB: more serial
drivers writing after disconnect") which prevented queued data from
being freed on disconnect.

The possible IO it was supposed to prevent is long gone.

Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

efivars: Handle duplicate names from get_next_variable()

2013-03-27T02:41:21+00:00

commit e971318bbed610e28bb3fde9d548e6aaf0a6b02e upstream.

Some firmware exhibits a bug where the same VariableName and
VendorGuid values are returned on multiple invocations of
GetNextVariableName(). See,

    https://bugzilla.kernel.org/show_bug.cgi?id=47631

As a consequence of such a bug, Andre reports hitting the following
WARN_ON() in the sysfs code after updating the BIOS on his, "Gigabyte
Technology Co., Ltd. To be filled by O.E.M./Z77X-UD3H, BIOS F19e
11/21/2012)" machine,

[    0.581554] EFI Variables Facility v0.08 2004-May-17
[    0.584914] ------------[ cut here ]------------
[    0.585639] WARNING: at /home/andre/linux/fs/sysfs/dir.c:536 sysfs_add_one+0xd4/0x100()
[    0.586381] Hardware name: To be filled by O.E.M.
[    0.587123] sysfs: cannot create duplicate filename '/firmware/efi/vars/SbAslBufferPtrVar-01f33c25-764d-43ea-aeea-6b5a41f3f3e8'
[    0.588694] Modules linked in:
[    0.589484] Pid: 1, comm: swapper/0 Not tainted 3.8.0+ #7
[    0.590280] Call Trace:
[    0.591066]  [] ? sysfs_add_one+0xd4/0x100
[    0.591861]  [] warn_slowpath_common+0x7f/0xc0
[    0.592650]  [] warn_slowpath_fmt+0x4c/0x50
[    0.593429]  [] ? strlcat+0x65/0x80
[    0.594203]  [] sysfs_add_one+0xd4/0x100
[    0.594979]  [] create_dir+0x78/0xd0
[    0.595753]  [] sysfs_create_dir+0x86/0xe0
[    0.596532]  [] kobject_add_internal+0x9c/0x220
[    0.597310]  [] kobject_init_and_add+0x67/0x90
[    0.598083]  [] ? efivar_create_sysfs_entry+0x61/0x1c0
[    0.598859]  [] efivar_create_sysfs_entry+0x11b/0x1c0
[    0.599631]  [] register_efivars+0xde/0x420
[    0.600395]  [] ? edd_init+0x2f5/0x2f5
[    0.601150]  [] efivars_init+0xb8/0x104
[    0.601903]  [] do_one_initcall+0x12a/0x180
[    0.602659]  [] kernel_init_freeable+0x13e/0x1c6
[    0.603418]  [] ? loglevel+0x31/0x31
[    0.604183]  [] ? rest_init+0x80/0x80
[    0.604936]  [] kernel_init+0xe/0xf0
[    0.605681]  [] ret_from_fork+0x7c/0xb0
[    0.606414]  [] ? rest_init+0x80/0x80
[    0.607143] ---[ end trace 1609741ab737eb29 ]---

There's not much we can do to work around and keep traversing the
variable list once we hit this firmware bug. Our only solution is to
terminate the loop because, as Lingzhu reports, some machines get
stuck when they encounter duplicate names,

  > I had an IBM System x3100 M4 and x3850 X5 on which kernel would
  > get stuck in infinite loop creating duplicate sysfs files because,
  > for some reason, there are several duplicate boot entries in nvram
  > getting GetNextVariableName into a circle of iteration (with
  > period > 2).

Also disable the workqueue, as efivar_update_sysfs_entries() uses
GetNextVariableName() to figure out which variables have been created
since the last iteration. That algorithm isn't going to work if
GetNextVariableName() returns duplicates. Note that we don't disable
EFI variable creation completely on the affected machines, it's just
that any pstore dump-* files won't appear in sysfs until the next
boot.

Reported-by: Andre Heider 
Reported-by: Lingzhu Xiang 
Tested-by: Lingzhu Xiang 
Cc: Seiji Aguchi 
Signed-off-by: Matt Fleming 
[bwh: Backported to 3.2: reason is not checked in efi_pstore_write()]
Signed-off-by: Ben Hutchings

efivars: explicitly calculate length of VariableName

2013-03-27T02:41:21+00:00

commit ec50bd32f1672d38ddce10fb1841cbfda89cfe9a upstream.

It's not wise to assume VariableNameSize represents the length of
VariableName, as not all firmware updates VariableNameSize in the same
way (some don't update it at all if EFI_SUCCESS is returned). There
are even implementations out there that update VariableNameSize with
values that are both larger than the string returned in VariableName
and smaller than the buffer passed to GetNextVariableName(), which
resulted in the following bug report from Michael Schroeder,

  > On HP z220 system (firmware version 1.54), some EFI variables are
  > incorrectly named :
  >
  > ls -d /sys/firmware/efi/vars/*8be4d* | grep -v -- -8be returns
  > /sys/firmware/efi/vars/dbxDefault-pport8be4df61-93ca-11d2-aa0d-00e098032b8c
  > /sys/firmware/efi/vars/KEKDefault-pport8be4df61-93ca-11d2-aa0d-00e098032b8c
  > /sys/firmware/efi/vars/SecureBoot-pport8be4df61-93ca-11d2-aa0d-00e098032b8c
  > /sys/firmware/efi/vars/SetupMode-Information8be4df61-93ca-11d2-aa0d-00e098032b8c

The issue here is that because we blindly use VariableNameSize without
verifying its value, we can potentially read garbage values from the
buffer containing VariableName if VariableNameSize is larger than the
length of VariableName.

Since VariableName is a string, we can calculate its size by searching
for the terminating NULL character.

Reported-by: Frederic Crozat 
Cc: Matthew Garrett 
Cc: Josh Boyer 
Cc: Michael Schroeder 
Cc: Lee, Chun-Yi 
Cc: Lingzhu Xiang 
Cc: Seiji Aguchi 
Signed-off-by: Matt Fleming 
Signed-off-by: Ben Hutchings

efi_pstore: Introducing workqueue updating sysfs

2013-03-27T02:41:20+00:00

commit a93bc0c6e07ed9bac44700280e65e2945d864fd4 upstream.

[Problem]
efi_pstore creates sysfs entries, which enable users to access to NVRAM,
in a write callback. If a kernel panic happens in an interrupt context,
it may fail because it could sleep due to dynamic memory allocations during
creating sysfs entries.

[Patch Description]
This patch removes sysfs operations from a write callback by introducing
a workqueue updating sysfs entries which is scheduled after the write
callback is called.

Also, the workqueue is kicked in a just oops case.
A system will go down in other cases such as panic, clean shutdown and emergency
restart. And we don't need to create sysfs entries because there is no chance for
users to access to them.

efi_pstore will be robust against a kernel panic in an interrupt context with this patch.

Signed-off-by: Seiji Aguchi 
Acked-by: Matt Fleming 
Signed-off-by: Tony Luck 
[bwh: Backported to 3.2:
 - Adjust contest
 - Don't check reason in efi_pstore_write(), as it is not given as a
   parameter
 - Move up declaration of __efivars]
Signed-off-by: Ben Hutchings