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

ACPICA: Utilities: Cleanup to remove useless ACPI_PRINTF/FORMAT_xxx helpers.

2015-08-06T23:32:20+00:00

commit 1d0a0b2f6df2bf2643fadc990eb143361eca6ada upstream.

ACPICA commit b60612373a4ef63b64a57c124576d7ddb6d8efb6

For physical addresses, since the address may exceed 32-bit address range
after calculation, we should use 0x%8.8X%8.8X instead of ACPI_PRINTF_UINT
and ACPI_FORMAT_UINT64() instead of
ACPI_FORMAT_NATIVE_UINT()/ACPI_FORMAT_TO_UINT().

This patch also removes above replaced macros as there are no users.

This is a preparation to switch acpi_physical_address to 64-bit on 32-bit
kernel builds.

Link: https://github.com/acpica/acpica/commit/b6061237
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Dirk Behme 
[gdavis: Move tbprint.c changes to tbutils.c due to lack of commit
	 "42f4786 ACPICA: Split table print utilities to a new a
	 separate file" in linux-3.10.y]
Signed-off-by: George G. Davis 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

ACPICA: Utilities: Cleanup to convert physical address printing formats.

2015-08-06T23:32:20+00:00

commit cc2080b0e5a7c6c33ef5e9ffccbc2b8f6f861393 upstream.

ACPICA commit 7f06739db43a85083a70371c14141008f20b2198

For physical addresses, since the address may exceed 32-bit address range
after calculation, we should use %8.8X%8.8X (see ACPI_FORMAT_UINT64()) to
convert the %p formats.

This is a preparation to switch acpi_physical_address to 64-bit on 32-bit
kernel builds.

Link: https://github.com/acpica/acpica/commit/7f06739d
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Dirk Behme 
[gdavis: Move tbinstall.c changes to tbutils.c due to lack of commit
	 "42f4786 ACPICA: Split table print utilities to a new a
	 separate file" in linux-3.10.y]
Signed-off-by: George G. Davis 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2:
 - Drop inapplicable changes to drivers/acpi/acpica/utaddress.c and
   acpi_tb_install_table()
 - Fix similar format issues in acpi_tb_add_table() and
   acpi_tb_install_table() that aren't present upstream]
Signed-off-by: Ben Hutchings

ACPICA: Debug output: Update output for Processor object.

2015-08-06T23:32:20+00:00

commit 0b232fcad225c35513c9d5719613ae552abccd82 upstream.

Cleanup output for Processor(). Length is a byte, not a word.

Signed-off-by: Bob Moore 
Signed-off-by: Feng Tang 
Signed-off-by: Len Brown 
Signed-off-by: Ben Hutchings

ACPICA: Tables: Change acpi_find_root_pointer() to use acpi_physical_address.

2015-08-06T23:32:20+00:00

commit 85e014b4304626972bff42249556748ad3fcf812 upstream.

commit f254e3c57b9d952e987502aefa0804c177dd2503 upstream.

ACPICA commit 7d9fd64397d7c38899d3dc497525f6e6b044e0e3

OSPMs like Linux expect an acpi_physical_address returning value from
acpi_find_root_pointer(). This triggers warnings if sizeof (acpi_size) doesn't
equal to sizeof (acpi_physical_address):
  drivers/acpi/osl.c:275:3: warning: passing argument 1 of 'acpi_find_root_pointer' from incompatible pointer type [enabled by default]
  In file included from include/acpi/acpi.h:64:0,
                   from include/linux/acpi.h:36,
                   from drivers/acpi/osl.c:41:
  include/acpi/acpixf.h:433:1: note: expected 'acpi_size *' but argument is of type 'acpi_physical_address *'
This patch corrects acpi_find_root_pointer().

Link: https://github.com/acpica/acpica/commit/7d9fd643
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Dirk Behme 
Signed-off-by: George G. Davis 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

staging: line6: avoid __sync_fetch_and_{and,or}

2015-08-06T23:32:19+00:00

commit 9f613601482c56e05884f21565e3d218fac427ae upstream.

__sync_fetch_and_and and __sync_fetch_and_or are functions that are provided
by gcc and depending on the target architecture may be implemented in libgcc,
which is not always available in the kernel. This leads to a build failure
on ARMv5:

drivers/built-in.o: In function `line6_pcm_release':
:(.text+0x3bfe80): undefined reference to `__sync_fetch_and_and_4'
drivers/built-in.o: In function `line6_pcm_acquire':
:(.text+0x3bff30): undefined reference to `__sync_fetch_and_or_4'

To work around this, we can use the kernel-provided cmpxchg macro.

Build-tested only.

Signed-off-by: Arnd Bergmann 
Cc: Markus Grabner 
Acked-by: Randy Dunlap 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2:
 - Adjust context
 - Fix up two more instances of __sync_fetch_and_and() that were removed
   separately upstream]
Signed-off-by: Ben Hutchings

UBI: fix soft lockup in ubi_check_volume()

2015-08-06T23:32:19+00:00

commit 9aa272b492e7551a9ee0e2c83c720ea013698485 upstream.

Running mtd-utils/tests/ubi-tests/io_basic.c could cause
soft lockup or watchdog reset. It is because *updatevol*
will perform ubi_check_volume() after updating finish
and this function will full scan the updated lebs if the
volume is initialized as STATIC_VOLUME.

This patch adds *cond_resched()* in the loop of lebs scan
to avoid soft lockup.

Helped by Richard Weinberger 

[ 2158.067096] INFO: rcu_sched self-detected stall on CPU { 1}  (t=2101 jiffies g=1606 c=1605 q=56)
[ 2158.172867] CPU: 1 PID: 2073 Comm: io_basic Tainted: G           O 3.10.53 #21
[ 2158.172898] [] (unwind_backtrace+0x0/0x120) from [] (show_stack+0x10/0x14)
[ 2158.172918] [] (show_stack+0x10/0x14) from [] (rcu_check_callbacks+0x1c0/0x660)
[ 2158.172936] [] (rcu_check_callbacks+0x1c0/0x660) from [] (update_process_times+0x38/0x64)
[ 2158.172953] [] (update_process_times+0x38/0x64) from [] (tick_sched_handle+0x54/0x60)
[ 2158.172966] [] (tick_sched_handle+0x54/0x60) from [] (tick_sched_timer+0x44/0x74)
[ 2158.172978] [] (tick_sched_timer+0x44/0x74) from [] (__run_hrtimer+0xc8/0x1b8)
[ 2158.172992] [] (__run_hrtimer+0xc8/0x1b8) from [] (hrtimer_interrupt+0x128/0x2a4)
[ 2158.173007] [] (hrtimer_interrupt+0x128/0x2a4) from [] (arch_timer_handler_virt+0x28/0x30)
[ 2158.173022] [] (arch_timer_handler_virt+0x28/0x30) from [] (handle_percpu_devid_irq+0x9c/0x124)
[ 2158.173036] [] (handle_percpu_devid_irq+0x9c/0x124) from [] (generic_handle_irq+0x20/0x30)
[ 2158.173049] [] (generic_handle_irq+0x20/0x30) from [] (handle_IRQ+0x64/0x8c)
[ 2158.173060] [] (handle_IRQ+0x64/0x8c) from [] (gic_handle_irq+0x3c/0x60)
[ 2158.173074] [] (gic_handle_irq+0x3c/0x60) from [] (__irq_svc+0x40/0x50)
[ 2158.173083] Exception stack(0xc4043c98 to 0xc4043ce0)
[ 2158.173092] 3c80:                                                       c4043ce4 00000019
[ 2158.173102] 3ca0: 1f8a865f c050ad10 1f8a864c 00000031 c04b5970 0003ebce 00000000 f3550000
[ 2158.173113] 3cc0: bf00bc68 00000800 0003ebce c4043ce0 c0186d14 c0186cb8 80000013 ffffffff
[ 2158.173130] [] (__irq_svc+0x40/0x50) from [] (read_current_timer+0x4/0x38)
[ 2158.173145] [] (read_current_timer+0x4/0x38) from [<1f8a865f>] (0x1f8a865f)
[ 2183.927097] BUG: soft lockup - CPU#1 stuck for 22s! [io_basic:2073]
[ 2184.002229] Modules linked in: nandflash(O) [last unloaded: nandflash]

Signed-off-by: Wang Kai 
Signed-off-by: hujianyang 
Signed-off-by: Richard Weinberger 
Signed-off-by: Ben Hutchings

sb_edac: Fix erroneous bytes->gigabytes conversion

2015-08-06T23:32:18+00:00

commit 8c009100295597f23978c224aec5751a365bc965 upstream.

Signed-off-by: Jim Snow 
Signed-off-by: Lukasz Anaczkowski 
Signed-off-by: Mauro Carvalho Chehab 
Cc: Vinson Lee 
[lizf: Backported to 3.4:
 - adjust context
 - use debugf0() instead of edac_dbg()]
Signed-off-by: Zefan Li 
Signed-off-by: Ben Hutchings

Fix sb_edac compilation with 32 bits kernels

2015-08-06T23:32:18+00:00

commit 5b889e379f340f43b1252abde5d37a7084c846b9 upstream.

As reported by Josh Boyer :
>	drivers/edac/sb_edac.c: In function 'get_memory_error_data':
> 	drivers/edac/sb_edac.c:861:2: warning: left shift count >= width of type
> 	[enabled by default]
> 	
> 	ERROR: "__udivdi3" [drivers/edac/sb_edac.ko] undefined!
> 	make[1]: *** [__modpost] Error 1
> 	make: *** [modules] Error 2

PS.: compile-tested only

Reported-by: Josh Boyer 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Prerequisite for "sb_edac: Fix erroneous bytes->gigabytes conversion"]
Signed-off-by: Ben Hutchings

xen: netback: read hotplug script once at start of day.

2015-08-06T23:32:16+00:00

[ Upstream commit 31a418986a5852034d520a5bab546821ff1ccf3d ]

When we come to tear things down in netback_remove() and generate the
uevent it is possible that the xenstore directory has already been
removed (details below).

In such cases netback_uevent() won't be able to read the hotplug
script and will write a xenstore error node.

A recent change to the hypervisor exposed this race such that we now
sometimes lose it (where apparently we didn't ever before).

Instead read the hotplug script configuration during setup and use it
for the lifetime of the backend device.

The apparently more obvious fix of moving the transition to
state=Closed in netback_remove() to after the uevent does not work
because it is possible that we are already in state=Closed (in
reaction to the guest having disconnected as it shutdown). Being
already in Closed means the toolstack is at liberty to start tearing
down the xenstore directories. In principal it might be possible to
arrange to unregister the device sooner (e.g on transition to Closing)
such that xenstore would still be there but this state machine is
fragile and prone to anger...

A modern Xen system only relies on the hotplug uevent for driver
domains, when the backend is in the same domain as the toolstack it
will run the necessary setup/teardown directly in the correct sequence
wrt xenstore changes.

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

net: dp83640: fix broken calibration routine.

2015-08-06T23:32:16+00:00

[ Upstream commit 397a253af5031de4a4612210055935309af4472c ]

Currently, the calibration function that corrects the initial offsets
among multiple devices only works the first time.  If the function is
called more than once, the calibration fails and bogus offsets will be
programmed into the devices.

In a well hidden spot, the device documentation tells that trigger indexes
0 and 1 are special in allowing the TRIG_IF_LATE flag to actually work.

This patch fixes the issue by using one of the special triggers during the
recalibration method.

Signed-off-by: Richard Cochran 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings