af_key: initialize satype in key_notify_policy_flush()

This field was left uninitialized. Some user daemons perform check against this
field.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
xen/xen-blkback: preq.dev is used without initialized

If call xen_vbd_translate failed, the preq.dev will be not initialized.
Use blkif->vbd.pdevice instead (still better to print relative info).

Note that before commit 01c681d4c70d64cb72142a2823f27c4146a02e63
(xen/blkback: Don't trust the handle from the frontend.)
the value bogus, as it was the guest provided value from req->u.rw.handle
rather than the actual device.

Signed-off-by: Chen Gang <gang.chen@asianux.com>
Acked-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
mac80211: always synchronize_net() during station removal

If there are keys left during station removal, then a
synchronize_net() will be done (for each key, I have a
patch to address this for 3.10), otherwise it won't be
done at all which causes issues because the station
could be used for TX while it's being removed from the
driver -- that might confuse the driver.

Fix this by always doing synchronize_net() if no key
was present any more.

Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
cfg80211: fix inconsistency in trace for rdev_set_mac_acl

There is NETDEV_ENTRY that was incorrectly assigned as WIPHY_ASSIGN,
fix it.

Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
cfg80211: fix potential BSS memory leak and update

In the odd case that while updating information from a beacon,
a BSS was found that is part of a hidden group, we drop the
new information. In this case, however, we leak the IE buffer
from the update, and erroneously update the entry's timestamp
so it will never time out. Fix both these issues.

Cc: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: fix crash with P2P Device returning action frames

If a P2P Device interface receives an unhandled action
frame, we attempt to return it. This crashes because it
doesn't have a channel context. Fix the crash by using
status->band and properly mark the return frame as an
off-channel frame.

Reported-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
xen/blkback: correctly respond to unknown, non-native requests

If the frontend is using a non-native protocol (e.g., a 64-bit
frontend with a 32-bit backend) and it sent an unrecognized request,
the request was not translated and the response would have the
incorrect ID.  This may cause the frontend driver to behave
incorrectly or crash.

Since the ID field in the request is always in the same place,
regardless of the request type we can get the correct ID and make a
valid response (which will report BLKIF_RSP_EOPNOTSUPP).

This bug affected 64-bit SLES 11 guests when using a 32-bit backend.
This guest does a BLKIF_OP_RESERVED_1 (BLKIF_OP_PACKET in the SLES
source) and would crash in blkif_int() as the ID in the response would
be invalid.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: stable@vger.kernel.org
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
xen/blkback: Change statistics counter types to unsigned

These values shouldn't be negative, but after an overflow their value
can turn into negative, if they are signed. xentop can show bogus
values in this case.

Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
Reported-by: Ichiro Ogino <ichiro.ogino@citrix.co.jp>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
block: IBM RamSan 70/80 trivial changes.

This patch includes trivial changes that were recommended by
different members of the Linux Community.

Changes include:
o Removing the redundant wmb().
o Formatting
o Various other little things.

Signed-off-by: Philip J Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
block: IBM RamSan 70/80 fixes inconsistent locking.

This patch includes changes to the cregs locking scheme. Before,
inconsistant locking would occur because of misuse of spin_lock,
spin_lock_bh, and counter parts.

Signed-off-by: Philip J Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
block: IBM RamSan 70/80 branding changes.

This patch includes changing the hardware branding name from
IBM RamSan to IBM FlashSystem.

v2 Changes include:
o Removing the unnecessary IBM Vendor ID #define

v1 Changes include:
o Changed all references of RamSan to FlashSystem.
o Changed the vendor/device IDs for the product.
o Changed driver version number.
o Updated the MAINTAINERS file.
o Various other little things.

Signed-off-by: Philip J Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
block: IBM RamSan 70/80 error message bug fix.

This patch includes a simple change to the rsxx_pci_remove
function that caused error messages because traffic was halted
too early.

Signed-off-by: Philip J Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
ARM: OMAP1: fix USB host on 1710

There is a long-standing bug that OHCI USB host controller does
not respond on 1710, because of wrong clock definitions. See e.g.
http://marc.info/?l=linux-omap&m=119634441229321&w=2. All register reads
return just zeroes:

[    1.896606] ohci ohci: OMAP OHCI
[    1.912597] ohci ohci: new USB bus registered, assigned bus number 1
[    1.933776] ohci ohci: irq 38, io mem 0xfffba000
[    2.012573] ohci ohci: init err (00000000 0000)
[    2.030334] ohci ohci: can't start
[    2.046661] ohci ohci: startup error -75
[    2.063201] ohci ohci: USB bus 1 deregistered

After some experiments, it seems that when changing the usb_dc_ck /
SOFT_REQ enable bit from USB_REQ_EN_SHIFT to SOFT_USB_OTG_DPLL_REQ_SHIFT
(like done also on 7XX), the USB appears to work:

[    2.183959] ohci ohci: OMAP OHCI
[    2.198242] ohci ohci: new USB bus registered, assigned bus number 1
[    2.215820] ohci ohci: irq 38, io mem 0xfffba000
[    2.324798] hub 1-0:1.0: USB hub found
[    2.361267] hub 1-0:1.0: 3 ports detected

The patch is tested on Nokia 770.

Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP4: clock data: lock USB DPLL on boot

Some versions of the u-boot bootloader do not lock the USB DPLL and
when the USB DPLL is not locked, then it is observed that the L3INIT
power domain does not transition to retention state during kernel
suspend on OMAP4 devices. Fix this by locking the USB DPLL at 960 MHz
on kernel boot.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP3: hwmod data: keep MIDLEMODE in force-standby for musb

For some unknown reason, allowing hwmod to control MIDLEMODE causes
core_pwrdm to not hit idle states for musb in DM3730 at least.
I've verified that setting any MIDLEMODE value other than "force
standby" before enabling the device causes subsequent suspend
attempts to fail with core_pwrdm not entering idle states, even
if the driver is unloaded and "force standby" is restored before
suspend attempt. To recover from this, soft reset can be used, but
that's not suitable solution for suspend.

Keeping the register set at force standby (reset value) makes it work
and device still functions properly, as musb has driver-controlled
OTG_FORCESTDBY register that controls MSTANDBY signal.
Note that TI PSP kernels also have similar workarounds.

This patch also fixes HWMOD_SWSUP_MSTANDBY documentation to match the
actual flag name.

Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP4: PM: fix PM regression introduced by recent clock cleanup

Commit 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb ("ARM: OMAP4:
clock/hwmod data: start to remove some IP block control "clocks"")
introduced a regression preventing the L3INIT clockdomain of OMAP4
systems from entering idle.  This in turn prevented these systems from
entering full chip clock-stop.

The regression was caused by the incorrect removal of a so-called
"optional functional clock" from the OMAP4 clock data.  This wasn't
caught for two reasons.  First, I missed the retention entry failure
in the branch test logs:

http://www.pwsan.com/omap/testlogs/cleanup_a_3.9/20130126014242/pm/4460pandaes/4460pandaes_log.txt

Second, the integration data for the OCP2SCP PHY IP block, added by
commit 0c6688753f9912c6a7013549ec31c8844020bbc1 ("ARM: OMAP4: hwmod
data: add remaining USB-related IP blocks"), should have associated this
clock with the IP block, but did not.

Fix by adding back the so-called "optional" functional clock to the
clock data, and by linking that clock to the OCP2SCP PHY IP block
integration hwmod data.

The problem patch was discovered by J, Keerthy <j-keerthy@ti.com>.

Cc: Keerthy <j-keerthy@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Adding in EEH support to the IBM FlashSystem 70/80 device driver

Changes in v2 include:
o Fixed spelling of guarantee.
o Fixed potential memory leak if slot reset fails out.
o Changed list_for_each_entry_safe with list_for_each_entry.

Signed-off-by: Philip J Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
rsxx: fix missing unlock on error return in rsxx_eeh_remap_dmas()

Spotted by Fenguan Wu's super build robot.

Signed-off-by: Jens Axboe <axboe@kernel.dk>
ARM: ep93xx: Fix wait for UART FIFO to be empty

Commit 210dce5f "ARM: ep93xx: properly wait for UART FIFO to be empty"

Removed the timeout loop while waiting for the uart transmit fifo to
empty. Some bootloaders leave the uart in a state where there might
be bytes in the uart that are not transmitted when execution is handed
over to the kernel. This results in a deadlocked system while waiting
for the fifo to empty.

Add back the timeout wait to prevent the deadlock.

Increase the wait time to hopefully prevent the decompressor corruption
that lead to commit 210dce5f. This corruption was probably due to a
slow uart baudrate. The 10* increase in the wait time should be enough
for all cases.

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Ryan Mallon <rmallon@gmail.com>
Revert "virtio_console: Initialize guest_connected=true for rproc_serial"

This reverts commit 8078db789a92b10ff6e2d713231b5367e014c53b, and
adds a lengthy comment explaining the problem area.

The reverted patch caused opening of ports to fail for rproc_serial.
In probe guest_connected was set to true, but port_fops_open()
fails with -EMFILE if guest_connected already is true.

Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
Acked-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>