- 13 Oct, 2013 34 commits
-
-
Peter Korsgaard authored
[ Upstream commit bf0ea638 ] Pass-all-multicast is controlled by bit 3 in RX control, not bit 2 (pass undersized frames). Reported-by:
Joseph Chang <joseph_chang@davicom.com.tw> Signed-off-by:
Peter Korsgaard <peter@korsgaard.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eric Dumazet authored
[ Upstream commit 9a3bab6b ] A host might need net_secret[] and never open a single socket. Problem added in commit aebda156 ("net: defer net_secret[] initialization") Based on prior patch from Hannes Frederic Sowa. Reported-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Hannes Frederic Sowa <hannes@strressinduktion.org> Signed-off-by:
-
Catalin(ux) M. BOIE authored
[ Upstream commit 7df37ff3 ] When a router is doing DNAT for 6to4/6rd packets the latest anti-spoofing commit 218774dc ("ipv6: add anti-spoofing checks for 6to4 and 6rd") will drop them because the IPv6 address embedded does not match the IPv4 destination. This patch will allow them to pass by testing if we have an address that matches on 6to4/6rd interface. I have been hit by this problem using Fedora and IPV6TO4_IPV4ADDR. Also, log the dropped packets (with rate limit). Signed-off-by:
Catalin(ux) M. BOIE <catab@embedromix.ro> Acked-by:
-
Roger Luethi authored
[ Upstream commit 207070f5 ] Outgoing packets sent by via-rhine have their VLAN PCP field off by one (when hardware acceleration is enabled). The TX descriptor expects only VID and PCP (without a CFI/DEI bit). Peter Boström noticed and reported the bug. Signed-off-by:
Roger Luethi <rl@hellgate.ch> Cc: Peter Boström <peter.bostrom@netrounds.com> Signed-off-by:
-
Hannes Frederic Sowa authored
[ Upstream commit 2811ebac ] In the following scenario the socket is corked: If the first UDP packet is larger then the mtu we try to append it to the write queue via ip6_ufo_append_data. A following packet, which is smaller than the mtu would be appended to the already queued up gso-skb via plain ip6_append_data. This causes random memory corruptions. In ip6_ufo_append_data we also have to be careful to not queue up the same skb multiple times. So setup the gso frame only when no first skb is available. This also fixes a shortcoming where we add the current packet's length to cork->length but return early because of a packet > mtu with dontfrag set (instead of sutracting it again). Found with trinity. Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
-
Ansis Atteka authored
[ Upstream commit 703133de ] If local fragmentation is allowed, then ip_select_ident() and ip_select_ident_more() need to generate unique IDs to ensure correct defragmentation on the peer. For example, if IPsec (tunnel mode) has to encrypt large skbs that have local_df bit set, then all IP fragments that belonged to different ESP datagrams would have used the same identificator. If one of these IP fragments would get lost or reordered, then peer could possibly stitch together wrong IP fragments that did not belong to the same datagram. This would lead to a packet loss or data corruption. Signed-off-by:
Ansis Atteka <aatteka@nicira.com> Signed-off-by:
-
Ansis Atteka authored
[ Upstream commit 749154aa ] skb->data already points to IP header, but for the sake of consistency we can also use ip_hdr() to retrieve it. Signed-off-by:
-
Duan Jiong authored
[ Upstream commit bd784a14 ] DCCP shouldn't be setting sk_err on redirects as it isn't an error condition. it should be doing exactly what tcp is doing and leaving the error handler without touching the socket. Signed-off-by:
Duan Jiong <duanj.fnst@cn.fujitsu.com> Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit 3f96a532 ] Adapt the same behaviour for SCTP as present in TCP for ICMP redirect messages. For IPv6, RFC4443, section 2.4. says: ... (e) An ICMPv6 error message MUST NOT be originated as a result of receiving the following: ... (e.2) An ICMPv6 redirect message [IPv6-DISC]. ... Therefore, do not report an error to user space, just invoke dst's redirect callback and leave, same for IPv4 as done in TCP as well. The implication w/o having this patch could be that the reception of such packets would generate a poll notification and in worst case it could even tear down the whole connection. Therefore, stop updating sk_err on redirects. Reported-by:
Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
-
Ding Zhi authored
[ Upstream commit 0d2ede92 ] IFLA_IPTUN_LOCAL and IFLA_IPTUN_REMOTE were inverted. Introduced by c075b130 (ip6tnl: advertise tunnel param via rtnl). Signed-off-by:
Ding Zhi <zhi.ding@6wind.com> Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
-
Hong Zhiguo authored
[ Upstream commit 716ec052 ] The NULL deref happens when br_handle_frame is called between these 2 lines of del_nbp: dev->priv_flags &= ~IFF_BRIDGE_PORT; /* --> br_handle_frame is called at this time */ netdev_rx_handler_unregister(dev); In br_handle_frame the return of br_port_get_rcu(dev) is dereferenced without check but br_port_get_rcu(dev) returns NULL if: !(dev->priv_flags & IFF_BRIDGE_PORT) Eric Dumazet pointed out the testing of IFF_BRIDGE_PORT is not necessary here since we're in rcu_read_lock and we have synchronize_net() in netdev_rx_handler_unregister. So remove the testing of IFF_BRIDGE_PORT and by the previous patch, make sure br_port_get_rcu is called in bridging code. Signed-off-by:
Hong Zhiguo <zhiguohong@tencent.com> Acked-by:
-
Hong Zhiguo authored
[ Upstream commit 1fb1754a ] current br_port_get_rcu is problematic in bridging path (NULL deref). Change these calls in netlink path first. Signed-off-by:
-
Herbert Xu authored
[ Upstream commit be4f154d ] At some point limits were added to forward_delay. However, the limits are only enforced when STP is enabled. This created a scenario where you could have a value outside the allowed range while STP is disabled, which then stuck around even after STP is enabled. This patch fixes this by clamping the value when we enable STP. I had to move the locking around a bit to ensure that there is no window where someone could insert a value outside the range while we're in the middle of enabling STP. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Chris Healy authored
[ Upstream commit 9a062013 ] This changes the message_age_timer calculation to use the BPDU's max age as opposed to the local bridge's max age. This is in accordance with section 8.6.2.3.2 Step 2 of the 802.1D-1998 sprecification. With the current implementation, when running with very large bridge diameters, convergance will not always occur even if a root bridge is configured to have a longer max age. Tested successfully on bridge diameters of ~200. Signed-off-by:
Chris Healy <cphealy@gmail.com> Signed-off-by:
-
David Vrabel authored
[ Upstream commit 6e43fc04 ] When a VM is providing an iSCSI target and the LUN is used by the backend domain, the generated skbs for direct I/O writes to the disk have large, multi-page skb->data but no frags. With some lengths and starting offsets, xen_netbk_count_skb_slots() would be one short because the simple calculation of DIV_ROUND_UP(skb_headlen(), PAGE_SIZE) was not accounting for the decisions made by start_new_rx_buffer() which does not guarantee responses are fully packed. For example, a skb with length < 2 pages but which spans 3 pages would be counted as requiring 2 slots but would actually use 3 slots. skb->data: | 1111|222222222222|3333 | Fully packed, this would need 2 slots: |111122222222|22223333 | But because the 2nd page wholy fits into a slot it is not split across slots and goes into a slot of its own: |1111 |222222222222|3333 | Miscounting the number of slots means netback may push more responses than the number of available requests. This will cause the frontend to get very confused and report "Too many frags/slots". The frontend never recovers and will eventually BUG. Fix this by counting the number of required slots more carefully. In xen_netbk_count_skb_slots(), more closely follow the algorithm used by xen_netbk_gop_skb() by introducing xen_netbk_count_frag_slots() which is the dry-run equivalent of netbk_gop_frag_copy(). Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Acked-by:
Ian Campbell <ian.campbell@citrix.com> Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit 95ee6208 ] Alan Chester reported an issue with IPv6 on SCTP that IPsec traffic is not being encrypted, whereas on IPv4 it is. Setting up an AH + ESP transport does not seem to have the desired effect: SCTP + IPv4: 22:14:20.809645 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 116) 192.168.0.2 > 192.168.0.5: AH(spi=0x00000042,sumlen=16,seq=0x1): ESP(spi=0x00000044,seq=0x1), length 72 22:14:20.813270 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 340) 192.168.0.5 > 192.168.0.2: AH(spi=0x00000043,sumlen=16,seq=0x1): SCTP + IPv6: 22:31:19.215029 IP6 (class 0x02, hlim 64, next-header SCTP (132) payload length: 364) fe80::222:15ff:fe87:7fc.3333 > fe80::92e6:baff:fe0d:5a54.36767: sctp 1) [INIT ACK] [init tag: 747759530] [rwnd: 62464] [OS: 10] [MIS: 10] Moreover, Alan says: This problem was seen with both Racoon and Racoon2. Other people have seen this with OpenSwan. When IPsec is configured to encrypt all upper layer protocols the SCTP connection does not initialize. After using Wireshark to follow packets, this is because the SCTP packet leaves Box A unencrypted and Box B believes all upper layer protocols are to be encrypted so it drops this packet, causing the SCTP connection to fail to initialize. When IPsec is configured to encrypt just SCTP, the SCTP packets are observed unencrypted. In fact, using `socat sctp6-listen:3333 -` on one end and transferring "plaintext" string on the other end, results in cleartext on the wire where SCTP eventually does not report any errors, thus in the latter case that Alan reports, the non-paranoid user might think he's communicating over an encrypted transport on SCTP although he's not (tcpdump ... -X): ... 0x0030: 5d70 8e1a 0003 001a 177d eb6c 0000 0000 ]p.......}.l.... 0x0040: 0000 0000 706c 6169 6e74 6578 740a 0000 ....plaintext... Only in /proc/net/xfrm_stat we can see XfrmInTmplMismatch increasing on the receiver side. Initial follow-up analysis from Alan's bug report was done by Alexey Dobriyan. Also thanks to Vlad Yasevich for feedback on this. SCTP has its own implementation of sctp_v6_xmit() not calling inet6_csk_xmit(). This has the implication that it probably never really got updated along with changes in inet6_csk_xmit() and therefore does not seem to invoke xfrm handlers. SCTP's IPv4 xmit however, properly calls ip_queue_xmit() to do the work. Since a call to inet6_csk_xmit() would solve this problem, but result in unecessary route lookups, let us just use the cached flowi6 instead that we got through sctp_v6_get_dst(). Since all SCTP packets are being sent through sctp_packet_transmit(), we do the route lookup / flow caching in sctp_transport_route(), hold it in tp->dst and skb_dst_set() right after that. If we would alter fl6->daddr in sctp_v6_xmit() to np->opt->srcrt, we possibly could run into the same effect of not having xfrm layer pick it up, hence, use fl6_update_dst() in sctp_v6_get_dst() instead to get the correct source routed dst entry, which we assign to the skb. Also source address routing example from 62503411 ("sctp: fix sctp to work with ipv6 source address routing") still works with this patch! Nevertheless, in RFC5095 it is actually 'recommended' to not use that anyway due to traffic amplification [1]. So it seems we're not supposed to do that anyway in sctp_v6_xmit(). Moreover, if we overwrite the flow destination here, the lower IPv6 layer will be unable to put the correct destination address into IP header, as routing header is added in ipv6_push_nfrag_opts() but then probably with wrong final destination. Things aside, result of this patch is that we do not have any XfrmInTmplMismatch increase plus on the wire with this patch it now looks like: SCTP + IPv6: 08:17:47.074080 IP6 2620:52:0:102f:7a2b:cbff:fe27:1b0a > 2620:52:0:102f:213:72ff:fe32:7eba: AH(spi=0x00005fb4,seq=0x1): ESP(spi=0x00005fb5,seq=0x1), length 72 08:17:47.074264 IP6 2620:52:0:102f:213:72ff:fe32:7eba > 2620:52:0:102f:7a2b:cbff:fe27:1b0a: AH(spi=0x00003d54,seq=0x1): ESP(spi=0x00003d55,seq=0x1), length 296 This fixes Kernel Bugzilla 24412. This security issue seems to be present since 2.6.18 kernels. Lets just hope some big passive adversary in the wild didn't have its fun with that. lksctp-tools IPv6 regression test suite passes as well with this patch. [1] http://www.secdev.org/conf/IPv6_RH_security-csw07.pdfReported-by:
Alan Chester <alan.chester@tekelec.com> Reported-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Jason Wang authored
[ Upstream commit 662ca437 ] Commit c8d68e6b (tuntap: multiqueue support) only call free_netdev() on error in tun_set_iff(). This causes several issues: - memory of tun security were leaked - use after free since the flow gc timer was not deleted and the tfile were not detached This patch solves the above issues. Reported-by:
Wannes Rombouts <wannes.rombouts@epitech.eu> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Nikolay Aleksandrov authored
[ Upstream commit d0fe8c88 ] I've been hitting a NULL ptr deref while using netconsole because the np->dev check and the pointer manipulation in netpoll_cleanup are done without rtnl and the following sequence happens when having a netconsole over a vlan and we remove the vlan while disabling the netconsole: CPU 1 CPU2 removes vlan and calls the notifier enters store_enabled(), calls netdev_cleanup which checks np->dev and then waits for rtnl executes the netconsole netdev release notifier making np->dev == NULL and releases rtnl continues to dereference a member of np->dev which at this point is == NULL Signed-off-by:
Nikolay Aleksandrov <nikolay@redhat.com> Signed-off-by:
-
Sonic Zhang authored
[ Upstream commit b0dd663b ] The received ARP request type in the Ethernet packet head is ETH_P_ARP other than ETH_P_IP. [ Bug introduced by commit b7394d24 ("netpoll: prepare for ipv6") ] Signed-off-by:
Sonic Zhang <sonic.zhang@analog.com> Signed-off-by:
-
Francois Romieu authored
[ Upstream commit 3ced8c95 ] Same narrative as eb2dc35d ("r8169: RxConfig hack for the 8168evl.") regarding AMD IOMMU errors. RTL_GIGA_MAC_VER_36 - 8168f as well - has not been reported to behave the same. Tested-by:
David R <david@unsolicited.net> Tested-by:
Frédéric Leroy <fredo@starox.org> Cc: Hayes Wang <hayeswang@realtek.com> Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
-
Vimalkumar authored
[ Upstream commit f3ad857e ] Fix a typo added in commit 56b765b7 ("htb: improved accuracy at high rates") cbuffer should not be a copy of buffer. Signed-off-by:
Vimalkumar <j.vimal@gmail.com> Signed-off-by:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit b8678358 ] In commit 8ed78166 ("flow_keys: include thoff into flow_keys for later usage"), we missed that existing code was using nhoff as a temporary variable that could not always contain transport header offset. This is not a problem for TCP/UDP because port offset (@poff) is 0 for these protocols. Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 50d1784e ] commit 416186fb ("net: Split core bits of netdev_pick_tx into __netdev_pick_tx") added a bug that disables caching of queue index in the socket. This is the source of packet reorders for TCP flows, and again this is happening more often when using FQ pacing. Old code was doing if (queue_index != old_index) sk_tx_queue_set(sk, queue_index); Alexander renamed the variables but forgot to change sk_tx_queue_set() 2nd parameter. if (queue_index != new_index) sk_tx_queue_set(sk, queue_index); This means we store -1 over and over in sk->sk_tx_queue_mapping Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit 88362ad8 ] This was originally reported in [1] and posted by Neil Horman [2], he said: Fix up a missed null pointer check in the asconf code. If we don't find a local address, but we pass in an address length of more than 1, we may dereference a NULL laddr pointer. Currently this can't happen, as the only users of the function pass in the value 1 as the addrcnt parameter, but its not hot path, and it doesn't hurt to check for NULL should that ever be the case. The callpath from sctp_asconf_mgmt() looks okay. But this could be triggered from sctp_setsockopt_bindx() call with SCTP_BINDX_REM_ADDR and addrcnt > 1 while passing all possible addresses from the bind list to SCTP_BINDX_REM_ADDR so that we do *not* find a single address in the association's bind address list that is not in the packed array of addresses. If this happens when we have an established association with ASCONF-capable peers, then we could get a NULL pointer dereference as we only check for laddr == NULL && addrcnt == 1 and call later sctp_make_asconf_update_ip() with NULL laddr. BUT: this actually won't happen as sctp_bindx_rem() will catch such a case and return with an error earlier. As this is incredably unintuitive and error prone, add a check to catch at least future bugs here. As Neil says, its not hot path. Introduced by 8a07eb0a ("sctp: Add ASCONF operation on the single-homed host"). [1] http://www.spinics.net/lists/linux-sctp/msg02132.html [2] http://www.spinics.net/lists/linux-sctp/msg02133.htmlReported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit a0fb05d1 ] If we do not add braces around ... mask |= POLLERR | sock_flag(sk, SOCK_SELECT_ERR_QUEUE) ? POLLPRI : 0; ... then this condition always evaluates to true as POLLERR is defined as 8 and binary or'd with whatever result comes out of sock_flag(). Hence instead of (X | Y) ? A : B, transform it into X | (Y ? A : B). Unfortunatelty, commit 8facd5fb ("net: fix smatch warnings inside datagram_poll") forgot about SCTP. :-( Introduced by 7d4c04fc ("net: add option to enable error queue packets waking select"). Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit ae7b4e1f ] When the kernel is compiled with CONFIG_IPV6_SUBTREES, and we return with an error in fn = fib6_add_1(), then error codes are encoded into the return pointer e.g. ERR_PTR(-ENOENT). In such an error case, we write the error code into err and jump to out, hence enter the if(err) condition. Now, if CONFIG_IPV6_SUBTREES is enabled, we check for: if (pn != fn && pn->leaf == rt) ... if (pn != fn && !pn->leaf && !(pn->fn_flags & RTN_RTINFO)) ... Since pn is NULL and fn is f.e. ERR_PTR(-ENOENT), then pn != fn evaluates to true and causes a NULL-pointer dereference on further checks on pn. Fix it, by setting both NULL in error case, so that pn != fn already evaluates to false and no further dereference takes place. This was first correctly implemented in 4a287eba ("IPv6 routing, NLM_F_* flag support: REPLACE and EXCL flags support, warn about missing CREATE flag"), but the bug got later on introduced by 188c517a ("ipv6: return errno pointers consistently for fib6_add_1()"). Signed-off-by:
Matti Vaittinen <matti.vaittinen@nsn.com> Signed-off-by:
-
Jiri Pirko authored
[ Upstream commit 8112b1fe ] In rfc4942 and rfc2460 I cannot find anything which would implicate to drop packets which have only padding in tlv. Current behaviour breaks TAHI Test v6LC.1.2.6. Problem was intruduced in: 9b905fe6 "ipv6/exthdrs: strict Pad1 and PadN check" Signed-off-by:
-
Dave Jones authored
[ Upstream commit e2e5c4c0 ] Signed-off-by:
Dave Jones <davej@fedoraproject.org> Acked-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
-
Dave Jones authored
[ Upstream commit 0c1db731 ] The indentation here implies this was meant to be a multi-line if. Introduced several years back in commit c85c2951 ("caif: Handle dev_queue_xmit errors.") Signed-off-by:
-
Jiri Kosina authored
commit bc197eed upstream. 27ce4050 ("HID: fix data access in implement()") by mistake removed a setting of buffer size in hidp. Fix that by putting it back. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Jiri Kosina authored
commit 27ce4050 upstream. implement() is setting bytes in LE data stream. In case the data is not aligned to 64bits, it reads past the allocated buffer. It doesn't really change any value there (it's properly bitmasked), but in case that this read past the boundary hits a page boundary, pagefault happens when accessing 64bits of 'x' in implement(), and kernel oopses. This happens much more often when numbered reports are in use, as the initial 8bit skip in the buffer makes the whole process work on values which are not aligned to 64bits. This problem dates back to attempts in 2005 and 2006 to make implement() and extract() as generic as possible, and even back then the problem was realized by Adam Kroperlin, but falsely assumed to be impossible to cause any harm: http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html I have made several attempts at fixing it "on the spot" directly in implement(), but the results were horrible; the special casing for processing last 64bit chunk and switching to different math makes it unreadable mess. I therefore took a path to allocate a few bytes more which will never make it into final report, but are there as a cushion for all the 64bit math operations happening in implement() and extract(). All callers of hid_output_report() are converted at the same time to allocate the buffer by newly introduced hid_alloc_report_buf() helper. Bruno noticed that the whole raw_size test can be dropped as well, as hid_alloc_report_buf() makes sure that the buffer is always of a proper size. Reviewed-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
-
Dan Carpenter authored
commit 58f09e00 upstream. The arg64 struct has a hole after ->buf_size which isn't cleared. Or if any of the calls to copy_from_user() fail then that would cause an information leak as well. This was assigned CVE-2013-2147. Signed-off-by:
Mike Miller <mike.miller@hp.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dan Carpenter authored
commit 627aad1c upstream. The pciinfo struct has a two byte hole after ->dev_fn so stack information could be leaked to the user. This was assigned CVE-2013-2147. Signed-off-by:
-
Daniel Drake authored
commit 6390d885 upstream. When trying to unset a previously-set multicast list (i.e. the new list has 0 entries), mwifiex_set_multicast_list() was calling down to mwifiex_request_set_multicast_list() while leaving mcast_list.num_multicast_addr as an uninitialized value. We were arriving at mwifiex_cmd_mac_multicast_adr() which would then proceed to do an often huge memcpy of mcast_list.num_multicast_addr*ETH_ALEN bytes, causing memory corruption and hard to debug crashes. Fix this by setting mcast_list.num_multicast_addr to 0 when no multicast list is provided. Similarly, fix up the logic in mwifiex_request_set_multicast_list() to unset the multicast list that was previously sent to the hardware in such cases. Signed-off-by:
Daniel Drake <dsd@laptop.org> Acked-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
- 05 Oct, 2013 6 commits
-
-
Greg Kroah-Hartman authored
-
Daniel Vetter authored
commit 0ce99f74 upstream. Apparently Bspec is wrong in this case here even for gm45. Note that Bspec is horribly misguided on i965g/gm, so we don't have any other data points besides that it seems to make machines work better. With this changes all the bits in PORT_HOTPLUG_STAT for the digital ports are ordered the same way. This seems to agree with what register dumps from the hpd storm handling code shows, where the LIVE bit and the short/long pulse STATUS bits light up at the same time with this enumeration (but no with the one from Bspec). Also tested on my gm45 which has two DP+ ports, and everything seems to still work as expected. References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg23054.html Cc: Egbert Eich <eich@suse.com> Cc: Jan Niggemann <jn@hz6.de> Tested-by:
Jan Niggemann <jn@hz6.de> [danvet: Add a big warning that Bspec seems to be wrong for these bits, suggested by Jani.] Acked-by:
Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Liam Girdwood authored
commit 4028b6c4 upstream. snd_unregister_device() should return the device type and not stream direction. Signed-off-by:
Liam Girdwood <liam.r.girdwood@linux.intel.com> Acked-by:
Vinod Koul <vinod.koul@intel.com> Tested-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Henrik Rydberg authored
commit 5f451386 upstream. After reports from Chris and Josh Boyer of a rare crash in applesmc, Guenter pointed at the initialization problem fixed below. The patch has not been verified to fix the crash, but should be applied regardless. Reported-by: <jwboyer@fedoraproject.org> Suggested-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Henrik Rydberg <rydberg@euromail.se> Signed-off-by:
-
Arnd Bergmann authored
commit 7a9caf59 upstream. When building a kernel without CONFIG_PM, we get a link error from referencing mxs_pm_init in the machine descriptor. This defines a macro to NULL for that case. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Alex Deucher authored
commit 58d327da upstream. These asics seem to use a mix of the DCE2.x and DCE3.2 audio interfaces despite what the register spec says. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=69729 https://bugs.freedesktop.org/show_bug.cgi?id=69671Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
