linux-toradex.git/drivers, branch v4.9.58

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

target/iscsi: Fix unsolicited data seq_end_offset calculation

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

[ Upstream commit 4d65491c269729a1e3b375c45e73213f49103d33 ]

In case of unsolicited data for the first sequence
seq_end_offset must be set to minimum of total data length
and FirstBurstLength, so do not add cmd->write_data_done
to the min of total data length and FirstBurstLength.

This patch avoids that with ImmediateData=Yes, InitialR2T=No,
MaxXmitDataSegmentLength < FirstBurstLength that a WRITE command
with IO size above FirstBurstLength triggers sequence error
messages, for example

Set following parameters on target (linux-4.8.12)
ImmediateData = Yes
InitialR2T = No
MaxXmitDataSegmentLength = 8k
FirstBurstLength = 64k

Log in from Open iSCSI initiator and execute
dd if=/dev/zero of=/dev/sdb bs=128k count=1 oflag=direct

Error messages on target
Command ITT: 0x00000035 with Offset: 65536, Length: 8192 outside
of Sequence 73728:131072 while DataSequenceInOrder=Yes.
Command ITT: 0x00000035, received DataSN: 0x00000001 higher than
expected 0x00000000.
Unable to perform within-command recovery while ERL=0.

Signed-off-by: Varun Prakash 
[ bvanassche: Use min() instead of open-coding it / edited patch description ]
Signed-off-by: Bart Van Assche 
Signed-off-by: Nicholas Bellinger 

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

IB/hfi1: Allocate context data on memory node

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

[ Upstream commit b448bf9a0df6093dbadac36979a55ce4e012a677 ]

There are some memory allocation calls in hfi1_create_ctxtdata()
that do not use the numa function parameter. This
can cause cache lines to be filled over QPI.

Reviewed-by: Mike Marciniszyn 
Signed-off-by: Sebastian Sanchez 
Signed-off-by: Dennis Dalessandro 
Signed-off-by: Doug Ledford 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

IB/hfi1: Use static CTLE with Preset 6 for integrated HFIs

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

[ Upstream commit 39e2afa8d042a53d855137d4c5a689a6f5492b39 ]

After extended testing, it was found that the previous PCIe Gen
3 recipe, which used adaptive CTLE with Preset 4, could cause an
NMI/Surprise Link Down in about 1 in 100 to 1 in 1000 power cycles on
some platforms. New EV data combined with extensive empirical data
indicates that the new recipe should use static CTLE with Preset 6 for
all integrated silicon SKUs.

Fixes: c3f8de0b334c ("IB/hfi1: Add static PCIe Gen3 CTLE tuning")
Reviewed-by: Dennis Dalessandro 
Signed-off-by: Easwar Hariharan 
Signed-off-by: Dennis Dalessandro 
Signed-off-by: Doug Ledford 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

i2c: at91: ensure state is restored after suspending

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

[ Upstream commit e3ccc921b7d8fd1fcd10a00720e09823d8078666 ]

When going to suspend, the I2C registers may be lost because the power to
VDDcore is cut. Restore them when resuming.

Signed-off-by: Alexandre Belloni 
Acked-by: Ludovic Desroches 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman