lib: spinlock_debug: Avoid livelock in do_raw_spin_lock

The logic in do_raw_spin_lock attempts to acquire a spinlock
by invoking arch_spin_trylock in a loop with a delay between
each attempt. Now consider the following situation in a 2
CPU system:

1. Cpu 0 continually acquires and releases a spinlock in a
   tight loop; it stays in this loop until some condition X
   is satisfied. X can only be satisfied by another CPU.

2. Cpu 1 tries to acquire the same spinlock, in an attempt
   to satisfy the aforementioned condition X. However, it
   never sees the unlocked value of the lock because the
   debug spinlock code uses trylock instead of just lock;
   it checks at all the wrong moments - whenever Cpu 0 has
   locked the lock.

Now in the absence of debug spinlocks, the architecture specific
spinlock code can correctly allow Cpu1 to wait in a "queue"
(e.g., ticket spinlocks), ensuring that it acquires the lock at
some point. However, with the debug spinlock code, livelock
can easily occur due to the use of try_lock, which obviously
cannot put the CPU in that "queue".

Address this by actually attempting arch_spin_lock once it is
suspected that there is a spinlock lockup. If we're in a
situation that is described above, the arch_spin_lock should
succeed; otherwise other timeout mechanisms (e.g., watchdog)
should alert the system of a lockup.

Additionally, the delay between each trylock attempt adds up
to a total delay of 1 second. On some embedded architectures,
this is an unacceptably large value. Reduce this to a ~62 ms
delay.

CRs-Fixed: 393351
Change-Id: I56f0d8f5e483cd7e8167fc7a363b9de7777a0830
Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
USB: ci13xxx_udc: Reduce busywait time from 100msec to 25msec

Commit 037476 "lib: spinlock_debug: Avoid livelock in
do_raw_spin_lock" reduced timeout value in spin_try_lock from
1sec to 62msec. Once this timeout happens, system would then
crash detecting spinlock lockup.
USB driver is currently using 100msec as timeout during busywait
loops with spinlock acquired. It may result in above spin lockup
crash whenever timeout happens due to some hardware issue.
Fix this by reducing timeout to 25msec as confirmed by h/w team.

CRs-Fixed: 487591
Change-Id: Idadcbe4b21fea456256586657ef07dfcb578f5c1
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
switch: Reset device's drvdata before destroying it

dev_set_drvdata() sets the device specific driver data at
dev->p->driver_data.  However, dev is destroyed and has it's
context memory freed in device_destroy().  As a result, calling
dev_set_drvdata() causes a fault when accessing dev->p.

Change-Id: Id6cc72e1c635d6c4e69db3404bf57ebbab35d464
Signed-off-by: Deva Ramasubramanian <dramasub@codeaurora.org>
PM / Sleep: Look for wakeup events in later stages of device suspend

Currently, the device suspend code in drivers/base/power/main.c
only checks if there have been any wakeup events, and therefore the
ongoing system transition to a sleep state should be aborted, during
the first (i.e. "suspend") device suspend phase.  However, wakeup
events may be reported later as well, so it's reasonable to look for
them in the in the subsequent (i.e. "late suspend" and "suspend
noirq") phases.

Change-Id: Idc55bb84fd820c4f0b5e037186fb337daa612fb4
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: 52d136cc2cf6659ee247dbcc88c9e7bd7428ad06
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
net: wireless: bcmdhd: Add support for hidden ssid PNO scan

Changes to support hidden ssid config to be sent to FW. Earlier
all ssids were hard coded as hidden, now only those indicated
as such by supplicant will be.

Conflicts:
	drivers/net/wireless/bcmdhd/dhd_pno.c
	drivers/net/wireless/bcmdhd/include/wlioctl.h
	drivers/net/wireless/bcmdhd/wl_android.c
	drivers/net/wireless/bcmdhd/wl_cfg80211.c

Change-Id: I927030fe12f162c52c93277b2ebfb4bf55daef4a
Signed-off-by: Ashwin <ashwin.bhat@broadcom.com>
lib: spinlock_debug: Avoid livelock in do_raw_spin_lock

The logic in do_raw_spin_lock attempts to acquire a spinlock
by invoking arch_spin_trylock in a loop with a delay between
each attempt. Now consider the following situation in a 2
CPU system:

1. Cpu 0 continually acquires and releases a spinlock in a
   tight loop; it stays in this loop until some condition X
   is satisfied. X can only be satisfied by another CPU.

2. Cpu 1 tries to acquire the same spinlock, in an attempt
   to satisfy the aforementioned condition X. However, it
   never sees the unlocked value of the lock because the
   debug spinlock code uses trylock instead of just lock;
   it checks at all the wrong moments - whenever Cpu 0 has
   locked the lock.

Now in the absence of debug spinlocks, the architecture specific
spinlock code can correctly allow Cpu1 to wait in a "queue"
(e.g., ticket spinlocks), ensuring that it acquires the lock at
some point. However, with the debug spinlock code, livelock
can easily occur due to the use of try_lock, which obviously
cannot put the CPU in that "queue".

Address this by actually attempting arch_spin_lock once it is
suspected that there is a spinlock lockup. If we're in a
situation that is described above, the arch_spin_lock should
succeed; otherwise other timeout mechanisms (e.g., watchdog)
should alert the system of a lockup.

Additionally, the delay between each trylock attempt adds up
to a total delay of 1 second. On some embedded architectures,
this is an unacceptably large value. Reduce this to a ~62 ms
delay.

CRs-Fixed: 393351
Change-Id: I56f0d8f5e483cd7e8167fc7a363b9de7777a0830
Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
USB: ci13xxx_udc: Reduce busywait time from 100msec to 25msec

Commit 037476 "lib: spinlock_debug: Avoid livelock in
do_raw_spin_lock" reduced timeout value in spin_try_lock from
1sec to 62msec. Once this timeout happens, system would then
crash detecting spinlock lockup.
USB driver is currently using 100msec as timeout during busywait
loops with spinlock acquired. It may result in above spin lockup
crash whenever timeout happens due to some hardware issue.
Fix this by reducing timeout to 25msec as confirmed by h/w team.

CRs-Fixed: 487591
Change-Id: Idadcbe4b21fea456256586657ef07dfcb578f5c1
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
switch: Reset device's drvdata before destroying it

dev_set_drvdata() sets the device specific driver data at
dev->p->driver_data.  However, dev is destroyed and has it's
context memory freed in device_destroy().  As a result, calling
dev_set_drvdata() causes a fault when accessing dev->p.

Change-Id: Id6cc72e1c635d6c4e69db3404bf57ebbab35d464
Signed-off-by: Deva Ramasubramanian <dramasub@codeaurora.org>
PM / Sleep: Look for wakeup events in later stages of device suspend

Currently, the device suspend code in drivers/base/power/main.c
only checks if there have been any wakeup events, and therefore the
ongoing system transition to a sleep state should be aborted, during
the first (i.e. "suspend") device suspend phase.  However, wakeup
events may be reported later as well, so it's reasonable to look for
them in the in the subsequent (i.e. "late suspend" and "suspend
noirq") phases.

Change-Id: Idc55bb84fd820c4f0b5e037186fb337daa612fb4
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: 52d136cc2cf6659ee247dbcc88c9e7bd7428ad06
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
add graphite flags
Merge remote-tracking branch 'upstream/cm-11.0' into neocore