linux-toradex.git, branch v4.9.58

Linux 4.9.58

2017-10-21T15:21:39+00:00

usb: dwc3: gadget: Correct ISOC DATA PIDs for short packets

2017-10-21T15:21:39+00:00

commit 40d829fb2ec636b6b4b0cc95e2546ab9aca04cc9 upstream.

The PIDs for Isochronous data transfers are incorrect
for high bandwidth IN endpoints when the request length
is less than EP wMaxPacketSize.

As per spec correct PIDs for ISOC data transfers are:

1) For request length <= maxpacket
	- DATA0,

2) For maxpacket < length <= (2 * maxpacket)
	- DATA1, DATA0

3) For (2 * maxpacket) <  length <= (3 * maxpacket)
	- DATA2, DATA1, DATA0.

But driver always sets PCM fields based on wMaxPacketSize
due to which DATA2 happens even for small requests.

Fix this by setting the PCM field of trb->size depending
on request length rather than fixing it to the value
depending on wMaxPacketSize.

Ideally it shouldn't give any issues as dwc3 will send
0-length packet for next IN token if host sends (even
after receiving a short packet). Windows seems to ignore
this but with MacOS frame loss observed when using f_uvc.

Signed-off-by: Manu Gautam 
Signed-off-by: Felipe Balbi 
[b-liu@ti.com added following change for v4.9.]

-	unsigned int maxp = usb_endpoint_maxp(ep->desc);
+	unsigned int maxp;
+	maxp = usb_endpoint_maxp(ep->desc) & 0x07ff;

Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman

cpufreq: CPPC: add ACPI_PROCESSOR dependency

2017-10-21T15:21:38+00:00

[ Upstream commit a578884fa0d2768f13d37c6591a9e1ed600482d3 ]

Without the Kconfig dependency, we can get this warning:

warning: ACPI_CPPC_CPUFREQ selects ACPI_CPPC_LIB which has unmet direct dependencies (ACPI && ACPI_PROCESSOR)

Fixes: 5477fb3bd1e8 (ACPI / CPPC: Add a CPUFreq driver for use with CPPC)
Signed-off-by: Arnd Bergmann 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

EDAC, mce_amd: Print IPID and Syndrome on a separate line

2017-10-21T15:21:38+00:00

[ Upstream commit 75bf2f6478cab9b0c1d7f5f674a765d1e2ad530e ]

Currently, the IPID and Syndrome are printed on the same line as the
Address. There are cases when we can have a valid Syndrome but not a
valid Address.

For example, the MCA_SYND register can be used to hold more detailed
error info that the hardware folks can use. It's not just DRAM ECC
syndromes. There are some error types that aren't related to memory that
may have valid syndromes, like some errors related to links in the Data
Fabric, etc.

In these cases, the IPID and Syndrome are not printed at the same log
level as the rest of the stanza, so users won't see them on the console.

Console:
  [Hardware Error]: CPU:16 (17:1:0) MC22_STATUS[Over|CE|MiscV|-|-|-|-|SyndV|-]: 0xd82000000002080b
  [Hardware Error]: Power, Interrupts, etc. Extended Error Code: 2

Dmesg:
  [Hardware Error]: CPU:16 (17:1:0) MC22_STATUS[Over|CE|MiscV|-|-|-|-|SyndV|-]: 0xd82000000002080b
  , Syndrome: 0x000000010b404000, IPID: 0x0001002e00000002
  [Hardware Error]: Power, Interrupts, etc. Extended Error Code: 2

Print the IPID first and on a new line. The IPID should always be
printed on SMCA systems. The Syndrome will then be printed with the IPID
and at the same log level when valid:

  [Hardware Error]: CPU:16 (17:1:0) MC22_STATUS[Over|CE|MiscV|-|-|-|-|SyndV|-]: 0xd82000000002080b
  [Hardware Error]: IPID: 0x0001002e00000002, Syndrome: 0x000000010b404000
  [Hardware Error]: Power, Interrupts, etc. Extended Error Code: 2

Signed-off-by: Yazen Ghannam 
Cc: linux-edac 
Link: http://lkml.kernel.org/r/1487192182-2474-1-git-send-email-Yazen.Ghannam@amd.com
Signed-off-by: Borislav Petkov 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

btmrvl: avoid double-disable_irq() race

2017-10-21T15:21:38+00:00

[ Upstream commit 9af02d86e11dc409e5c3de46e81c0a492ba58905 ]

It's much the same as what we did for mwifiex in:
b9da4d2 mwifiex: avoid double-disable_irq() race

"We have a race where the wakeup IRQ might be in flight while we're
calling mwifiex_disable_wake() from resume(). This can leave us
disabling the IRQ twice.

Let's disable the IRQ and enable it in case if we have double-disabled
it."

Signed-off-by: Jeffy Chen 
Reviewed-by: Brian Norris 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

regulator: core: Resolve supplies before disabling unused regulators

2017-10-21T15:21:38+00:00

[ Upstream commit 3827b64dba27ebadb4faf51f2c91143e01ba1f6d ]

After commit 66d228a2bf03 ("regulator: core: Don't use regulators as
supplies until the parent is bound"), input supplies aren't resolved
if the input supplies parent device has not been bound. This prevent
regulators to hold an invalid reference if its supply parent device
driver probe is deferred.

But this causes issues on some boards where a PMIC's regulator use as
input supply a regulator from another PMIC whose driver is registered
after the driver for the former.

In this case the regulators for the first PMIC will fail to resolve
input supplies on regulators registration (since the other PMIC wasn't
probed yet). And when the core attempts to resolve again latter when
the other PMIC registers its own regulators, it will fail again since
the parent device isn't bound yet.

This will cause some parent supplies to never be resolved and wrongly
be disabled on boot due taking them as unused.

To solve this problem, also attempt to resolve the pending regulators
input supplies before disabling the unused regulators.

Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/gr/gf100-: fix ccache error logging

2017-10-21T15:21:38+00:00

[ Upstream commit 1894054dc1b6e4395048b2c0f28832a3f4320fd3 ]

Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

powerpc/perf: Add restrictions to PMC5 in power9 DD1

2017-10-21T15:21:38+00:00

[ Upstream commit 8d911904f3ce412b20874a9c95f82009dcbb007c ]

PMC5 on POWER9 DD1 may not provide right counts in all
sampling scenarios, hence use PM_INST_DISP event instead
in PMC2 or PMC3 in preference.

Signed-off-by: Madhavan Srinivasan 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

nfsd/callback: Cleanup callback cred on shutdown

2017-10-21T15:21:38+00:00

[ Upstream commit f7d1ddbe7648af7460d23688c8c131342eb43b3a ]

The rpccred gotten from rpc_lookup_machine_cred() should be put when
state is shutdown.

Signed-off-by: Kinglong Mee 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

hrtimer: Catch invalid clockids again

2017-10-21T15:21:38+00:00

[ Upstream commit 336a9cde10d641e70bac67d90ae91b3190c3edca ]

commit 82e88ff1ea94 ("hrtimer: Revert CLOCK_MONOTONIC_RAW support") removed
unfortunately a sanity check in the hrtimer code which was part of that
MONOTONIC_RAW patch series.

It would have caught the bogus usage of CLOCK_MONOTONIC_RAW in the wireless
code. So bring it back.

It is way too easy to take any random clockid and feed it to the hrtimer
subsystem. At best, it gets mapped to a monotonic base, but it would be
better to just catch illegal values as early as possible.

Detect invalid clockids, map them to CLOCK_MONOTONIC and emit a warning.

[ tglx: Replaced the BUG by a WARN and gracefully map to CLOCK_MONOTONIC ]

Signed-off-by: Marc Zyngier 
Cc: Tomasz Nowicki 
Cc: Christoffer Dall 
Link: http://lkml.kernel.org/r/1452879670-16133-3-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman