XHCI ring changes have already been traced by the ring trace
events. It's unnecessary to put the same messages in kernel
log. This patch removes the debugging code for a ring.
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

enq_updates and deq_updates were introduced in the first place
to check whether an xhci hardware is able to respond to trbs
enqueued in the ring. We now have trb tracers to trace every
single enqueue/dequeue trb. It's time to remove them and the
associated debugging code.
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Omit extra messages for memory allocation failure.
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Several functions have a single user in the same file where it
is defined. There's no need to expose it anywhere else.
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci_dbg_ep_rings() isn't used in xhci driver anymore. Remove
it to reduce the module binary size.
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch creates a new event class called xhci_log_ring, and
defines the events used for tracing the change of all kinds of
rings used by an xhci host. An xHCI ring is basically a memory
block shared between software and hardware. By tracing changes
of rings, it makes the life easier for debugging hardware or
software problems.

This info can be used, later, to print, in a human readable way,
the life cycle of an xHCI ring using the trace-cmd tool and the
appropriate plugin.
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Introduce a new xhci_hc_died() function that takes care of handling
pending commands and URBs if a host controller becomes unresponsive.

This addresses issues on hotpluggable xhci controllers that disappear
from the bus suddenly, often while the bus (PCI) remove function is
still being processed.

xhci_hc_died() sets a XHCI_STATUS_DYING flag to prevent new URBs and
commands or to be queued. The flag also ensures xhci_hc_died() will
give back pending commands and URBs once.

Host is considered dead if register read returns 0xffffffff, or host
fails to abort the command ring, or fails stopping an endpoint after
trying for 5 seconds.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We can't halt the host controller immediately when first HCD is removed as
it will cause problems if we have devices attached to the second (primary)
HCD, like a keyboard.

We've been carrying this in our Linux-as-a-bootloader environment for a
little while now. The machines all have the same TI TUSB73x0 part,
and when we kexec the devices don't come back until a system power cycle.

[minor adjustments, code comments and remove HALT check  -Mathias]
Signed-off-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There's one annoyance in how xhci prints debug messages, we often
get logs with messages but it's hard to say from which device and
endpoint the message originates. Add slot_id, ep_index messages
in handle_tx_event.
Signed-off-by: NZhengjun Xing <zhengjun.xing@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Format for each TRB in each control transfer stage differs. Let's make
sure we correctly pretty print these fields to avoid confusion.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

With these, we can track what's happening with the HW while executing
each and every command. It will give us visibility into how the
different contexts are being modified by xHC which can bring insight
into problems while debugging.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

By extracting and exposing xhci_slot_state_string() in a header file, we
can re-use it to print Slot Context State from our tracepoints, which
can aid in tracking down problems related to command execution.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This will help us figuring out which device $this URB belongs to while
debugging.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For usb2 ports, the port test mode Test_J_State, Test_K_State,
Test_Packet, Test_SE0_NAK and Test_Force_En can be enabled
as described in usb2 spec.

USB2 test mode is a required hardware feature for system integrators
validating their hardware according to USB spec, regarding signal
strength and stuff. It is purely a hardware test feature.

Usually you need an oscilloscope and have to enable those test modes on
the hardware. This will send some specific test patterns on D+/D-. There
is no report available (in Linux itself) as it is purely externally
visible. Regular USB usage is not possible at that time.
Anyone (well access to e.g. /dev/bus/usb/001/001 provided) can use it by
sending appropriate USB_PORT_FEAT_TEST requests to the hub.

[Add better commit message by Alexander Stein  -Mathias]
Signed-off-by: NGuoqing Zhang <guoqing.zhang@intel.com>
Cc: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Change the visability of xhci_start() so that it
can be used when enabling test mode.
Signed-off-by: NGuoqing Zhang <guoqing.zhang@intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Refactoring slot disable related code into a helper
function xhci_disable_slot() which can be used when
enabling test mode.
Signed-off-by: NGuoqing Zhang <guoqing.zhang@intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Refactoring port power on/off related code into
a helper function xhci_set_power_on() which can
be reused when enabling test mode.

[set port state to neutral before writing port power -Mathias]
Signed-off-by: NGuoqing Zhang <guoqing.zhang@intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

EINT(Event Interrupt) is a write-1-to-clear type of bit in xhci
status register. It should be cleared by writing a 1. Writing 0
to this bit has no effect.

Xhci driver tries to clear this bit by writing 0 to it. This is
not the right way to go. This patch corrects this by reading the
register first, then clearing all RO/RW1C/RsvZ bits and setting
the clearing bit, and writing back the new value at last.

Xhci spec requires that software that uses EINT shall clear it
prior to clearing any IP flags in section 5.4.2. This is the
reason why this patch is CC'ed stable as well.

[old way didn't cause any issues, skip stable, send to next -Mathias]

Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

USB host controllers can take a significant amount of time to suspend
and resume, adding several hundred miliseconds to the kernel resume
time. Since the XHCI controller has no outside dependencies (other than
clocks, which are suspended late/resumed early), allow it to suspend and
resume asynchronously.
Signed-off-by: NAndrew Bresticker <abrestic@chromium.org>
Tested-by: NAndrew Bresticker <abrestic@chromium.org>
Tested-by: NRobert Foss <robert.foss@collabora.com>
Signed-off-by: NRobert Foss <robert.foss@collabora.com>
Reviewed-by: NBaolin Wang <baolin.wang@linaro.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

vhci_tx_urb() should be able to get the vhci_device from
its caller vhci_urb_enqueue(), instead of brutal-force
searching it.
Reviewed-by: NKrzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: NYuyang Du <yuyang.du@intel.com>
Acked-by: NShuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Code refactoring to make the flow easier to follow.
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add missing continue in switch.

Addresses-Coverity-ID: 1248733
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8c06e40 ("usb: separate out sysdev pointer from
usb_bus") converted to use hcd->self.sysdev for DMA
operations instead of hcd->self.controller but forgot to do
it for one instance.

This gets caught when DMA debugging is enabled since dma map
and unmap end up using different device pointers.

Fix it.

Fixes: a8c06e40 ("usb: separate out sysdev pointer from usb_bus")
Reported-by: NCarlos Hernandez <ceh@ti.com>
Acked-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The work-around for the Qualcomm Datacenter Technologies QDF2400
erratum 44 sets the "qdf2400_e44_present" global variable if the
work-around is needed.  However, this check does not happen until after
earlycon is initialized, which means the work-around is not
used, and the console hangs as soon as it displays one character.

Fixes: d8a4995b ("tty: pl011: Work around QDF2400 E44 stuck BUSY bit")
Signed-off-by: NTimur Tabi <timur@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

write_used was introduced with commit 884b600f ("[PATCH] USB: fix acm
trouble with terminals") but never used since.
Signed-off-by: NTobias Herzog <t-herzog@gmx.de>
Acked-by: NOliver Neukum <oneukum@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Adds a similar log message to USB_CDC_NOTIFY_SERIAL_STATE as it is
already done with USB_CDC_NOTIFY_NETWORK_CONNECTION.
Signed-off-by: NTobias Herzog <t-herzog@gmx.de>
Acked-by: NOliver Neukum <oneukum@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

USB devices may have very limited endpoint packet sizes, so that
notifications can not be transferred within one single usb packet.
Reassembling of multiple packages may be necessary.
Signed-off-by: NTobias Herzog <t-herzog@gmx.de>
Acked-by: NOliver Neukum <oneukum@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Notifications may only be 8 bytes long. Accessing the 9th and
10th byte of unimplemented/unknown notifications may be insecure.
Also check the length of known notifications before accessing anything
behind the 8th byte.
Signed-off-by: NTobias Herzog <t-herzog@gmx.de>
Acked-by: NOliver Neukum <oneukum@suse.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

kbuild test robot reported a non-static variable name collision between
a staging driver and a RapidIO driver, with a generic variable name of
'dbg_level'.

Both drivers should be changed so that they don't use this generic
public variable name.  This patch fixes the RapidIO driver but does not
change the user interface (name) for the module parameter.

  drivers/staging/built-in.o:(.bss+0x109d0): multiple definition of `dbg_level'
  drivers/rapidio/built-in.o:(.bss+0x16c): first defined here

Link: http://lkml.kernel.org/r/ab527fc5-aa3c-4b07-5d48-eef5de703192@infradead.orgSigned-off-by: NRandy Dunlap <rdunlap@infradead.org>
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Jérémy Lefaure <jeremy.lefaure@lse.epita.fr>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

In commit d0aeaa83 ("serial: exar:
split out the exar code from 8250_pci") the exar driver got its own
Kconfig.  However the text for the new option was never changed from
the original 8250_PCI text, and hence it appears confusing when you
get asked the same question twice:

  8250/16550 PCI device support (SERIAL_8250_PCI) [Y/n/m/?] (NEW)
    8250/16550 PCI device support (SERIAL_8250_EXAR) [Y/n/m] (NEW)

Adding to the confusion, is that there is no help text for this new
option to indicate it is specific to a certain family of cards.

Fix both issues at the same time, as well as the space vs. tab issues
introduced in the same commit.

Fixes: d0aeaa83 ("serial: exar: split out the exar code from 8250_pci")
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-serial@vger.kernel.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NSudip Mukherjee <sudipm.mukherjee@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A side effect of 89d82324 ("tty/serial: atmel_serial: BUG: stop DMA
from transmitting in stop_tx") is that the console can be called with
TX path disabled. Then the system would hang trying to push charecters
out in atmel_console_putchar().
Signed-off-by: NNicolas Ferre <nicolas.ferre@microchip.com>
Fixes: 89d82324 ("tty/serial: atmel_serial: BUG: stop DMA from transmitting
in stop_tx")
Cc: stable <stable@vger.kernel.org>	#4.4+
Acked-by: NRichard Genoud <richard.genoud@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If uart_flush_buffer() is called between atmel_tx_dma() and
atmel_complete_tx_dma(), the circular buffer has been cleared, but not
atmel_port->tx_len.
That leads to a circular buffer overflow (dumping (UART_XMIT_SIZE -
atmel_port->tx_len) bytes).
Tested-by: NNicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Cc: stable <stable@vger.kernel.org> # 3.12+
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The reference manual for the i.MX28 recommends to calculate the divisor
as

	divisor = (UARTCLK * 32) / baud rate, rounded to the nearest integer

, so let's do this. For a typical setup of UARTCLK = 24 MHz and baud
rate = 115200 this changes the divisor from 6666 to 6667 and so the
actual baud rate improves from 115211.521 Bd (error ≅ 0.01 %) to
115194.240 Bd (error ≅ 0.005 %).
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 4cfffcfa ("irqchip/mips-gic: Fix local interrupts") added
mapping of several local interrupts during initialisation of the gic
driver. This associates virq numbers with these interrupts.
Unfortunately, as not all of the interrupts are mapped in hardware
order, when drivers subsequently request these interrupts they conflict
with the mappings that have already been set up. For example, this
manifests itself in the gic clocksource driver, which fails to probe
with the message:

clocksource: GIC: mask: 0xffffffffffffffff max_cycles: 0x7350c9738,
max_idle_ns: 440795203769 ns
GIC timer IRQ 25 setup failed: -22

This is because virq 25 (the correct IRQ number specified via device
tree) was allocated to the PERFCTR interrupt (and 24 to the timer, 26 to
the FDC). To fix this, map all of these local interrupts in the hardware
order so as to associate their virq numbers with the correct hw
interrupts.

Fixes: 4cfffcfa ("irqchip/mips-gic: Fix local interrupts")
Acked-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

The controller has different timings for MMC_TIMING_UHS_DDR50 and
MMC_TIMING_MMC_DDR52. Configuring the controller with SDHCI_CTRL_UHS_DDR50,
when MMC_TIMING_MMC_DDR52 timings are requested, is not correct and can
lead to unexpected behavior.
Signed-off-by: NLudovic Desroches <ludovic.desroches@microchip.com>
Fixes: bb5f8ea4 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC")
Cc: <stable@vger.kernel.org> # 4.4+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

SDIO cards may need clock to send the card interrupt to the host.

On a cherrytrail tablet with a RTL8723BS wifi chip, without this patch
pinging the tablet results in:

PING 192.168.1.14 (192.168.1.14) 56(84) bytes of data.
64 bytes from 192.168.1.14: icmp_seq=1 ttl=64 time=78.6 ms
64 bytes from 192.168.1.14: icmp_seq=2 ttl=64 time=1760 ms
64 bytes from 192.168.1.14: icmp_seq=3 ttl=64 time=753 ms
64 bytes from 192.168.1.14: icmp_seq=4 ttl=64 time=3.88 ms
64 bytes from 192.168.1.14: icmp_seq=5 ttl=64 time=795 ms
64 bytes from 192.168.1.14: icmp_seq=6 ttl=64 time=1841 ms
64 bytes from 192.168.1.14: icmp_seq=7 ttl=64 time=810 ms
64 bytes from 192.168.1.14: icmp_seq=8 ttl=64 time=1860 ms
64 bytes from 192.168.1.14: icmp_seq=9 ttl=64 time=812 ms
64 bytes from 192.168.1.14: icmp_seq=10 ttl=64 time=48.6 ms

Where as with this patch I get:

PING 192.168.1.14 (192.168.1.14) 56(84) bytes of data.
64 bytes from 192.168.1.14: icmp_seq=1 ttl=64 time=3.96 ms
64 bytes from 192.168.1.14: icmp_seq=2 ttl=64 time=1.97 ms
64 bytes from 192.168.1.14: icmp_seq=3 ttl=64 time=17.2 ms
64 bytes from 192.168.1.14: icmp_seq=4 ttl=64 time=2.46 ms
64 bytes from 192.168.1.14: icmp_seq=5 ttl=64 time=2.83 ms
64 bytes from 192.168.1.14: icmp_seq=6 ttl=64 time=1.40 ms
64 bytes from 192.168.1.14: icmp_seq=7 ttl=64 time=2.10 ms
64 bytes from 192.168.1.14: icmp_seq=8 ttl=64 time=1.40 ms
64 bytes from 192.168.1.14: icmp_seq=9 ttl=64 time=2.04 ms
64 bytes from 192.168.1.14: icmp_seq=10 ttl=64 time=1.40 ms

Cc: Dong Aisheng <b29396@freescale.com>
Cc: Ian W MORRISON <ianwmorrison@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NDong Aisheng <aisheng.dong@nxp.com>
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Without this, the first modeset would dereference past the allocation
when trying to free the mm node.
Signed-off-by: NEric Anholt <eric@anholt.net>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170328201343.4884-1-eric@anholt.net
Fixes: d8dbf44f ("drm/vc4: Make the CRTCs cooperate on allocating display lists.")
Cc: <stable@vger.kernel.org> # v4.6+
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Commit a544c619 ("HID: wacom: do not attempt to switch mode
while in probe") introduces delayed work for querying (setting the
mode) on all tablets. Bamboo Touch (056a:00d0) has a ghost
interface which claims to be a pen device. Though this device can
be removed, we have to set the mode on the ghost pen interface
before we remove it. After the aforementioned delay was introduced
the device was being removed before the mode setting could be
executed.
Signed-off-by: NAaron Armstrong Skomra <aaron.skomra@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

A previous commit (below) adds a check for already probed interfaces to
Wacom's matching heuristic. Unfortunately this causes the Bamboo Pen
(CTL-460) to match itself to its 'ghost' touch interface. After
subsequent changes to the driver this match to the ghost causes the
kernel to crash. This patch avoids calling wacom_add_shared_data()
for the BAMBOO_PEN's ghost touch interface.

Fixes: 41372d5d ("HID: wacom: Augment 'oVid' and 'oPid' with heuristics for HID_GENERIC")
Cc: stable <stable@vger.kernel.org>     # 4.9
Signed-off-by: NAaron Armstrong Skomra <aaron.skomra@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

drv->cpumask defaults to cpu_possible_mask in __cpuidle_driver_init().
On PowerNV platform cpu_present could be less than cpu_possible in cases
where firmware detects the cpu, but it is not available to the OS.  When
CONFIG_HOTPLUG_CPU=n, such cpus are not hotplugable at runtime and hence
we skip creating cpu_device.

This breaks cpuidle on powernv where register_cpu() is not called for
cpus in cpu_possible_mask that cannot be hot-added at runtime.

Trying cpuidle_register_device() on cpu without cpu_device will cause
crash like this:

cpu 0xf: Vector: 380 (Data SLB Access) at [c000000ff1503490]
    pc: c00000000022c8bc: string+0x34/0x60
    lr: c00000000022ed78: vsnprintf+0x284/0x42c
    sp: c000000ff1503710
   msr: 9000000000009033
   dar: 6000000060000000
  current = 0xc000000ff1480000
  paca    = 0xc00000000fe82d00   softe: 0        irq_happened: 0x01
    pid   = 1, comm = swapper/8
Linux version 4.11.0-rc2 (sv@sagarika) (gcc version 4.9.4
(Buildroot 2017.02-00004-gc28573e) ) #15 SMP Fri Mar 17 19:32:02 IST 2017
enter ? for help
[link register   ] c00000000022ed78 vsnprintf+0x284/0x42c
[c000000ff1503710] c00000000022ebb8 vsnprintf+0xc4/0x42c (unreliable)
[c000000ff1503800] c00000000022ef40 vscnprintf+0x20/0x44
[c000000ff1503830] c0000000000ab61c vprintk_emit+0x94/0x2cc
[c000000ff15038a0] c0000000000acc9c vprintk_func+0x60/0x74
[c000000ff15038c0] c000000000619694 printk+0x38/0x4c
[c000000ff15038e0] c000000000224950 kobject_get+0x40/0x60
[c000000ff1503950] c00000000022507c kobject_add_internal+0x60/0x2c4
[c000000ff15039e0] c000000000225350 kobject_init_and_add+0x70/0x78
[c000000ff1503a60] c00000000053c288 cpuidle_add_sysfs+0x9c/0xe0
[c000000ff1503ae0] c00000000053aeac cpuidle_register_device+0xd4/0x12c
[c000000ff1503b30] c00000000053b108 cpuidle_register+0x98/0xcc
[c000000ff1503bc0] c00000000085eaf0 powernv_processor_idle_init+0x140/0x1e0
[c000000ff1503c60] c00000000000cd60 do_one_initcall+0xc0/0x15c
[c000000ff1503d20] c000000000833e84 kernel_init_freeable+0x1a0/0x25c
[c000000ff1503dc0] c00000000000d478 kernel_init+0x24/0x12c
[c000000ff1503e30] c00000000000b564 ret_from_kernel_thread+0x5c/0x78

This patch fixes the bug by passing correct cpumask from
powernv-cpuidle driver.
Signed-off-by: NVaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Reviewed-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
Acked-by: NMichael Ellerman <mpe@ellerman.id.au>
[ rjw: Comment massage ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>