- 17 Sep, 2014 15 commits
-
-
Thomas Petazzoni authored
commit e06871cd upstream. In commit f814f9ac ("spi/orion: add device tree binding"), Device Tree support was added to the spi-orion driver. However, this commit reads the "cell-index" property, without taking into account the fact that DT properties are big-endian encoded. Since most of the platforms using spi-orion with DT have apparently not used anything but cell-index = <0>, the problem was not visible. But as soon as one starts using cell-index = <1>, the problem becomes clearly visible, as the master->bus_num gets a wrong value (actually it gets the value 0, which conflicts with the first bus that has cell-index = <0>). This commit fixes that by using of_property_read_u32() to read the property value, which does the appropriate endianness conversion when needed. Fixes: f814f9ac ("spi/orion: add device tree binding") Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Joerg Roedel authored
commit 9b29d3c6 upstream. When multiple devices are detached in __detach_device, they are also removed from the domains dev_list. This makes it unsafe to use list_for_each_entry_safe, as the next pointer might also not be in the list anymore after __detach_device returns. So just repeatedly remove the first element of the list until it is empty. Tested-by:
Marti Raudsepp <marti@juffo.org> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Joerg Roedel authored
commit e7f9fa54 upstream. When the BUS_NOTIFY_DEL_DEVICE event is received the device might still be attached to a driver. In this case the domain can't be released as the mappings might still be in use. Defer the domain removal in this case until we receivce the BUS_NOTIFY_UNBOUND_DRIVER event. Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
Gavin Shan authored
commit 763fe0ad upstream. When we take full hotplug to recover from EEH errors, PCI buses could be involved. For the case, the child devices of involved PCI buses can't be attached to IOMMU group properly, which is caused by commit 3f28c5af ("powerpc/powernv: Reduce multi-hit of iommu_add_device()"). When adding the PCI devices of the newly created PCI buses to the system, the IOMMU group is expected to be added in (C). (A) fails to bind the IOMMU group because bus->is_added is false. (B) fails because the device doesn't have binding IOMMU table yet. bus->is_added is set to true at end of (C) and pdev->is_added is set to true at (D). pcibios_add_pci_devices() pci_scan_bridge() pci_scan_child_bus() pci_scan_slot() pci_scan_single_device() pci_scan_device() pci_device_add() pcibios_add_device() A: Ignore device_add() B: Ignore pcibios_fixup_bus() pcibios_setup_bus_devices() pcibios_setup_device() C: Hit pcibios_finish_adding_to_bus() pci_bus_add_devices() pci_bus_add_device() D: Add device If the parent PCI bus isn't involved in hotplug, the IOMMU group is expected to be bound in (B). (A) should fail as the sysfs entries aren't populated. The patch fixes the issue by reverting commit 3f28c5af and remove WARN_ON() in iommu_add_device() to allow calling the function even the specified device already has associated IOMMU group. Reported-by:
Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Acked-by:
Wei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Alex Williamson authored
commit c875d2c1 upstream. The user of the IOMMU API domain expects to have full control of the IOVA space for the domain. RMRRs are fundamentally incompatible with that idea. We can neither map the RMRR into the IOMMU API domain, nor can we guarantee that the device won't continue DMA with the area described by the RMRR as part of the new domain. Therefore we must prevent such devices from being used by the IOMMU API. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
Paul Bolle authored
commit 3c4b422a upstream. X-Patchwork-Delegate: mchehab@redhat.com Remove the CONFIG_ prefix from two Kconfig symbols in a dependency for SMS_SIANO_DEBUGFS. This prefix is invalid inside Kconfig files. Note that the current (common sense) dependency on SMS_USB_DRV and SMS_SDIO_DRV being equal ensures that SMS_SIANO_DEBUGFS will not violate its constraints. These constraint are that: - it should only be built if SMS_USB_DRV is set; - it can't be builtin if USB support is modular. So drop the dependency on SMS_USB_DRV, as it is unneeded. Fixes: 6c84b214 ("[media] sms: fix randconfig building error") Reported-by:
Martin Walch <walch.martin@web.de> Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by:
-
Laurent Pinchart authored
commit bd994ddb upstream. videobuf2 stores the driver streaming state internally in the queue in the start_streaming_called variable. The state is set right after the driver start_stream operation returns, and checked in the vb2_buffer_done() function, typically called from the frame completion interrupt handler. A race condition exists if the hardware finishes processing the first frame before the start_stream operation returns. Fix this by setting start_streaming_called to 1 before calling the start_stream operation, and resetting it to 0 if the operation fails. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Laurent Pinchart authored
commit e51daefc upstream. The field is assigned but never read, remove it. This fixes a bug caused by the struct vb2_buffer field not being be the very first field of the vsp1_video_buffer buffer structure as required by videobuf2. Reported-by:
Takanari Hayama <taki@igel.co.jp> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Philipp Zabel authored
commit f17bc3f4 upstream. Since (min_row_time - crop->width) can be negative, we have to do a signed comparison here. Otherwise max_t casts the negative value to unsigned int and sets min_hblank to that invalid value. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Salva Peiró authored
commit f8ca6ac0 upstream. After the zeroing the whole struct struct media_entity_desc u_ent, it is no longer necessary to memset(0) its u_ent.name field. Signed-off-by:
Salva Peiró <speiro@ai2.upv.es> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 64ea37bb upstream. It seems that there's a bug at au0828 hardware/firmware related to alternate setting: when the device is already at alt 5, a further call causes the URBs to receive -ESHUTDOWN. I found two different encarnations of this issue: 1) at qv4l2, it fails the second time we try to open the video screen; 2) at xawtv, when audio underrun occurs, with is very frequent, at least on my test machine. The fix is simple: just check if alt=5 before calling set_usb_interface(). Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 4c07e328 upstream. The programmed frequency on xc4000 is not the middle frequency, but the initial frequency on the bandwidth range. However, the DVB API works with the middle frequency. This works fine on set_frontend, as the device calculates the needed offset. However, at get_frequency(), the returned value is the initial frequency. That's generally not a big problem on most drivers, however, starting with changeset 6fe1099c, the frequency drift is taken into account at dib7000p driver. This broke support for PCTV 340e, with uses dib7000p demod and xc4000 tuner. Signed-off-by:
-
Mauro Carvalho Chehab authored
commit a3eec916 upstream. The programmed frequency on xc5000 is not the middle frequency, but the initial frequency on the bandwidth range. However, the DVB API works with the middle frequency. Signed-off-by:
-
Jan Kara authored
commit 01777836 upstream. If do_journal_release() races with do_journal_end() which requeues delayed works for transaction flushing, we can leave work items for flushing outstanding transactions queued while freeing them. That results in use after free and possible crash in run_timers_softirq(). Fix the problem by not requeueing works if superblock is being shut down (MS_ACTIVE not set) and using cancel_delayed_work_sync() in do_journal_release(). Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Jeff Mahoney authored
commit 27d0e5bc upstream. Commits f1f007c3 (reiserfs: balance_leaf refactor, pull out balance_leaf_insert_left) and cf22df18 (reiserfs: balance_leaf refactor, pull out balance_leaf_paste_left) missed that the `body' pointer was getting repositioned. Subsequent users of the pointer would expect it to be repositioned, and as a result, parts of the tree would get overwritten. The most common observed corruption is indirect block pointers being overwritten. Since the body value isn't actually used anymore in the called routines, we can pass back the offset it should be shifted. We constify the body and ih pointers in the balance_leaf as a mostly-free preventative measure. Reported-and-tested-by:
Jeff Chua <jeff.chua.linux@gmail.com> Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
-
- 05 Sep, 2014 25 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
commit a9ef803d upstream. commit bdd405d2 ("usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1") causes a build error if CONFIG_PM_RUNTIME is disabled. Fix that by doing a simple #ifdef guard around it. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Cc: Roger Quadros <rogerq@ti.com> Cc: Michael Welling <mwelling@emacinc.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Oleg Nesterov authored
commit 4449a51a upstream. Aleksei hit the soft lockup during reading /proc/PID/smaps. David investigated the problem and suggested the right fix. while_each_thread() is racy and should die, this patch updates vm_is_stack(). Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Reported-by:
Aleksei Besogonov <alex.besogonov@gmail.com> Tested-by:
David Rientjes <rientjes@google.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Trond Myklebust authored
commit aee7af35 upstream. In the presence of delegations, we can no longer assume that the state->n_rdwr, state->n_rdonly, state->n_wronly reflect the open stateid share mode, and so we need to calculate the initial value for calldata->arg.fmode using the state->flags. Reported-by:
James Drews <drews@engr.wisc.edu> Fixes: 88069f77 (NFSv41: Fix a potential state leakage when...) Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Trond Myklebust authored
commit 412f6c4c upstream. If we did an OPEN_DOWNGRADE, then the right thing to do on success, is to apply the new open mode to the struct nfs4_state. Instead, we were unconditionally clearing the state, making it appear to our state machinery as if we had just performed a CLOSE. Fixes: 226056c5 (NFSv4: Use correct locking when updating nfs4_state...) Signed-off-by:
-
Trond Myklebust authored
commit f87d928f upstream. When creating a new object on the NFS server, we should not be sending posix setacl requests unless the preceding posix_acl_create returned a non-trivial acl. Doing so, causes Solaris servers in particular to return an EINVAL. Fixes: 013cdf10 (nfs: use generic posix ACL infrastructure,,,) Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1132786Signed-off-by:
-
Chuck Lever authored
commit 3c45ddf8 upstream. The current code always selects XPRT_TRANSPORT_BC_TCP for the back channel, even when the forward channel was not TCP (eg, RDMA). When a 4.1 mount is attempted with RDMA, the server panics in the TCP BC code when trying to send CB_NULL. Instead, construct the transport protocol number from the forward channel transport or'd with XPRT_TRANSPORT_BC. Transports that do not support bi-directional RPC will not have registered a "BC" transport, causing create_backchannel_client() to fail immediately. Fixes: https://bugzilla.linux-nfs.org/show_bug.cgi?id=265Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Scott Mayhew authored
commit 71a6ec8a upstream. Commit c8e47028 made it possible to change resvport/noresvport and sharecache/nosharecache via a remount operation, neither of which should be allowed. Signed-off-by:
Scott Mayhew <smayhew@redhat.com> Fixes: c8e47028 (nfs: Apply NFS_MOUNT_CMP_FLAGMASK to nfs_compare_remount_data) Signed-off-by:
-
Andrey Utkin authored
commit 7a9e75a1 upstream. There was a check for result being not NULL. But get_acl() may return NULL, or ERR_PTR, or actual pointer. The purpose of the function where current change is done is to "list ACLs only when they are available", so any error condition of get_acl() mustn't be elevated, and returning 0 there is still valid. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81111Signed-off-by:
Andrey Utkin <andrey.krieger.utkin@gmail.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Fixes: 74adf83f (nfs: only show Posix ACLs in listxattr if actually...) Signed-off-by:
-
Kinglong Mee authored
commit d9499a95 upstream. A memory allocation failure could cause nfsd_startup_generic to fail, in which case nfsd_users wouldn't be incorrectly left elevated. After nfsd restarts nfsd_startup_generic will then succeed without doing anything--the first consequence is likely nfs4_start_net finding a bad laundry_wq and crashing. Signed-off-by:
Kinglong Mee <kinglongmee@gmail.com> Fixes: 4539f149 "nfsd: replace boolean nfsd_up flag by users counter" Signed-off-by:
-
Takashi Iwai authored
commit dd5f5006 upstream. The commit [5ee0f803: usbcore: don't log on consecutive debounce failures of the same port] added the check of the reliable port, but it also replaced the device argument to dev_err() wrongly, which leads to a NULL dereference. This patch restores the right device, port_dev->dev. Also, since dev_err() itself shows the port number, reduce the port number shown in the error message, essentially reverting to the state before the commit 5ee0f803. [The fix suggested by Hannes, and the error message cleanup suggested by Alan Stern] Fixes: 5ee0f803 ('usbcore: don't log on consecutive debounce failures of the same port') Reported-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Roger Quadros authored
commit bdd405d2 upstream. If user specifies that USB autosuspend must be disabled by module parameter "usbcore.autosuspend=-1" then we must prevent autosuspend of USB hub devices as well. commit 596d789a introduced in v3.8 changed the original behaivour and stopped respecting the usbcore.autosuspend parameter for hubs. Fixes: 596d789a "USB: set hub's default autosuspend delay as 0" Signed-off-by:
Roger Quadros <rogerq@ti.com> Tested-by:
Michael Welling <mwelling@emacinc.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Peter Chen authored
commit 5cbcc35e upstream. The roothub's index per controller is from 0, but the hub port index per hub is from 1, this patch fixes "can't find device at roohub" problem for connecting test fixture at roohub when do USB-IF Embedded Host High-Speed Electrical Test. This patch is for v3.12+. Signed-off-by:
Peter Chen <peter.chen@freescale.com> Acked-by:
-
James Forshaw authored
commit 6817ae22 upstream. This patch fixes a potential security issue in the whiteheat USB driver which might allow a local attacker to cause kernel memory corrpution. This is due to an unchecked memcpy into a fixed size buffer (of 64 bytes). On EHCI and XHCI busses it's possible to craft responses greater than 64 bytes leading a buffer overflow. Signed-off-by:
James Forshaw <forshaw@google.com> Signed-off-by:
-
Jaša Bartelj authored
commit 646907f5 upstream. Added support to the ftdi_sio driver for ekey Converter USB which uses an FT232BM chip. Signed-off-by:
Jaša Bartelj <jasa.bartelj@gmail.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
commit 6552cc7f upstream. Add device id for Basic Micro ATOM Nano USB2Serial adapters. Reported-by:
Nicolas Alt <n.alt@mytum.de> Tested-by:
-
Tony Lindgren authored
commit cc824534 upstream. Looks like MUSB cable removal can cause wake-up interrupts to stop working for device tree based booting at least for UART3 even as nothing is dynamically remuxed. This can be fixed by calling reconfigure_io_chain() for device tree based booting in hwmod code. Note that we already do that for legacy booting if the legacy mux is configured. My guess is that this is related to UART3 and MUSB ULPI hsusb0_data0 and hsusb0_data1 support for Carkit mode that somehow affect the configured IO chain for UART3 and require rearming the wake-up interrupts. In general, for device tree based booting, pinctrl-single calls the rearm hook that in turn calls reconfigure_io_chain so calling reconfigure_io_chain should not be needed from the hwmod code for other events. So let's limit the hwmod rearming of iochain only to HWMOD_FORCE_MSTANDBY where MUSB is currently the only user of it. If we see other devices needing similar changes we can add more checks for it. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Hans de Goede authored
commit e21eba05 upstream. This is a bit bigger hammer then I would like to use for this, but for now it will have to make do. I'm working on getting my hands on one of these so that I can try to get streams to work (with a quirk flag if necessary) and then we can re-enable them. For now this at least makes uas capable disk enclosures work again by forcing fallback to the usb-storage driver. https://bugzilla.kernel.org/show_bug.cgi?id=79511Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Mathias Nyman authored
commit 365038d8 upstream. When we manually need to move the TR dequeue pointer we need to set the correct cycle bit as well. Previously we used the trb pointer from the last event received as a base, but this was changed in commit 1f81b6d2 ("usb: xhci: Prefer endpoint context dequeue pointer") to use the dequeue pointer from the endpoint context instead It turns out some Asmedia controllers advance the dequeue pointer stored in the endpoint context past the event triggering TRB, and this messed up the way the cycle bit was calculated. Instead of adding a quirk or complicating the already hard to follow cycle bit code, the whole cycle bit calculation is now simplified and adapted to handle event and endpoint context dequeue pointer differences. Fixes: 1f81b6d2 ("usb: xhci: Prefer endpoint context dequeue pointer") Reported-by:
Maciej Puzio <mx34567@gmail.com> Reported-by:
Evan Langlois <uudruid74@gmail.com> Reviewed-by:
Julius Werner <jwerner@chromium.org> Tested-by:
-
Huang Rui authored
commit 2597fe99 upstream. AMD xHC also needs short tx quirk after tested on most of chipset generations. That's because there is the same incorrect behavior like Fresco Logic host. Please see below message with on USB webcam attached on xHC host: [ 139.262944] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.266934] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.270913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.274937] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.278914] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.282936] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.286915] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.290938] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.294913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.298917] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? Reported-by:
Arindam Nath <arindam.nath@amd.com> Tested-by:
Shriraj-Rai P <shriraj-rai.p@amd.com> Signed-off-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Hans de Goede authored
commit 9a548863 upstream. When using a Renesas uPD720231 chipset usb-3 uas to sata bridge with a 120G Crucial M500 ssd, model string: Crucial_ CT120M500SSD1, together with a the integrated Intel xhci controller on a Haswell laptop: 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04) The following error gets logged to dmesg: xhci error: Transfer event TRB DMA ptr not part of current TD Treating COMP_STOP the same as COMP_STOP_INVAL when no event_seg gets found fixes this. Signed-off-by:
-
Larry Finger authored
commit a2fa6721 upstream. The Elecom WDC-150SU2M uses this chip. Reported-by:
Hiroki Kondo <kompiro@gmail.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Holger Paradies authored
commit 8626d524 upstream. The stick is not recognized. This dongle uses r8188eu but usb-id is missing. 3.16.0 Signed-off-by:
Holger Paradies <retabell@gmx.de> Signed-off-by:
-
Mark Einon authored
commit ec0a38bf upstream. Fix two reported bugs, caused by et131x_adapter->phydev->addr being accessed before it is initialised, by: - letting et131x_mii_write() take a phydev address, instead of using the one stored in adapter by default. This is so et131x_mdio_write() can use it's own addr value. - removing implementation of et131x_mdio_reset(), as it's not needed. - moving a call to et131x_disable_phy_coma() in et131x_pci_setup(), which uses phydev->addr, until after the mdiobus has been registered. Link: https://bugzilla.kernel.org/show_bug.cgi?id=80751 Link: https://bugzilla.kernel.org/show_bug.cgi?id=77121Signed-off-by:
Mark Einon <mark.einon@gmail.com> Signed-off-by:
-
Pranith Kumar authored
commit e409842a upstream. The following patch fixes a build error on sparc32. I think it should go to stable 3.16. Remove a circular dependency on atomic.h header file which leads to compilation failure on sparc32 as reported here: http://kisskb.ellerman.id.au/kisskb/buildresult/11340509/ The specific dependency is as follows: In file included from arch/sparc/include/asm/smp_32.h:24:0, from arch/sparc/include/asm/smp.h:6, from arch/sparc/include/asm/switch_to_32.h:4, from arch/sparc/include/asm/switch_to.h:6, from arch/sparc/include/asm/ptrace.h:84, from arch/sparc/include/asm/processor_32.h:16, from arch/sparc/include/asm/processor.h:6, from arch/sparc/include/asm/barrier_32.h:4, from arch/sparc/include/asm/barrier.h:6, from arch/sparc/include/asm/atomic_32.h:17, from arch/sparc/include/asm/atomic.h:6, from drivers/staging/lustre/lustre/obdclass/class_obd.c:38 Signed-off-by:
Pranith Kumar <bobby.prani@gmail.com> Signed-off-by:
-
