Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.217 2018-04-26T09:02:03+00:00 2018-04-26T09:02:03+00:00 Hector Martin marcan@marcan.st 2017-11-03T11:28:57+00:00 urn:sha1:4a5d70332d57bd473ffe76d8777a2e9f847c7863 [ Upstream commit 188775181bc05f29372b305ef96485840e351fde ] At least some JMicron controllers issue buggy oversized DMA reads when fetching context descriptors, always fetching 0x20 bytes at once for descriptors which are only 0x10 bytes long. This is often harmless, but can cause page faults on modern systems with IOMMUs: DMAR: [DMA Read] Request device [05:00.0] fault addr fff56000 [fault reason 06] PTE Read access is not set firewire_ohci 0000:05:00.0: DMA context IT0 has stopped, error code: evt_descriptor_read This works around the problem by always leaving 0x10 padding bytes at the end of descriptor buffer pages, which should be harmless to do unconditionally for controllers in case others have the same behavior. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2015-11-05T13:25:31+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2015-11-01T14:52:13+00:00 urn:sha1:a354cf00c71390c46927335fe20b65f38a528b59 software_reset() may fail - due to unresponsive chip with -EBUSY (-16), or - due to ejected or unseated card with -ENODEV (-19). Let the PCI probe and resume routines log the actual error code instead of hardwired -EBUSY. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2015-11-05T13:17:30+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2015-11-03T00:46:21+00:00 urn:sha1:100ceb66d5c40cc0c7018e06a9474302470be73c Reported by Clifford and Craig for JMicron OHCI-1394 + SDHCI combo controllers: Often or even most of the time, the controller is initialized with the message "added OHCI v1.10 device as card 0, 4 IR + 0 IT contexts, quirks 0x10". With 0 isochronous transmit DMA contexts (IT contexts), applications like audio output are impossible. However, OHCI-1394 demands that at least 4 IT contexts are implemented by the link layer controller, and indeed JMicron JMB38x do implement four of them. Only their IsoXmitIntMask register is unreliable at early access. With my own JMB381 single function controller I found: - I can reproduce the problem with a lower probability than Craig's. - If I put a loop around the section which clears and reads IsoXmitIntMask, then either the first or the second attempt will return the correct initial mask of 0x0000000f. I never encountered a case of needing more than a second attempt. - Consequently, if I put a dummy reg_read(...IsoXmitIntMaskSet) before the first write, the subsequent read will return the correct result. - If I merely ignore a wrong read result and force the known real result, later isochronous transmit DMA usage works just fine. So let's just fix this chip bug up by the latter method. Tested with JMB381 on kernel 3.13 and 4.3. Since OHCI-1394 generally requires 4 IT contexts at a minium, this workaround is simply applied whenever the initial read of IsoXmitIntMask returns 0, regardless whether it's a JMicron chip or not. I never heard of this issue together with any other chip though. I am not 100% sure that this fix works on the OHCI-1394 part of JMB380 and JMB388 combo controllers exactly the same as on the JMB381 single- function controller, but so far I haven't had a chance to let an owner of a combo chip run a patched kernel. Strangely enough, IsoRecvIntMask is always reported correctly, even though it is probed right before IsoXmitIntMask. Reported-by: Clifford Dunn Reported-by: Craig Moore <craig.moore@qenos.com> Cc: stable@vger.kernel.org Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2015-01-22T10:08:52+00:00 Rickard Strandqvist rickard_strandqvist@spectrumdigital.se 2015-01-02T21:02:43+00:00 urn:sha1:b625a825955ede39047e821f4b69f36cf042b952 Remove the function ar_prev_buffer_index() that is not used anywhere. This was partially found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2014-11-19T10:57:50+00:00 Clemens Ladisch clemens@ladisch.de 2014-11-16T20:08:49+00:00 urn:sha1:51b04d59c27430a57c347b55478415c342009035 vm_map_ram() is intended for short-lived objects, so using it for the AR buffers could fragment address space, especially on a 32-bit machine. For an allocation that lives as long as the device, vmap() is the better choice. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2014-07-27T16:42:06+00:00 Linus Torvalds torvalds@linux-foundation.org 2014-07-27T16:42:06+00:00 urn:sha1:2bdb5eb79bbb0403fd272d097b14ae649302b98d Pull firewire regression fix from Stefan Richter: "IEEE 1394 (FireWire) subsystem fix: MSI don't work on VIA PCIe controllers with some isochronous workloads (regression since v3.16-rc1)" * tag 'firewire-fix-vt6315' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: ohci: disable MSI for VIA VT6315 again 2014-07-23T18:11:19+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2014-07-23T18:08:12+00:00 urn:sha1:d584a66279949561418c82b12bb4c055e6c25836 Revert half of commit d151f9854f21: If isochronous I/O is attempted with packets larget than 1 kByte, VIA VT6315 rev 01 immediately stops to generate any interrupts if MSI are used. Fix this by going back to legacy interrupts. [Thread "Isochronous streaming with VT6315 OHCI", http://marc.info/?t=139049641500003] With smaller packets, the loss of IRQs happens too but only very rarely --- rarely eneough that it was not yet possible for me to determine whether QUIRK_NO_MSI is an actual fix for this rare variation of this chip bug. I am keeping QUIRK_CYCLE_TIMER off of VT6315 rev >= 1 because this has been verified by myself with certainty. On the other hand, I am also keeping QUIRK_CYCLE_TIMER on for VT6315 rev 0 because I don't know at this time whether this revision accesses Cycle Timer non-atomically like most of the other VIA OHCIs are known to do. Reported-by: Rémy Bruno <remy-fw@remy.trinnov.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2014-06-04T14:47:03+00:00 Linus Torvalds torvalds@linux-foundation.org 2014-06-04T14:47:03+00:00 urn:sha1:1b3636093d4e07f5fc8a8eb2f9a5e14a5a2674bf Pull firewire updates from Stefan Richter: "IEEE 1394 (FireWire) subsystem changes: One optimization for some VIA controllers, one fix, one kconfig brushup" * tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: ohci: enable MSI for VIA VT6315 rev 1, drop cycle timer quirk firewire: Use COMPILE_TEST for build testing firewire: net: fix NULL derefencing in fwnet_probe() 2014-06-03T19:57:53+00:00 Linus Torvalds torvalds@linux-foundation.org 2014-06-03T19:57:53+00:00 urn:sha1:776edb59317ada867dfcddde40b55648beeb0078 Pull core locking updates from Ingo Molnar: "The main changes in this cycle were: - reduced/streamlined smp_mb__*() interface that allows more usecases and makes the existing ones less buggy, especially in rarer architectures - add rwsem implementation comments - bump up lockdep limits" * 'locking-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (33 commits) rwsem: Add comments to explain the meaning of the rwsem's count field lockdep: Increase static allocations arch: Mass conversion of smp_mb__*() arch,doc: Convert smp_mb__*() arch,xtensa: Convert smp_mb__*() arch,x86: Convert smp_mb__*() arch,tile: Convert smp_mb__*() arch,sparc: Convert smp_mb__*() arch,sh: Convert smp_mb__*() arch,score: Convert smp_mb__*() arch,s390: Convert smp_mb__*() arch,powerpc: Convert smp_mb__*() arch,parisc: Convert smp_mb__*() arch,openrisc: Convert smp_mb__*() arch,mn10300: Convert smp_mb__*() arch,mips: Convert smp_mb__*() arch,metag: Convert smp_mb__*() arch,m68k: Convert smp_mb__*() arch,m32r: Convert smp_mb__*() arch,ia64: Convert smp_mb__*() ... 2014-05-29T17:02:22+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2014-04-15T23:08:08+00:00 urn:sha1:d151f9854f21fbb6a2df73553a27f9b664ecd10c Commit af0cdf494781 "firewire: ohci: fix regression with VIA VT6315, disable MSI" acted upon a report against VT6315 rev 0: http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02301.html $ lspci -nn VIA Technologies, Inc. VT6315 Series Firewire Controller [1106:3403] I now got a card with $ lspci -nn VIA Technologies, Inc. VT6315 Series Firewire Controller [1106:3403] (rev 01) and this works fine with MSI enabled. Second, I tested this VT6315 rev 1 without CYCLE_TIMER quirk flag using http://me.in-berlin.de/~s5r6/linux1394/utils/test_cycle_time_v20100125.c and found that this chip does in fact access the cycle timer atomically. Things I can't test because I don't have the hardware: - whether VT6315 rev 0 really needs QUIRK_CYCLE_TIMER, - whether the VT6320 PCI device needs QUIRK_CYCLE_TIMER, - whether the VT6325 and VT6330 PCIe devices need QUIRK_CYCLE_TIMER and QUIRK_NO_MSI. Hence, just add a whitelist entry specifically for VT6315 rev >= 1 without any quirk flags. Before this entry we need an extra entry to catch VT6315 rev <= 0 due to how our ID matching logic works. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>