- 09 May, 2011 40 commits
-
-
Bruce Rogers authored
commit 3e9d08ec upstream. Under harsh testing conditions, including low memory, the guest would stop receiving packets. With this patch applied we no longer see any problems in the driver while performing these tests for extended periods of time. Make sure napi is scheduled subsequent to each napi_enable. Signed-off-by:
Bruce Rogers <brogers@novell.com> Signed-off-by:
Olaf Kirch <okir@suse.de> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> [bwh: Adjust for 2.6.32] Signed-off-by:
-
Edgar (gimli) Hucek authored
commit 87232dd4 upstream. This patch add support for the MacBookAir3,1 and MacBookAir3,2 to the alsa sound system. Signed-off-by:
Edgar (gimli) Hucek <gimli@dark-green.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit f46119b7 upstream. Reference: Novell bnc#645066 https://bugzilla.novell.com/show_bug.cgi?id=645066Signed-off-by:
-
Vince Weaver authored
commit 4e7d7c60 upstream. I've found the following patch is necessary to enable line-in on my MacBookPro 5,3 machine. With the patch applied I've successfully recorded audio from the line-in jack. This is based on the existing 5,5 support. Signed-off-by:
Vince Weaver <vweaver1@eecs.utk.edu> Signed-off-by:
-
Rafael Avila de Espindola authored
commit 1a5ba2e9 upstream. With the attached patch I am able to use the sound on a new IMac 27. What works: *) Internal speakers *) Internal microphone *) Headphone I don't have an external mic or a SPDIF device to test the rest. Signed-off-by:
Rafael Avila de Espindola <rafael.espindola@gmail.com> Signed-off-by:
-
Risto Suominen authored
commit b6d73350 upstream. Lineout (Pro Speaker) detection on PowerMac G4 Digital Audio (Tumbler). Signed-off-by:
Risto Suominen <Risto.Suominen@gmail.com> Signed-off-by:
-
Risto Suominen authored
commit 819ef70b upstream. Reverse headphone detection bit on PowerMac G4 Digital Audio (Tumbler). Signed-off-by:
-
Ben Hutchings authored
commit a254dba3 upstream. Reported-by:
Carmen Cru <carmen.cru@belgacom.net> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Edgar Hucek authored
commit 132af032 upstream. This patch add support for the MacBookAir3,1 and MacBookAir3,2 to the applesmc driver. [rydberg@euromail.se: minor cleanup] Signed-off-by:
Henrik Rydberg <rydberg@euromail.se> Signed-off-by:
Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by:
-
Henrik Rydberg authored
commit 405eaa1c upstream. This patch adds generic support for the MacBook Pro 7 family based on the 7,1 model. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Bernhard Froemel authored
commit 872bad55 upstream. This patch adds generic support for the MacBook Pro 6 family based on the 6,2 model. [rydberg@euromail.se: patch cleanup] Signed-off-by:
Bernhard Froemel <froemel@vmars.tuwien.ac.at> Signed-off-by:
-
Henrik Rydberg authored
commit 4e4a99d3 upstream. The MacBookPro 5,3 model has two fans, whereas the 5,4 model has only one. This patch adds explicit support for the 5,3 and 5,4 models. Signed-off-by:
-
Justin P. Mattock authored
commit e1741712 upstream. Add the iMac9,1 and the MacBookPro2,2 temperature sensors to hwmon driver applesmc to fix kernel bug #14429: https://bugzilla.kernel.org/show_bug.cgi?id=14429Signed-off-by:
Justin P. Mattock <justinmattock@gmail.com> Acked-by:
Nicolas Boichat <nicolas@boichat.ch> Signed-off-by:
-
Ron Murray authored
commit 60abe782 upstream. Please add support for Microsoft MN-120 PCMCIA network card. It's an old card, I know, but adding support is very easy. You just need to get tulip_core.c to recognise its vendor/device ID. Patch for kernel 2.6.32.4 (and many previous) attached. .....Ron Murray Signed-off-by:
Ron Murray <rjmx@rjmx.net> Signed-off-by:
-
Linus Torvalds authored
commit 34d211a2 upstream. It turns out that while a maximum of 8 partitions may be what people "should" have had, you can actually fit up to 18 entries(*) in a sector. And some people clearly were taking advantage of that, like Michael Cree, who had ten partitions on one of his OSF disks. (*) The OSF partition data starts at byte offset 64 in the first sector, and the array of 16-byte partition entries start at offset 148 in the on-disk partition structure. Reported-by:
Michael Cree <mcree@orcon.net.nz> Cc: stable@kernel.org (v2.6.38) Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Timo Warns authored
commit 1eafbfeb upstream. The kernel automatically evaluates partition tables of storage devices. The code for evaluating OSF partitions contains a bug that leaks data from kernel heap memory to userspace for certain corrupted OSF partitions. In more detail: for (i = 0 ; i < le16_to_cpu(label->d_npartitions); i++, partition++) { iterates from 0 to d_npartitions - 1, where d_npartitions is read from the partition table without validation and partition is a pointer to an array of at most 8 d_partitions. Add the proper and obvious validation. Signed-off-by:
Timo Warns <warns@pre-sense.de> Cc: stable@kernel.org [ Changed the patch trivially to not repeat the whole le16_to_cpu() thing, and to use an explicit constant for the magic value '8' ] Signed-off-by:
-
Jovi Zhang authored
commit 43b7c3f0 upstream. this commit fix compilation warning as following: linux-2.6/fs/nfs/nfs4proc.c:3265: warning: comparison of distinct pointer types lacks a cast Signed-off-by:
Jovi Zhang <bookjovi@gmail.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Neil Horman authored
commit e9e3d724 upstream. The "bad_page()" page allocator sanity check was reported recently (call chain as follows): bad_page+0x69/0x91 free_hot_cold_page+0x81/0x144 skb_release_data+0x5f/0x98 __kfree_skb+0x11/0x1a tcp_ack+0x6a3/0x1868 tcp_rcv_established+0x7a6/0x8b9 tcp_v4_do_rcv+0x2a/0x2fa tcp_v4_rcv+0x9a2/0x9f6 do_timer+0x2df/0x52c ip_local_deliver+0x19d/0x263 ip_rcv+0x539/0x57c netif_receive_skb+0x470/0x49f :virtio_net:virtnet_poll+0x46b/0x5c5 net_rx_action+0xac/0x1b3 __do_softirq+0x89/0x133 call_softirq+0x1c/0x28 do_softirq+0x2c/0x7d do_IRQ+0xec/0xf5 default_idle+0x0/0x50 ret_from_intr+0x0/0xa default_idle+0x29/0x50 cpu_idle+0x95/0xb8 start_kernel+0x220/0x225 _sinittext+0x22f/0x236 It occurs because an skb with a fraglist was freed from the tcp retransmit queue when it was acked, but a page on that fraglist had PG_Slab set (indicating it was allocated from the Slab allocator (which means the free path above can't safely free it via put_page. We tracked this back to an nfsv4 setacl operation, in which the nfs code attempted to fill convert the passed in buffer to an array of pages in __nfs4_proc_set_acl, which gets used by the skb->frags list in xs_sendpages. __nfs4_proc_set_acl just converts each page in the buffer to a page struct via virt_to_page, but the vfs allocates the buffer via kmalloc, meaning the PG_slab bit is set. We can't create a buffer with kmalloc and free it later in the tcp ack path with put_page, so we need to either: 1) ensure that when we create the list of pages, no page struct has PG_Slab set or 2) not use a page list to send this data Given that these buffers can be multiple pages and arbitrarily sized, I think (1) is the right way to go. I've written the below patch to allocate a page from the buddy allocator directly and copy the data over to it. This ensures that we have a put_page free-able page for every entry that winds up on an skb frag list, so it can be safely freed when the frame is acked. We do a put page on each entry after the rpc_call_sync call so as to drop our own reference count to the page, leaving only the ref count taken by tcp_sendpages. This way the data will be properly freed when the ack comes in Successfully tested by myself to solve the above oops. Note, as this is the result of a setacl operation that exceeded a page of data, I think this amounts to a local DOS triggerable by an uprivlidged user, so I'm CCing security on this as well. Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> CC: Trond Myklebust <Trond.Myklebust@netapp.com> CC: security@kernel.org CC: Jeff Layton <jlayton@redhat.com> Signed-off-by:
-
Andy Chittenden authored
commit 669502ff upstream. When reusing a TCP connection, ensure that it's aborted if a previous shutdown attempt has been made on that connection so that the RPC over TCP recovery mechanism succeeds. Signed-off-by:
Andy Chittenden <andyc.bluearc@gmail.com> Signed-off-by:
-
Abhijith Das authored
commit 8b421601 upstream. HighMem pages on i686 do not get mapped to the buffer_heads and this was causing a NULL pointer dereference when we were trying to memset page buffers to zero. We now use zero_user() that kmaps the page and directly manipulates page data. This patch also fixes a boundary condition that was incorrect. Signed-off-by:
Abhi Das <adas@redhat.com> Signed-off-by:
Steven Whitehouse <swhiteho@redhat.com> [Adjusted to apply to 2.6.32 by dann frazier <dannf@debian.org>] Signed-off-by:
-
Abhijith Das authored
commit 7e619bc3 upstream. This is the upstream fix for this bug. This patch differs from the RHEL5 fix (Red Hat bz #555754) which simply writes to the 8-byte value field of the quota. In upstream quota code, we're required to write the entire quota (88 bytes) which can be split across a page boundary. We check for such quotas, and read/write the two parts from/to the corresponding pages holding these parts. With this patch, I don't see the bug anymore using the reproducer in Red Hat bz 555754. I successfully ran a couple of simple tests/mounts/ umounts and it doesn't seem like this patch breaks anything else. Signed-off-by:
-
Steven Whitehouse authored
commit 1e72c0f7 upstream. Both of these functions contained confusing and in one case duplicate code. This patch adds a new check in do_glock() so that we report -ENOENT if we are asked to sync a quota entry which doesn't exist. Due to the previous patch this is now reported correctly to userspace. Also there are a few new comments, and I hope that the code is easier to understand now. Signed-off-by:
-
Alan Stern authored
commit 834e2312 upstream. USB: teach "devices" file about Wireless and SuperSpeed USB The /sys/kernel/debug/usb/devices file doesn't know about Wireless or SuperSpeed USB. This patch (as1416b) teaches it, and updates the Documentation/usb/proc_sub_info.txt file accordingly. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> CC: David Vrabel <david.vrabel@csr.com> CC: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Alan Stern authored
commit 7aba8d01 upstream. This patch (as1364) avoids enabling remote wakeup by default on all non-root-hub USB devices. Individual drivers or userspace will have to enable it wherever it is needed, such as for keyboards or network interfaces. Note: This affects only system sleep, not autosuspend. External hubs will continue to relay wakeup requests received from downstream through their upstream port, even when remote wakeup is not enabled for the hub itself. Disabling remote wakeup on a hub merely prevents it from generating wakeup requests in response to connect, disconnect, and overcurrent events. Signed-off-by:
-
Dan Streetman authored
commit 16985408 upstream. Currently a non-root-hub USB device's wakeup settings are initialized when the device is set to a configured state using device_init_wakeup(), but this is not correct as wakeup is split into "capable" (can_wakeup) and "enabled" (should_wakeup). The settings should be initialized instead in the device initialization (usb_new_device) with the "capable" setting disabled and the "enabled" setting enabled. The "capable" setting should be set based on the device being configured or unconfigured, and "enabled" setting set based on the sysfs power/wakeup control. This patch retains the sysfs power/wakeup setting of a non-root-hub USB device over a USB device re-configuration, which can happen (for example) after a suspend/resume cycle. Signed-off-by:
Dan Streetman <ddstreet@ieee.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Florian Schilhabel authored
commit 15d93ed0 upstream. This patch adds some device ids. The list of supported devices was extracted from realteks driver package. (0x050d, 0x815F) and (0x0df6, 0x004b) are not in the official list of supported devices and may not work correctly. In case of problems with these, they should probably be removed from the list. Signed-off-by:
Florian Schilhabel <florian.c.schilhabel@googlemail.com> Signed-off-by:
-
Florian Schilhabel authored
commit 60b42de3 upstream. This patch removes some device-ids. The list of unsupported devices was extracted from realteks driver package. removed IDs are: (0x0bda, 0x8192) (0x0bda, 0x8709) (0x07aa, 0x0043) (0x050d, 0x805E) (0x0df6, 0x0031) (0x1740, 0x9201) (0x2001, 0x3301) (0x5a57, 0x0290) These devices are _not_ rtl819su based. Signed-off-by:
-
Ben Hutchings authored
commit 41a38d9e upstream. The current code creates directories in procfs named after interfaces, but doesn't handle renaming. This can result in name collisions and consequent WARNINGs. It also means that the interface name cannot reliably be used to remove the directory - in fact the current code doesn't even try, and always uses "wlan0"! Since the name of a proc_dir_entry is embedded in it, use that when removing it. Add a netdev notifier to catch interface renaming, and remove and re-add the directory at this point. Signed-off-by:
-
Ben Hutchings authored
commit 9a3dfa05 upstream. Currently various resources may be leaked in case of an error. Signed-off-by:
-
Florian Schilhabel authored
commit 199ef62a upstream. added 2 checks for skb == NULL. plus cosmetics Signed-off-by:
-
Éric Piel authored
commit 7f29f17b upstream. According to the Dell/Ubuntu driver, what was previously observed as "jumpy cursor" corresponds to the hardware sending incorrect data for the first two reports of a one touch finger. So let's use the same workaround as in the other driver. Also, detect another firmware version with the same behaviour, as in the other driver. Signed-off-by:
Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> [bwh: Adjust for 2.6.32] Signed-off-by:
-
Dmitry Torokhov authored
commit a083632e upstream. Apparently there are Elantech touchpads that report non-zero in the 2nd byte of their signature. Adjust the detection routine so that if 2nd byte is zero and 3rd byte contains value that is not a valid report rate, we still assume that signature is valid. Tested-by:
-
Dmitry Torokhov authored
commit 504e8bee upstream. Apparently all 3 bytes returned by ETP_FW_VERSION_QUERY are significant and should be taken into account when matching hardware version/features. Tested-by:
-
Florian Ragwitz authored
commit e938fbfd upstream. In older versions of the elantech hardware/firmware those bits always were unset, so it didn't actually matter, but newer versions seem to use those high bits for something else, screwing up the coordinates we report to the input layer for those devices. Signed-off-by:
Florian Ragwitz <rafl@debian.org> Signed-off-by:
-
Florian Ragwitz authored
commit f81bc788 upstream. Apparently hardware vendors now ship elantech touchpads with different version magic. This options allows for them to be tested easier with the current driver in order to add their magic to the whitelist later. Signed-off-by:
-
Florian Ragwitz authored
commit 225c61aa upstream. The check determining whether device should use 4- or 6-byte packets was trying to compare firmware with 2.48, but was failing on majors greater than 2. The new check ensures that versions like 4.1 are checked properly. Signed-off-by:
-
Dmitry Torokhov authored
commit c7a1f3cc upstream. Elantech touchpads work in absolute mode and do not generate relative events so they should not be advertising them. Signed-off-by:
-
Takashi Iwai authored
commit 5f57d67d upstream. The new type of touchpads can be detected via a new query command 0x0c. The clickpad flags are in cap[0]:4 and cap[1]:0 bits. When the device is detected, the driver now reports only the left button as the supported buttons so that X11 driver can detect that the device is Clickpad. A Clickpad device gives the button events only as the middle button. The kernel driver morphs to the left button. The real handling of Clickpad is done rather in X driver side. Signed-off-by:
-
Ben Hutchings authored
commit b3ccbb24 upstream. Signed-off-by:
-
Ben Hutchings authored
commit 866691a2 upstream. Signed-off-by:
-
