9 years agoblock: Make cfq_target_latency tunable through sysfs.
Tao Ma [Sun, 1 Apr 2012 21:33:39 +0000]
block: Make cfq_target_latency tunable through sysfs.

In cfq, when we calculate a time slice for a process(or a cfqq to
be precise), we have to consider the cfq_target_latency so that all the
sync request have an estimated latency(300ms) and it is controlled by
cfq_target_latency. But in some hadoop test, we have found that if
there are many processes doing sequential read(24 for example), the
throughput is bad because every process can only work for about 25ms
and the cfqq is switched. That leads to a higher disk seek. We can
achive the good throughput by setting low_latency=0, but then some
read's latency is too much for the application.

So this patch makes cfq_target_latency tunable through sysfs so that
we can tune it and find some magic number which is not bad for both
the throughput and the read latency.

Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

9 years agoblock: use lockdep_assert_held for queue locking
Andi Kleen [Fri, 30 Mar 2012 10:33:28 +0000]
block: use lockdep_assert_held for queue locking

Instead of an ugly open coded variant.

Cc: axboe@kernel.dk
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

9 years agoblock: blk_alloc_queue_node(): use caller's GFP flags instead of GFP_KERNEL
Dan Carpenter [Fri, 23 Mar 2012 08:58:54 +0000]
block: blk_alloc_queue_node(): use caller's GFP flags instead of GFP_KERNEL

We should use the GFP flags that the caller specified instead of picking
our own.  All the callers specify GFP_KERNEL so this doesn't make a
difference to how the kernel runs, it's just a cleanup.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

9 years agocpufreq: OMAP: fix build errors: depends on ARCH_OMAP2PLUS
Kevin Hilman [Fri, 13 Apr 2012 20:32:30 +0000]
cpufreq: OMAP: fix build errors: depends on ARCH_OMAP2PLUS

The OMAP driver needs a 'depends on ARCH_OMAP2PLUS' since it only
builds for OMAP2+ platforms.

This 'depends on' was in the original patch from Russell King, but was
erroneously removed by me when making this option user-selectable in
commit b09db45c (cpufreq: OMAP driver depends CPUfreq tables.)  This
patch remedies that.

Apologies to Russell King for breaking his originally working patch.

Also, thanks to Grazvydas Ignotas for reporting the same problem.

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

9 years agosparc64: Eliminate obsolete __handle_softirq() function
Paul E. McKenney [Fri, 13 Apr 2012 03:35:13 +0000]
sparc64: Eliminate obsolete __handle_softirq() function

The invocation of softirq is now handled by irq_exit(), so there is no
need for sparc64 to invoke it on the trap-return path.  In fact, doing so
is a bug because if the trap occurred in the idle loop, this invocation
can result in lockdep-RCU failures.  The problem is that RCU ignores idle
CPUs, and the sparc64 trap-return path to the softirq handlers fails to
tell RCU that the CPU must be considered non-idle while those handlers
are executing.  This means that RCU is ignoring any RCU read-side critical
sections in those handlers, which in turn means that RCU-protected data
can be yanked out from under those read-side critical sections.

The shiny new lockdep-RCU ability to detect RCU read-side critical sections
that RCU is ignoring located this problem.

The fix is straightforward: Make sparc64 stop manually invoking the
softirq handlers.

Reported-by: Meelis Roos <mroos@linux.ee>
Suggested-by: David Miller <davem@davemloft.net>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Meelis Roos <mroos@linux.ee>
Cc: stable@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>

9 years agosparc64: Fix bootup crash on sun4v.
David S. Miller [Fri, 13 Apr 2012 18:56:22 +0000]
sparc64: Fix bootup crash on sun4v.

The DS driver registers as a subsys_initcall() but this can be too
early, in particular this risks registering before we've had a chance
to allocate and setup module_kset in kernel/params.c which is
performed also as a subsyts_initcall().

Register DS using device_initcall() insteal.

Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: stable@vger.kernel.org

9 years agohwmon: (pmbus_core) Fix compiler warning
Guenter Roeck [Wed, 28 Mar 2012 16:14:03 +0000]
hwmon: (pmbus_core) Fix compiler warning

Some configurations produce the following compiler warning:

drivers/hwmon/pmbus/pmbus_core.c: In function 'pmbus_show_boolean':
drivers/hwmon/pmbus/pmbus_core.c:752: warning: 'val' may be used uninitialized in this function

While this is a false positive, it can easily be fixed by overloading the return
value from pmbus_get_boolean with both val and error return code (val is a
boolean and thus never negative).

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>

9 years agohwmon: (smsc47m1) Fix compiler warning
Guenter Roeck [Wed, 28 Mar 2012 15:55:12 +0000]
hwmon: (smsc47m1) Fix compiler warning

Some configurations produce the following compiler warning:

drivers/hwmon/smsc47m1.c: In function 'sm_smsc47m1_init':
drivers/hwmon/smsc47m1.c:938: warning: 'address' may be used uninitialized in this function

While this is a false positive, it can easily be fixed by overloading the return
value from smsc47m1_find with both address and error return code (the address
is an unsigned short and thus never negative). This also reduces module size by
a few bytes (46 bytes for x86_64).

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>

9 years agohwmon: (acpi_power_meter) Fix compiler warning seen in some configurations
Guenter Roeck [Wed, 28 Mar 2012 16:03:26 +0000]
hwmon: (acpi_power_meter) Fix compiler warning seen in some configurations

In some configurations, BUG() does not result in an endless loop but returns
to the caller. This results in the following compiler warning:

drivers/hwmon/acpi_power_meter.c: In function 'show_str':
drivers/hwmon/acpi_power_meter.c:380: warning: 'val' may be used uninitialized in this function

Fix the warning by setting val to an empty string after BUG().

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>

9 years agohwmon: (smsc47b397) Fix compiler warning
Guenter Roeck [Wed, 28 Mar 2012 15:35:26 +0000]
hwmon: (smsc47b397) Fix compiler warning

Some configurations produce the following compiler warning:

drivers/hwmon/smsc47b397.c: In function 'smsc47b397_init':
drivers/hwmon/smsc47b397.c:385: warning: 'address' may be used uninitialized in this function

While this is a false positive, it can easily be fixed by overloading the return
value from smsc47b397_find with both address and error return code (the address
is an unsigned short and thus never negative). This also reduces module size by
a few bytes (64 bytes for x86_64).

Cc: Mark M. Hoffman <mhoffman@lightlink.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Acked-by: Jean Delvare <khali@linux-fr.org>

9 years agogpio/exynos: Fix compiler warning in gpio-samsung.c file
Sachin Kamat [Tue, 3 Apr 2012 08:42:55 +0000]
gpio/exynos: Fix compiler warning in gpio-samsung.c file

Fixes the following warning when "SAMSUNG EXYNOS5" is not selected:

warning: ‘exynos5_gpios_1’ defined but not used [-Wunused-variable]
warning: ‘exynos5_gpios_2’ defined but not used [-Wunused-variable]
warning: ‘exynos5_gpios_3’ defined but not used [-Wunused-variable]
warning: ‘exynos5_gpios_4’ defined but not used [-Wunused-variable]

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

9 years agogpio: Fix range check in of_gpio_simple_xlate()
Roland Stigge [Wed, 4 Apr 2012 00:02:58 +0000]
gpio: Fix range check in of_gpio_simple_xlate()

of_gpio_simple_xlate() has an off-by-one bug where it checks to see if
args[0] is > ngpio instead of >=.  args[0] must always be less than
ngpio because it is a zero-based enumeration.

Signed-off-by: Roland Stigge <stigge@antcom.de>
[grant.likely: beef up commit text]
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

9 years agogpio: Fix uninitialized variable bit in adp5588_irq_handler
Axel Lin [Fri, 6 Apr 2012 12:37:43 +0000]
gpio: Fix uninitialized variable bit in adp5588_irq_handler

The variable 'bit' is uninitialized in the first iteration of for
loop. Fix it.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

9 years agogpio/sodaville: Convert sodaville driver to new irqdomain API
Grant Likely [Wed, 28 Mar 2012 20:55:04 +0000]
gpio/sodaville: Convert sodaville driver to new irqdomain API

The irqdomain api changed significantly in v3.4 which caused a build
failure for this driver.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Hans J. Koch <hjk@linutronix.de>
Cc: Torben Hohn <torbenh@linutronix.de>

9 years agospi/imx: prevent NULL pointer dereference in spi_imx_probe()
Lothar Waßmann [Tue, 3 Apr 2012 13:03:44 +0000]
spi/imx: prevent NULL pointer dereference in spi_imx_probe()

When no platform_data is present and either 'spi-num-chipselects' is
not defined in the DT or 'cs-gpios' has less entries than
'spi-num-chipselects' specifies, the NULL platform_data pointer is
being dereferenced.

Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

9 years agospi/imx: mark base member in spi_imx_data as __iomem
Uwe Kleine-König [Thu, 29 Mar 2012 19:54:18 +0000]
spi/imx: mark base member in spi_imx_data as __iomem

This fixes 36 sparse warnings like:

drivers/spi/spi-imx.c:143:1: warning: incorrect type in argument 1 (different address spaces)
drivers/spi/spi-imx.c:143:1:    expected void const volatile [noderef] <asn:2>*<noident>
drivers/spi/spi-imx.c:143:1:    got void *

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

9 years agospi/mpc83xx: fix NULL pdata dereference bug
Kenth Eriksson [Fri, 30 Mar 2012 15:05:30 +0000]
spi/mpc83xx: fix NULL pdata dereference bug

Commit 178db7d3, "spi: Fix device unregistration when unregistering
the bus master", changed device initialization to be children of the
bus master, not children of the bus masters parent device. The pdata
pointer used in fsl_spi_chipselect must updated to reflect the changed

Signed-off-by: Kenth Eriksson <kenth.eriksson@transmode.com>
Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

9 years agospi/davinci: Fix DMA API usage in davinci
Shubhrajyoti D [Tue, 20 Mar 2012 10:40:09 +0000]
spi/davinci: Fix DMA API usage in davinci

The driver uses NULL for dma_unmap_single instead of
the struct device that the API expects.

Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Tested-by: Akshay Shankarmurthy <akshay.s@ti.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

9 years agospi/pL022: include types.h to remove compilation warnings
Viresh Kumar [Fri, 23 Mar 2012 07:35:48 +0000]
spi/pL022: include types.h to remove compilation warnings

linux/pl022.h uses definitions like, u8, u16, etc, which have dependency of
types.h file, which isn't included in it. So, we get compilation warnings.

This patch includes types.h there to fix these warnings.

Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

9 years agoIB/srpt: Set srq_type to IB_SRQT_BASIC
Roland Dreier [Thu, 12 Apr 2012 14:51:08 +0000]
IB/srpt: Set srq_type to IB_SRQT_BASIC

Since commit 96104eda0169 ("RDMA/core: Add SRQ type field"), kernel
users of SRQs need to specify srq_type = IB_SRQT_BASIC in struct
ib_srq_init_attr, or else most low-level drivers will fail in
when srpt_add_one() calls ib_create_srq() and gets -ENOSYS.

(mlx4_ib works OK nearly all of the time, because it just needs
srq_type != IB_SRQT_XRC.  And apparently nearly everyone using
ib_srpt is using mlx4 hardware)

Reported-by: Alexey Shvetsov <alexxy@gentoo.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Roland Dreier <roland@purestorage.com>

9 years agokconfig: delete last traces of __enabled_ from autoconf.h
Paul Gortmaker [Thu, 12 Apr 2012 23:46:34 +0000]
kconfig: delete last traces of __enabled_ from autoconf.h

We've now fixed IS_ENABLED() and friends to not require any special
"__enabled_" prefixed versions of the normal Kconfig options, so delete
the last traces of them being generated.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

9 years agoRevert "kconfig: fix __enabled_ macros definition for invisible and un-selected symbols"
Paul Gortmaker [Thu, 12 Apr 2012 23:46:33 +0000]
Revert "kconfig: fix __enabled_ macros definition for invisible and un-selected symbols"

This reverts commit 953742c8fe8ac45be453fee959d7be40cd89f920.

Dumping two lines into autoconf.h for all existing Kconfig options
results in a giant file (~16k lines) we have to process each time we
compile something.  We've weaned IS_ENABLED() and similar off of
requiring the __enabled_ definitions so now we can revert the change
which caused all the extra lines.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

9 years agokconfig: fix IS_ENABLED to not require all options to be defined
Paul Gortmaker [Thu, 12 Apr 2012 23:46:32 +0000]
kconfig: fix IS_ENABLED to not require all options to be defined

Using IS_ENABLED() within C (vs.  within CPP #if statements) in its
current form requires us to actually define every possible bool/tristate
Kconfig option twice (__enabled_* and __enabled_*_MODULE variants).

This results in a huge autoconf.h file, on the order of 16k lines for a
x86_64 defconfig.

Fixing IS_ENABLED to be able to work on the smaller subset of just
things that we really have defined is step one to fixing this.  Which
means it has to not choke when fed non-enabled options, such as:

  include/linux/netdevice.h:964:1: warning: "__enabled_CONFIG_FCOE_MODULE" is not defined [-Wundef]

The original prototype of how to implement a C and preprocessor
compatible way of doing this came from the Google+ user "comex ." in
response to Linus' crowdsourcing challenge for a possible improvement on
his earlier C specific solution:

#define config_enabled(x)       (__stringify(x)[0] == '1')

In this implementation, I've chosen variable names that hopefully make
how it works more understandable.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

9 years agoUSB: update usbtmc api documentation
Stephen Lewis [Mon, 2 Apr 2012 20:38:49 +0000]
USB: update usbtmc api documentation

Correct path names in API documentation for usbtmc

Signed-off-by: Stephen Lewis <lewis@sdf.lonestar.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoxHCI: Correct the #define XHCI_LEGACY_DISABLE_SMI
Alex He [Fri, 30 Mar 2012 02:21:38 +0000]
xHCI: Correct the #define XHCI_LEGACY_DISABLE_SMI

Re-define XHCI_LEGACY_DISABLE_SMI and used it in right way. All SMI enable
bits will be cleared to zero and flag bits 29:31 are also cleared to zero.
Other bits should be presvered as Table 146.

This patch should be backported to kernels as old as 2.6.31.

Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

9 years agoxHCI: use gfp flags from caller instead of GFP_ATOMIC
Dan Carpenter [Wed, 28 Mar 2012 07:30:26 +0000]
xHCI: use gfp flags from caller instead of GFP_ATOMIC

The caller is allowed to specify the GFP flags for these functions.
We should prefer their flags unless we have good reason.  For
example, if we take a spin_lock ourselves we'd need to use
GFP_ATOMIC.  But in this case it's safe to use the callers GFP

The callers all pass GFP_ATOMIC here, so this change doesn't affect
how the kernel behaves but we may add other callers later and this
is a cleanup.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

9 years agoxHCI: add XHCI_RESET_ON_RESUME quirk for VIA xHCI host
Elric Fu [Thu, 29 Mar 2012 07:47:50 +0000]
xHCI: add XHCI_RESET_ON_RESUME quirk for VIA xHCI host

The suspend operation of VIA xHCI host have some issues and
hibernate operation works fine, so The XHCI_RESET_ON_RESUME
quirk is added for it.

This patch should base on "xHCI: Don't write zeroed pointer
to xHC registers" that is released by Sarah. Otherwise, the
host system error will ocurr in the hibernate operation

This should be backported to stable kernels as old as 2.6.37,
that contain the commit c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9
"xhci: Add reset on resume quirk for asrock p67 host".

Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

9 years agoUSB: fix bug of device descriptor got from superspeed device
Elric Fu [Mon, 26 Mar 2012 13:16:02 +0000]
USB: fix bug of device descriptor got from superspeed device

When the Seagate Goflex USB3.0 device is attached to VIA xHCI
host, sometimes the device will downgrade mode to high speed.
By the USB analyzer, I found the device finished the link
training process and worked at superspeed mode. But the device
descriptor got from the device shows the device works at 2.1.
It is very strange and seems like the device controller of
Seagate Goflex has a little confusion.

The first 8 bytes of device descriptor should be:
12 01 00 03 00 00 00 09

But the first 8 bytes of wrong device descriptor are:
12 01 10 02 00 00 00 40

The wrong device descriptor caused the initialization of mass
storage failed. After a while, the device would be recognized
as a high speed device and works fine.

This patch will warm reset the device to fix the issue after
finding the bcdUSB field of device descriptor isn't 0x0300
but the speed mode of device is superspeed.

This patch should be backported to kernels as old as 3.2, or ones that
contain the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore:
refine warm reset logic".

Signed-off-by: Elric Fu <elricfu1@gmail.com>
Acked-by: Andiry Xu <Andiry.Xu@amd.com>
Acked-by: Sergei Shtylyov <sshtylyov@mvista.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

9 years agoxhci: Fix register save/restore order.
Sarah Sharp [Fri, 16 Mar 2012 20:19:35 +0000]
xhci: Fix register save/restore order.

The xHCI 1.0 spec errata released on June 13, 2011, changes the ordering
that the xHCI registers are saved and restored in.  It moves the
interrupt pending (IMAN) and interrupt control (IMOD) registers to be
saved and restored last.  I believe that's because the host controller
may attempt to fetch the event ring table when interrupts are
re-enabled.  Therefore we need to restore the event ring registers
before we re-enable interrupts.

This should be backported to kernels as old as 2.6.37, that contain the
commit 5535b1d5f8885695c6ded783c692e3c0d0eda8ca "USB: xHCI: PCI power
management implementation"

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org

9 years agoxhci: Restore event ring dequeue pointer on resume.
Sarah Sharp [Fri, 16 Mar 2012 20:27:39 +0000]
xhci: Restore event ring dequeue pointer on resume.

The xhci_save_registers() function saved the event ring dequeue pointer
in the s3 register structure, but xhci_restore_registers() never
restored it.  No other code in the xHCI successful resume path would
ever restore it either.  Fix that.

This should be backported to kernels as old as 2.6.37, that contain the
commit 5535b1d5f8885695c6ded783c692e3c0d0eda8ca "USB: xHCI: PCI power
management implementation".

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org

9 years agoxhci: Don't write zeroed pointers to xHC registers.
Sarah Sharp [Fri, 16 Mar 2012 20:09:39 +0000]
xhci: Don't write zeroed pointers to xHC registers.

When xhci_mem_cleanup() is called, we can't be sure if the xHC is
actually halted.  We can ask the xHC to halt by writing to the RUN bit
in the command register, but that might timeout due to a HW hang.

If the host controller is still running, we should not write zeroed
values to the event ring dequeue pointers or base tables, the DCBAA
pointers, or the command ring pointers.  Eric Fu reports his VIA VL800
host accesses the event ring pointers after a failed register restore on
resume from suspend.  The hypothesis is that the host never actually
halted before the register write to change the event ring pointer to

Remove all writes of zeroed values to pointer registers in
xhci_mem_cleanup().  Instead, make all callers of the function reset the
host controller first, which will reset those registers to zero.
xhci_mem_init() is the only caller that doesn't first halt and reset the
host controller before calling xhci_mem_cleanup().

This should be backported to kernels as old as 2.6.32.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Cc: stable@vger.kernel.org

9 years agoxhci: Warn when hosts don't halt.
Sarah Sharp [Fri, 16 Mar 2012 19:58:20 +0000]
xhci: Warn when hosts don't halt.

Eric Fu reports a problem with his VIA host controller fetching a zeroed
event ring pointer on resume from suspend.  The host should have been
halted, but we can't be sure because that code ignores the return value
from xhci_halt().  Print a warning when the host controller refuses to
halt within XHCI_MAX_HALT_USEC (currently 16 seconds).

(Update: it turns out that the VIA host controller is reporting a halted
state when it fetches the zeroed event ring pointer.  However, we still
need this warning for other host controllers.)

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

9 years agoxhci: don't re-enable IE constantly
Felipe Balbi [Thu, 15 Mar 2012 14:37:08 +0000]
xhci: don't re-enable IE constantly

While we're at that, define IMAN bitfield to aid readability.

The interrupt enable bit should be set once on driver init, and we
shouldn't need to continually re-enable it.  Commit c21599a3 introduced
a read of the irq_pending register, and that allows us to preserve the
state of the IE bit.  Before that commit, we were blindly writing 0x3 to
the register.

This patch should be backported to kernels as old as 2.6.36, or ones
that contain the commit c21599a36165dbc78b380846b254017a548b9de5 "USB:
xhci: Reduce reads and writes of interrupter registers".

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

9 years agousb: xhci: fix section mismatch in linux-next
Gerard Snitselaar [Fri, 16 Mar 2012 18:34:11 +0000]
usb: xhci: fix section mismatch in linux-next

xhci_unregister_pci() is called in xhci_hcd_init().

Signed-off-by: Gerard Snitselaar <dev@snitselaar.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

9 years agoxHCI: correct to print the true HSEE of USBCMD
Alex He [Thu, 22 Mar 2012 07:06:59 +0000]
xHCI: correct to print the true HSEE of USBCMD

Correct the print of HSEE of USBCMD in xhci-dbg.c.

Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

9 years agoUSB: serial: fix race between probe and open
Johan Hovold [Tue, 20 Mar 2012 15:59:33 +0000]
USB: serial: fix race between probe and open

Fix race between probe and open by making sure that the disconnected
flag is not cleared until all ports have been registered.

A call to tty_open while probe is running may get a reference to the
serial structure in serial_install before its ports have been
registered. This may lead to usb_serial_core calling driver open before
port is fully initialised.

With ftdi_sio this result in the following NULL-pointer dereference as
the private data has not been initialised at open:

[  199.698286] IP: [<f811a089>] ftdi_open+0x59/0xe0 [ftdi_sio]
[  199.698297] *pde = 00000000
[  199.698303] Oops: 0000 [#1] PREEMPT SMP
[  199.698313] Modules linked in: ftdi_sio usbserial
[  199.698323]
[  199.698327] Pid: 1146, comm: ftdi_open Not tainted 3.2.11 #70 Dell Inc. Vostro 1520/0T816J
[  199.698339] EIP: 0060:[<f811a089>] EFLAGS: 00010286 CPU: 0
[  199.698344] EIP is at ftdi_open+0x59/0xe0 [ftdi_sio]
[  199.698348] EAX: 0000003e EBX: f5067000 ECX: 00000000 EDX: 80000600
[  199.698352] ESI: f48d8800 EDI: 00000001 EBP: f515dd54 ESP: f515dcfc
[  199.698356]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  199.698361] Process ftdi_open (pid: 1146, ti=f515c000 task=f481e040 task.ti=f515c000)
[  199.698364] Stack:
[  199.698368]  f811a9fe f811a9e0 f811b3ef 00000000 00000000 00001388 00000000 f4a86800
[  199.698387]  00000002 00000000 f806e68e 00000000 f532765c f481e040 00000246 22222222
[  199.698479]  22222222 22222222 22222222 f5067004 f5327600 f5327638 f515dd74 f806e6ab
[  199.698496] Call Trace:
[  199.698504]  [<f806e68e>] ? serial_activate+0x2e/0x70 [usbserial]
[  199.698511]  [<f806e6ab>] serial_activate+0x4b/0x70 [usbserial]
[  199.698521]  [<c126380c>] tty_port_open+0x7c/0xd0
[  199.698527]  [<f806e660>] ? serial_set_termios+0xa0/0xa0 [usbserial]
[  199.698534]  [<f806e76f>] serial_open+0x2f/0x70 [usbserial]
[  199.698540]  [<c125d07c>] tty_open+0x20c/0x510
[  199.698546]  [<c10e9eb7>] chrdev_open+0xe7/0x230
[  199.698553]  [<c10e48f2>] __dentry_open+0x1f2/0x390
[  199.698559]  [<c144bfec>] ? _raw_spin_unlock+0x2c/0x50
[  199.698565]  [<c10e4b76>] nameidata_to_filp+0x66/0x80
[  199.698570]  [<c10e9dd0>] ? cdev_put+0x20/0x20
[  199.698576]  [<c10f3e08>] do_last+0x198/0x730
[  199.698581]  [<c10f4440>] path_openat+0xa0/0x350
[  199.698587]  [<c10f47d5>] do_filp_open+0x35/0x80
[  199.698593]  [<c144bfec>] ? _raw_spin_unlock+0x2c/0x50
[  199.698599]  [<c10ff110>] ? alloc_fd+0xc0/0x100
[  199.698605]  [<c10f0b72>] ? getname_flags+0x72/0x120
[  199.698611]  [<c10e4450>] do_sys_open+0xf0/0x1c0
[  199.698617]  [<c11fcc08>] ? trace_hardirqs_on_thunk+0xc/0x10
[  199.698623]  [<c10e458e>] sys_open+0x2e/0x40
[  199.698628]  [<c144c990>] sysenter_do_call+0x12/0x36
[  199.698632] Code: 85 89 00 00 00 8b 16 8b 4d c0 c1 e2 08 c7 44 24 14 88 13 00 00 81 ca 00 00 00 80 c7 44 24 10 00 00 00 00 c7 44 24 0c 00 00 00 00 <0f> b7 41 78 31 c9 89 44 24 08 c7 44 24 04 00 00 00 00 c7 04 24
[  199.698884] EIP: [<f811a089>] ftdi_open+0x59/0xe0 [ftdi_sio] SS:ESP 0068:f515dcfc
[  199.698893] CR2: 0000000000000078
[  199.698925] ---[ end trace 77c43ec023940cff ]---

Reported-and-tested-by: Ken Huang <csuhgw@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoUHCI: hub_status_data should indicate if ports are resuming
Alan Stern [Tue, 3 Apr 2012 19:24:43 +0000]
UHCI: hub_status_data should indicate if ports are resuming

This patch (as1538) causes uhci_hub_status_data() to return a nonzero
value when any port is undergoing a resume transition while the root
hub is suspended.  This will allow usbcore to handle races between
root-hub suspend and port wakeup.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoEHCI: keep track of ports being resumed and indicate in hub_status_data
Alan Stern [Wed, 18 Apr 2012 14:55:45 +0000]
EHCI: keep track of ports being resumed and indicate in hub_status_data

This patch (as1537) adds a bit-array to ehci-hcd for keeping track of
which ports are undergoing a resume transition.  If any of the bits
are set when ehci_hub_status_data() is called, the routine will return
a nonzero value even if no ports have any status changes pending.
This will allow usbcore to handle races between root-hub suspend and
port wakeup.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
CC: Chen Peter-B29397 <B29397@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>



Change-Id: I30669c6e4ceb78c26209bcadf4d9647141741898

9 years agoUSB: fix race between root-hub suspend and remote wakeup
Alan Stern [Tue, 3 Apr 2012 19:24:18 +0000]
USB: fix race between root-hub suspend and remote wakeup

This patch (as1533) fixes a race between root-hub suspend and remote
wakeup.  If a wakeup event occurs while a root hub is suspending, it
might not cause the suspend to fail.  Although the host controller
drivers check for pending wakeup events at the start of their
bus_suspend routines, they generally do not check for wakeup events
while the routines are running.

In addition, if a wakeup event occurs any time after khubd is frozen
and before the root hub is fully suspended, it might not cause a
system sleep transition to fail.  For example, the host controller
drivers do not fail root-hub suspends when a connect-change event is

To fix both these issues, this patch causes hcd_bus_suspend() to query
the controller driver's hub_status_data method after a root hub is
suspended, if the root hub is enabled for wakeup.  Any pending status
changes will count as wakeup events, causing the root hub to be
resumed and the overall suspend to fail with -EBUSY.

A significant point is that not all events are reflected immediately
in the status bits.  Both EHCI and UHCI controllers notify the CPU
when remote wakeup begins on a port, but the port's suspend-change
status bit doesn't get set until after the port has completed the
transition out of the suspend state, some 25 milliseconds later.
Consequently, the patch will interpret any nonzero return value from
hub_status_data as indicating a pending event, even if none of the
status bits are set in the data buffer.  Follow-up patches make the
necessary changes to ehci-hcd and uhci-hcd.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
CC: Chen Peter-B29397 <B29397@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoUSB: sierra: add support for Sierra Wireless MC7710
Anton Samokhvalov [Wed, 4 Apr 2012 18:26:01 +0000]
USB: sierra: add support for Sierra Wireless MC7710

Just add new device id. 3G works fine, LTE not tested.

Signed-off-by: Anton Samokhvalov <pg83@yandex.ru>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoUSB: ftdi_sio: fix race condition in TIOCMIWAIT, and abort of TIOCMIWAIT when the...
Simon Arlott [Mon, 26 Mar 2012 22:27:59 +0000]
USB: ftdi_sio: fix race condition in TIOCMIWAIT, and abort of TIOCMIWAIT when the device is removed

There are two issues here, one is that the device is generating
spurious very fast modem status line changes somewhere:

CTS becomes high then low 18µs later:
[121226.924373] ftdi_process_packet: prev rng=0 dsr=10 dcd=0 cts=6
[121226.924378] ftdi_process_packet: status=10 prev=00 diff=10
[121226.924382] ftdi_process_packet: now rng=0 dsr=10 dcd=0 cts=7
(wake_up_interruptible is called)
[121226.924391] ftdi_process_packet: prev rng=0 dsr=10 dcd=0 cts=7
[121226.924394] ftdi_process_packet: status=00 prev=10 diff=10
[121226.924397] ftdi_process_packet: now rng=0 dsr=10 dcd=0 cts=8
(wake_up_interruptible is called)

This wakes up the task in TIOCMIWAIT:
[121226.924405] ftdi_ioctl: 19451 rng=0->0 dsr=10->10 dcd=0->0 cts=6->8
(wait from 20:51:46 returns and observes both changes)

Which then calls TIOCMIWAIT again:
20:51:46.400239 ioctl(3, TIOCMIWAIT, 0x20) = 0
22:11:09.441818 ioctl(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
22:11:09.442812 ioctl(3, TIOCMIWAIT, 0x20) = -1 EIO (Input/output error)
(the second wake_up_interruptible takes effect and an I/O error occurs)

The other issue is that TIOCMIWAIT will wait forever (unless the task is
interrupted) if the device is removed.

This change removes the -EIO return that occurs if the counts don't
appear to have changed. Multiple counts may have been processed as
one or the waiting task may have started waiting after recording the
current count.

It adds a bool to indicate that the device has been removed so that
TIOCMIWAIT doesn't wait forever, and wakes up any tasks so that they can
return -EIO.

Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoUSB: ftdi_sio: fix status line change handling for TIOCMIWAIT and TIOCGICOUNT
Simon Arlott [Mon, 26 Mar 2012 20:19:40 +0000]
USB: ftdi_sio: fix status line change handling for TIOCMIWAIT and TIOCGICOUNT

Handling of TIOCMIWAIT was changed by commit 1d749f9afa657f6ee9336b2bc1fcd750a647d157
 USB: ftdi_sio.c: Use ftdi async_icount structure for TIOCMIWAIT, as in other drivers

FTDI_STATUS_B0_MASK does not indicate the changed modem status lines,
it indicates the value of the current modem status lines. An xor is
still required to determine which lines have changed.

The count was only being incremented if the line was high. The only
reason TIOCMIWAIT still worked was because the status packet is
repeated every 1ms, so the count was always changing. The wakeup
itself still ran based on the status lines changing.

This change fixes handling of updates to the modem status lines and
allows multiple processes to use TIOCMIWAIT concurrently.

Tested with two processes waiting on different status lines being
toggled independently.

Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Cc: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoUSB: don't ignore suspend errors for root hubs
Alan Stern [Wed, 28 Mar 2012 19:56:17 +0000]
USB: don't ignore suspend errors for root hubs

This patch (as1532) fixes a mistake in the USB suspend code.  When the
system is going to sleep, we should ignore errors in powering down USB
devices, because they don't really matter.  The devices will go to low
power anyway when the entire USB bus gets suspended (except for
SuperSpeed devices; maybe they will need special treatment later).

However we should not ignore errors in suspending root hubs,
especially if the error indicates that the suspend raced with a wakeup
request.  Doing so might leave the bus powered on while the system was
supposed to be asleep, or it might cause the suspend of the root hub's
parent controller device to fail, or it might cause a wakeup request
to be ignored.

The patch fixes the problem by ignoring errors only when the device in
question is not a root hub.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Chen Peter <B29397@freescale.com>
CC: <stable@vger.kernel.org>
Tested-by: Chen Peter <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoUSB: fix bug in serial driver unregistration
Alan Stern [Wed, 28 Mar 2012 20:10:49 +0000]
USB: fix bug in serial driver unregistration

This patch (as1536) fixes a bug in the USB serial core.  Unloading and
reloading a serial driver while a serial device is plugged in causes
errors because of the code in usb_serial_disconnect() that tries to
make sure the port_remove method is called.  With the new order of
driver registration introduced in the 3.4 kernel, this is definitely
not the right thing to do (if indeed it ever was).

The patch removes that whole section code, along with the mechanism
for keeping track of each port's registration state, which is no
longer needed.  The driver core can handle all that stuff for us.

Note: This has been tested only with one or two USB serial drivers.
In theory, other drivers might still run into trouble.  But if they
do, it will be the fault of the drivers, not of this patch -- that is,
the drivers will need to be fixed.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoUSB: serial: metro-usb: Fix idProduct for Uni-Directional mode.
Aleksey Babahin [Mon, 19 Mar 2012 20:46:31 +0000]
USB: serial: metro-usb: Fix idProduct for Uni-Directional mode.

The right idProduct for Metrologic Bar Code Scanner
in Uni-Directional Serial Emulation mode is 0x0700.

Also rename idProduct for Bi-Directional mode to be a bit more informative.

Signed-off-by: Aleksey Babahin <tamerlan311@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoUSB: option: re-add NOVATELWIRELESS_PRODUCT_HSPA_HIGHSPEED to option_id array
Santiago Garcia Mantinan [Mon, 19 Mar 2012 17:17:00 +0000]
USB: option: re-add NOVATELWIRELESS_PRODUCT_HSPA_HIGHSPEED to option_id array


Signed-off-by: Santiago Garcia Mantinan <manty@debian.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoUSB: pl2303: fix DTR/RTS being raised on baud rate change
Johan Hovold [Fri, 23 Mar 2012 14:23:18 +0000]
USB: pl2303: fix DTR/RTS being raised on baud rate change

DTR/RTS should only be raised when changing baudrate from B0 and not on
any baud rate change (> B0).

Reported-by: Søren Holm <sgh@sgh.dk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoUSB: remove compile warning on gadget/inode.c
Michael BRIGHT [Thu, 22 Mar 2012 17:42:52 +0000]
USB: remove compile warning on gadget/inode.c

Removed unused "restart:" label, which was causing compiler warning.

Signed-off-by: Michael BRIGHT <mjbrightfr+git-kernel@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoUSB documentation: explain lifetime rules for unlinking URBs
Alan Stern [Wed, 28 Mar 2012 20:13:28 +0000]
USB documentation: explain lifetime rules for unlinking URBs

This patch (as1534c) updates the documentation for usb_unlink_urb and
related functions.  It explains that the caller must prevent the URB
being unlinked from getting deallocated while the unlink is taking

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoUSB: don't clear urb->dev in scatter-gather library
Alan Stern [Thu, 22 Mar 2012 15:00:21 +0000]
USB: don't clear urb->dev in scatter-gather library

This patch (as1517b) fixes an error in the USB scatter-gather library.
The library code uses urb->dev to determine whether or nor an URB is
currently active; the completion handler sets urb->dev to NULL.
However the core unlinking routines need to use urb->dev.  Since
unlinking always racing with completion, the completion handler must
not clear urb->dev -- it can lead to invalid memory accesses when a
transfer has to be cancelled.

This patch fixes the problem by getting rid of the lines that clear
urb->dev after urb has been submitted.  As a result we may end up
trying to unlink an URB that failed in submission or that has already
completed, so an extra check is added after each unlink to avoid
printing an error message when this happens.  The checks are updated
in both sg_complete() and sg_cancel(), and the second is updated to
match the first (currently it prints out unnecessary warning messages
if a device is unplugged while a transfer is in progress).

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Illia Zaitsev <I.Zaitsev@adbglobal.com>
CC: Ming Lei <tom.leiming@gmail.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agousb: storage: fix lockdep warning inside usb_stor_pre_reset(v2)
Ming Lei [Mon, 19 Mar 2012 07:20:57 +0000]
usb: storage: fix lockdep warning inside usb_stor_pre_reset(v2)

This patch fixes one lockdep warning[1] inside usb_stor_pre_reset.

If the current configuration includes multiple mass storage interfaces,
the 'AA' lockdep warning will be triggered since the lock class of
'us->dev_mutex' is acquired two times in .reset path. It isn't
a real deadlock, so just take the lockdep_set_class annotation to
remove the warning.

[1], lockdep warning log
:[ INFO: possible recursive locking detected ]
:3.3.0-0.rc5.git3.1.fc17.x86_64 #1 Tainted: G        W
:usb-storage/14846 is trying to acquire lock:
: (&(us->dev_mutex)){+.+.+.}, at: [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage]
:but task is already holding lock:
: (&(us->dev_mutex)){+.+.+.}, at: [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage]
:other info that might help us debug this:
: Possible unsafe locking scenario:
:       CPU0
:       ----
:  lock(&(us->dev_mutex));
:  lock(&(us->dev_mutex));
: *** DEADLOCK ***
: May be due to missing lock nesting notation
:2 locks held by usb-storage/14846:
: #0:  (&__lockdep_no_validate__){......}, at: [<ffffffff8147e6a5>] usb_lock_device_for_reset+0x95/0x100
: #1:  (&(us->dev_mutex)){+.+.+.}, at: [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage]
:stack backtrace:
:Pid: 14846, comm: usb-storage Tainted: G        W 3.3.0-0.rc5.git3.1.fc17.x86_64 #1
:Call Trace:
: [<ffffffff810cbdaf>] __lock_acquire+0x168f/0x1bb0
: [<ffffffff81021083>] ? native_sched_clock+0x13/0x80
: [<ffffffff810210f9>] ? sched_clock+0x9/0x10
: [<ffffffff810210f9>] ? sched_clock+0x9/0x10
: [<ffffffff810a2975>] ? sched_clock_local+0x25/0xa0
: [<ffffffff810cc9a1>] lock_acquire+0xa1/0x1e0
: [<ffffffffa0481c0c>] ? usb_stor_pre_reset+0x1c/0x20 [usb_storage]
: [<ffffffff81699c86>] mutex_lock_nested+0x76/0x3a0
: [<ffffffffa0481c0c>] ? usb_stor_pre_reset+0x1c/0x20 [usb_storage]
: [<ffffffffa0481c0c>] ? usb_stor_pre_reset+0x1c/0x20 [usb_storage]
: [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage]
: [<ffffffff8148184d>] usb_reset_device+0x7d/0x190
: [<ffffffffa048119c>] usb_stor_port_reset+0x7c/0x80 [usb_storage]
: [<ffffffffa0481234>] usb_stor_invoke_transport+0x94/0x560 [usb_storage]
: [<ffffffff810cd3b2>] ? mark_held_locks+0xb2/0x130
: [<ffffffff8169dbd0>] ? _raw_spin_unlock_irq+0x30/0x50
: [<ffffffffa047fe3e>] usb_stor_transparent_scsi_command+0xe/0x10 [usb_storage]
: [<ffffffffa0481ae3>] usb_stor_control_thread+0x173/0x280 [usb_storage]
: [<ffffffffa0481970>] ? fill_inquiry_response+0x20/0x20 [usb_storage]
: [<ffffffff8108a3f7>] kthread+0xb7/0xc0
: [<ffffffff816a7d34>] kernel_thread_helper+0x4/0x10
: [<ffffffff8169e0f4>] ? retint_restore_args+0x13/0x13
: [<ffffffff8108a340>] ? kthread_worker_fn+0x1a0/0x1a0
: [<ffffffff816a7d30>] ? gs_change+0x13/0x13

Reported-By: Dave Jones <davej@redhat.com>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agousb/usbmon: correct the data interpretation of usbmon's output
Sebastian Andrzej Siewior [Sat, 17 Mar 2012 14:23:49 +0000]
usb/usbmon: correct the data interpretation of usbmon's output

The doc says that the data
55534243 5e000000 00000000 00000600 00000000 00000000 00000000 000000
is the SCSI command 0x5e. According to the usbmon source, it dumps one
byte after the other. The first 4 bytes are US_BULK_CB_SIGN which is
correct. After that we see the TAG which is 0x5e. The cdb is 0x00 in
this example.
In order to correct this, I change the example to a READ_10 command
which is 0x28 so it is not just a zero somewhere in the stream.

Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agousb: Put USB Kconfig items back under USB.
David Daney [Thu, 22 Mar 2012 21:01:07 +0000]
usb: Put USB Kconfig items back under USB.

commit 53c6bc24fdc8db87109a5760579cbb060fa644cf (usb: Don't make
USB_ARCH_HAS_{XHCI,OHCI,EHCI} depend on USB_SUPPORT.)  Removed the
dependency of the USB_ARCH_HAS_* symbols on USB_SUPPORT.  However the
resulting Kconfig somehow caused many of the USB configuration items
to appear under the top level devices menu.

To fix this we reunite the 'menuconfig USB_SUPPORT' with the 'if
USB_SUPPORT', and the config items magically go back to their desired

Reported-by: Julian Wollrath <jwollrath@web.de>
Reported-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Reported-by: Borislav Petkov <bp@alien8.de>
Reported-by: Rupesh Gujare <rgujare@ozmodevices.com>
Reported-by: Feng King <ronyjin@tencent.com>
Reported-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: David Daney <david.daney@cavium.com>
Tested-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agopch_uart: Add Kontron COMe-mTT10 uart clock quirk
Michael Brunner [Fri, 23 Mar 2012 10:06:37 +0000]
pch_uart: Add Kontron COMe-mTT10 uart clock quirk

Add UART clock quirk for the Kontron COMe-mTT10 module.

The board has previously been called nanoETXexpress-TT, therefore this
is also checked.

As suggested by Darren Hart the comparison in this patch version is
placed after the FRI2 checks to ensure it will also work with possible
upcoming changes to the FRI2 firmware.

This patch follows the patchset submitted by Darren Hart at
commit a46f5533ecfc7bbdd646d84fdab8656031a715c6.

Signed-off-by: Michael Brunner <mibru@gmx.de>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agopch_uart: Fix MSI setting issue
Tomoya MORINAGA [Mon, 2 Apr 2012 05:36:22 +0000]
pch_uart: Fix MSI setting issue

The following patch (MSI setting) is not enough.

commit e463595fd9c752fa4bf06b47df93ef9ade3c7cf0
Author: Alexander Stein <alexander.stein@systec-electronic.com>
Date:   Mon Jul 4 08:58:31 2011 +0200

    pch_uart: Add MSI support

Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

To enable MSI mode, PCI bus-mastering must be enabled.
This patch enables the setting.

cc: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoserial/8250_pci: add a "force background timer" flag and use it for the "kt" serial...
Dan Williams [Fri, 6 Apr 2012 18:49:50 +0000]
serial/8250_pci: add a "force background timer" flag and use it for the "kt" serial port

Workaround dropped notifications in the iir register.  Register reads
coincident with new interrupt notifications sometimes result in this
device clearing the interrupt event without reporting it in the read

The serial core already has a heuristic for determining when a device
has an untrustworthy iir register.  In this case when we apriori know
that the iir is faulty use a flag (UPF_BUG_THRE) to bypass the test and
force usage of the background timer.

[stable: 3.3.x]
Acked-by: Alan Cox <alan@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Reported-by: Nhan H Mai <nhan.h.mai@intel.com>
Reported-by: Sudhakar Mamillapalli <sudhakar@fb.com>
Tested-by: Nhan H Mai <nhan.h.mai@intel.com>
Tested-by: Sudhakar Mamillapalli <sudhakar@fb.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoRevert "serial/8250_pci: setup-quirk workaround for the kt serial controller"
Dan Williams [Fri, 6 Apr 2012 18:49:44 +0000]
Revert "serial/8250_pci: setup-quirk workaround for the kt serial controller"

This reverts commit 448ac154c957c4580531fa0c8f2045816fe2f0e7.

The semantic of UPF_IIR_ONCE is only guaranteed to workaround the race
condition in the kt serial's iir register if the only source of
interrupts is THRE (fifo-empty) events.  An modem status event at the
wrong time can again cause an iir read to drop the 'empty' status
leading to a hang.  So, revert this in preparation for using the
existing "I don't trust my iir register" workaround in the 8250 core

[stable: 3.3.x]
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Cox <alan@linux.intel.com>
Cc: Sudhakar Mamillapalli <sudhakar@fb.com>
Reported-by: Nhan H Mai <nhan.h.mai@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoRevert "serial/8250_pci: init-quirk msi support for kt serial controller"
Dan Williams [Fri, 6 Apr 2012 18:49:37 +0000]
Revert "serial/8250_pci: init-quirk msi support for kt serial controller"

This reverts commit e86ff4a63c9fdd875ba8492577cd1ad2252f525c.

This tried to enforce the semantics of one interrupt per iir read of the
THRE (transmit-hold empty) status, but events from other sources
(particularly modem status) defeat this guarantee.

This change also broke 8250_pci suspend/resume support as
pciserial_resume_ports() re-runs .init() quirks, but does not run
.exit() quirks in pciserial_suspend_ports() leading to reports like:

  sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:16.3/msi_irqs'

...and a subsequent crash.  The mismatch of init/exit at suspend/resume
seems like a bug in its own right.

[stable: 3.3.x]
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Cox <alan@linux.intel.com>
Cc: Sudhakar Mamillapalli <sudhakar@fb.com>
Reported-by: Nhan H Mai <nhan.h.mai@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agotty/serial/omap: console can only be built-in
Arnd Bergmann [Mon, 2 Apr 2012 22:32:17 +0000]
tty/serial/omap: console can only be built-in

When the omap serial driver is built as a module, we must
not allow the console driver to be selected, because consoles
can not be loadable modules.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoserial: samsung: fix omission initialize ulcon in reset port fn()
Kukjin Kim [Wed, 4 Apr 2012 01:14:24 +0000]
serial: samsung: fix omission initialize ulcon in reset port fn()

Fix omission initialize ulcon in s3c24xx_serial_resetport(),
reset port function in drivers/tty/serial/samsung.c. It has
been happened from commit 0dfb3b41("serial: samsung: merge
all SoC specific port reset functions")

Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: stable <stable@vger.kernel.org> [3.3]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoprintk(): add KERN_CONT where needed in hpet and vt code
Kay Sievers [Tue, 3 Apr 2012 01:18:23 +0000]
printk(): add KERN_CONT where needed in hpet and vt code

A prototype for kmsg records instead of a byte-stream buffer revealed
a couple of missing printk(KERN_CONT ...) uses. Subsequent calls produce
one record per printk() call, while all should have ended up in a single

Instead of:
  ACPI: (supports S0 S5)
  ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
  hpet0: at MMIO 0xfed00000, IRQs 2 , 8 , 0

It prints:
  ACPI: (supports S0
  ACPI: PCI Interrupt Link [LNKA] (IRQs
  hpet0: at MMIO 0xfed00000, IRQs
  , 8
  , 0

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agotty/serial: atmel_serial: fix RS485 half-duplex problem
Siftar, Gabe [Thu, 29 Mar 2012 13:40:05 +0000]
tty/serial: atmel_serial: fix RS485 half-duplex problem

On our custom board, we are using RS485 in half-duplex mode on an AT91SAM9G45.
SER_RS485_RX_DURING_TX is not set as we do not want to receive the data we
transmit (our transceiver will receive transmitted data).
Although the current driver attempts to disable and enable the receiver at the
appropriate points, incoming data is still loaded into the receive register
causing our code to receive the very last byte that was sent once the receiver
is enabled.

I ran this by Atmel support and they wrote: "The issue comes from the fact
that you disable the PDC/DMA Reception and not the USART Reception channel. In
your case, the[n] you will still receive data into the USART_RHR register, and
maybe you [h]ave the overrun flag set. So please disable the USART reception

The following patch should force the driver to enable/disable the receiver via
RXEN/RXDIS fields of the USART control register. It fixed the issue I was

Signed-off-by: Gabe Siftar <gabe.siftar@getingeusa.com>
[nicolas.ferre@atmel.com: slightly modify commit message]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agotty: serial: altera_uart: Check for NULL platform_data in probe.
Yuriy Kozlov [Thu, 29 Mar 2012 07:55:27 +0000]
tty: serial: altera_uart: Check for NULL platform_data in probe.

Follow altera_jtag_uart.  This fixes a crash if there is a mistake in the DTS.

Signed-off-by: Yuriy Kozlov <ykozlov@ptcusa.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoisdn/gigaset: use gig_dbg() for debugging output
Tilman Schmidt [Sun, 25 Mar 2012 17:12:37 +0000]
isdn/gigaset: use gig_dbg() for debugging output

The "TTY buffer in tty_port" patchset introduced an opencoded
debug message in the Gigaset tty device if_close() function.
Change it to use the gig_dbg() macro like everywhere else in
the driver.

Signed-off-by: Tilman Schmidt <tilman@imap.cc>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoomap-serial: Fix the error handling in the omap_serial probe
Shubhrajyoti D [Wed, 21 Mar 2012 11:52:22 +0000]
omap-serial: Fix the error handling in the omap_serial probe

The patch does the following

- The pm_runtime_disable is called in the remove not in the error
  case of probe.The patch calls the pm_runtime_disable in the error
- Calls pm_runtime_put in the error case.
- The  up is not freed in the error path. Fix the memory leak by using
  devm_* so that the memory need not be freed in the driver.
- Also the iounmap is not called fix the same by calling using devm_ioremap.
- Make the name of the error tags more meaningful.

Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoserial: PL011: move interrupt clearing
Linus Walleij [Wed, 21 Mar 2012 19:15:18 +0000]
serial: PL011: move interrupt clearing

Commit 360f748b204275229f8398cb2f9f53955db1503b
"serial: PL011: clear pending interrupts"
attempts to clear interrupts by writing to a
yet-unassigned memory address. This fixes the issue.

The breaking patch is marked for stable so should be
carried along with the other patch.

Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: stable <stable@vger.kernel.org>
Cc: Nicolas Pitre <nico@fluxnic.net>
Reported-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agostaging: android: fix mem leaks in __persistent_ram_init()
Jesper Juhl [Wed, 11 Apr 2012 20:10:20 +0000]
staging: android: fix mem leaks in __persistent_ram_init()

If, in __persistent_ram_init(), the call to
persistent_ram_buffer_init() fails or the call to
persistent_ram_init_ecc() fails then we fail to free the memory we
allocated to 'prz' with kzalloc() - thus leaking it.

To prevent the leaks I consolidated all error exits from the function
at a 'err:' label at the end and made all error cases jump to that
label where we can then make sure we always free 'prz'. This is safe
since all the situations where the code bails out happen before 'prz'
has been stored anywhere and although we'll do a redundant kfree(NULL)
call in the case of kzalloc() itself failing that's OK since kfree()
deals gracefully with NULL pointers and I felt it was more important
to keep all error exits at a single location than to avoid that one
harmless/redundant kfree() on a error path.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Colin Cross <ccross@android.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agostaging: vt6656: Don't leak memory in drivers/staging/vt6656/ioctl.c::private_ioctl()
Jesper Juhl [Wed, 11 Apr 2012 22:35:46 +0000]
staging: vt6656: Don't leak memory in drivers/staging/vt6656/ioctl.c::private_ioctl()

If copy_to_user() fails in the WLAN_CMD_GET_NODE_LIST case of the
switch in drivers/staging/vt6656/ioctl.c::private_ioctl() we'll leak
the memory allocated to 'pNodeList'. Fix that by kfree'ing the memory
in the failure case.
Also remove a pointless cast (to type 'PSNodeList') of a kmalloc()
return value - kmalloc() returns a void pointer that is implicitly
converted, so there is no need for an explicit cast.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agostaging: iio: hmc5843: Fix crash in probe function.
Marek Belisko [Thu, 12 Apr 2012 19:48:03 +0000]
staging: iio: hmc5843: Fix crash in probe function.

Fix crash after issuing:
echo hmc5843 0x1e > /sys/class/i2c-dev/i2c-2/device/new_device

[   37.180999] device: '2-001e': device_add
[   37.188293] bus: 'i2c': add device 2-001e
[   37.194549] PM: Adding info for i2c:2-001e
[   37.200958] bus: 'i2c': driver_probe_device: matched device 2-001e with driver hmc5843
[   37.210815] bus: 'i2c': really_probe: probing driver hmc5843 with device 2-001e
[   37.224884] HMC5843 initialized
[   37.228759] ------------[ cut here ]------------
[   37.233612] kernel BUG at mm/slab.c:505!
[   37.237701] Internal error: Oops - BUG: 0 [#1] PREEMPT
[   37.243103] Modules linked in:
[   37.246337] CPU: 0    Not tainted  (3.3.1-gta04+ #28)
[   37.251647] PC is at kfree+0x84/0x144
[   37.255493] LR is at kfree+0x20/0x144
[   37.259338] pc : [<c00b408c>]    lr : [<c00b4028>]    psr: 40000093
[   37.259368] sp : de249cd8  ip : 0000000c  fp : 00000090
[   37.271362] r10: 0000000a  r9 : de229eac  r8 : c0236274
[   37.276855] r7 : c09d6490  r6 : a0000013  r5 : de229c00  r4 : de229c10
[   37.283691] r3 : c0f00218  r2 : 00000400  r1 : c0eea000  r0 : c00b4028
[   37.290527] Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   37.298095] Control: 10c5387d  Table: 9e1d0019  DAC: 00000015
[   37.304107] Process sh (pid: 91, stack limit = 0xde2482f0)
[   37.309844] Stack: (0xde249cd8 to 0xde24a000)
[   37.314422] 9cc0:                                                       de229c10 de229c00
[   37.322998] 9ce0: de229c10 ffffffea 00000005 c0236274 de140a80 c00b4798 dec00080 de140a80
[   37.331573] 9d00: c032f37c dec00080 000080d0 00000001 de229c00 de229c10 c048d578 00000005
[   37.340148] 9d20: de229eac 0000000a 00000090 c032fa40 00000001 00000000 00000001 de229c10
[   37.348724] 9d40: de229eac 00000029 c075b558 00000001 00000003 00000004 de229c10 c048d594
[   37.357299] 9d60: 00000000 60000013 00000018 205b0007 37332020 3432322e 5d343838 c0060020
[   37.365905] 9d80: de251600 00000001 00000000 de251600 00000001 c0065a84 de229c00 de229c48
[   37.374481] 9da0: 00000006 0048d62c de229c38 de229c00 de229c00 de1f6c00 de1f6c20 00000001
[   37.383056] 9dc0: 00000000 c048d62c 00000000 de229c00 de229c00 de1f6c00 de1f6c20 00000001
[   37.391632] 9de0: 00000000 c048d62c 00000000 c0330164 00000000 de1f6c20 c048d62c de1f6c00
[   37.400207] 9e00: c0330078 de1f6c04 c078d714 de189b58 00000000 c02ccfd8 de1f6c20 c0795f40
[   37.408782] 9e20: c0238330 00000000 00000000 c02381a8 de1b9fc0 de1f6c20 de1f6c20 de249e48
[   37.417358] 9e40: c0238330 c0236bb0 decdbed8 de7d0f14 de1f6c20 de1f6c20 de1f6c54 de1f6c20
[   37.425933] 9e60: 00000000 c0238030 de1f6c20 c078d7bc de1f6c20 c02377ec de1f6c20 de1f6c28
[   37.434509] 9e80: dee64cb0 c0236138 c047c554 de189b58 00000000 c004b45c de1f6c20 de1f6cd8
[   37.443084] 9ea0: c0edfa6c de1f6c00 dee64c68 de1f6c04 de1f6c20 dee64cb8 c047c554 de189b58
[   37.451690] 9ec0: 00000000 c02cd634 dee64c68 de249ef4 de23b008 dee64cb0 0000000d de23b000
[   37.460266] 9ee0: de23b007 c02cd78c 00000002 00000000 00000000 35636d68 00333438 00000000
[   37.468841] 9f00: 00000000 00000000 001e0000 00000000 00000000 00000000 00000000 0a10cec0
[   37.477416] 9f20: 00000002 de249f80 0000000d dee62990 de189b40 c0234d88 0000000d c010c354
[   37.485992] 9f40: 0000000d de210f28 000acc88 de249f80 0000000d de248000 00000000 c00b7bf8
[   37.494567] 9f60: de210f28 000acc88 de210f28 000acc88 00000000 00000000 0000000d c00b7ed8
[   37.503143] 9f80: 00000000 00000000 0000000d 00000000 0007fa28 0000000d 000acc88 00000004
[   37.511718] 9fa0: c000e544 c000e380 0007fa28 0000000d 00000001 000acc88 0000000d 00000000
[   37.520294] 9fc0: 0007fa28 0000000d 000acc88 00000004 00000001 00000020 00000002 00000000
[   37.528869] 9fe0: 00000000 beab8624 0000ea05 b6eaebac 600d0010 00000001 00000000 00000000
[   37.537475] [<c00b408c>] (kfree+0x84/0x144) from [<c0236274>] (device_add+0x530/0x57c)
[   37.545806] [<c0236274>] (device_add+0x530/0x57c) from [<c032fa40>] (iio_device_register+0x8c8/0x990)
[   37.555480] [<c032fa40>] (iio_device_register+0x8c8/0x990) from [<c0330164>] (hmc5843_probe+0xec/0x114)
[   37.565338] [<c0330164>] (hmc5843_probe+0xec/0x114) from [<c02ccfd8>] (i2c_device_probe+0xc4/0xf8)
[   37.574737] [<c02ccfd8>] (i2c_device_probe+0xc4/0xf8) from [<c02381a8>] (driver_probe_device+0x118/0x218)
[   37.584777] [<c02381a8>] (driver_probe_device+0x118/0x218) from [<c0236bb0>] (bus_for_each_drv+0x4c/0x84)
[   37.594818] [<c0236bb0>] (bus_for_each_drv+0x4c/0x84) from [<c0238030>] (device_attach+0x78/0xa4)
[   37.604125] [<c0238030>] (device_attach+0x78/0xa4) from [<c02377ec>] (bus_probe_device+0x28/0x9c)
[   37.613433] [<c02377ec>] (bus_probe_device+0x28/0x9c) from [<c0236138>] (device_add+0x3f4/0x57c)
[   37.622650] [<c0236138>] (device_add+0x3f4/0x57c) from [<c02cd634>] (i2c_new_device+0xf8/0x19c)
[   37.631805] [<c02cd634>] (i2c_new_device+0xf8/0x19c) from [<c02cd78c>] (i2c_sysfs_new_device+0xb4/0x130)
[   37.641754] [<c02cd78c>] (i2c_sysfs_new_device+0xb4/0x130) from [<c0234d88>] (dev_attr_store+0x18/0x24)
[   37.651611] [<c0234d88>] (dev_attr_store+0x18/0x24) from [<c010c354>] (sysfs_write_file+0x10c/0x140)
[   37.661193] [<c010c354>] (sysfs_write_file+0x10c/0x140) from [<c00b7bf8>] (vfs_write+0xb0/0x178)
[   37.670410] [<c00b7bf8>] (vfs_write+0xb0/0x178) from [<c00b7ed8>] (sys_write+0x3c/0x68)
[   37.678833] [<c00b7ed8>] (sys_write+0x3c/0x68) from [<c000e380>] (ret_fast_syscall+0x0/0x3c)
[   37.687683] Code: 1593301c e5932000 e3120080 1a000000 (e7f001f2)
[   37.700775] ---[ end trace aaf805debdb69390 ]---

Client data was assigned to iio_dev structure in probe but in
hmc5843_init_client function casted to private driver data structure which
is wrong. Possibly calling mutex_init(&data->lock); corrupt data
which the lead to above crash.

Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agostaging/xgifb: fix display on XGI Volari Z11m cards
Dmitry Eremin-Solenikov [Mon, 19 Mar 2012 17:50:09 +0000]
staging/xgifb: fix display on XGI Volari Z11m cards

Image on Z11m cards was totally garbled due to wrong memory being
selected. Add a special handling for Z11m cards. Tested on PCIe Z11 and
Z11m cards.

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoStaging: android: timed_gpio: Fix resource leak in timed_gpio_probe error paths
Axel Lin [Wed, 21 Mar 2012 01:24:57 +0000]
Staging: android: timed_gpio: Fix resource leak in timed_gpio_probe error paths

If gpio_request fails, we need to free all allocated resources.
Current code uses wrong array index to access gpio_data array.
So current code actually frees gpio_data[i].gpio by j times.

This patch moves the error handling code to err_out and thus improves

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoandroid: make persistent_ram based drivers depend on HAVE_MEMBLOCK
Colin Cross [Wed, 21 Mar 2012 17:18:33 +0000]
android: make persistent_ram based drivers depend on HAVE_MEMBLOCK

m68k doesn't have memblock_reserve, which causes a build failure
with allmodconfig.  Make PERSISTENT_RAM and RAM_CONSOLE depend on

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agostaging: iio: ak8975: Remove i2c client data corruption
Preetham Chandru [Wed, 18 Apr 2012 14:41:36 +0000]
staging: iio: ak8975: Remove i2c client data corruption

i2c client data set is of type struct indio_dev pointer and hence the
pointer returned from i2c_get_clientdata() should be assigned to
an object of type struct indio_dev and not to an object of type
struct ak8975_data.

Also in ak8975_probe() client data should be set first
before calling ak8975_setup() as it references the client data.

Signed-off-by: Preetham Chandru R <pchandru@nvidia.com>
CC: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>



Change-Id: Ia38ef9daf887d17ea290a9220b3ccd0218fcc533

9 years agostaging: drm/omap: move where DMM driver is registered
Rob Clark [Thu, 5 Apr 2012 15:34:56 +0000]
staging: drm/omap: move where DMM driver is registered

Not sure what triggered the change in behavior, but seems to
result in recursively acquiring a mutex and hanging on boot.  But
omap_drm_init() seems a much more sane place to register the
driver for the DMM sub-device.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agostaging: zsmalloc: fix memory leak
Nitin Gupta [Mon, 2 Apr 2012 14:13:56 +0000]
staging: zsmalloc: fix memory leak

This patch fixes a memory leak in zsmalloc where the first
subpage of each zspage is leaked when the zspage is freed.

Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Acked-by: Seth Jennings <sjenning@linux.vnet.ibm.com>
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoStaging: rts_pstor: off by one in for loop
Dan Carpenter [Thu, 29 Mar 2012 18:52:57 +0000]
Staging: rts_pstor: off by one in for loop

I already fixed the other similar for loop in this file.  I'm not sure
how I missed this one.  We use seg_no+1 inside the loop so we can't go
right up to the end of the loop.

Also if we don't break out of the loop then we end up past the end of
the array, but with this fix we end up on the last element.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agostaging: ozwpan: Added new maintainer for ozwpan
Chris Kelly [Thu, 29 Mar 2012 12:09:45 +0000]
staging: ozwpan: Added new maintainer for ozwpan

Added Rupesh Gujare to MAINTAINERS file and contact in TODO file
for ozwpan driver.

Signed-off-by: Chris Kelly <ckelly@ozmodevices.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agostaging:rts_pstor:Avoid "Bad target number" message when probing driver
wwang [Tue, 27 Mar 2012 08:43:20 +0000]
staging:rts_pstor:Avoid "Bad target number" message when probing driver

Avoid "Bad LUN" and "Bad target number" message by setting the supported
max_lun and max_id for the scsi host

Signed-off-by: wwang <wei_wang@realsil.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agostaging:rts_pstor:Fix possible panic by NULL pointer dereference
wwang [Tue, 27 Mar 2012 08:43:11 +0000]
staging:rts_pstor:Fix possible panic by NULL pointer dereference

rtsx_transport.c (rtsx_transfer_sglist_adma_partial):
pointer struct scatterlist *sg, which is mapped in dma_map_sg,
is used as an iterator in later transfer operation. It is corrupted and
passed to dma_unmap_sg, thus causing fatal unmap of some erroneous address.
Fix it by duplicating *sg_ptr for iterating.

Signed-off-by: wwang <wei_wang@realsil.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoStaging: vt6655-6: check keysize before memcpy()
Dan Carpenter [Thu, 29 Mar 2012 06:43:54 +0000]
Staging: vt6655-6: check keysize before memcpy()

We need to check the we don't copy too much memory.  This comes from a
copy_from_user() in the ioctl.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agostaging/media/as102: Don't call release_firmware() on uninitialized variable
Jesper Juhl [Sat, 24 Mar 2012 22:39:18 +0000]
staging/media/as102: Don't call release_firmware() on uninitialized variable

If, in drivers/staging/media/as102/as102_fw.c::as102_fw_upload(), the call
cmd_buf = kzalloc(MAX_FW_PKT_SIZE, GFP_KERNEL);
should fail and return NULL so that we jump to the 'error:' label,
then we'll end up calling 'release_firmware(firmware);' with
'firmware' still uninitialized - not good.

The easy fix is to just initialize 'firmware' to NULL when we declare
it, since release_firmware() deals gracefully with being passed NULL

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agostaging:iio:core add missing increment of loop index in iio_map_array_unregister()
Lothar Waßmann [Sat, 24 Mar 2012 06:19:25 +0000]
staging:iio:core add missing increment of loop index in iio_map_array_unregister()

staging:iio:core add missing increment of loop index in iio_map_array_unregister()

Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agostaging: ramster: unbreak my heart
Dan Magenheimer [Fri, 23 Mar 2012 16:40:15 +0000]
staging: ramster: unbreak my heart

The just-merged ramster staging driver was dependent on a cleanup patch in
cleancache, so was marked CONFIG_BROKEN until that patch could be
merged.  That cleancache patch is now merged (and the correct SHA of the
cleancache patch is 3167760f83899ccda312b9ad9306ec9e5dda06d4 rather than
the one shown in the comment removed in the patch below).

So remove the CONFIG_BROKEN now and the comment that is no longer true...

Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agostaging/vme: Fix module parameters
Gerard Snitselaar [Fri, 23 Mar 2012 10:21:05 +0000]
staging/vme: Fix module parameters

loopback should be declared bool, and variant probably shouldn't be

Signed-off-by: Gerard Snitselaar <dev@snitselaar.org>
Acked-by: Martyn Welch <martyn.welch@ge.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agostaging: sep: Fix sign of error
Alan Cox [Wed, 21 Mar 2012 12:32:32 +0000]
staging: sep: Fix sign of error

One of our errors wasn't negative as intended. Fix this.
(Found by Hillf Danton)

While we are at it turn user causable messages down to dev_dbg level in the
ioctl paths.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agokobject: provide more diagnostic info for kobject_add_internal() failures
Dan Williams [Fri, 6 Apr 2012 20:41:15 +0000]
kobject: provide more diagnostic info for kobject_add_internal() failures

1/ convert open-coded KERN_ERR+dump_stack() to WARN(), so that automated
   tools pick up this warning.

2/ include the 'child' and 'parent' kobject names.  This information was
   useful for tracking down the case where scsi invoked device_del() on a
   parent object and subsequently invoked device_add() on a child.  Now the
   warning looks like:

     kobject_add_internal failed for target8:0:16 (error: -2 parent: end_device-8:0:24)
     Pid: 2942, comm: scsi_scan_8 Not tainted 3.3.0-rc7-isci+ #2
     Call Trace:
      [<ffffffff8125e551>] kobject_add_internal+0x1c1/0x1f3
      [<ffffffff81075149>] ? trace_hardirqs_on+0xd/0xf
      [<ffffffff8125e659>] kobject_add_varg+0x41/0x50
      [<ffffffff8125e723>] kobject_add+0x64/0x66
      [<ffffffff8131124b>] device_add+0x12d/0x63a
      [<ffffffff8125e0ef>] ? kobject_put+0x4c/0x50
      [<ffffffff8132f370>] scsi_sysfs_add_sdev+0x4e/0x28a
      [<ffffffff8132dce3>] do_scan_async+0x9c/0x145

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: James Bottomley <JBottomley@parallels.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agosysfs: handle 'parent deleted before child added'
Dan Williams [Fri, 6 Apr 2012 20:41:06 +0000]
sysfs: handle 'parent deleted before child added'

In scsi at least two cases of the parent device being deleted before the
child is added have been observed.

1/ scsi is performing async scans and the device is removed prior to the
   async can thread running (can happen with an in-opportune / unlikely
   unplug during initial scan).

2/ libsas discovery event running after the parent port has been torn
   down (this is a bug in libsas).

Result in crash signatures like:
 BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
 IP: [<ffffffff8115e100>] sysfs_create_dir+0x32/0xb6
 Process scsi_scan_8 (pid: 5417, threadinfo ffff88080bd16000, task ffff880801b8a0b0)
  00000000fffffffe ffff880813470628 ffff88080bd17cd0 ffff88080614b7e8
  ffff88080b45c108 00000000fffffffe ffff88080bd17d20 ffffffff8125e4a8
  ffff88080bd17cf0 ffffffff81075149 ffff88080bd17d30 ffff88080614b7e8
 Call Trace:
  [<ffffffff8125e4a8>] kobject_add_internal+0x120/0x1e3
  [<ffffffff81075149>] ? trace_hardirqs_on+0xd/0xf
  [<ffffffff8125e641>] kobject_add_varg+0x41/0x50
  [<ffffffff8125e70b>] kobject_add+0x64/0x66
  [<ffffffff8131122b>] device_add+0x12d/0x63a

In this scenario the parent is still valid (because we have a
reference), but it has been device_del()'d which means its kobj->sd
pointer is NULL'd via:


...and then sysfs_create_dir() (without this fix) goes ahead and
de-references parent_sd via sysfs_ns_type():

 return (sd->s_flags & SYSFS_NS_TYPE_MASK) >> SYSFS_NS_TYPE_SHIFT;

This scenario is being fixed in scsi/libsas, but if other subsystems
present the same ordering the system need not immediately crash.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: James Bottomley <JBottomley@parallels.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agosysfs: Prevent crash on unset sysfs group attributes
Bruno Prémont [Tue, 3 Apr 2012 07:59:48 +0000]
sysfs: Prevent crash on unset sysfs group attributes

Do not let the kernel crash when a device is registered with
sysfs while group attributes are not set (aka NULL).

Warn about the offender with some information about the offending

This would warn instead of trying NULL pointer deref like:
 BUG: unable to handle kernel NULL pointer dereference at (null)
 IP: [<ffffffff81152673>] internal_create_group+0x83/0x1a0
 PGD 0
 Oops: 0000 [#1] SMP
 CPU 0
 Modules linked in:

 Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc1-x86_64 #3 HP ProLiant DL360 G4
 RIP: 0010:[<ffffffff81152673>]  [<ffffffff81152673>] internal_create_group+0x83/0x1a0
 RSP: 0018:ffff88019485fd70  EFLAGS: 00010202
 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000001
 RDX: ffff880192e99908 RSI: ffff880192e99630 RDI: ffffffff81a26c60
 RBP: ffff88019485fdc0 R08: 0000000000000000 R09: 0000000000000000
 R10: ffff880192e99908 R11: 0000000000000000 R12: ffffffff81a16a00
 R13: ffff880192e99908 R14: ffffffff81a16900 R15: 0000000000000000
 FS:  0000000000000000(0000) GS:ffff88019bc00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000000000000000 CR3: 0000000001a0c000 CR4: 00000000000007f0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process swapper/0 (pid: 1, threadinfo ffff88019485e000, task ffff880194878000)
  ffff88019485fdd0 ffff880192da9d60 0000000000000000 ffff880192e99908
  ffff880192e995d8 0000000000000001 ffffffff81a16a00 ffff880192da9d60
  0000000000000000 0000000000000000 ffff88019485fdd0 ffffffff811527be
 Call Trace:
  [<ffffffff811527be>] sysfs_create_group+0xe/0x10
  [<ffffffff81376ca6>] device_add_groups+0x46/0x80
  [<ffffffff81377d3d>] device_add+0x46d/0x6a0

Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agosysfs: Update the name hash for an entry after changing the namespace
Tom Goff [Wed, 4 Apr 2012 19:06:20 +0000]
sysfs: Update the name hash for an entry after changing the namespace

This is needed to allow renaming network devices that have been moved
to another network namespace.

Signed-off-by: Tom Goff <thomas.goff@boeing.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agodrivers/base: fix compiler warning in SoC export driver - idr should be ida
Lee Jones [Sat, 17 Mar 2012 09:17:49 +0000]
drivers/base: fix compiler warning in SoC export driver - idr should be ida

This fixes:
  note: expected ‘struct ida *’ but argument is of type ‘struct idr *’
  warning: passing argument 1 of ‘ida_pre_get’ from incompatible pointer type

Reported-by: Arnd Bergman <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agodrivers/base: Remove unneeded spin_lock_init call for soc_lock
Axel Lin [Tue, 20 Mar 2012 08:32:39 +0000]
drivers/base: Remove unneeded spin_lock_init call for soc_lock

soc_lock is already initialized by DEFINE_SPINLOCK.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

9 years agoirq_domain: fix type mismatch in debugfs output format
Grant Likely [Thu, 12 Apr 2012 20:42:15 +0000]
irq_domain: fix type mismatch in debugfs output format

sizeof(void*) returns an unsigned long, but it was being used as a width parameter to a "%-*s" format string which requires an int.  On 64 bit platforms this causes a type mismatch:

    linux/kernel/irq/irqdomain.c:575: warning: field width should have type
    'int', but argument 6 has type 'long unsigned int'

This change casts the size to an int so printf gets the right data type.

Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: David Daney <david.daney@cavium.com>

9 years agoperf tools: Fix getrusage() related build failure on glibc trunk
Markus Trippelsdorf [Wed, 4 Apr 2012 08:45:27 +0000]
perf tools: Fix getrusage() related build failure on glibc trunk

On a system running glibc trunk perf doesn't build:

CC builtin-sched.o
builtin-sched.c: In function ‘get_cpu_usage_nsec_parent’: builtin-sched.c:399:16: error: storage size of ‘ru’ isn’t known builtin-sched.c:403:2: error: implicit declaration of function ‘getrusage’ [-Werror=implicit-function-declaration]

Fix it by including sys/resource.h.

Signed-off-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20120404084527.GA294@x4
Signed-off-by: Ingo Molnar <mingo@kernel.org>

9 years agoRevert "clocksource: Load the ACPI PM clocksource asynchronously"
Thomas Gleixner [Wed, 11 Apr 2012 21:49:16 +0000]
Revert "clocksource: Load the ACPI PM clocksource asynchronously"

This reverts commit b519508298e0292e1771eecf14aaf67755adc39d.

The reason for this revert is that making the frequency verification
preemptible and interruptible is not working reliably. Michaels
machine failed to use PM-timer with the message:

  PM-Timer running at invalid rate: 113% of normal - aborting.

That's not a surprise as the frequency verification does rely on
interrupts being disabled. With a async scheduled thread there is no
guarantee to achieve the same result. Also some driver might fiddle
with the CTC channel 2 during the verification period, which makes the
result even more random and unpredictable.

This can be solved by using the same mechanism as we use in the
deferred TSC validation code, but that only will work if we verified a
working HPET _BEFORE_ trying to do the PM-Timer lazy validation.

So for now reverting is the safe option.

Bisected-by: Michael Witten <mfwitten@gmail.com>
Cc: Arjan van de Ven <arjanvandeven@gmail.com>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Len Brown <lenb@kernel.org>
LKML-Reference: <alpine.LFD.2.02.1204112303270.2542@ionos>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

9 years agoclockevents: tTack broadcast device mode change in tick_broadcast_switch_to_oneshot()
Suresh Siddha [Mon, 9 Apr 2012 22:41:44 +0000]
clockevents: tTack broadcast device mode change in tick_broadcast_switch_to_oneshot()

In the commit 77b0d60c5adf39c74039e2142a1d3cd1e4d53799,
"clockevents: Leave the broadcast device in shutdown mode when not needed",
we were bailing out too quickly in tick_broadcast_switch_to_oneshot(),
with out tracking the broadcast device mode change to 'TICKDEV_MODE_ONESHOT'.

This breaks the platforms which need broadcast device oneshot services during
deep idle states. tick_broadcast_oneshot_control() thinks that it is
in periodic mode and fails to take proper decisions based on the
CLOCK_EVT_NOTIFY_BROADCAST_[ENTER, EXIT] notifications during deep
idle entry/exit.

Fix this by tracking the broadcast device mode as 'TICKDEV_MODE_ONESHOT',
before leaving the broadcast HW device in shutdown mode if there are no active
requests for the moment.

Reported-and-tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: johnstul@us.ibm.com
Link: http://lkml.kernel.org/r/1334011304.12400.81.camel@sbsiddha-desk.sc.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

9 years agoitimer: Use printk_once instead of WARN_ONCE
Thomas Gleixner [Tue, 10 Apr 2012 08:50:55 +0000]
itimer: Use printk_once instead of WARN_ONCE

David pointed out, that WARN_ONCE() to report usage of an deprecated
misfeature make folks unhappy. Use printk_once() instead.

Andrew told me to stop grumbling and to remove the silly typecast
while touching the file.

Reported-by: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

9 years agonohz: Fix stale jiffies update in tick_nohz_restart()
Neal Cardwell [Tue, 27 Mar 2012 19:09:37 +0000]
nohz: Fix stale jiffies update in tick_nohz_restart()

Fix tick_nohz_restart() to not use a stale ktime_t "now" value when
calling tick_do_update_jiffies64(now).

If we reach this point in the loop it means that we crossed a tick
boundary since we grabbed the "now" timestamp, so at this point "now"
refers to a time in the old jiffy, so using the old value for "now" is
incorrect, and is likely to give us a stale jiffies value.

In particular, the first time through the loop the
tick_do_update_jiffies64(now) call is always a no-op, since the
caller, tick_nohz_restart_sched_tick(), will have already called
tick_do_update_jiffies64(now) with that "now" value.

Note that tick_nohz_stop_sched_tick() already uses the correct
approach: when we notice we cross a jiffy boundary, grab a new
timestamp with ktime_get(), and *then* update jiffies.

Signed-off-by: Neal Cardwell <ncardwell@google.com>
Cc: Ben Segall <bsegall@google.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1332875377-23014-1-git-send-email-ncardwell@google.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

9 years agotick: Document TICK_ONESHOT config option
Thomas Gleixner [Sat, 31 Mar 2012 10:45:43 +0000]
tick: Document TICK_ONESHOT config option

This option has been selected from arch code as it was assumed that
it's necessary to support oneshot mode clockevent devices. But it's
just a core internal helper to compile tick-oneshot.c if NOHZ or
HIG_RES_TIMERS are selected.

Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

9 years agoproc: stats: Use arch_idle_time for idle and iowait times if available
Martin Schwidefsky [Fri, 30 Mar 2012 10:23:08 +0000]
proc: stats: Use arch_idle_time for idle and iowait times if available

Git commit a25cac5198d4ff28 "proc: Consider NO_HZ when printing idle and
iowait times" changes the code for /proc/stat to use get_cpu_idle_time_us
and get_cpu_iowait_time_us if the system is running with nohz enabled.
For architectures which define arch_idle_time (currently s390 only)
this is a change for the worse. The result of arch_idle_time is supposed
to be the exact sleep time of the target cpu and should be used instead
of the value kept by the scheduler.

Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/20120330122308.18720283@de.ibm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

9 years agoitimer: Schedule silent NULL pointer fixup in setitimer() for removal
Sasikantha babu [Wed, 18 Apr 2012 14:33:40 +0000]
itimer: Schedule silent NULL pointer fixup in setitimer() for removal

setitimer() should return -EFAULT if called with an invalid pointer
for value. The current code excludes a NULL pointer from this rule and
silently uses it to stop the timer. This violates the spec.

Warn about user space apps which rely on that feature and schedule it
for removal.

[ tglx: Massaged changelog, warn message and Doc entry ]

Signed-off-by: Sasikantha babu <sasikanth.v19@gmail.com>
Link: http://lkml.kernel.org/r/1332340854-26053-1-git-send-email-sasikanth.v19@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>



Change-Id: Id0920441c09d32cf8375e58afb955add51325df9