- 05 Oct, 2014 40 commits
-
-
Nathan Lynch authored
commit 9cc6d9e5 upstream. Joachim Eastwood reports that commit fbfb872f "ARM: 8148/1: flush TLS and thumbee register state during exec" causes a boot-time crash on a Cortex-M4 nommu system: Freeing unused kernel memory: 68K (281e5000 - 281f6000) Unhandled exception: IPSR = 00000005 LR = fffffff1 CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-rc6-00313-gd2205fa30aa7 #191 task: 29834000 ti: 29832000 task.ti: 29832000 PC is at flush_thread+0x2e/0x40 LR is at flush_thread+0x21/0x40 pc : [<2800954a>] lr : [<2800953d>] psr: 4100000b sp : 29833d60 ip : 00000000 fp : 00000001 r10: 00003cf8 r9 : 29b1f000 r8 : 00000000 r7 : 29b0bc00 r6 : 29834000 r5 : 29832000 r4 : 29832000 r3 : ffff0ff0 r2 : 29832000 r1 : 00000000 r0 : 282121f0 xPSR: 4100000b CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-rc6-00313-gd2205fa30aa7 #191 [<2800afa5>] (unwind_backtrace) from [<2800a327>] (show_stack+0xb/0xc) [<2800a327>] (show_stack) from [<2800a963>] (__invalid_entry+0x4b/0x4c) The problem is that set_tls is attempting to clear the TLS location in the kernel-user helper page, which isn't set up on V7M. Fix this by guarding the write to the kuser helper page with a CONFIG_KUSER_HELPERS ifdef. Fixes: fbfb872f ARM: 8148/1: flush TLS and thumbee register state during exec Reported-by:
Joachim Eastwood <manabian@gmail.com> Tested-by:
Nathan Lynch <nathan_lynch@mentor.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Robin Murphy authored
commit 5ca918e5 upstream. The alignment fixup incorrectly decodes faulting ARM VLDn/VSTn instructions (where the optional alignment hint is given but incorrect) as LDR/STR, leading to register corruption. Detect these and correctly treat them as unhandled, so that userspace gets the fault it expects. Reported-by:
Simon Hosie <simon.hosie@arm.com> Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
Nathan Lynch authored
commit fbfb872f upstream. The TPIDRURO and TPIDRURW registers need to be flushed during exec; otherwise TLS information is potentially leaked. TPIDRURO in particular needs careful treatment. Since flush_thread basically needs the same code used to set the TLS in arm_syscall, pull that into a common set_tls helper in tls.h and use it in both places. Similarly, TEEHBR needs to be cleared during exec as well. Clearing its save slot in thread_info isn't right as there is no guarantee that a thread switch will occur before the new program runs. Just setting the register directly is sufficient. Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Sudeep Holla authored
commit a040803a upstream. Since commit 1dbfa187 ("ARM: irq migration: force migration off CPU going down") the ARM interrupt migration code on cpu offline calls irqchip.irq_set_affinity() with the argument force=true. At the point of this change the argument had no effect because it was not used by any interrupt chip driver and there was no semantics defined. This changed with commit 01f8fa4f ("genirq: Allow forcing cpu affinity of interrupts") which made the force argument useful to route interrupts to not yet online cpus without checking the target cpu against the cpu online mask. The following commit ffde1de6 ("irqchip: gic: Support forced affinity setting") implemented this for the GIC interrupt controller. As a consequence the ARM cpu offline irq migration fails if CPU0 is offlined, because CPU0 is still set in the affinity mask and the validataion against cpu online mask is skipped to the force argument being true. The following first_cpu(mask) selection always selects CPU0 as the target. Solve the issue by calling irq_set_affinity() with force=false from the CPU offline irq migration code so the GIC driver validates the affinity mask against CPU online mask and therefore removes CPU0 from the possible target candidates. Tested on TC2 hotpluging CPU0 in and out. Without this patch the system locks up as the IRQs are not migrated away from CPU0. Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
-
Nishanth Menon authored
commit 68e4d9e5 upstream. While auditing the various pin ctrl configurations using the following command: grep PIN_ arch/arm/boot/dts/dra7-evm.dts|(while read line; do v=`echo "$line" | sed -e "s/\s\s*/|/g" | cut -d '|' -f1 | cut -d 'x' -f2|tr [a-z] [A-Z]`; HEX=`echo "obase=16;ibase=16;4A003400+$v"| bc`; echo "$HEX ===> $line"; done) against DRA75x/74x NDA TRM revision S(SPRUHI2S August 2014), documentation errors were found for spi1 pinctrl. Fix the same. Fixes: 6e58b8f1 ("ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board") Signed-off-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Nishanth Menon authored
commit e49d519c upstream. GPIO modules are also interrupt sources. However, they require both the GPIO number and IRQ type to function properly. By declaring that GPIO uses interrupt-cells=<1>, we essentially do not allow users of the nodes to use the interrupt property appropritely. With this change, the following now works: interrupt-parent = <&gpio6>; interrupts = <5 IRQ_TYPE_LEVEL_LOW>; Fixes: 6e58b8f1 ('ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board') Signed-off-by:
-
Rajendra Nayak authored
commit f7f7a29b upstream. To deal with IPs which are specific to dra74x and dra72x, maintain seperate ocp interface lists, while keeping the common list for all common IPs. Move USB OTG SS4 to dra74x only list since its unavailable in dra72x and is giving an abort during boot. The dra72x only list is empty for now and a placeholder for future hwmod additions which are specific to dra72x. Fixes: d904b38d ("ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss") Reported-by:
Keerthy <j-keerthy@ti.com> Signed-off-by:
Rajendra Nayak <rnayak@ti.com> Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Tested-by:
Paul Walmsley <paul@pwsan.com> Signed-off-by:
-
Mark Rutland authored
commit 85868313 upstream. The ARMv6 and ARMv7 early abort handlers clear the exclusive monitors upon entry to the kernel, but this is redundant: - We clear the monitors on every exception return since commit 200b812d ("Clear the exclusive monitor when returning from an exception"), so this is not necessary to ensure the monitors are cleared before returning from a fault handler. - Any dummy STREX will target a temporary scratch area in memory, and may succeed or fail without corrupting useful data. Its status value will not be used. - Any other STREX in the kernel must be preceded by an LDREX, which will initialise the monitors consistently and will not depend on the earlier state of the monitors. Therefore we have no reason to care about the initial state of the exclusive monitors when a data abort is taken, and clearing the monitors prior to exception return (as we already do) is sufficient. This patch removes the redundant clearing of the exclusive monitors from the early abort handlers. Signed-off-by:
-
Andy Shevchenko authored
commit c9d5d6fe upstream. The commit 04f421e7 "spi: dw: use managed resources" changes drivers to use managed functions, but seems wasn't properly tested in PCI case. The regs field of struct dw_spi left uninitialized. Thus, kernel crashes when tries to access to the SPI controller registers. This patch fixes the issue. Fixes: 04f421e7 (spi: dw: use managed resources) Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Jorge A. Ventura authored
commit 3d0763c0 upstream. The spi hangs waiting the completion of omap2_mcspi_rx_callback. Signed-off-by:
Jorge A. Ventura <jorge.araujo.ventura@gmail.com> Signed-off-by:
-
Trond Myklebust authored
commit cd9288ff upstream. James Drew reports another bug whereby the NFS client is now sending an OPEN_DOWNGRADE in a situation where it should really have sent a CLOSE: the client is opening the file for O_RDWR, but then trying to do a downgrade to O_RDONLY, which is not allowed by the NFSv4 spec. Reported-by:
James Drews <drews@engr.wisc.edu> Link: http://lkml.kernel.org/r/541AD7E5.8020409@engr.wisc.edu Fixes: aee7af35 (NFSv4: Fix problems with close in the presence...) Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Steve Dickson authored
commit 080af20c upstream. There is a race between nfs4_state_manager() and nfs_server_remove_lists() that happens during a nfsv3 mount. The v3 mount notices there is already a supper block so nfs_server_remove_lists() called which uses the nfs_client_lock spin lock to synchronize access to the client list. At the same time nfs4_state_manager() is running through the client list looking for work to do, using the same lock. When nfs4_state_manager() wins the race to the list, a v3 client pointer is found and not ignored properly which causes the panic. Moving some protocol checks before the state checking avoids the panic. Signed-off-by:
Steve Dickson <steved@redhat.com> Signed-off-by:
-
Olav Haugan authored
commit 1fc870c7 upstream. Stage-1 context banks do not have the SMMU_CBn_TCR[SL0] field since it is only applicable to stage-2 context banks. This patch ensures that we don't set the reserved TCR bits for stage-1 translations. Signed-off-by:
Olav Haugan <ohaugan@codeaurora.org> Signed-off-by:
-
Lee, Chun-Yi authored
commit 9389f46e upstream. The value64 parameter is an u64 point that used to transfer the value for write to CMOS, or used to return the value that's read from CMOS. The value64 is an u64 point, so don't need get address again. It causes acpi_cmos_rtc_space_handler always return 0 to reader and didn't write expected value to CMOS. Signed-off-by:
Lee, Chun-Yi <jlee@suse.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Felipe Balbi authored
commit 81a60b7f upstream. we don't to gate clocks until our children are done with their remove path. Fixes: af310e96 (usb: dwc3: omap: use runtime API's to enable clocks) Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Alan Stern authored
commit 7312b5dd upstream. Old code in ehci-hcd tries to expedite disabling endpoints after the controller has stopped, by destroying the endpoint's associated QH without first unlinking the QH. This was necessary back when the driver wasn't so careful about keeping track of the controller's state. But now we are careful about it, and the driver knows that when the controller isn't running, no unlinking delay is needed. Furthermore, skipping the unlink step will trigger a BUG() in qh_destroy() when the preceding QH is released, because the link pointer will be non-NULL. Removing the lines that skip the unlinking step and go directly to QH_STATE_IDLE fixes the problem. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Joe Lawrence <joe.lawrence@stratus.com> Tested-by:
-
Mark authored
commit c80b4495 upstream. This patch adds quirks for Entrega Technologies (later Xircom PortGear) USB- SCSI converters. They use Shuttle Technology EUSB-01/EUSB-S1 chips. The US_FL_SCM_MULT_TARG quirk is needed to allow multiple devices on the SCSI chain to be accessed. Without it only the (single) device with SCSI ID 0 can be used. The standalone converter sold by Entrega had model number U1-SC25. Xircom acquired Entrega and re-branded the product line PortGear. The PortGear USB to SCSI Converter (model PGSCSI) is internally identical to the Entrega product, but later models may use a different USB ID. The Entrega-branded units have USB ID 1645:0007, as does my Xircom PGSCSI, but the Windows and Macintosh drivers also support 085A:0028. Entrega also sold the "Mac USB Dock", which provides two USB ports, a Mac (8-pin mini-DIN) serial port and a SCSI port. It appears to the computer as a four-port hub, USB-serial, and USB-SCSI converters. The USB-SCSI part may have initially used the same ID as the standalone U1-SC25 (1645:0007), but later production used 085A:0026. My Xircom PortGear PGSCSI has bcdDevice=0x0100. Units with bcdDevice=0x0133 probably also exist. This patch adds quirks for 1645:0007, 085A:0026 and 085A:0028. The Windows driver INF file also mentions 085A:0032 "PortStation SCSI Module", but I couldn't find any mention of that actually existing in the wild; perhaps it was cancelled before release? Signed-off-by:
Mark Knibbs <markk@clara.co.uk> Signed-off-by:
-
Mark authored
commit b6a3ed67 upstream. Hi, The Ariston Technologies iConnect 025 and iConnect 050 (also known as e.g. iSCSI-50) are SCSI-USB converters which use Shuttle Technology/SCM Microsystems chips. Only the connectors differ; both have the same USB ID. The US_FL_SCM_MULT_TARG quirk is required to use SCSI devices with ID other than 0. I don't have one of these, but based on the other entries for Shuttle/ SCM-based converters this patch is very likely correct. I used 0x0000 and 0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which bcdDevice value the products use. Signed-off-by:
-
Mark authored
commit 67d365a5 upstream. The Adaptec USBConnect 2000 is another SCSI-USB converter which uses Shuttle Technology/SCM Microsystems chips. The US_FL_SCM_MULT_TARG quirk is required to use SCSI devices with ID other than 0. I don't have a USBConnect 2000, but based on the other entries for Shuttle/ SCM-based converters this patch is very likely correct. I used 0x0000 and 0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which bcdDevice value the product uses. Signed-off-by:
-
Mark authored
commit c66f1c62 upstream. The Iomega Jaz USB Adapter is a SCSI-USB converter cable. The hardware seems to be identical to e.g. the Microtech XpressSCSI, using a Shuttle/ SCM chip set. However its firmware restricts it to only work with Jaz drives. On connecting the cable a message like this appears four times in the log: reset full speed USB device number 4 using uhci_hcd That's non-fatal but the US_FL_SINGLE_LUN quirk fixes it. Signed-off-by:
-
Joe Lawrence authored
commit c605f3cd upstream. During surprise device hotplug removal tests, it was observed that hub_events may try to call usb_lock_device on a device that has already been freed. Protect the usb_device by taking out a reference (under the hub_event_lock) when hub_events pulls it off the list, returning the reference after hub_events is finished using it. Signed-off-by:
-
Mathias Nyman authored
commit 96044694 upstream. Resuming from hibernate (S4) will restart and re-initialize xHC. The device contexts are freed and will be re-allocated later during device reset. Usb core will disable link pm in device resume before device reset, which will try to change the max exit latency, accessing the device contexts before they are re-allocated. There is no need to zero (disable) the max exit latency when disabling hw lpm for a freshly re-initialized xHC. So check that device context exists before doing anything. The max exit latency will be set again after device reset when usb core enables the link pm. Reported-by:
Imre Deak <imre.deak@intel.com> Tested-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Mathias Nyman authored
commit c207e7c5 upstream. If xhci initialization fails before the roothub bandwidth domains (xhci->rh_bw[i]) are allocated it will oops when trying to access rh_bw members in xhci_mem_cleanup(). Reported-by:
Manuel Reimer <manuel.reimer@gmx.de> Signed-off-by:
-
Felipe Balbi authored
commit 96908589 upstream. Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) implemented a workaround for a known issue with Texas Instruments' USB 3.0 redriver IC but it left a condition where any xHCI host would be taken out of reset if port was placed in compliance mode and there was no device connected to the port. That condition would trigger a fake connection to a non-existent device so that usbcore would trigger a warm reset of the port, thus taking the link out of reset. This has the side-effect of preventing any xHCI host connected to a Linux machine from starting and running the USB 3.0 Electrical Compliance Suite because the port will mysteriously taken out of compliance mode and, thus, xHCI won't step through the necessary compliance patterns for link validation. This patch fixes the issue by just adding a missing check for XHCI_COMP_MODE_QUIRK inside xhci_hub_report_usb3_link_state() when PORT_CAS isn't set. This patch should be backported to all kernels containing commit 71c731a2. Fixes: 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) Cc: Alexis R. Cortes <alexis.cortes@ti.com> Signed-off-by:
-
Thomas Pugliese authored
commit 675f0ab2 upstream. Make sure the uwb_dev->bce entry is set before calling uwb_dev_add in uwbd_dev_onair so that usermode will only see the device after it is properly initialized. This fixes a kernel panic that can occur if usermode tries to access the IEs sysfs attribute of a UWB device before the driver has had a chance to set the beacon cache entry. Signed-off-by:
Thomas Pugliese <thomas.pugliese@gmail.com> Signed-off-by:
-
Johan Hovold authored
commit 30966910 upstream. Add back some PIDs that were mistakingly remove when reverting commit 73228a05 ("USB: option,zte_ev: move most ZTE CDMA devices to zte_ev"), which apparently did more than its commit message claimed in that it not only moved some PIDs from option to zte_ev but also added some new ones. Fixes: 63a901c0 ("Revert "USB: option,zte_ev: move most ZTE CDMA devices to zte_ev"") Reported-by:
Lei Liu <lei35151@163.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
commit ee444609 upstream. Add device id for NOVITUS Bono E thermal printer. Reported-by:
Emanuel Koczwara <poczta@emanuelkoczwara.pl> Signed-off-by:
-
Taylor Braun-Jones authored
commit 9c491c37 upstream. Signed-off-by:
Taylor Braun-Jones <taylor.braun-jones@ge.com> Cc: Johan Hovold <johan@kernel.org> Signed-off-by:
-
Ivan T. Ivanov authored
commit 233c7daf upstream. Initialize USB PHY after every Link controller reset Cc: Tim Bird <tbird20d@gmail.com> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
Ivan T. Ivanov <iivanov@mm-sol.com> Signed-off-by:
-
Ivan T. Ivanov authored
commit ea290056 upstream. PHY drivers keep track of the current state of the hardware, so don't change PHY settings under it. Cc: Tim Bird <tbird20d@gmail.com> Signed-off-by:
-
Tony Lindgren authored
commit 96be39ab upstream. Commit 30a70b02 ("usb: musb: fix obex in g_nokia.ko causing kernel panic") attempted to fix runtime PM handling for PHYs that are on the I2C bus. Commit 3063a12b ("usb: musb: fix PHY power on/off") then changed things around to enable of PHYs that rely on runtime PM. These changes however broke idling of the PHY and causes at least 100 mW extra power consumption on omaps, which is a lot with the idle power consumption being below 10 mW range on many devices. As calling phy_power_on/off from runtime PM calls in the USB causes complicated issues with I2C connected PHYs, let's just let the PHY do it's own runtime PM as needed. This leaves out the dependency between PHYs and USB controller drivers for runtime PM. Let's fix the regression for twl4030-usb by adding minimal runtime PM support. This allows idling the PHY on disconnect. Note that we are changing to use standard runtime PM handling for twl4030_phy_init() as that function just checks the state and does not initialize the PHY. The PHY won't get initialized until in twl4030_phy_power_on(). Fixes: 30a70b02 ("usb: musb: fix obex in g_nokia.ko causing kernel panic") Fixes: 3063a12b ("usb: musb: fix PHY power on/off") Acked-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
Tony Lindgren authored
commit 85601b8d upstream. Commit 249751f2 ("usb: phy: twl4030-usb: poll for ID disconnect") added twl4030_id_workaround_work() to deal with lost interrupts after ID pin goes down. Looks like commit f1ddc24c ("usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops") changed things around for the generic phy framework, and delayed work no longer got called except initially during boot. The PHY connect and disconnect interrupts for twl4030-usb are not working after disconnecting a USB-A cable from the board, and the deeper idle states for omap are blocked as the USB controller stays busy. The issue can be solved by calling delayed work from twl4030_usb_irq() when ID pin is down and the PHY is not asleep like we already do in twl4030_id_workaround_work(). But as both twl4030_usb_irq() and twl4030_id_workaround_work() already do pretty much the same thing, let's call twl4030_usb_irq() from twl4030_id_workaround_work() instead of adding some more duplicate code. We also must call sysfs_notify() only when we have an interrupt and not from the delayed work as notified by Grazvydas Ignotas <notasas@gmail.com>. Fixes: f1ddc24c ("usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops") Acked-by:
-
Thierry Reding authored
commit 9ce9ec95 upstream. The PHY configuration is stored in an opaque "config" field, but when allocating the structure, its proper size needs to be known. In the case of UTMI, the proper structure is tegra_utmip_config of which a local variable already exists, so we can use that to obtain the size from. Fixes the following warning from the sparse checker: drivers/usb/phy/phy-tegra-usb.c:882:17: warning: expression using sizeof(void) Fixes: 81d5dfe6 (usb: phy: tegra: Read UTMIP parameters from device tree) Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Bjørn Mork authored
commit 5b3da692 upstream. This VID:PID is used for some Direct IP devices behaving identical to the already supported 0F3D:68AA devices. Reported-by:
Lars Melin <larsm17@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Bjørn Mork authored
commit 049255f5 upstream. Sierra Wireless Direct IP devices using the 68A3 product ID can be configured for modes including a CDC ECM class function. The known example uses interface numbers 12 and 13 for the ECM control and data interfaces respectively, consistent with CDC MBIM function interface numbering on other Sierra devices. It seems cleaner to restrict this driver to the ff/ff/ff vendor specific interfaces rather than increasing the already long interface number blacklist. This should be more future proof if Sierra adds more class functions using interface numbers not yet in the blacklist. Signed-off-by:
-
Karol Lewandowski authored
Applicable for 3.14-stable only, as this revertes a previous commit that was incorrect. This commit drops duplicate declaration of struct usb_functionfs_descs_head erronousely added in commit 28c5980b ("usb: gadget: f_fs: resurect usb_functionfs_descs_head structure"). Fix from 28c5980b is applicable only for v3.15-rc1 and newer kernels. This fixes error in uapi: /src/linux$ make -C tools usb make: Entering directory '/src/linux/tools' DESCEND usb make[1]: Entering directory '/src/linux/tools/usb' gcc -Wall -Wextra -g -I../include -o testusb testusb.c -lpthread gcc -Wall -Wextra -g -I../include -o ffs-test ffs-test.c -lpthread In file included from ffs-test.c:41:0: ../../include/uapi/linux/usb/functionfs.h:42:8: error: redefinition of ‘struct usb_functionfs_descs_head’ struct usb_functionfs_descs_head { ^ ../../include/uapi/linux/usb/functionfs.h:31:8: note: originally defined here struct usb_functionfs_descs_head { ^ Cc: Michal Nazarewicz <mina86@mina86.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by:
Karol Lewandowski <k.lewandowsk@samsung.com> Signed-off-by:
-
Johan Hovold authored
commit 754eb21c upstream. Remove dublicate Qualcom PID 0x3197 which is already handled by the moto-modem driver since commit 6986a978 ("USB: add new moto_modem driver for some Morotola phones"). Fixes: 799ee924 ("USB: serial: add zte_ev.c driver") Signed-off-by:
-
Johan Hovold authored
commit 95be5739 upstream. Remove dublicate Gobi PID 0x9008 which is already handled by the qcserial driver since commit f05932c0 ("USB: qcserial: Add extra device IDs"). Fixes: 799ee924 ("USB: serial: add zte_ev.c driver") Signed-off-by:
-
Johan Hovold authored
commit 63a901c0 upstream. This reverts commit 73228a05 ("USB: option,zte_ev: move most ZTE CDMA devices to zte_ev"). Move the IDs of the devices that were previously driven by the option driver back to that driver. As several users have reported, the zte_ev driver is causing random disconnects as well as reconnect failures. A closer analysis of the zte_ev setup code reveals that it consists of standard CDC requests (SET/GET_LINE_CODING and SET_CONTROL_LINE_STATE) but unfortunately fails to get some of those right. In particular, as reported by Liu Lei, it fails to lower DTR/RTS on close. It also appears that the control requests lack the interface argument. Note that the zte_ev driver is based on code (once) distributed by ZTE that still appears to originally have been reverse-engineered and bolted onto the generic driver. Since line control is already handled properly by the option driver, and the SET/GET_LINE_CODING requests appears to be redundant (amounts to a SET 9600 8N1), this is a first step in ultimately removing the redundant zte_ev driver. Note that AC2726 had already been moved back to option, and that some IDs were in the device table of both drivers prior to the commit being reverted. Reported-by:
Lei Liu <liu.lei78@zte.com.cn> Signed-off-by:
-
Brennan Ashton authored
commit d7730273 upstream. This VIA Telecom baseband processor is used is used by by u-blox in both the FW2770 and FW2760 products and may be used in others as well. This patch has been tested on both of these modem versions. Signed-off-by:
Brennan Ashton <bashton@brennanashton.com> Signed-off-by:
-
