linux-stable.git/drivers, branch v3.18.44

xhci: fix usb2 resume timing and races.

2016-10-22T20:43:20+00:00

[ Upstream commit f69115fdbc1ac0718e7d19ad3caa3da2ecfe1c96 ]

According to USB 2 specs ports need to signal resume for at least 20ms,
in practice even longer, before moving to U0 state.
Both host and devices can initiate resume.

On device initiated resume, a port status interrupt with the port in resume
state in issued. The interrupt handler tags a resume_done[port]
timestamp with current time + USB_RESUME_TIMEOUT, and kick roothub timer.
Root hub timer requests for port status, finds the port in resume state,
checks if resume_done[port] timestamp passed, and set port to U0 state.

On host initiated resume, current code sets the port to resume state,
sleep 20ms, and finally sets the port to U0 state. This should also
be changed to work in a similar way as the device initiated resume, with
timestamp tagging, but that is not yet tested and will be a separate
fix later.

There are a few issues with this approach

1. A host initiated resume will also generate a resume event. The event
   handler will find the port in resume state, believe it's a device
   initiated resume, and act accordingly.

2. A port status request might cut the resume signalling short if a
   get_port_status request is handled during the host resume signalling.
   The port will be found in resume state. The timestamp is not set leading
   to time_after_eq(jiffies, timestamp) returning true, as timestamp = 0.
   get_port_status will proceed with moving the port to U0.

3. If an error, or anything else happens to the port during device
   initiated resume signalling it will leave all the device resume
   parameters hanging uncleared, preventing further suspend, returning
   -EBUSY, and cause the pm thread to busyloop trying to enter suspend.

Fix this by using the existing resuming_ports bitfield to indicate that
resume signalling timing is taken care of.
Check if the resume_done[port] is set before using it for timestamp
comparison, and also clear out any resume signalling related variables
if port is not in U0 or Resume state

This issue was discovered when a PM thread busylooped, trying to runtime
suspend the xhci USB 2 roothub on a Dell XPS

Cc: stable 
Reported-by: Daniel J Blueman 
Tested-by: Daniel J Blueman 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

can: flexcan: fix resume function

2016-10-06T02:40:20+00:00

[ Upstream commit 4de349e786a3a2d51bd02d56f3de151bbc3c3df9 ]

On a imx6ul-pico board the following error is seen during system suspend:

dpm_run_callback(): platform_pm_resume+0x0/0x54 returns -110
PM: Device 2090000.flexcan failed to resume: error -110

The reason for this suspend error is because when the CAN interface is not
active the clocks are disabled and then flexcan_chip_enable() will
always fail due to a timeout error.

In order to fix this issue, only call flexcan_chip_enable/disable()
when the CAN interface is active.

Based on a patch from Dong Aisheng in the NXP kernel.

Signed-off-by: Fabio Estevam 
Cc: linux-stable 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Sasha Levin

USB: change bInterval default to 10 ms

2016-10-06T02:40:20+00:00

[ Upstream commit 08c5cd37480f59ea39682f4585d92269be6b1424 ]

Some full-speed mceusb infrared transceivers contain invalid endpoint
descriptors for their interrupt endpoints, with bInterval set to 0.
In the past they have worked out okay with the mceusb driver, because
the driver sets the bInterval field in the descriptor to 1,
overwriting whatever value may have been there before.  However, this
approach was never sanctioned by the USB core, and in fact it does not
work with xHCI controllers, because they use the bInterval value that
was present when the configuration was installed.

Currently usbcore uses 32 ms as the default interval if the value in
the endpoint descriptor is invalid.  It turns out that these IR
transceivers don't work properly unless the interval is set to 10 ms
or below.  To work around this mceusb problem, this patch changes the
endpoint-descriptor parsing routine, making the default interval value
be 10 ms rather than 32 ms.

Signed-off-by: Alan Stern 
Tested-by: Wade Berrier 
CC: 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

genirq: Generic chip: Change irq_reg_{readl,writel} arguments

2016-10-06T02:40:20+00:00

[ Upstream commit 332fd7c4fef5f3b166e93decb07fd69eb24f7998 ]

Pass in the irq_chip_generic struct so we can use different readl/writel
settings for each irqchip driver, when appropriate.  Compute
(gc->reg_base + reg_offset) in the helper function because this is pretty
much what all callers want to do anyway.

Compile-tested using the following configurations:

    at91_dt_defconfig (CONFIG_ATMEL_AIC_IRQ=y)
    sama5_defconfig (CONFIG_ATMEL_AIC5_IRQ=y)
    sunxi_defconfig (CONFIG_ARCH_SUNXI=y)

tb10x (ARC) is untested.

Signed-off-by: Kevin Cernekee 
Acked-by: Thomas Gleixner 
Acked-by: Acked-by: Arnd Bergmann 
Link: https://lkml.kernel.org/r/1415342669-30640-3-git-send-email-cernekee@gmail.com
Signed-off-by: Jason Cooper 
Signed-off-by: Sasha Levin

USB: serial: simple: add support for another Infineon flashloader

2016-10-06T02:40:20+00:00

[ Upstream commit f190fd92458da3e869b4e2c6289e2c617490ae53 ]

This patch adds support for Infineon flashloader 0x8087/0x0801.

The flashloader is used in Telit LE940B modem family with Telit
flashing application.

Signed-off-by: Daniele Palmas 
Cc: stable 
Signed-off-by: Johan Hovold 
Signed-off-by: Sasha Levin

xhci: fix null pointer dereference in stop command timeout function

2016-10-06T02:40:20+00:00

[ Upstream commit bcf42aa60c2832510b9be0f30c090bfd35bb172d ]

The stop endpoint command has its own 5 second timeout timer.
If the timeout function is triggered between USB3 and USB2 host
removal it will try to call usb_hc_died(xhci_to_hcd(xhci)->primary_hcd)

the ->primary_hcd will be set to NULL at USB3 hcd removal.

Fix this by first checking if the PCI host is being removed, and
also by using only xhci_to_hcd() as it will always return the primary
hcd.

CC: 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: renesas_usbhs: fix clearing the {BRDY,BEMP}STS condition

2016-10-06T02:40:20+00:00

[ Upstream commit 519d8bd4b5d3d82c413eac5bb42b106bb4b9ec15 ]

The previous driver is possible to stop the transfer wrongly.
For example:
 1) An interrupt happens, but not BRDY interruption.
 2) Read INTSTS0. And than state->intsts0 is not set to BRDY.
 3) BRDY is set to 1 here.
 4) Read BRDYSTS.
 5) Clear the BRDYSTS. And then. the BRDY is cleared wrongly.

Remarks:
 - The INTSTS0.BRDY is read only.
  - If any bits of BRDYSTS are set to 1, the BRDY is set to 1.
  - If BRDYSTS is 0, the BRDY is set to 0.

So, this patch adds condition to avoid such situation. (And about
NRDYSTS, this is not used for now. But, avoiding any side effects,
this patch doesn't touch it.)

Fixes: d5c6a1e024dd ("usb: renesas_usbhs: fixup interrupt status clear method")
Cc:  # v3.8+
Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin

iio: accel: kxsd9: Fix scaling bug

2016-10-06T02:40:20+00:00

[ Upstream commit 307fe9dd11ae44d4f8881ee449a7cbac36e1f5de ]

All the scaling of the KXSD9 involves multiplication with a
fraction number < 1.

However the scaling value returned from IIO_INFO_SCALE was
unpredictable as only the micros of the value was assigned, and
not the integer part, resulting in scaling like this:

$cat in_accel_scale
-1057462640.011978

Fix this by assigning zero to the integer part.

Cc: stable@vger.kernel.org
Tested-by: Jonathan Cameron 
Signed-off-by: Linus Walleij 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin

bus: arm-ccn: Fix XP watchpoint settings bitmask

2016-10-04T04:53:32+00:00

[ Upstream commit b928466b2169e061822daad48ecf55b005445547 ]

The code setting XP watchpoint comparator and mask registers should, in
order to be fully compliant with specification, zero one or more most
significant bits of each field. In both L cases it means zeroing bit 63.
The bitmask doing this was wrong, though, zeroing bit 60 instead.
Fortunately, due to a lucky coincidence, this turned out to be fairly
innocent with the existing hardware.

Fixed now.

Cc: stable@vger.kernel.org # 3.17+
Signed-off-by: Pawel Moll 
Signed-off-by: Sasha Levin

bus: arm-ccn: Do not attempt to configure XPs for cycle counter

2016-10-04T04:53:26+00:00

[ Upstream commit b7c1beb278e8e3dc664ed3df3fc786db126120a9 ]

Fuzzing the CCN perf driver revealed a small but definitely dangerous
mistake in the event setup code. When a cycle counter is requested, the
driver should not reconfigure the events bus at all, otherwise it will
corrupt (in most but the simplest cases) its configuration and may end
up accessing XP array out of its bounds and corrupting control
registers.

Reported-by: Mark Rutland 
Reviewed-by: Mark Rutland 
Tested-by: Mark Rutland 
Cc: stable@vger.kernel.org # 3.17+
Signed-off-by: Pawel Moll 
Signed-off-by: Sasha Levin