- 16 Aug, 2011 40 commits
-
-
Klement Fish authored
[ Upstream commit fe66101f ] Addresses https://bugzilla.kernel.org/show_bug.cgi?id=34552Signed-off-by:
Klement Fish <klement2@azet.sk> Acked-by:
Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Tushar Gohad authored
[ Upstream commit 4203223a ] Fix the min and max bit lengths for AES-CTR (RFC3686) keys. The number of bits in key spec is the key length (128/256) plus 32 bits of nonce. This change takes care of the "Invalid key length" errors reported by setkey when specifying 288 bit keys for aes-ctr. Signed-off-by:
Tushar Gohad <tgohad@mvista.com> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Chris Clayton authored
[ Upstream commit a0295a3b ] Try to send to correct address this time! ---------- Forwarded Message ---------- Subject: [PATCH] Fix cdc-phonet build Date: Saturday 23 Jul 2011 From: Chris Clayton <chris2553@googlemail.com> To: linux-net@vger.kernel.org cdc-phonet does not presently build on linux-3.0 because there is no entry for it in drivers/net/Makefile. This patch adds that entry. Signed-off-by:
Chris Clayton <chris2553@googlemail.com> Signed-off-by:
-
Andy Gospodarek authored
[ Upstream commit f4bb2e9c ] When a bond contains a device where one name is the subset of another (eth1 and eth10, for example), one cannot properly set the primary device or the currently active device. This was reported and based on work by Takuma Umeya. I also verified the problem and tested that this fix resolves it. V2: A few did not like the the current code or my changes, so I refactored bonding_store_primary and bonding_store_active_slave to be a bit cleaner, dropped the use of strnicmp since we did not really need the comparison to be case insensitive, and formatted the input string from sysfs so a comparison to IFNAMSIZ could be used. I also discovered an error in bonding_store_active_slave that would modify bond->primary_slave rather than bond->curr_active_slave before forcing the bonding driver to choose a new active slave. V3: Actually sending the proper patch.... Signed-off-by:
Andy Gospodarek <andy@greyhouse.net> Reported-by:
Takuma Umeya <tumeya@redhat.com> Signed-off-by:
-
Neil Horman authored
[ Upstream commit 550fd08c ] After the last patch, We are left in a state in which only drivers calling ether_setup have IFF_TX_SKB_SHARING set (we assume that drivers touching real hardware call ether_setup for their net_devices and don't hold any state in their skbs. There are a handful of drivers that violate this assumption of course, and need to be fixed up. This patch identifies those drivers, and marks them as not being able to support the safe transmission of skbs by clearning the IFF_TX_SKB_SHARING flag in priv_flags Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> CC: Karsten Keil <isdn@linux-pingi.de> CC: "David S. Miller" <davem@davemloft.net> CC: Jay Vosburgh <fubar@us.ibm.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: Patrick McHardy <kaber@trash.net> CC: Krzysztof Halasa <khc@pm.waw.pl> CC: "John W. Linville" <linville@tuxdriver.com> CC: Greg Kroah-Hartman <gregkh@suse.de> CC: Marcel Holtmann <marcel@holtmann.org> CC: Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Neil Horman authored
[ Upstream commit d8873315 ] Pktgen attempts to transmit shared skbs to net devices, which can't be used by some drivers as they keep state information in skbs. This patch adds a flag marking drivers as being able to handle shared skbs in their tx path. Drivers are defaulted to being unable to do so, but calling ether_setup enables this flag, as 90% of the drivers calling ether_setup touch real hardware and can handle shared skbs. A subsequent patch will audit drivers to ensure that the flag is set properly Signed-off-by:
Jiri Pirko <jpirko@redhat.com> CC: Robert Olsson <robert.olsson@its.uu.se> CC: Eric Dumazet <eric.dumazet@gmail.com> CC: Alexey Dobriyan <adobriyan@gmail.com> CC: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Zoltan Kiss authored
[ Upstream commit b76d0789 ] If a device event generates gratuitous ARP messages, only primary address is used for sending. This patch iterates through the whole list. Tested with 2 IP addresses configuration on bonding interface. Signed-off-by:
Zoltan Kiss <schaman@sch.bme.hu> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit e1738bd9 ] commit 8efa8854 (sch_sfq: avoid giving spurious NET_XMIT_CN signals) forgot to call qdisc_tree_decrease_qlen() to signal upper levels that a packet (from another flow) was dropped, leading to various problems. With help from Michal Soltys and Michal Pokrywka, who did a bisection. Bugzilla ref: https://bugzilla.kernel.org/show_bug.cgi?id=39372 Debian ref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631945Reported-by:
Lucas Bocchi <lucas.bocchi@gmail.com> Reported-and-bisected-by:
Michal Pokrywka <wolfmoon@o2.pl> Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> CC: Michal Soltys <soltys@ziu.info> Acked-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Julia Lawall authored
[ Upstream commit 956837f7 ] Convert array index from the loop bound to the loop index. A simplified version of the semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression e1,e2,ar; @@ for(e1 = 0; e1 < e2; e1++) { <... ar[ - e2 + e1 ] ...> } // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
-
Julia Lawall authored
[ Upstream commit a1889c0d ] Convert array index from the loop bound to the loop index. A simplified version of the semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression e1,e2,ar; @@ for(e1 = 0; e1 < e2; e1++) { <... ar[ - e2 + e1 ] ...> } // </smpl> Signed-off-by:
-
Simon Horman authored
[ Upstream commit 7676e345 ] This resolves a panic on module removal. Reported-by:
Dave Jones <davej@redhat.com> Acked-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
Hans Schillstrom <hans.schillstrom@ericsson.com> Signed-off-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
-
Julian Anastasov authored
[ Upstream commit d547f727 ] compare_keys and ip_route_input_common rely on rt_oif for distinguishing of input and output routes with same keys values. But sometimes the input route has also same hash chain (keyed by iif != 0) with the output routes (keyed by orig_oif=0). Problem visible if running with small number of rhash_entries. Fix them to use rt_route_iif instead. By this way input route can not be returned to users that request output route. The patch fixes the ip_rt_bug errors that were reported in ip_local_out context, mostly for 255.255.255.255 destinations. Signed-off-by:
-
Bill Sommerfeld authored
[ Upstream commit d9be4f7a ] Because the ip fragment offset field counts 8-byte chunks, ip fragments other than the last must contain a multiple of 8 bytes of payload. ip_ufo_append_data wasn't respecting this constraint and, depending on the MTU and ip option sizes, could create malformed non-final fragments. Google-Bug-Id: 5009328 Signed-off-by:
Bill Sommerfeld <wsommerfeld@google.com> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 415b3334 ] icmp_route_lookup() uses the wrong flow parameters if the reverse session route lookup isn't used. So do not commit to the re-decoded flow until we actually make a final decision to use a real route saved in 'rt2'. Reported-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Eric Dumazet authored
[ Backport of upstream commit 87c48fa3 ] Fernando Gont reported current IPv6 fragment identification generation was not secure, because using a very predictable system-wide generator, allowing various attacks. IPv4 uses inetpeer cache to address this problem and to get good performance. We'll use this mechanism when IPv6 inetpeer is stable enough in linux-3.1 For the time being, we use jhash on destination address to provide less predictable identifications. Also remove a spinlock and use cmpxchg() to get better SMP performance. Reported-by:
Fernando Gont <fernando@gont.com.ar> Signed-off-by:
-
Clemens Ladisch authored
commit 824818b1 upstream. The Focusrite Scarlett 18i6 USB has them that way, which is probably a bug. Anyway, the driver should simply ignore this fact. Signed-off-by:
Daniel Mack <zonque@gmail.com> Reported-by:
Nicolai Krakowiak <nicolai.krakowiak@gmail.com> Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Daniel Mack authored
commit 1faa5d07 upstream. When creating the mixers for an USB audio device, the current code looks at the host interface stored in mixer->chip->ctrl_if. Change this and rather keep a local pointer to the interface that was given when snd_usb_create_mixer() was called. Signed-off-by:
Lean-Yves LENHOF <jean-yves@lenhof.eu.org> Acked-by:
-
Nicolai Krakowiak authored
commit 60c961a9 upstream. Signed-off-by:
-
Daniel Mack authored
commit f4389489 upstream. Signed-off-by:
Renato <naretobh@gmail.com> Signed-off-by:
-
Takashi Iwai authored
commit 0584ffa5 upstream. A slave-timer instance has no timer reference, and this results in NULL-dereference at stopping the timer, typically called at closing the device. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=40682Signed-off-by:
-
Wolfram Sang authored
commit 151798f8 upstream. Cache handling in this driver is broken. The chip has 16-bit registers, yet the register numbers also increase by 2 per register, i.e. there are only even-numbered registers. The cache in this driver, though, simply increments register numbers, so it does need some mapping as seen in sgtl5000_restore_regs(), note the '>> 1': snd_soc_write(codec, SGTL5000_CHIP_LINREG_CTRL, cache[SGTL5000_CHIP_LINREG_CTRL >> 1]); That, of course, won't work with snd_soc_update_bits(). (Thus, we won't even notice the missing register 0x1c in the default regs which shifted all follwing registers to wrong values.) Noticed on the MX28EVK where enabling the regulators simply locked up the chip. Refactor the routines and use a properly sized default_regs array which matches the register layout of the underlying chip, i.e. create a truly flat cache. This also saves some code which should make up for the bigger array a little. When soc-core will somewhen have another cache type which handles a step size, this conversion will also ease the transition. Signed-off-by:
Wolfram Sang <w.sang@pengutronix.de> Tested-by:
Dong Aisheng <b29396@freescale.com> Tested-by:
Shawn Guo <shawn.guo@linaro.org> Acked-by:
Liam Girdwood <lrg@ti.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Jeff Layton authored
commit f9e8c450 upstream. Regression from 2.6.39... The delimiters in the prefixpath are not being converted based on whether posix paths are in effect. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=727834Reported-and-Tested-by:
Iain Arnell <iarnell@gmail.com> Reported-by:
Patrick Oltmann <patrick.oltmann@gmx.net> Cc: Pavel Shilovsky <piastryyy@gmail.com> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Jeff Layton authored
commit 80975d21 upstream. The loop around lookup_one_len doesn't handle the case where it might return a negative dentry, which can cause an oops on the next pass through the loop. Check for that and break out of the loop with an error of -ENOENT if there is one. Fixes the panic reported here: https://bugzilla.redhat.com/show_bug.cgi?id=727927Reported-by:
TR Bentley <home@trarbentley.net> Reported-by:
-
Pavel Shilovsky authored
commit 0193e072 upstream. if we failed on getting mid entry in cifs_call_async. Signed-off-by:
Pavel Shilovsky <piastryyy@gmail.com> Signed-off-by:
-
Corentin Chary authored
commit 3df5fdad upstream. Signed-off-by:
Corentin Chary <corentin.chary@gmail.com> Signed-off-by:
Matthew Garrett <mjg@redhat.com> Signed-off-by:
-
Corentin Chary authored
commit 49979d09 upstream. The code was completly broken, and should never had been sent to the kernel. That's what happens when you write code without hardware to test it. Signed-off-by:
-
David S. Miller authored
Computers have become a lot faster since we compromised on the partial MD4 hash which we use currently for performance reasons. MD5 is a much safer choice, and is inline with both RFC1948 and other ISS generators (OpenBSD, Solaris, etc.) Furthermore, only having 24-bits of the sequence number be truly unpredictable is a very serious limitation. So the periodic regeneration and 8-bit counter have been removed. We compute and use a full 32-bit sequence number. For ipv6, DCCP was found to use a 32-bit truncated initial sequence number (it needs 43-bits) and that is fixed here as well. Reported-by:
Dan Kaminsky <dan@doxpara.com> Tested-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
-
David S. Miller authored
We are going to use this for TCP/IP sequence number and fragment ID generation. Signed-off-by:
-
Keith Packard authored
commit 40ee3381 upstream. drm_helper_hpd_irq_event queues another work proc to go and deliver the user-space event, and that function also wants to hold the config mutex, so we shouldn't hold the mutex across the drm_helper_hpd_irq_event call. Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
-
Keith Packard authored
commit a65e34c7 upstream. Hotplug detection is a mode setting operation and must hold the struct_mutex or risk colliding with other mode setting operations. In particular, the display port hotplug function attempts to re-train the link if the monitor is supposed to be running when plugged back in. If that happens while mode setting is underway, the link will get scrambled, leaving it in an inconsistent state. This is a special case -- usually the driver mode setting entry points are covered by the upper level DRM code, but in this case the function is invoked as a work function not under the control of DRM. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Keith Packard authored
commit f3234706 upstream. Physically-addressed hardware status pages are initialized early in the driver load process by i915_init_phys_hws. For UMS environments, the ring structure is not initialized until the X server starts. At that point, the entire ring structure is re-initialized with all new values. Any values set in the ring structure (including ring->status_page.page_addr) will be lost when the ring is re-initialized. This patch moves the initialization of the status_page.page_addr value to intel_render_ring_init_dri. Signed-off-by:
-
Ole Henrik Jahren authored
commit 842d4529 upstream. Because of a typo, calling ioctl with DRM_IOCTL_I915_OVERLAY_PUT_IMAGE is broken if the macro is used directly. When using libdrm the bug is not hit, since libdrm handles the ioctl encoding internally. The typo also leads to the .cmd and .cmd_drv fields of the drm_ioctl structure for DRM_I915_OVERLAY_PUT_IMAGE having inconsistent content. Signed-off-by:
Ole Henrik Jahren <olehenja@alumni.ntnu.no> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jesse Barnes authored
commit 9c54c0dd upstream. Per the specs and to address https://bugs.freedesktop.org/show_bug.cgi?id=36888. Signed-off-by:
-
Adam Jackson authored
commit 302983e9 upstream. Consider a 1600x900 panel, upscaling a 1360x768 mode, full-aspect. The old math would give you: scaled_width = 1600 * 768; /* 1228800 */ scaled_height = 1360 * 900; /* 1224000 */ if (scaled_width > scaled_height) { /* pillarbox, and true */ width = 1224000 / 768; /* int(1593.75) = 1593 */ x = (1600 - 1593 + 1) / 2; /* 4 */ y = 0; height = 768; } /* ... */ This is broken. The total width of scanout would then be 1593 + 4 + 4, or 1601, which is wider than the panel itself. The hardware very dutifully implements this, and you end up with a black 45° diagonal from the top-left corner to the bottom edge of the screen. It's a cool effect and all, but not what you wanted. Similar things happen for the letterbox case. The problem is that you have an integer number of pixels, which means it's usually impossible to upscale equally on both axes. 1360/768 is 1.7708, 1600/900 is 1.7777. Since we're constrained on the one axis, the other one wants to come out as an even number of pixels (the panel is almost certainly even on both axes, and the x/y offsets will be applied on both sides). In the math above, if 'width' comes out even, rounding down is correct; if it's odd, you'd rather round up. So just increment width/height in those cases. Tested on a Lenovo T500 (Ironlake). Signed-off-by:
Adam Jackson <ajax@redhat.com> Tested-By:
Daniel Manrique <daniel.manrique@canonical.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38851Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Thomas Reim authored
commit d522d9cc upstream. Log PCI subsystem vendor and subsystem device ID in addition to PCI vendor and device ID during kernel mode initialisation. This helps to better identify radeon devices of third-party vendors, e. g. for bug analysis. Tested for kernel 2.6.35, 2.6.38 and 3.0 on Asus M2A-VM HDMI board Signed-off-by:
Thomas Reim <reimth@gmail.com> Reviewed-by:
Alex Deucher <alexdeucher@gmail.com> Acked-by:
Stephen Michaels <Stephen.Micheals@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Thomas Reim authored
commit a81b31e9 upstream. ECS A740GM-M with ATI RADEON 2100 sends data to i2c bus for a DVI connector that is not implemented/existent on the board. Fix by applying extented DDC probing for this connector. Requires [PATCH] drm/radeon: Extended DDC Probing for Connectors with Improperly Wired DDC Lines Tested for kernel 2.6.38 on Asus ECS A740GM-M board BugLink: http://bugs.launchpad.net/bugs/810926Signed-off-by:
-
Thomas Reim authored
drm/radeon: Extended DDC Probing for Connectors with Improperly Wired DDC Lines (here: Asus M2A-VM HDMI) commit e384fab8 upstream. Some integrated ATI Radeon chipset implementations with add-on HDMI card (e. g. Asus M2A-VM HDMI) indicate the availability of a DDC even when the add-on card is not plugged in or HDMI is disabled in BIOS setup. In this case, drm_get_edid() and drm_edid_block_valid() periodically dump data and kernel errors into system log files and onto terminals. For these connectors DDC probing is extended by a check for a correct EDID header. Only in case a valid EDID header is also found, the (HDMI or DVI) connector will be used by the Radeon driver. This prevents the kernel driver from useless flooding of logs and terminal sessions with EDID dumps and error messages. This patch adds a flag 'requires_extended_probe' to the radeon_connector structure. In function radeon_connector_needs_extended_probe() this flag can be set on a chipset family/vendor/connector type specific basis. In addition, function radeon_ddc_probe() has been adapted to perform extended DDC probing if required by the connector's flag. Requires function drm_edid_header_is_valid() in DRM module provided by [PATCH] drm: Separate EDID Header Check from EDID Block Check. Tested for kernel 2.6.35, 2.6.38 and 3.0 on Asus M2A-VM HDMI board BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=668196 BugLink: http://bugs.launchpad.net/bugs/7228066Signed-off-by:
-
Thomas Reim authored
commit 051963d4 upstream. Provides function drm_edid_header_is_valid() for EDID header check and replaces EDID header check part of function drm_edid_block_valid() by a call of drm_edid_header_is_valid(). This is a prerequisite to extend DDC probing, e. g. in function radeon_ddc_probe() for Radeon devices, by a central EDID header check. Tested for kernel 2.6.35, 2.6.38 and 3.0 Signed-off-by:
-
Jeremy Fitzhardinge authored
commit c2419b4a upstream. Get the information about the VGA console hardware from Xen, and put it into the form the bootloader normally generates, so that the rest of the kernel can deal with VGA as usual. [ Impact: make VGA console work in dom0 ] Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> [v1: Rebased on 2.6.39] [v2: Removed incorrect comments and fixed compile warnings] Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Tetsuo Handa authored
commit c71d8ebe upstream. The sendmmsg() introduced by commit 228e548e "net: Add sendmmsg socket system call" is capable of sending to multiple different destination addresses. SMACK is using destination's address for checking sendmsg() permission. However, security_socket_sendmsg() is called for only once even if multiple different destination addresses are passed to sendmmsg(). Therefore, we need to call security_socket_sendmsg() for each destination address rather than only the first destination address. Since calling security_socket_sendmsg() every time when only single destination address was passed to sendmmsg() is a waste of time, omit calling security_socket_sendmsg() unless destination address of previous datagram and that of current datagram differs. Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
