- Apr 28, 2011
-
-
Andi Kleen authored
Release 2.6.35.13 From: Andi Kleen <andi@firstfloor.org> Release 2.6.35.13 Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Chuck Ebbert authored
Also please revert the patch "fix-cred-leak-in-af_netlink" from 2.6.35.12. The proper fix was "af_netlink-add-needed-scm_destroy-after-scm_send" which was also added in that release. Here's a revert patch: Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Linus Torvalds authored
[ upstream commit e5871372 ] This reverts commit 9b29050f . It has caused hibernate regressions, for example Juri Sladby's report: "I'm unable to hibernate 2.6.37.1 unless I rmmod tpm_tis: [10974.074587] Suspending console(s) (use no_console_suspend to debug) [10974.103073] tpm_tis 00:0c: Operation Timed out [10974.103089] legacy_suspend(): pnp_bus_suspend+0x0/0xa0 returns -62 [10974.103095] PM: Device 00:0c failed to freeze: error -62" and Rafael points out that some of the new conditionals in that commit seem to make no sense. This commit needs more work and testing, let's revert it for now. Reported-by:
Norbert Preining <preining@logic.at> Reported-and-requested-by:
Jiri Slaby <jirislaby@gmail.com> Cc: Stefan Berger <stefanb@linux.vnet.ibm.com> Cc: Guillaume Chazarain <guichaz@gmail.com> Cc: Rajiv Andrade <srajiv@linux.vnet.ibm.com> Acked-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Linus Torvalds authored
[ upstream commit 8d1dc20e ] This reverts commit c4ff4b82. Ted Ts'o reports: "TPM is working for me so I can log into employer's network in 2.6.37. It broke when I tried 2.6.38-rc6, with the following relevant lines from my dmesg: [ 11.081627] tpm_tis 00:0b: 1.2 TPM (device-id 0x0, rev-id 78) [ 25.734114] tpm_tis 00:0b: Operation Timed out [ 78.040949] tpm_tis 00:0b: Operation Timed out This caused me to get suspicious, especially since the _other_ TPM commit in 2.6.38 had already been reverted, so I tried reverting commit c4ff4b82 : "TPM: Long default timeout fix". With this commit reverted, my TPM on my Lenovo T410 is once again working." Requested-and-tested-by:
Theodore Ts'o <tytso@mit.edu> Acked-by:
Rajiv Andrade <srajiv@linux.vnet.ibm.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Phil Edworthy authored
This reverts commit 1219932c (commit d8b5fc01 upstream). The reverted commit depends on an upstream commit that has not been applied to 2.6.35.y (d7627467 ). This fixes a build failure on all SH devices: /arch/sh/kernel/process_32.c:299: error: conflicting types for 'sys_execve' /arch/sh/include/asm/syscalls_32.h:22: note: previous declaration of 'sys_execve' was here Signed-off-by:
Phil Edworthy <phil.edworthy@renesas.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Dmitry Torokhov authored
upstream commit: 2dea75d9 Currently, when resetting a device, xHCI driver disables all but one endpoints and frees their rings, but leaves alone any streams that might have been allocated. Later, when users try to free allocated streams, we oops in xhci_setup_no_streams_ep_input_ctx() because ep->ring is NULL. Let's free not only rings but also stream data as well, so that calling free_streams() on a device that was reset will be safe. This should be queued for stable trees back to 2.6.35. Reviewed-by:
Micah Elizabeth Scott <micah@vmware.com> Signed-off-by:
Dmitry Torokhov <dtor@vmware.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Cc: stable@kernel.org
-
Matthew Wilcox authored
upstream commit: b214f191 If I unplug a device while the UAS driver is loaded, I get an oops in usb_free_streams(). This is because usb_unbind_interface() calls usb_disable_interface() which calls usb_disable_endpoint() which sets ep_out and ep_in to NULL. Then the UAS driver calls usb_pipe_endpoint() which returns a NULL pointer and passes an array of NULL pointers to usb_free_streams(). I think the correct fix for this is to check for the NULL pointer in usb_free_streams() rather than making the driver check for this situation. My original patch for this checked for dev->state == USB_STATE_NOTATTACHED, but the call to usb_disable_interface() is conditional, so not all drivers would want this check. Note from Sarah Sharp: This patch does avoid a potential dereference, but the real fix (which will be implemented later) is to set the .soft_unbind flag in the usb_driver structure for the UAS driver, and all drivers that allocate streams. The driver should free any streams when it is unbound from the interface. This avoids leaking stream rings in the xHCI driver when usb_disable_interface() is called. This should be queued for stable trees back to 2.6.35. Signed-off-by:
Matthew Wilcox <willy@linux.intel.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Cc: stable@kernel.org
-
Jan Kiszka authored
upstream commit 7a661013 Obtain the new pgd pointer before releasing the page containing this value. Cc: stable@kernel.org Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Reviewed-by:
Sheng Yang <sheng@linux.intel.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com>
-
Stanislaw Gruszka authored
[AK: Did some changes for the backport to .35. Stanislaw, please verify them] Since commit a120e912 Author: Stanislaw Gruszka <sgruszka@redhat.com> Date: Fri Feb 19 15:47:33 2010 -0800 iwlwifi: sanity check before counting number of tfds can be free we use skb->data after calling ieee80211_tx_status_irqsafe(), which could free skb instantly. On current kernels I do not observe practical problems related with bug, but on 2.6.35.y it cause random system hangs when stressing wireless link. Cc: stable@kernel.org # 2.6.32+ Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Lydia Wang authored
commit bff5fbf5 upstream. Modify function via_mux_enum_put() to fix stereo mixer recording no sound issue. Signed-off-by:
Lydia Wang <lydiawang@viatech.com.cn> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Lydia Wang authored
commit ab657e0c upstream. Modify mute_aa_path() function to support VT1718S codec. Signed-off-by:
Lydia Wang <lydiawang@viatech.com.cn> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Greg Kroah-Hartman authored
This reverts commit 05f7676d . To quote Len Brown: intel_idle was deemed a "feature", and thus not included in 2.6.33.stable, and thus 2.6.33.stable does not need this patch. so I'm removing it. Cc: Len Brown <len.brown@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Laurent Pinchart authored
commit 4093a5c4 upstream. Commit 4057ac6c V4L/DVB (13505): uvcvideo: Refactor chain scan broke output terminals parsing. Fix it. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Fry, Donald H authored
commit 41504cce upstream. New iwlwifi-5000 microcode requires driver support for API version 5. Signed-off-by:
Don Fry <donald.h.fry@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Stefan Haberland authored
commit 5da24b76 upstream. The 3880 storage control unit supports a 3380 device type, but not a 3390 device type. Reported-by:
Stephen Powell <zlinuxman@wowway.com> Signed-off-by:
Stefan Haberland <stefan.haberland@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Cc: Stephen Powell <zlinuxman@wowway.com> Cc: Jonathan Nieder <jrnieder@gmail.com> Cc: Bastian Blank <waldi@debian.org>
-
Greg Rose authored
commit b1d670f1 upstream. declaration. Reported-by:
Andi Kleen <andi@firstfloor.org> Signed-off-by:
Greg Rose <gregory.v.rose@intel.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Tested-by:
Emil Tantilov <emil.s.tantilov@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Andreas Radke <a.radke@arcor.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Artem Bityutskiy authored
commit 6e0d9fd3 upstream. This patch fixes the following symptoms: 1. Unmount UBIFS cleanly. 2. Start mounting UBIFS R/W and have a power cut immediately 3. Start mounting UBIFS R/O, this succeeds 4. Try to re-mount UBIFS R/W - this fails immediately or later on, because UBIFS will write the master node to the flash area which has been written before. The analysis of the problem: 1. UBIFS is unmounted cleanly, both copies of the master node are clean. 2. UBIFS is being mounter R/W, starts changing master node copy 1, and a power cut happens. The copy N1 becomes corrupted. 3. UBIFS is being mounted R/O. It notices the copy N1 is corrupted and reads copy N2. Copy N2 is clean. 4. Because of R/O mode, UBIFS cannot recover copy 1. 5. The mount code (ubifs_mount()) sees that the master node is clean, so it decides that no recovery is needed. 6. We are re-mounting R/W. UBIFS believes no recovery is needed and starts updating the master node, but copy N1 is still corrupted and was not recovered! Fix this problem by marking the master node as dirty every time we recover it and we are in R/O mode. This forces further recovery and the UBIFS cleans-up the corruptions and recovers the copy N1 when re-mounting R/W later. Signed-off-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Ben Hutchings authored
commit 3ba41621 upstream. Commit 40aee729 ('kconfig: fix default value for choice input') fixed some cases where kconfig would select the wrong option from a choice with a single valid option and thus enter an infinite loop. However, this broke the test for user input of the form 'N?', because when kconfig selects the single valid option the input is zero-length and the test will read the byte before the input buffer. If this happens to contain '?' (as it will in a mips build on Debian unstable today) then kconfig again enters an infinite loop. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Mark Brown authored
commit 39cca168 upstream. The output PGA was not being powered up in headphone and speaker paths, removing the ability to offer volume control and mute with the output PGA. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by:
Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Uwe Kleine-König authored
commit 5680e941 upstream. If cts changes between reading the level at the cts input (USR1_RTSS) and acking the irq (USR1_RTSD) the last edge doesn't generate an irq and uart_handle_cts_change is called with a outdated value for cts. The race was introduced by commit ceca629e ([ARM] 2971/1: i.MX uart handle rts irq) Reported-by:
Arwed Springer <Arwed.Springer@de.trumpf.com> Tested-by:
Arwed Springer <Arwed.Springer@de.trumpf.com> Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Trond Myklebust authored
commit 27dc1cd3 upstream. If the call to nfs_wcc_update_inode() results in an attribute update, we need to ensure that the inode's attr_gencount gets bumped too, otherwise we are not protected against races with other GETATTR calls. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Alex Deucher authored
commit 8e461123 upstream. Noticed by Patrick Lowry. Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Alex Williamson authored
commit 2fe9723d upstream. If we run out of domain_ids and fail iommu_attach_domain(), we fall into domain_exit() without having setup enough of the domain structure for this to do anything useful. In fact, it typically runs off into the weeds walking the bogus domain->devices list. Just free the domain. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Acked-by:
Donald Dutile <ddutile@redhat.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Alex Williamson authored
commit a97590e5 upstream. When we remove a device, we unlink the iommu from the domain, but we never do the reverse unlinking of the domain from the iommu. This means that we never clear iommu->domain_ids, eventually leading to resource exhaustion if we repeatedly bind and unbind a device to a driver. Also free empty domains to avoid a resource leak. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Acked-by:
Donald Dutile <ddutile@redhat.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Joerg Roedel authored
commit 665d3e2a upstream. The GART can only map physical memory below 1TB. Make sure the gart driver in the kernel does not try to map memory above 1TB. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Link: http://lkml.kernel.org/r/1303134346-5805-5-git-send-email-joerg.roedel@amd.com Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jason Conti authored
commit a6756da9 upstream. This patch fixes a very serious off-by-one bug in the driver, which could leave the device in an unresponsive state. The problem was that the extra_len variable [used to reserve extra scratch buffer space for the firmware] was left uninitialized. Because p54_assign_address later needs the value to reserve additional space, the resulting frame could be to big for the small device's memory window and everything would immediately come to a grinding halt. Reference: https://bugs.launchpad.net/bugs/722185 Acked-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
Jason Conti <jason.conti@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Liu Yuan authored
commit ed5302d3 upstream. We do not call blk_trace_remove_sysfs() in err return path if kobject_add() fails. This path fixes it. Signed-off-by:
Liu Yuan <tailai.ly@taobao.com> Signed-off-by:
Jens Axboe <jaxboe@fusionio.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Christian Lamparter authored
commit bd39a274 upstream. Joe Culler reported a problem with his AR9170 device: > ath: EEPROM regdomain: 0x5c > ath: EEPROM indicates we should expect a direct regpair map > ath: invalid regulatory domain/country code 0x5c > ath: Invalid EEPROM contents It turned out that the regdomain 'APL7_FCCA' was not mapped yet. According to Luis R. Rodriguez [Atheros' engineer] APL7 maps to FCC_CTL and FCCA maps to FCC_CTL as well, so the attached patch should be correct. Reported-by:
Joe Culler <joe.culler@gmail.com> Acked-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Felix Fietkau authored
[ upstream commit f62d816f ] When the chip is still asleep when ath9k_start is called, ath9k_hw_configpcipowersave can trigger a data bus error. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Cc: stable@kernel.org Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Jan Beulich authored
[ upstream commit 70874867 ] 'struct dmi_system_id' arrays must always have a terminator to keep dmi_check_system() from looking at data (and possibly crashing) it isn't supposed to look at. The issue went unnoticed until ef8313bb, but was introduced about a year earlier with 7705d548 (which also similarly changed lifebook.c, but the problem there got eliminated shortly afterwards). The first hunk therefore is a stable candidate back to 2.6.33, while the full change is needed only on 2.6.38. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Cc: stable@kernel.org Signed-off-by:
Dmitry Torokhov <dtor@mail.ru>
-
Kees Cook authored
commit 5b919f83 upstream. Commit fe10ae53 adds a memset() to clear the structure being sent back to userspace, but accidentally used the wrong size. Reported-by:
Brad Spengler <spender@grsecurity.net> Signed-off-by:
Kees Cook <kees.cook@canonical.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Hans Rosenfeld authored
commit 07a7795c upstream. A bug in the family-model-stepping matching code caused the presence of errata to go undetected when OSVW was not used. This causes hangs on some K8 systems because the E400 workaround is not enabled. Signed-off-by:
Hans Rosenfeld <hans.rosenfeld@amd.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com> LKML-Reference: <1282141190-930137-1-git-send-email-hans.rosenfeld@amd.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Dmitry Torokhov authored
commit dfa49c4a upstream. When parsing exponent-expressed intervals we subtract 1 from the value and then expect it to match with original + 1, which is highly unlikely, and we end with frequent spew: usb 3-4: ep 0x83 - rounding interval to 512 microframes Also, parsing interval for fullspeed isochronous endpoints was incorrect - according to USB spec they use exponent-based intervals (but xHCI spec claims frame-based intervals). I trust USB spec more, especially since USB core agrees with it. This should be queued for stable kernels back to 2.6.31. Reviewed-by:
Micah Elizabeth Scott <micah@vmware.com> Signed-off-by:
Dmitry Torokhov <dtor@vmware.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Dmitry Torokhov authored
commit 5a6c2f3f upstream. Macro arguments used in expressions need to be enclosed in parenthesis to avoid unpleasant surprises. This should be queued for kernels back to 2.6.31 Signed-off-by:
Dmitry Torokhov <dtor@vmware.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Dmitry Torokhov authored
commit 2868a2b1 upstream. Isochronous and interrupt SuperSpeed endpoints use the same mechanisms for decoding bInterval values as HighSpeed ones so adjust the code accordingly. Also bandwidth reservation for SuperSpeed matches highspeed, not low/full speed. Signed-off-by:
Dmitry Torokhov <dtor@vmware.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Alan Stern authored
commit 94ae4976 upstream. This patch (as1458) fixes a problem affecting ultra-reliable systems: When hardware failover of an EHCI controller occurs, the data structures do not get released correctly. This is because the routine responsible for removing unused QHs from the async schedule assumes the controller is running properly (the frame counter is used in determining how long the QH has been idle) -- but when a failover causes the controller to be electronically disconnected from the PCI bus, obviously it stops running. The solution is simple: Allow scan_async() to remove a QH from the async schedule if it has been idle for long enough _or_ if the controller is stopped. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Reported-and-Tested-by:
Dan Duval <dan.duval@stratus.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Linus Torvalds authored
commit d8bdc59f upstream. Rather than pass in some random truncated offset to the pid-related functions, check that the offset is in range up-front. This is just cleanup, the previous commit fixed the real problem. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Linus Torvalds authored
commit c78193e9 upstream. next_pidmap() just quietly accepted whatever 'last' pid that was passed in, which is not all that safe when one of the users is /proc. Admittedly the proc code should do some sanity checking on the range (and that will be the next commit), but that doesn't mean that the helper functions should just do that pidmap pointer arithmetic without checking the range of its arguments. So clamp 'last' to PID_MAX_LIMIT. The fact that we then do "last+1" doesn't really matter, the for-loop does check against the end of the pidmap array properly (it's only the actual pointer arithmetic overflow case we need to worry about, and going one bit beyond isn't going to overflow). [ Use PID_MAX_LIMIT rather than pid_max as per Eric Biederman ] Reported-by:
Tavis Ormandy <taviso@cmpxchg8b.com> Analyzed-by:
Robert Święcki <robert@swiecki.net> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Pavel Emelyanov <xemul@openvz.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Marius B. Kotsbak authored
commit 80f9df3e upstream. Bind only modem AT command endpoint to option. Signed-off-by:
Marius B. Kotsbak <marius@kotsbak.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Enrico Mioso authored
commit c6991b6f upstream. This patch, adds to the option driver the Onda Communication (http://www.ondacommunication.com ) vendor id, and the MT825UP modem device id. Note that many variants of this same device are being release here in Italy (at least one or two per telephony operator). These devices are perfectly equivalent except for some predefined settings (which can be changed of course). It should be noted that most ONDA devices are allready supported (they used other vendor's ids in the past). The patch seems working fine here, and the rest of the driver seems uninfluenced. Signed-off-by:
Enrico Mioso <mrkiko.rs@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-