patch: fixup kernel for gcc4.6
patch: add support for compiling with -Ofast
Makefile: add a few compiler flags
patch: disable GENTLTE_FAIR_SLEEPERS
htc_headset_gpio: increase irq_delay to fix audio during screen off (credits: adwinp@xda)
cable_detect: cleanup driver
usb: gadget: android: Reset next_string_id before enable

Reset next_string_id to 0 before enabling the gadget driver. Otherwise,
after a large number of enable/disable cycles, bind will fail
because we cannot allocate new string ids. String ids cannot be larger
than 254 per USB spec.

Change-Id: I44f5fece45008b7a0a18c025d4eb5ce842585c28
Signed-off-by: Benoit Goby <benoit@android.com>
usb: gadget: android: Cancel pending ctrlrequest before disabling

Make sure there is no pending ctrlrequest before removing the config.
Otherwise the ctrlrequest complete callback could access structures
after they have been freed. Unbind cancels pending transfers but not
ep0 requests.

Bug: 5513065 5440193

Change-Id: I063c22bf5d104a3d2df71cf622409459fac5f27a
Signed-off-by: Benoit Goby <benoit@android.com>
usb: gadget: Fix usb string id allocation

Don't reset next_string_id every time the gadget is enabled, this makes
the next strings allocated overwrite strings allocated at probe time.
Instead, fix rndis not to allocate new string ids on every config bind.

Change-Id: Ied28ee416bb6f00c434c34176fe5b7f0dcb2b2d4
Signed-off-by: Benoit Goby <benoit@android.com>
usb: gadget: zero: fix bug in loopback autoresume handling

commit 683da59d7b8ae04891636d4b59893cd4e9b0b7e5 upstream.

ab943a2e125b (USB: gadget: gadget zero uses new suspend/resume hooks)
introduced a copy-paste error where f_loopback.c writes to a variable
declared in f_sourcesink.c. This prevents one from creating gadgets
that only have a loopback function.

Signed-off-by: Timo Juhani Lindfors <timo.lindfors@iki.fi>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: gadget: Make g_hid device class conform to spec.

commit 33d2832ab0149a26418d360af3c444969a63fb28 upstream.

HID devices should specify this in their interface descriptors, not in the
device descriptor. This fixes a "missing hardware id" bug under Windows 7 with
a VIA VL800 (3.0) controller.

Signed-off-by: Orjan Friberg <of@flatfrog.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/arm/mach-tegra/usb_phy.c: add missing function return type
arch/arm/mach-tegra/usb_phy.c: fix mixed declaration and code
arch/arm/mach-tegra/usb_phy.c: fix wrong printf format & correct code tabbing
arch/arm/mach-tegra/usb_phy.c: fix wrong printf format & correct code tabbing #2
net / netfilter: remove annoying 'comparison will always be true' warning

-adding a new function which avoids this warning
-using the new function in all places where it makes no sense to check
ARM: 7215/1: mmc: mmci: Increase max_segs from 16 to 128

A significant increase (10-20%) in performance throughput for
USB mass storage is the reason for incrementing the value.
By some reason the USB driver allocates buffers which requires
a scattergather list to contain a lot more than 16 elements to
get optimal performance. This change sets the maximum elements
to 128.

Tests with large reads and large writes (100 MiB) show that the
throughput increase is significant for write (10% for this test)
but not for read. Tests are run on a Linux host with ext4 FS on
the gadget mass storage device. The sg-len still exceeds 16 for
the read tests but the performance gain is low or nothing.

Tested-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Per Forlin <per.forlin@stericsson.com>
Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
mmc: mmci: reduce max_blk_count to avoid overflowing max_req_size

On a system with large pages (64k in my case), the following BUG is
triggered in MMC core:

[    2.338023] BUG: failure at drivers/mmc/core/core.c:221/mmc_start_request()!
[    2.338102] Kernel panic - not syncing: BUG!
[    2.338155] Call trace:
[    2.338228] [<ffffffc00008635c>] dump_backtrace+0x0/0x120
[    2.338317] [<ffffffc0003365ec>] dump_stack+0x14/0x1c
[    2.338403] [<ffffffc000336990>] panic+0xbc/0x1f0
[    2.338498] [<ffffffc00027a494>] mmc_start_request+0x154/0x184
[    2.338600] [<ffffffc00027abdc>] mmc_start_req+0x110/0x140
[    2.338701] [<ffffffc00028604c>] mmc_blk_issue_rw_rq+0x7c/0x39c
[    2.338804] [<ffffffc00028652c>] mmc_blk_issue_rq+0x1c0/0x468
[    2.338905] [<ffffffc000287564>] mmc_queue_thread+0x68/0x118
[    2.338995] [<ffffffc0000bc308>] kthread+0x84/0x8c

This is because of a 64k request with a max_req_size of 64k-1 bytes.

The following patch fixes the problem by limiting the max_blk_count
such that max_blk_count * max_blk_size == max_req_size. I couldn't
pursuade the compiler to emit a shift instead of a div without encoding
the shift explicitly.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Revert "Revert "Revert "arm: tegra3: change min_rate for clocks"""

This reverts commit 6dd3dcdeabde29bb954eb5efaf60132a1d8f54a4.
cpufreq: update interactive governor and implement tracing