Fix nasty 32-bit overflow bug in buffer i/o code.

On 32-bit architectures, the legacy buffer_head functions are not always
handling the sector number with the proper 64-bit types, and will thus
fail on 4TB+ disks.

Any code that uses __getblk() (and thus bread(), breadahead(),
sb_bread(), sb_breadahead(), sb_getblk()), and calls it using a 64-bit
block on a 32-bit arch (where "long" is 32-bit) causes an inifinite loop
in __getblk_slow() with an infinite stream of errors logged to dmesg
like this:

__find_get_block_slow() failed. block=6740375944, b_blocknr=2445408648
b_state=0x00000020, b_size=512
device sda1 blocksize: 512

Note how in hex block is 0x191C1F988 and b_blocknr is 0x91C1F988 i.e.
the
top 32-bits are missing (in this case the 0x1 at the top).

This is because grow_dev_page() is broken and has a 32-bit overflow due
to shifting the page index value (a pgoff_t - which is just 32 bits on
32-bit architectures) left-shifted as the block number.  But the top
bits to get lost as the pgoff_t is not type cast to sector_t / 64-bit
before the shift.

This patch fixes this issue by type casting "index" to sector_t before
doing the left shift.

Note this is not a theoretical bug but has been seen in the field on a
4TiB hard drive with logical sector size 512 bytes.

This patch has been verified to fix the infinite loop problem on
3.17-rc5
kernel using a 4TB disk image mounted using "-o loop".  Without this
patch
doing a "find /nt" where /nt is an NTFS volume causes the inifinite loop
100% reproducibly whilst with the patch it works fine as expected.

Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: Add interface to set/get min/max freq

* Interface similar to that for setting governor.
* Interface can be used by drivers to change/get
  min/max freq per cpu.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: limiter: Simplify and debugify min/max freq

* 5echo2@xda reported that sibling cores may or may not
  get updated with required max freq after every resume
  operation.
* This patch make use of hooks added in cpufreq driver.
  These hooks save desired min/max freq if CPU is
  offline OR update min/max freq if CPU is online
  and thus sibling cores will have their proper scaling
  frequencies updated whenever called.
* Also live_min_freq and live_max_freq are added per-cpu
  to help user retrieve actual min/max per cpu.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: Make get governor interface always return good value

* In rare scenario, we may not able to lock policy
  and in such case, get governor interface returns
  "invalid" governor.
* This patch ensures we never get "invalid" governor.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: limiter: Do not store governor locally

* @RenderBroken reported that local variables do
  not reflect actual value on boot.
* This happens because ramdisk or userspace apps
  change scaling_governor by using following path
  /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
* When above path is updated with new governor, local
  variables in limiter driver are not.
* Drop local variables and reflect actual governor per
  core always.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: limiter: Add readable tunable for current frequency

* It returns 0 if core is offline else current frequency
  of that core.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
USB: u_ether: Set complete handler before queueing to endpoint

rndis function driver will queue requests for TX endpoints in
tasklet context and interrupt context. While queueing requests
in interrupt context, not setting completion handler before
queueing to TX endpoint. Due to this, there is a chance that
usb request will be queued to USB HW without setting completion
handler. This results in crash when that particular usb request
is completed. Hence mark complete handler before queueing usb
request in interrupt context.

CRs-Fixed: 534958
Change-Id: I4cf235ace13f05f1e7bf2415b8a7dccf09d1115d
Signed-off-by: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
USB: core: hub.c: Fix bug in accessing freed memory

Current driver is accessing the buffer memory after it is freed.
This could result in getting wrong value and might could cause
memory corruption. Hence fix this issue by taking idvendor
value into a variable before freeing it.

Signed-off-by: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
USB: hub: Avoid NULL pointer dereference when hub doesn't have any ports

Return an error if hub->descriptor->bNbrPorts==0. Without this additional
check, we can end up doing a "hub->ports = kzalloc(0, GFP_KERNEL)".
This hub->ports pointer will therefore be non-NULL and will be used.
Example of dmesg:
   INIT: usb 1-1: New USB device found, idVendor=0424, idProduct=2512
   usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
   hub 1-1:1.0: USB hub found
   version 2.86 bootinghub 1-1:1.0: 0 ports detected
   Unable to handle kernel NULL pointer dereference at virtual address 00000010

Signed-off-by: David Linares <dlinares.linux@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
USB: android: Add support for USB UICC mass storage

USB UICC cards can support multiple partitions which can be
exposed to the host via USB mass storage function. The number
of partitions of UICC card may vary for each target. Hence
create a device tree property to accept the required luns.

Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
USB: ccid_bridge: Don't kill URB in release after device is disconnected

The URBs are killed in disconnect method. If the device is disconnected
before the /dev/ccid_bridge is closed, no need to kill the URBs again.
As the URB reference count is dropped in disconnect, accessing it in
release is causing the kernel panic.

Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
USB: ccid_bridge: Provide bulk message write/read stats via debugfs

The bulk message timeouts are observed occasionally during mass storage
transfers. This debug facility helps in identifying such timeout issues.

The sample output of the stats debugfs file.

ccid_bridge: connected
ccid_bridge: opened
total writes: 444
total reads: 444
write/read timeout val: 1000
write_timeout: 0
read_timeout: 0
write_max_time (msec): 130
read_max_time: (msec): 857

Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
dwc3: gadget: Add support for transfer complete events counting

Add counting of USB transfers completion events/interrupts
so that it can be used to determine USB transfers or BUS usage.
This is a simple approach which gives reasonable accuracy to
avoid counting actual bytes that got transferred over USB.

Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
USB: ci13xxx_udc: Add support for UI interrupts counting

Add counting of UI or USB transfers completion interrupts
so that it can be used to determine USB transfers or
BUS usage. This is a simple approach which gives
reasonable accuracy to avoid counting actual bytes
that got transferred over USB.

Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
xHCI: add aborting command ring function

Software have to abort command ring and cancel command
when a command is failed or hang. Otherwise, the command
ring will hang up and can't handle the others. An example
of a command that may hang is the Address Device Command,
because waiting for a SET_ADDRESS request to be acknowledged
by a USB device is outside of the xHC's ability to control.

To cancel a command, software will initialize a command
descriptor for the cancel command, and add it into a
cancel_cmd_list of xhci.

Sarah: Fixed missing newline on "Have the command ring been stopped?"
debugging statement.

This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.

Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
xhci: Don't enable/disable RWE on bus suspend/resume.

The RWE bit of the USB 2.0 PORTPMSC register is supposed to enable
remote wakeup for devices in the lower power link state L1.  It has
nothing to do with the device suspend remote wakeup from L2.  The RWE
bit is designed to be set once (when USB 2.0 LPM is enabled for the
port) and cleared only when USB 2.0 LPM is disabled for the port.

The xHCI bus suspend method was setting the RWE bit erroneously, and the
bus resume method was clearing it.  The xHCI 1.0 specification with
errata up to Aug 12, 2012 says in section 4.23.5.1.1.1 "Hardware
Controlled LPM":

"While Hardware USB2 LPM is enabled, software shall not modify the
HIRDBESL or RWE fields of the USB2 PORTPMSC register..."

If we have previously enabled USB 2.0 LPM for a device, that means when
the USB 2.0 bus is resumed, we violate the xHCI specification by
clearing RWE.  It also means that after a bus resume, the host would
think remote wakeup is disabled from L1 for ports with USB 2.0 Link PM
enabled, which is not what we want.

This patch should be backported to kernels as old as 3.2, that
contain the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set
USB2 hardware LPM".  That was the first kernel that supported USB 2.0
Link PM.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
[bwh: Backported to 3.2: deleted code was cosmetically different]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
xhci-mem: init list heads at the beginning of init

It is possible that we fail on xhci_mem_init, just before doing
the INIT_LIST_HEAD, and calling xhci_mem_cleanup.

Problem is that, the list_for_each_entry_safe macro, assumes
list heads are initialized (not NULL), and dereferences their 'next'
pointer, causing a kernel panic if this is not yet initialized.

Let's protect from that by moving inits to the beginning.

This patch should be backported to kernels as old as 3.2, that
contain the commit 9574323c39d1f8359a04843075d89c9f32d8b7e6 "xHCI: test
USB2 software LPM".

Signed-off-by: Sergio Aguirre <sergio.a.aguirre.rodriguez@intel.com>
Acked-by: David Cohen <david.a.cohen@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
xhci: delete endpoints from bandwidth list before freeing whole device

Lists of endpoints are stored for bandwidth calculation for roothub ports.
Make sure we remove all endpoints from the list before the whole device,
containing its endpoints list_head stuctures, is freed.

This used to be done in the wrong order in xhci_mem_cleanup(),
and triggered an oops in resume from S4 (hibernate).

Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
xhci: correct burst count field for isoc transfers on 1.0 xhci hosts

The transfer burst count (TBC) field in xhci 1.0 hosts should be set
to the number of bursts needed to transfer all packets in a isoc TD.
Supported values are 0-2 (1 to 3 bursts per service interval).

Formula for TBC calculation is given in xhci spec section 4.11.2.3:
TBC = roundup( Transfer Descriptor Packet Count / Max Burst Size +1 ) - 1

This patch should be applied to stable kernels since 3.0 that contain
the commit 5cd43e33b9519143f06f507dd7cbee6b7a621885
"xhci 1.0: Set transfer burst count field."

Suggested-by: ShiChun Ma <masc2008@qq.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
usbcore: enable USB2 LPM if port suspend fails

USB2 LPM is disabled when device begin to suspend and enabled after device
is resumed. That's because USB spec does not define the transition from
U1/U2 state to U3 state.

If usb_port_suspend() fails, usb_port_resume() is never called, and USB2 LPM
is disabled in this situation. Enable USB2 LPM if port suspend fails.

This patch should be backported to kernels as old as 3.2, that contain
the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2
hardware LPM".

Signed-off-by: Andiry Xu <andiry.xu@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>