Existing Intel xHCI controllers require a delay of 1 mS,
after setting the CMD_RESET bit in command register, before
accessing any HC registers. This allows the HC to complete
the reset operation and be ready for HC register access.
Without this delay, the subsequent HC register access,
may result in a system hang, very rarely.

Verified CherryView / Braswell platforms go through over
5000 warm reboot cycles (which was not possible without
this patch), without any xHCI reset hang.
Signed-off-by: NRajmohan Mani <rajmohan.mani@intel.com>
Tested-by: NJoe Lawrence <joe.lawrence@stratus.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

of_match_device could return NULL, and so cause a NULL pointer
dereference later.

Reported-by: coverity (CID 1324138)
Signed-off-by: NLABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>

of_match_device could return NULL, and so cause a NULL pointer
dereference later. Renaming tmp_dev to of_id (like all others do) in the
process.

Reported-by: coverity (CID 1324135)
Signed-off-by: NLABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>

This patch is to support load and unload gadget driver in full OTG mode.
Signed-off-by: NLi Jun <jun.li@freescale.com>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Tested-by: NJiada Wang <jiada_wang@mentor.com>
Cc: <stable@vger.kernel.org> #v4.0+

Since the ci->role will be set after the host role start is complete, there
will be nobody cared irq during start host if usb irq enabled. This error
can be reproduced on i.mx6 sololite EVK board by:
1. disable otg id irq(IDIE) and disable all real otg properties of usbotg1
   in dts.
2. boot up the board with ID cable and usb device connected.
3. echo gadget > /sys/kernel/debug/ci_hdrc.0/role
4. echo host > /sys/kernel/debug/ci_hdrc.0/role
5. irq 212: nobody cared.

Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: NLi Jun <jun.li@freescale.com>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>

Some i.mx platforms need three clocks to let controller work, but
others only need one, refine clock operation to adapt for all
platforms, it fixes a regression found at i.mx27.
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Tested-by: NFabio Estevam <fabio.estevam@freescale.com>
Cc: <stable@vger.kernel.org> #v4.1+

Following changes that appeared in lk 4.0.0, the gadget udc driver for
some ARM based Atmel SoCs (e.g. at91sam9x5 and sama5d3 families)
incorrectly deduced full-speed USB link speed even when the hardware
had negotiated a high-speed link. The fix is to make sure that the
UDPHS Interrupt Enable Register value does not mask the SPEED bit
in the Interrupt Status Register.

For a mass storage gadget this problem lead to failures when the host
had a USB 3 port with the xhci_hcd driver. If the host was a USB 2
port using the ehci_hcd driver then the mass storage gadget worked
(but probably at a lower speed than it should have).
Signed-off-by: NDouglas Gilbert <dgilbert@interlog.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Cc: <stable@vger.kernel.org> #4.0+
Fixes: 9870d895 ("usb: atmel_usba_udc: Mask status with enabled irqs")
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Change the permission of usb_dma parameter so it can
be used for runtime debug without reboot.
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

of_match_device could return NULL, and so cause a NULL pointer
dereference later.
Signed-off-by: NLABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In some SoCs, dwc3 is implemented as a USB2.0 only
core, meaning that it can't ever achieve SuperSpeed.

Currect driver always sets gadget.max_speed to
USB_SPEED_SUPER unconditionally. This can causes
issues to some Host stacks where the host will issue
a GetBOS() request and we will reply with a BOS
containing Superspeed Capability Descriptor.

At least Windows seems to be upset by this fact and
prints a warning that we should connect $this device
to another port.

[ balbi@ti.com : rewrote entire commit, including
source code comment to make a lot clearer what the
problem is ]

Cc: <stable@vger.kernel.org>
Signed-off-by: NBen McCauley <ben.mccauley@garmin.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Here are a few changes in musb_h_tx_flush_fifo().

- It has been observed that sometimes (if not always) musb is unable
  to flush tx fifo during urb dequeue when disconnect a device. But
  it seems to be harmless, since the tx fifo flush is done again in
  musb_ep_program() when re-use the hw_ep.

  But the WARN() floods the console in the case when multiple tx urbs
  are queued, so change it to dev_WARN_ONCE().

- applications could queue up many tx urbs, then the 1ms delay could
  causes minutes of delay in device disconnect. So remove it to get
  better user experience. The 1ms delay does not help the flushing
  anyway.

- cleanup the debug code - related to lastcsr.

----
Note: The tx fifo flush issue has been observed during device disconnect
on AM335x.

To reproduce the issue, ensure tx urb(s) are queued when unplug the usb
device which is connected to AM335x usb host port.

I found using a usb-ethernet device and running iperf (client on AM335x)
has very high chance to trigger the problem.

Better to turn on dev_dbg() in musb_cleanup_urb() with CPPI enabled to
see the issue when aborting the tx channel.
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The current code tries to allocate memory with GFP_KERNEL at
interrupt context, it would show below warning during the enumeration
when I test it with chipidea hardware, change GFP flag as GFP_ATOMIC
can fix this issue.

[   40.438237] zero gadget: high-speed config #2: loopback
[   40.444924] ------------[ cut here ]------------
[   40.449609] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2755 lockdep_trace_alloc+0x108/0x128()
[   40.461715] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
[   40.467130] Modules linked in:
[   40.470216]  usb_f_ss_lb g_zero libcomposite evbug
[   40.473822] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.3.0-rc5-00168-gb730aaf #604
[   40.481496] Hardware name: Freescale i.MX6 SoloX (Device Tree)
[   40.487345] Backtrace:
[   40.489857] [<80014e94>] (dump_backtrace) from [<80015088>] (show_stack+0x18/0x1c)
[   40.497445]  r6:80b67a80 r5:00000000 r4:00000000 r3:00000000
[   40.503234] [<80015070>] (show_stack) from [<802e27b4>] (dump_stack+0x8c/0xa4)
[   40.510503] [<802e2728>] (dump_stack) from [<8002cfe8>] (warn_slowpath_common+0x80/0xbc)
[   40.518612]  r6:8007510c r5:00000009 r4:80b49c88 r3:00000001
[   40.524396] [<8002cf68>] (warn_slowpath_common) from [<8002d05c>] (warn_slowpath_fmt+0x38/0x40)
[   40.533109]  r8:bcfdef80 r7:bdb705cc r6:000080d0 r5:be001e80 r4:809cc278
[   40.539965] [<8002d028>] (warn_slowpath_fmt) from [<8007510c>] (lockdep_trace_alloc+0x108/0x128)
[   40.548766]  r3:809d0128 r2:809cc278
[   40.552401]  r4:600b0193
[   40.554990] [<80075004>] (lockdep_trace_alloc) from [<801093d4>] (kmem_cache_alloc+0x28/0x15c)
[   40.563618]  r4:000080d0 r3:80b4aa8c
[   40.567270] [<801093ac>] (kmem_cache_alloc) from [<804d95e4>] (ep_alloc_request+0x58/0x68)
[   40.575550]  r10:7f01f104 r9:00000001 r8:bcfdef80 r7:bdb705cc r6:bc178700 r5:00000000
[   40.583512]  r4:bcfdef80 r3:813c0a38
[   40.587183] [<804d958c>] (ep_alloc_request) from [<7f01f7ec>] (loopback_set_alt+0x114/0x21c [usb_f_ss_lb])
[   40.596929] [<7f01f6d8>] (loopback_set_alt [usb_f_ss_lb]) from [<7f006910>] (composite_setup+0xbd0/0x17e8 [libcomposite])
[   40.607902]  r10:bd3a2c0c r9:00000000 r8:bcfdef80 r7:bc178700 r6:bdb702d0 r5:bcfdefdc
[   40.615866]  r4:7f0199b4 r3:00000002
[   40.619542] [<7f005d40>] (composite_setup [libcomposite]) from [<804dae88>] (udc_irq+0x784/0xd1c)
[   40.628431]  r10:80bb5619 r9:c0876140 r8:00012001 r7:bdb71010 r6:bdb70568 r5:00010001
[   40.636392]  r4:bdb70014
[   40.638985] [<804da704>] (udc_irq) from [<804d64f8>] (ci_irq+0x5c/0x118)
[   40.645702]  r10:80bb5619 r9:be11e000 r8:00000117 r7:00000000 r6:bdb71010 r5:be11e060
[   40.653666]  r4:bdb70010
[   40.656261] [<804d649c>] (ci_irq) from [<8007f638>] (handle_irq_event_percpu+0x7c/0x13c)
[   40.664367]  r6:00000000 r5:be11e060 r4:bdb05cc0 r3:804d649c
[   40.670149] [<8007f5bc>] (handle_irq_event_percpu) from [<8007f740>] (handle_irq_event+0x48/0x6c)
[   40.679036]  r10:00000000 r9:be008000 r8:00000001 r7:00000000 r6:bdb05cc0 r5:be11e060
[   40.686998]  r4:be11e000
[   40.689581] [<8007f6f8>] (handle_irq_event) from [<80082850>] (handle_fasteoi_irq+0xd4/0x1b0)
[   40.698120]  r6:80b56a30 r5:be11e060 r4:be11e000 r3:00000000
[   40.703898] [<8008277c>] (handle_fasteoi_irq) from [<8007ec04>] (generic_handle_irq+0x28/0x3c)
[   40.712524]  r7:00000000 r6:80b4aaf4 r5:00000117 r4:80b445fc
[   40.718304] [<8007ebdc>] (generic_handle_irq) from [<8007ef20>] (__handle_domain_irq+0x6c/0xe8)
[   40.727033] [<8007eeb4>] (__handle_domain_irq) from [<800095d4>] (gic_handle_irq+0x48/0x94)
[   40.735402]  r9:c080f100 r8:80b4ac6c r7:c080e100 r6:80b67d40 r5:80b49f00 r4:c080e10c
[   40.743290] [<8000958c>] (gic_handle_irq) from [<80015d38>] (__irq_svc+0x58/0x78)
[   40.750791] Exception stack(0x80b49f00 to 0x80b49f48)
[   40.755873] 9f00: 00000001 00000001 00000000 80024320 80b48000 80b4a9d0 80b4a984 80b433e4
[   40.764078] 9f20: 00000001 807f4680 00000000 80b49f5c 80b49f20 80b49f50 80071ca4 800113fc
[   40.772272] 9f40: 200b0013 ffffffff
[   40.775776]  r9:807f4680 r8:00000001 r7:80b49f34 r6:ffffffff r5:200b0013 r4:800113fc
[   40.783677] [<800113d4>] (arch_cpu_idle) from [<8006c5bc>] (default_idle_call+0x28/0x38)
[   40.791798] [<8006c594>] (default_idle_call) from [<8006c6dc>] (cpu_startup_entry+0x110/0x1b0)
[   40.800445] [<8006c5cc>] (cpu_startup_entry) from [<807e95dc>] (rest_init+0x12c/0x168)
[   40.808376]  r7:80b4a8c0 r3:807f4b7c
[   40.812030] [<807e94b0>] (rest_init) from [<80ad7cc0>] (start_kernel+0x360/0x3d4)
[   40.819528]  r5:80bcb000 r4:80bcb050
[   40.823171] [<80ad7960>] (start_kernel) from [<8000807c>] (0x8000807c)

It fixes commit 91c42b0d ("usb: gadget: loopback: Fix looping back
logic implementation").

Cc: <stable@vger.kernel.org> # v3.18+
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Reviewed-by: NKrzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In commit 734643df ("usb: dwc2: host: add flag to reflect bus
state") we changed dwc2_port_suspend() not to set the lx_state
anymore (instead it sets the new bus_suspended variable).  This
introduced a bug where we would fail to detect device insertions if:

1. Plug empty hub into dwc2
2. Plug USB flash drive into the empty hub.
3. Wait a few seconds
4. Unplug USB flash drive
5. Less than 2 seconds after step 4, plug the USB flash drive in again.

The dwc2_hcd_rem_wakeup() function should have been changed to look at
the new bus_suspended variable.

Let's fix it.  Since commit b46146d5 ("usb: dwc2: host: resume root
hub on remote wakeup") talks about needing the root hub resumed if the
bus was suspended, we'll include it in our test.

It appears that the "port_l1_change" should only be set to 1 if we were
in DWC2_L1 (the driver currently never sets this), so we'll update the
former "else" case based on this test.

Fixes: 734643df ("usb: dwc2: host: add flag to reflect bus state")
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Tested-by: NGregory Herrero <gregory.herrero@intel.com>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The comment for ahbcfg for rk3066 parameters (also used for rk3288)
claimed that ahbcfg was INCR16, but it wasn't.  Since the bits weren't
shifted properly, the 0x7 ended up being masked and we ended up
programming 0x3 for the HBstLen.  Let's set it to INCR16 properly.

As per Wu Liang Feng at Rockchip this may increase transmission
efficiency.  I did blackbox tests with writing 0s to a USB-based SD
reader (forcefully capping CPU Freq to try to measure efficiency):
  cd /sys/devices/system/cpu/cpu0/cpufreq
  echo userspace > scaling_governor
  echo 126000 > scaling_setspeed
  for i in $(seq 10); do
    dd if=/dev/zero of=/dev/sdb bs=1M count=750
  done

With the above tests I found that speeds went from ~15MB/s to ~18MB/s.
Note that most other tests I did (including reading from the same USB
reader) didn't show any difference in performance.
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Reviewed-by: NLiangfeng Wu <wulf@rock-chips.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

otg_dev->extcon was referenced before otg_dev was initialized. Fix.

Cc: <stable@vger.kernel.org> # v4.3
Fixes: a2fd2423 ("usb: phy: omap-otg: Replace deprecated API of extcon")
Reviewed-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

There is a bit of a mess in the order of arguments to the ulpi write
callback. There is

	int ulpi_write(struct ulpi *ulpi, u8 addr, u8 val)

in drivers/usb/common/ulpi.c;

	struct usb_phy_io_ops {
		...
		int (*write)(struct usb_phy *x, u32 val, u32 reg);
	}

in include/linux/usb/phy.h.

The callback registered by the musb driver has to comply to the latter,
but up to now had "offset" first which effectively made the function
broken for correct users. So flip the order and while at it also
switch to the parameter names of struct usb_phy_io_ops's write.

Fixes: ffb865b1 ("usb: musb: add ulpi access operations")
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

PCI IDs for Broxton based platforms.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

After merging the scsi tree, today's linux-next build (powerpc
allyesconfig) failed like this:

In file included from drivers/scsi/mpt3sas/mpt3sas_scsih.c:59:0:
drivers/scsi/mpt3sas/mpt3sas_scsih.c: In function '_scsih_io_done':
drivers/scsi/mpt3sas/mpt3sas_base.h:1414:1: error: inlining failed in call to always_inline 'mpt3sas_scsi_direct_io_get': function body not available
 mpt3sas_scsi_direct_io_get(struct MPT3SAS_ADAPTER *ioc, u16 smid);
 ^
drivers/scsi/mpt3sas/mpt3sas_scsih.c:4448:6: error: called from here
  if (mpt3sas_scsi_direct_io_get(ioc, smid) &&
      ^
In file included from drivers/scsi/mpt3sas/mpt3sas_scsih.c:59:0:
drivers/scsi/mpt3sas/mpt3sas_base.h:1416:1: error: inlining failed in call to always_inline 'mpt3sas_scsi_direct_io_set': function body not available
 mpt3sas_scsi_direct_io_set(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 direct_io);
 ^
drivers/scsi/mpt3sas/mpt3sas_scsih.c:4454:3: error: called from here
   mpt3sas_scsi_direct_io_set(ioc, smid, 0);
   ^
In file included from drivers/scsi/mpt3sas/mpt3sas_scsih.c:5
9:0:
drivers/scsi/mpt3sas/mpt3sas_base.h:1416:1: error: inlining failed in call to always_inline 'mpt3sas_scsi_direct_io_set': function body not available
 mpt3sas_scsi_direct_io_set(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 direct_io);
 ^
drivers/scsi/mpt3sas/mpt3sas_scsih.c:4454:3: error: called from here
   mpt3sas_scsi_direct_io_set(ioc, smid, 0);
   ^

Presumably caused by commit

  c84b06a4 ("mpt3sas: Single driver module which supports both SAS 2.0 & SAS 3.0 HBAs")
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

This reverts commit 52f5eb60.

Rockchip drm can't work with generic drm_of_component_probe now
Signed-off-by: NMark Yao <mark.yao@rock-chips.com>
Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Seems the crtc helpers call drm_calc_timestamping_constants()
unconditionally even if the driver didn't initialize vblank support by
calling drm_vblank_init(). That used to be OK since the constants were
stored under drm_crtc.

However I broke this with
commit eba1f35d ("drm: Move timestamping constants into drm_vblank_crtc")
when I moved the constants to live inside the drm_vblank_crtc struct
instead. If drm_vblank_init() isn't called, we don't allocate these
structures, and so drm_calc_timestamping_constants() will oops.

Fix it by adding a check into drm_calc_timestamping_constants() to see
if vblank support was initialized at all. And to keep in line with other
such checks, also toss in a check and warn for the case where vblank
support was initialized, but the wrong number of crtcs was specified.

Fixes the following sort of oops:
 BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0
 IP: [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm]
 PGD 0
 Oops: 0002 [#1] SMP
 Modules linked in: sr_mod cdrom mgag200(+) i2c_algo_bit drm_kms_helper ahci syscopyarea sysfillrect sysimgblt libahci fb_sys_fops bnx2x ttm tg3(+) mdio drm ptp sd_mod libata i2c_core pps_core libcrc32c hpsa dm_mirror dm_region_hash dm_log dm_mod
 CPU: 0 PID: 418 Comm: kworker/0:2 Not tainted 4.3.0+ #1
 Hardware name: HP ProLiant DL380 Gen9, BIOS P89 06/09/2015
 Workqueue: events work_for_cpu_fn
 task: ffff88046ca95500 ti: ffff88007830c000 task.ti: ffff88007830c000
 RIP: 0010:[<ffffffffa014b266>]  [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm]
 RSP: 0018:ffff88007830f4e8  EFLAGS: 00010246
 RAX: 0000000000fe4c00 RBX: ffff88006a849160 RCX: 0000000000000540
 RDX: 0000000000000000 RSI: 000000000000fde8 RDI: ffff88006a849000
 RBP: ffff88007830f518 R08: ffff88007830c000 R09: 00000001b87e3712
 R10: 00000000000050c4 R11: 0000000000000000 R12: 0000000000fe4c00
 R13: ffff88006a849000 R14: 0000000000000000 R15: 000000000000fde8
 FS:  0000000000000000(0000) GS:ffff88046f800000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00000000000000b0 CR3: 00000000019d6000 CR4: 00000000001406f0
 Stack:
  ffff88007830f518 ffff88006a849000 ffff880c69b90340 ffff880c69b90000
  ffff880c69b90348 ffff880c69b90340 ffff88007830f748 ffffffffa042f7e7
  ffff88006a849090 0000000000000000 ffff88006a849160 0000000000000000
 Call Trace:
  [<ffffffffa042f7e7>] drm_crtc_helper_set_mode+0x3d7/0x4b0 [drm_kms_helper]
  [<ffffffffa04307d4>] drm_crtc_helper_set_config+0x8d4/0xb10 [drm_kms_helper]
  [<ffffffffa01548d4>] drm_mode_set_config_internal+0x64/0x100 [drm]
  [<ffffffffa043c342>] drm_fb_helper_pan_display+0xa2/0x280 [drm_kms_helper]
  [<ffffffff81392c7b>] fb_pan_display+0xbb/0x170
  [<ffffffff8138cf70>] bit_update_start+0x20/0x50
  [<ffffffff8138b81b>] fbcon_switch+0x39b/0x590
  [<ffffffff8140a3d0>] redraw_screen+0x1a0/0x240
  [<ffffffff8140b30e>] do_bind_con_driver+0x2ee/0x310
  [<ffffffff8140b651>] do_take_over_console+0x141/0x1b0
  [<ffffffff81387377>] do_fbcon_takeover+0x57/0xb0
  [<ffffffff8138c98b>] fbcon_event_notify+0x60b/0x750
  [<ffffffff810a5599>] notifier_call_chain+0x49/0x70
  [<ffffffff810a58dd>] __blocking_notifier_call_chain+0x4d/0x70
  [<ffffffff810a5916>] blocking_notifier_call_chain+0x16/0x20
  [<ffffffff8139282b>] fb_notifier_call_chain+0x1b/0x20
  [<ffffffff81394881>] register_framebuffer+0x1f1/0x330
  [<ffffffffa043d9aa>] drm_fb_helper_initial_config+0x27a/0x3d0 [drm_kms_helper]
  [<ffffffffa0469b4d>] mgag200_fbdev_init+0xdd/0xf0 [mgag200]
  [<ffffffffa0468586>] mgag200_modeset_init+0x176/0x1e0 [mgag200]
  [<ffffffffa0464659>] mgag200_driver_load+0x3f9/0x580 [mgag200]
  [<ffffffffa014e067>] drm_dev_register+0xa7/0xb0 [drm]
  [<ffffffffa015054f>] drm_get_pci_dev+0x8f/0x1e0 [drm]
  [<ffffffffa046937b>] mga_pci_probe+0x9b/0xc0 [mgag200]
  [<ffffffff813662d5>] local_pci_probe+0x45/0xa0
  [<ffffffff8109afe4>] work_for_cpu_fn+0x14/0x20
  [<ffffffff8109e13c>] process_one_work+0x14c/0x3c0
  [<ffffffff8109eaa4>] worker_thread+0x244/0x470
  [<ffffffff8168bfba>] ? __schedule+0x2aa/0x760
  [<ffffffff8109e860>] ? rescuer_thread+0x310/0x310
  [<ffffffff810a4438>] kthread+0xd8/0xf0
  [<ffffffff810a4360>] ? kthread_park+0x60/0x60
  [<ffffffff8169030f>] ret_from_fork+0x3f/0x70
  [<ffffffff810a4360>] ? kthread_park+0x60/0x60
 Code: f6 31 d2 41 89 c2 8b 83 b4 00 00 00 0f af c1 48 98 48 69 c0 40 42 0f 00 48 f7 f6 f6 43 74 10 41 89 c4 75 26 f6 05 9a 6f 03 00 01 <45> 89 96 b0 00 00 00 45 89 a6 ac 00 00 00 75 35 48 83 c4 08 5b
 RIP  [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm]
  RSP <ffff88007830f4e8>
 CR2: 00000000000000b0

Cc: Jeff Moyer <jmoyer@redhat.com>
Reported-by: NJeff Moyer <jmoyer@redhat.com>
References: http://lists.freedesktop.org/archives/dri-devel/2015-November/094217.html
Fixes: eba1f35d ("drm: Move timestamping constants into drm_vblank_crtc")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This masking prevents access to the end of the device via dax_do_io(),
and is unnecessary as arch_add_memory() would have rejected an unaligned
allocation.

Cc: <stable@vger.kernel.org>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Rather than punt on the numa node for these e820 ranges try to find a
better answer with memory_add_physaddr_to_nid() when it is available.

Cc: <stable@vger.kernel.org>
Reported-by: NBoaz Harrosh <boaz@plexistor.com>
Tested-by: NBoaz Harrosh <boaz@plexistor.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Missing a include file caused compile error.

  drivers/thermal/rockchip_thermal.c: In function 'rockchip_thermal_suspend':
  drivers/thermal/rockchip_thermal.c:720:2: error: implicit declaration of function 'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration]
  ...

Fixes: 7e38a5b1 ("thermal: rockchip: support the sleep pinctrl state
to avoid glitches")
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NCaesar Wang <wxt@rock-chips.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

According to SPC-4, in a Mode Select, the PS bit in Mode Pages is
reserved and must be set to 0 by the driver.  In the sd implementation,
function cache_type_store does a Mode Sense, which might set the PS bit
on the read buffer, followed by a Mode Select, which receives the same
buffer, without explicitly clearing the PS bit.  So, in cases where
target supports saving the Mode Page to a non-volatile location, we end
up doing a Mode Select with the PS bit set, which could cause an illegal
request error if the target is checking this.

This was observed on a new firmware change, which was subsequently
reverted, but this changes sd.c to be more compliant with SPC-4.

This patch clears the PS bit in the buffer returned by Mode Select,
right before it is used in the Mode Select command.
Signed-off-by: NGabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

As defined in 4.6.9 of SAM-4, the encoding of LUN is
on 5 bits (max_lun=32) and the current value is only 8.
Set max_lun to IBMVSCSI_MAX_LUN (32).
Signed-off-by: NLaurent Vivier <lvivier@redhat.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

As devices with values greater than that are silently ignored,
this gives some hints to the sys admin to know why he doesn't see
his devices...
Signed-off-by: NLaurent Vivier <lvivier@redhat.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

There is a static checker warning here because "bytes" is controlled by
the user and we cap the upper bound with min() but allow negatives.
Negative bytes will result in some nasty warning messages but are not
super harmful.  Anyway, no one needs negative bytes so let's just check
for it and return NULL.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Replace the use of struct timeval and do_gettimeofday() with
64 bit ktime_get_real_seconds. Prevents 32-bit type overflow
in year 2038 on 32-bit systems.

Driver was using the seconds portion of struct timeval (.tv_secs)
to pass a millseconds timestamp to the firmware. This change maintains
that same behavior using ktime_get_real_seconds.

The structure used to pass the timestamp to firmware is 48 bits and
works fine as long as the top 16 bits are zero and they will be zero
for a long time..ie. thousands of years.

Alternative Change:  Add sub second granularity to timestamp

As noted above, the driver only used the seconds portion of timeval,
ignores the microseconds portion, and by multiplying by 1000 effectively
does a <<10 and always writes zero into timestamp[0].

The alternative change would pass all the bits to the firmware:

        struct timespec64 ts;

        ktime_get_real_ts64(&ts);
        timestamp = ts.tv_sec * MSEC_PER_SEC + ts.tv_nsec / NSEC_PER_MSEC;
Signed-off-by: NAlison Schofield <amsfield22@gmail.com>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

struct mvumi_hs_page2 stores a "seconds_since1970" field which is of
type u64. It is however, written to, using 'struct timeval' which has
a 32-bit seconds field and whose value will overflow in year 2038.
This patch uses ktime_get_real_seconds() instead since it provides a
64-bit seconds value, which is 2038 safe.
Signed-off-by: NTina Ruchandani <ruchandani.tina@gmail.com>
Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

drivers/scsi/be2iscsi/be_main.c: In function 'be_sgl_create_contiguous':
drivers/scsi/be2iscsi/be_main.c:3187:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
  WARN_ON(!length > 0);

gcc version 5.2.1
Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
Cc: Jayamohan Kallickal <jayamohan.kallickal@avagotech.com>
Cc: Minh Tran <minh.tran@avagotech.com>
Cc: John Soni Jose <sony.john-n@avagotech.com>
Cc: "James E.J. Bottomley" <JBottomley@odin.com>
Reported-by: NJoel Stanley <joel@jms.id.au>
Reviewed-by: NManoj Kumar <manoj@linux.vnet.ibm.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

The only user of scsi_prep_async_scan() is scsi_scan_host() and it
handles the situation correctly. Move 'called twice' reporting to debug
level as well.

The issue is observed on Hyper-V: on any device add/remove event storvsc
driver calls scsi_scan_host() and in case previous scan is still running
we get the message and stack dump on console.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: NK. Y. Srinivasan <kys@microsoft.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Bump mpt3sas driver version to 09.102.00.00
Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@avagotech.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Modified the mpt3sas driver to have a single driver module which
supports both SAS 2.0 & SAS 3.0 HBA devices.

* Added SAS 2.0 HBA device IDs to the mpt3sas_pci_table pci table.

* Created two separate SCSI host templates for SAS2 and SAS3 HBAs so
  that, during the driver load time driver can use corresponding host
  template(based the pci device ID) while registering a scsi host
  adapter instance for that pci device.

* Registered two IOCTL devices, mpt2ctl is for SAS2 HBAs & mpt3ctl for
  SAS3 HBAs. Also updated the code to make sure that mpt2ctl device
  processes only those ioctl cmds issued for the SAS2 HBAs and mpt3ctl
  device processes only those ioctl cmds issued for the SAS3 HBAs.

* Added separate indexing for SAS2 and SAS3 HBAs.

* Replaced compile time check 'MPT2SAS_SCSI' to run time check
  'hba_mpi_version_belonged' whereever needed.

* Aliased this merged driver to mpt2sas using MODULE_ALIAS.

* Moved global varaible 'driver_name' to per adapter instance variable.

* Created two raid function template and used corresponding raid
  function templates based on the run time check
  'hba_mpi_version_belonged'.

* Moved mpt2sas_warpdrive.c file from mpt2sas to mpt3sas folder and
  renamed it as mpt3sas_warpdrive.c.

* Also renamed the functions in mpt3sas_warpdrive.c file to follow
  current driver function name convention.

* Updated the Makefile to build mpt3sas_warpdrive.o file for these
  WarpDrive-specific functions.

* Also in function mpt3sas_setup_direct_io(), used sector_div() API
  instead of division operator (which gives compilation errors on 32 bit
  machines).

* Removed mpt2sas files, mpt2sas directory & mpt3sas_module.c file.

* Added module parameter 'hbas_to_enumerate' which permits using this
  merged driver as a legacy mpt2sas driver or as a legacy mpt3sas
  driver.

  Here are the available options for this module parameter:

   0 - Merged driver which enumerates both SAS 2.0 & SAS 3.0 HBAs
   1 - Acts as legacy mpt2sas driver, which enumerates only SAS 2.0 HBAs
   2 - Acts as legacy mpt3sas driver, which enumerates only SAS 3.0 HBAs

* Removed mpt2sas entries from SCSI's Kconfig and Makefile files.
Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@avagotech.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Bump the mpt2sas driver version to 20.102.00.00 and
Bump the mpt3sas driver version to 9.101.00.00.
Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@avagotech.com>
Acked-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

setpci reset on nytro warpdrive card along with sysfs access and cli
ioctl access resulted in kernel oops

1. pci_access_mutex lock added to provide synchronization between IOCTL,
   sysfs, PCI resource handling path

2. gioc_lock spinlock to protect list operations over multiple
   controllers

This patch is ported from commit 6229b414 ("mpt2sas: setpci reset
kernel oops fix").
Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@avagotech.com>
Acked-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Added OEM Gen2 PnP ID branding names from mpt2sas driver.
Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@avagotech.com>
Acked-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

The fw_event_work struct is concurrently referenced at shutdown. Add a
refcount to protect it and refactor the code to use it.

Additionally, refactor _scsih_fw_event_cleanup_queue() such that it no
longer iterates over the list without holding the lock since
_firmware_event_work() concurrently deletes items from the list.

This patch is ported from commit 008549f6 ("mpt2sas: Refcount
fw_events and fix unsafe list usage"). These changes are also required
for mpt3sas.
Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@avagotech.com>
Acked-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

sas_device objects can be referenced concurrently throughout the driver.
We need a way to make sure threads can't delete them out from under each
other. This patch adds the refcount and refactors the code to use it.

Additionally, we cannot iterate over the sas_device_list without holding
the lock or we risk corrupting random memory if items are added or
deleted as we iterate. This patch refactors _scsih_probe_sas() to use
the sas_device_list in a safe way.

This patch is ported from the following mpt2sas driver commit
d224fe0d ("mpt2sas: Refcount sas_device objects and fix unsafe list
usage").
Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@avagotech.com>
Acked-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

A new sysfs shost attribute called "BMR_status" is implemented to report
Backup Rail Monitor status.

This attribute is located in:

        /sys/class/scsi_host/host#/BMR_status

When reading this adapter attribute, the driver will output the state of
GPIO[24]. It returns "0" if BMR is healthy and "1" for failure.

If it returns an empty string then it means that there was an error
while obtaining the BMR status. Check dmesg for what error has occurred.

This sysfs shost attribute is mainly for WarpDrive controllers.

This commit is a port of 6c265660 ("mpt2sas: Provide sysfs attribute
to report Backup Rail Monitor Status").
Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@avagotech.com>
Acked-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Ported the following list of WarpDrive-specific patches:

1. commit 0bdccdb0 ("mpt2sas: WarpDrive
   New product SSS6200 support added")

2. commit 82a45258 ("mpt2sas: WarpDrive
   Infinite command retries due to wrong scsi command entry in MPI
   message")

3. commit ba96bd0b ("mpt2sas: Support
   for greater than 2TB capacity WarpDrive")

4. commit 4da7af94 ("mpt2sas: Do not
   retry a timed out direct IO for Warpdrive")

5. commit daeaa9df ("mpt2sas: Avoid type
   casting for direct I/O commands").

Also set the mpt2_ioctl_iocinfo adapter_type to:

1. MPT3_IOCTL_INTERFACE_SAS3 for Gen3 HBAs

2. MPT2_IOCTL_INTERFACE_SAS2_SSS6200 for Warp Drive

3. MPT2_IOCTL_INTERFACE_SAS2  for other Gen2 HBAs
Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@avagotech.com>
Acked-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>