- 05 Oct, 2014 40 commits
-
-
Li Zefan authored
commit aa32362f upstream. When cgroup_kn_lock_live() is called through some kernfs operation and another thread is calling cgroup_rmdir(), we'll trigger the warning in cgroup_get(). ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1228 at kernel/cgroup.c:1034 cgroup_get+0x89/0xa0() ... Call Trace: [<c16ee73d>] dump_stack+0x41/0x52 [<c10468ef>] warn_slowpath_common+0x7f/0xa0 [<c104692d>] warn_slowpath_null+0x1d/0x20 [<c10bb999>] cgroup_get+0x89/0xa0 [<c10bbe58>] cgroup_kn_lock_live+0x28/0x70 [<c10be3c1>] __cgroup_procs_write.isra.26+0x51/0x230 [<c10be5b2>] cgroup_tasks_write+0x12/0x20 [<c10bb7b0>] cgroup_file_write+0x40/0x130 [<c11aee71>] kernfs_fop_write+0xd1/0x160 [<c1148e58>] vfs_write+0x98/0x1e0 [<c114934d>] SyS_write+0x4d/0xa0 [<c16f656b>] sysenter_do_call+0x12/0x12 ---[ end trace 6f2e0c38c2108a74 ]--- Fix this by calling css_tryget() instead of cgroup_get(). v2: - move cgroup_tryget() right below cgroup_get() definition. (Tejun) Reported-by:
Toralf Förster <toralf.foerster@gmx.de> Signed-off-by:
Zefan Li <lizefan@huawei.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
J. Bruce Fields authored
commit aee37764 upstream. Commit 3b299709 "nfsd4: enforce rd_dircount" totally misunderstood rd_dircount; it refers to total non-attribute bytes returned, not number of directory entries returned. Bring the code into agreement with RFC 3530 section 14.2.24. Fixes: 3b299709 "nfsd4: enforce rd_dircount" Signed-off-by:
J. Bruce Fields <bfields@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:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Varun Sethi authored
commit 5a9137a6 upstream. iommu_group_get_for_dev determines the iommu group for the PCI device and adds the device to the group. In the PAMU driver we were again adding the device to the same group without checking if the device already had an iommu group. This resulted in the following warning. sysfs: cannot create duplicate filename '/devices/ffe200000.pcie/pci0000:00/0000:00:00.0/iommu_group' ------------[ cut here ]------------ WARNING: at fs/sysfs/dir.c:31 Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc3-00002-g7505ceaf-dirty #126 task: c0000001fe0a0000 ti: c0000001fe044000 task.ti: c0000001fe044000 NIP: c00000000018879c LR: c000000000188798 CTR: c00000000001ea50 REGS: c0000001fe047040 TRAP: 0700 Not tainted (3.17.0-rc3-00002-g7505ceaf-dirty) MSR: 0000000080029000 <CE,EE,ME> CR: 24ad8e22 XER: 20000000 SOFTE: 1 GPR00: c000000000188798 c0000001fe0472c0 c0000000009a52e0 0000000000000065 GPR04: 0000000000000001 0000000000000000 3a30303a00000000 0000000027000000 GPR08: 2f696f6d00000000 c0000000008d3830 c0000000009b3938 c0000000009bb3d0 GPR12: 0000000028ad8e24 c00000000fff4000 c00000000000205c 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 c0000000008a4c70 GPR24: c0000000007e9010 c0000001fe0140a8 ffffffffffffffef 0000000000000001 GPR28: c0000001fe22ebb8 c0000000007e9010 c00000000090bf10 c0000001fe220000 NIP [c00000000018879c] .sysfs_warn_dup+0x74/0xa4 LR [c000000000188798] .sysfs_warn_dup+0x70/0xa4 Call Trace: [c0000001fe0472c0] [c000000000188798] .sysfs_warn_dup+0x70/0xa4 (unreliable) [c0000001fe047350] [c000000000188d34] .sysfs_do_create_link_sd.clone.2+0x168/0x174 [c0000001fe047400] [c0000000004b3cf8] .iommu_group_add_device+0x78/0x244 [c0000001fe0474b0] [c0000000004b6964] .fsl_pamu_add_device+0x88/0x1a8 [c0000001fe047570] [c0000000004b3960] .iommu_bus_notifier+0xdc/0x15c [c0000001fe047600] [c000000000059848] .notifier_call_chain+0x8c/0xe8 [c0000001fe0476a0] [c000000000059d04] .__blocking_notifier_call_chain+0x58/0x84 [c0000001fe047750] [c00000000036619c] .device_add+0x464/0x5c8 [c0000001fe047820] [c000000000300ebc] .pci_device_add+0x14c/0x17c [c0000001fe0478c0] [c000000000300fbc] .pci_scan_single_device+0xd0/0xf4 [c0000001fe047970] [c00000000030104c] .pci_scan_slot+0x6c/0x18c [c0000001fe047a10] [c00000000030226c] .pci_scan_child_bus+0x40/0x114 [c0000001fe047ac0] [c000000000021974] .pcibios_scan_phb+0x240/0x2c8 [c0000001fe047b70] [c00000000085a970] .pcibios_init+0x64/0xc8 [c0000001fe047c00] [c000000000001884] .do_one_initcall+0xbc/0x224 [c0000001fe047d00] [c000000000852d50] .kernel_init_freeable+0x14c/0x21c [c0000001fe047db0] [c000000000002078] .kernel_init+0x1c/0xfa4 [c0000001fe047e30] [c000000000000884] .ret_from_kernel_thread+0x58/0xd4 Instruction dump: 7c7f1b79 4182001c 7fe4fb78 7f83e378 38a01000 4bffc905 60000000 7c641b78 e87e8008 7fa5eb78 48482ff5 60000000 <0fe00000> 7fe3fb78 4bf7bd39 60000000 Signed-off-by:
Varun Sethi <Varun.Sethi@freescale.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Joerg Roedel authored
commit c0df975f upstream. Checking adev == NULL is not sufficient as acpi_bus_get_device() might not touch the value of this parameter in an error case, so check the return value directly. Fixes: ed40356b Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Bjørn Mork authored
commit 508b3c67 upstream. This reverts commit 232de514 ("ACPI / battery: fix wrong value of capacity_now reported when fully charged") There is nothing wrong or unexpected about 'capacity_now' increasing above the last 'full_charge_capacity' value. Different charging cycles will cause 'full_charge_capacity' to vary, both up and down. Good battery firmwares will update 'full_charge_capacity' when the current charging cycle is complete, increasing it if necessary. It might even go above 'design_capacity' on a fresh and healthy battery. Capping 'capacity_now' to 'full_charge_capacity' is plain wrong, and printing a warning if this doesn't happen to match the 'design_capacity' is both annoying and terribly wrong. This results in bogus warnings on perfectly working systems/firmwares: [Firmware Bug]: battery: reported current charge level (39800) is higher than reported maximum charge level (39800). and wrong values being reported for 'capacity_now' and 'full_charge_capacity' after the warning has been triggered. Fixes: 232de514 ("ACPI / battery: fix wrong value of capacity_now reported when fully charged") Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Fu Zhonghui authored
commit f4168b61 upstream. PM entries of LPSS power domain were not implemented correctly in commit c78b0830 "ACPI / LPSS: custom power domain for LPSS". This patch fixes and completes these PM entries. Fixes: c78b0830 (ACPI / LPSS: custom power domain for LPSS) Signed-off-by:
Li Aubrey <aubrey.li@linux.intel.com> Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Fu Zhonghui <zhonghui.fu@linux.intel.com> 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:
-
Robert Baldyga authored
commit 604eac3c upstream. Endpoint 0 should not be disabled, so we start loop counter from number 1. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
-
Marek Szyprowski authored
commit eb3c56c5 upstream. This patch fixes kernel panic/interrupt storm/etc issues if bootloader left s3c-hsotg module in enabled state. Now interrupt handler is enabled only after proper configuration of hardware registers. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Marek Szyprowski authored
commit b510df5a upstream. This leads to potential spinlock recursion in composite framework, other udc drivers also don't call it directly from pullup method. Signed-off-by:
-
Marek Szyprowski authored
commit e0cbe595 upstream. This patch fixes possible freeze caused by infinite loop in interrupt context. Signed-off-by:
-
Kamil Debski authored
commit ca2c5ba8 upstream. In the Generic PHY Framework a NULL phy is considered to be a valid phy thus the "if (hsotg->phy)" check does not give us the information whether the Generic PHY Framework is used. In addition to the above this patch also removes phy_init from probe and phy_exit from remove. This is not necessary when init/exit is done in the s3c_hsotg_phy_enable/disable functions. Signed-off-by:
Kamil Debski <k.debski@samsung.com> Signed-off-by:
-
Kamil Debski authored
commit 0655314b upstream. When the driver is removed s3c_hsotg_phy_disable is called three times instead of once. This results in decreasing of the phy reference counter below zero and thus consecutive inserts of the module fails. This patch removes calls to s3c_hsotg_phy_disable from s3c_hsotg_remove and s3c_hsotg_udc_stop. s3c_hsotg_udc_stop is called from udc-core.c only after usb_gadget_disconnect, which in turn calls s3c_hsotg_pullup, which already calls s3c_hsotg_phy_disable. s3c_hsotg_remove must be called only after udc_stop, so there is no point in disabling phy once again there. 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:
-
Felipe Balbi authored
commit dc99f16f upstream. We can't suspend the PHYs before dwc3_core_exit_mode() has been called, that's because the host and/or device sides might still need to communicate with the far end link partner. Fixes: 8ba007a9 (usb: dwc3: core: enable the USB2 and USB3 phy in probe) Suggested-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Felipe Balbi authored
commit fed33afc upstream. Currently, we disable pm_runtime before all register accesses are done, this is dangerous and might lead to abort exceptions due to the driver trying to access a register which is clocked by a clock which was long gated. Fix that by moving pm_runtime_put_sync() and pm_runtime_disable() as the last thing we do before returning from our ->remove() method. Fixes: 72246da4 (usb: Introduce DesignWare USB3 DRD Driver) 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:
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:
-
Alan Stern authored
commit b6089f19 upstream. Commit d24d481b (usb-storage: Modify and export adjust_quirks so that it can be used by uas) added the 'u' flag to the quirks module parameter for usb-storage, but neglected to update the documentation. This patch adds the documentation. 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:
-
Al Cooper authored
commit 0eda06c7 upstream. The xhci driver will OOPS on resume from S2/S3 if dma_alloc_coherent() is out of memory. This is a result of two things: 1. xhci_mem_cleanup() in xhci-mem.c free's xhci->lpm_command if it's not NULL, but doesn't set it to NULL after the free. 2. xhci_mem_cleanup() is called twice on resume, once for normal restart and once from xhci_mem_init() if dma_alloc_coherent() fails, resulting in a free of xhci->lpm_command that has already been freed. The fix is to set xhci->lpm_command to NULL after freeing it. Signed-off-by:
Al Cooper <alcooperx@gmail.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:
Tony Lindgren <tony@atomide.com> Signed-off-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 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:
-
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:
-
