- Linux-stable-mirror - lists.linaro.org

Patch "ipv6: sr: fix NULL pointer dereference when setting encap source address" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ipv6: sr: fix NULL pointer dereference when setting encap source address to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ipv6-sr-fix-null-pointer-dereference-when-setting-encap-source-address.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Mar 28 18:38:30 CEST 2018 From: David Lebrun <dlebrun(a)google.com> Date: Tue, 20 Mar 2018 14:44:56 +0000 Subject: ipv6: sr: fix NULL pointer dereference when setting encap source address From: David Lebrun <dlebrun(a)google.com> [ Upstream commit 8936ef7604c11b5d701580d779e0f5684abc7b68 ] When using seg6 in encap mode, we call ipv6_dev_get_saddr() to set the source address of the outer IPv6 header, in case none was specified. Using skb->dev can lead to BUG() when it is in an inconsistent state. This patch uses the net_device attached to the skb's dst instead. [940807.667429] BUG: unable to handle kernel NULL pointer dereference at 000000000000047c [940807.762427] IP: ipv6_dev_get_saddr+0x8b/0x1d0 [940807.815725] PGD 0 P4D 0 [940807.847173] Oops: 0000 [#1] SMP PTI [940807.890073] Modules linked in: [940807.927765] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G W 4.16.0-rc1-seg6bpf+ #2 [940808.028988] Hardware name: HP ProLiant DL120 G6/ProLiant DL120 G6, BIOS O26 09/06/2010 [940808.128128] RIP: 0010:ipv6_dev_get_saddr+0x8b/0x1d0 [940808.187667] RSP: 0018:ffff88043fd836b0 EFLAGS: 00010206 [940808.251366] RAX: 0000000000000005 RBX: ffff88042cb1c860 RCX: 00000000000000fe [940808.338025] RDX: 00000000000002c0 RSI: ffff88042cb1c860 RDI: 0000000000004500 [940808.424683] RBP: ffff88043fd83740 R08: 0000000000000000 R09: ffffffffffffffff [940808.511342] R10: 0000000000000040 R11: 0000000000000000 R12: ffff88042cb1c850 [940808.598012] R13: ffffffff8208e380 R14: ffff88042ac8da00 R15: 0000000000000002 [940808.684675] FS: 0000000000000000(0000) GS:ffff88043fd80000(0000) knlGS:0000000000000000 [940808.783036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [940808.852975] CR2: 000000000000047c CR3: 00000004255fe000 CR4: 00000000000006e0 [940808.939634] Call Trace: [940808.970041] <IRQ> [940808.995250] ? ip6t_do_table+0x265/0x640 [940809.043341] seg6_do_srh_encap+0x28f/0x300 [940809.093516] ? seg6_do_srh+0x1a0/0x210 [940809.139528] seg6_do_srh+0x1a0/0x210 [940809.183462] seg6_output+0x28/0x1e0 [940809.226358] lwtunnel_output+0x3f/0x70 [940809.272370] ip6_xmit+0x2b8/0x530 [940809.313185] ? ac6_proc_exit+0x20/0x20 [940809.359197] inet6_csk_xmit+0x7d/0xc0 [940809.404173] tcp_transmit_skb+0x548/0x9a0 [940809.453304] __tcp_retransmit_skb+0x1a8/0x7a0 [940809.506603] ? ip6_default_advmss+0x40/0x40 [940809.557824] ? tcp_current_mss+0x24/0x90 [940809.605925] tcp_retransmit_skb+0xd/0x80 [940809.654016] tcp_xmit_retransmit_queue.part.17+0xf9/0x210 [940809.719797] tcp_ack+0xa47/0x1110 [940809.760612] tcp_rcv_established+0x13c/0x570 [940809.812865] tcp_v6_do_rcv+0x151/0x3d0 [940809.858879] tcp_v6_rcv+0xa5c/0xb10 [940809.901770] ? seg6_output+0xdd/0x1e0 [940809.946745] ip6_input_finish+0xbb/0x460 [940809.994837] ip6_input+0x74/0x80 [940810.034612] ? ip6_rcv_finish+0xb0/0xb0 [940810.081663] ipv6_rcv+0x31c/0x4c0 ... Fixes: 6c8702c60b886 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels") Reported-by: Tom Herbert <tom(a)quantonium.net> Signed-off-by: David Lebrun <dlebrun(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/seg6_iptunnel.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/net/ipv6/seg6_iptunnel.c +++ b/net/ipv6/seg6_iptunnel.c @@ -93,7 +93,8 @@ static void set_tun_src(struct net *net, /* encapsulate an IPv6 packet within an outer IPv6 header with a given SRH */ int seg6_do_srh_encap(struct sk_buff *skb, struct ipv6_sr_hdr *osrh, int proto) { - struct net *net = dev_net(skb_dst(skb)->dev); + struct dst_entry *dst = skb_dst(skb); + struct net *net = dev_net(dst->dev); struct ipv6hdr *hdr, *inner_hdr; struct ipv6_sr_hdr *isrh; int hdrlen, tot_len, err; @@ -134,7 +135,7 @@ int seg6_do_srh_encap(struct sk_buff *sk isrh->nexthdr = proto; hdr->daddr = isrh->segments[isrh->first_segment]; - set_tun_src(net, skb->dev, &hdr->daddr, &hdr->saddr); + set_tun_src(net, ip6_dst_idev(dst)->dev, &hdr->daddr, &hdr->saddr); #ifdef CONFIG_IPV6_SEG6_HMAC if (sr_has_hmac(isrh)) { Patches currently in stable-queue which might be from dlebrun(a)google.com are queue-4.14/ipv6-sr-fix-scheduling-in-rcu-when-creating-seg6-lwtunnel-state.patch queue-4.14/ipv6-sr-fix-null-pointer-dereference-when-setting-encap-source-address.patch

7 years, 5 months

1
0
0 0

Patch "ipv6: old_dport should be a __be16 in __ip6_datagram_connect()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ipv6: old_dport should be a __be16 in __ip6_datagram_connect() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ipv6-old_dport-should-be-a-__be16-in-__ip6_datagram_connect.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Mar 28 18:38:30 CEST 2018 From: Stefano Brivio <sbrivio(a)redhat.com> Date: Mon, 19 Mar 2018 11:24:58 +0100 Subject: ipv6: old_dport should be a __be16 in __ip6_datagram_connect() From: Stefano Brivio <sbrivio(a)redhat.com> [ Upstream commit 5f2fb802eee1df0810b47ea251942fe3fd36589a ] Fixes: 2f987a76a977 ("net: ipv6: keep sk status consistent after datagram connect failure") Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com> Acked-by: Paolo Abeni <pabeni(a)redhat.com> Acked-by: Guillaume Nault <g.nault(a)alphalink.fr> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/datagram.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/ipv6/datagram.c +++ b/net/ipv6/datagram.c @@ -149,7 +149,7 @@ int __ip6_datagram_connect(struct sock * struct in6_addr *daddr, old_daddr; __be32 fl6_flowlabel = 0; __be32 old_fl6_flowlabel; - __be32 old_dport; + __be16 old_dport; int addr_type; int err; Patches currently in stable-queue which might be from sbrivio(a)redhat.com are queue-4.14/ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.patch queue-4.14/ipv6-old_dport-should-be-a-__be16-in-__ip6_datagram_connect.patch

7 years, 5 months

1
0
0 0

Patch "ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Mar 28 18:38:30 CEST 2018 From: Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com> Date: Thu, 8 Mar 2018 17:00:02 +0100 Subject: ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option() From: Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com> [ Upstream commit 9f62c15f28b0d1d746734666d88a79f08ba1e43e ] Fix the following slab-out-of-bounds kasan report in ndisc_fill_redirect_hdr_option when the incoming ipv6 packet is not linear and the accessed data are not in the linear data region of orig_skb. [ 1503.122508] ================================================================== [ 1503.122832] BUG: KASAN: slab-out-of-bounds in ndisc_send_redirect+0x94e/0x990 [ 1503.123036] Read of size 1184 at addr ffff8800298ab6b0 by task netperf/1932 [ 1503.123220] CPU: 0 PID: 1932 Comm: netperf Not tainted 4.16.0-rc2+ #124 [ 1503.123347] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-2.fc27 04/01/2014 [ 1503.123527] Call Trace: [ 1503.123579] <IRQ> [ 1503.123638] print_address_description+0x6e/0x280 [ 1503.123849] kasan_report+0x233/0x350 [ 1503.123946] memcpy+0x1f/0x50 [ 1503.124037] ndisc_send_redirect+0x94e/0x990 [ 1503.125150] ip6_forward+0x1242/0x13b0 [...] [ 1503.153890] Allocated by task 1932: [ 1503.153982] kasan_kmalloc+0x9f/0xd0 [ 1503.154074] __kmalloc_track_caller+0xb5/0x160 [ 1503.154198] __kmalloc_reserve.isra.41+0x24/0x70 [ 1503.154324] __alloc_skb+0x130/0x3e0 [ 1503.154415] sctp_packet_transmit+0x21a/0x1810 [ 1503.154533] sctp_outq_flush+0xc14/0x1db0 [ 1503.154624] sctp_do_sm+0x34e/0x2740 [ 1503.154715] sctp_primitive_SEND+0x57/0x70 [ 1503.154807] sctp_sendmsg+0xaa6/0x1b10 [ 1503.154897] sock_sendmsg+0x68/0x80 [ 1503.154987] ___sys_sendmsg+0x431/0x4b0 [ 1503.155078] __sys_sendmsg+0xa4/0x130 [ 1503.155168] do_syscall_64+0x171/0x3f0 [ 1503.155259] entry_SYSCALL_64_after_hwframe+0x42/0xb7 [ 1503.155436] Freed by task 1932: [ 1503.155527] __kasan_slab_free+0x134/0x180 [ 1503.155618] kfree+0xbc/0x180 [ 1503.155709] skb_release_data+0x27f/0x2c0 [ 1503.155800] consume_skb+0x94/0xe0 [ 1503.155889] sctp_chunk_put+0x1aa/0x1f0 [ 1503.155979] sctp_inq_pop+0x2f8/0x6e0 [ 1503.156070] sctp_assoc_bh_rcv+0x6a/0x230 [ 1503.156164] sctp_inq_push+0x117/0x150 [ 1503.156255] sctp_backlog_rcv+0xdf/0x4a0 [ 1503.156346] __release_sock+0x142/0x250 [ 1503.156436] release_sock+0x80/0x180 [ 1503.156526] sctp_sendmsg+0xbb0/0x1b10 [ 1503.156617] sock_sendmsg+0x68/0x80 [ 1503.156708] ___sys_sendmsg+0x431/0x4b0 [ 1503.156799] __sys_sendmsg+0xa4/0x130 [ 1503.156889] do_syscall_64+0x171/0x3f0 [ 1503.156980] entry_SYSCALL_64_after_hwframe+0x42/0xb7 [ 1503.157158] The buggy address belongs to the object at ffff8800298ab600 which belongs to the cache kmalloc-1024 of size 1024 [ 1503.157444] The buggy address is located 176 bytes inside of 1024-byte region [ffff8800298ab600, ffff8800298aba00) [ 1503.157702] The buggy address belongs to the page: [ 1503.157820] page:ffffea0000a62a00 count:1 mapcount:0 mapping:0000000000000000 index:0x0 compound_mapcount: 0 [ 1503.158053] flags: 0x4000000000008100(slab|head) [ 1503.158171] raw: 4000000000008100 0000000000000000 0000000000000000 00000001800e000e [ 1503.158350] raw: dead000000000100 dead000000000200 ffff880036002600 0000000000000000 [ 1503.158523] page dumped because: kasan: bad access detected [ 1503.158698] Memory state around the buggy address: [ 1503.158816] ffff8800298ab900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1503.158988] ffff8800298ab980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1503.159165] >ffff8800298aba00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 1503.159338] ^ [ 1503.159436] ffff8800298aba80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1503.159610] ffff8800298abb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1503.159785] ================================================================== [ 1503.159964] Disabling lock debugging due to kernel taint The test scenario to trigger the issue consists of 4 devices: - H0: data sender, connected to LAN0 - H1: data receiver, connected to LAN1 - GW0 and GW1: routers between LAN0 and LAN1. Both of them have an ethernet connection on LAN0 and LAN1 On H{0,1} set GW0 as default gateway while on GW0 set GW1 as next hop for data from LAN0 to LAN1. Moreover create an ip6ip6 tunnel between H0 and H1 and send 3 concurrent data streams (TCP/UDP/SCTP) from H0 to H1 through ip6ip6 tunnel (send buffer size is set to 16K). While data streams are active flush the route cache on HA multiple times. I have not been able to identify a given commit that introduced the issue since, using the reproducer described above, the kasan report has been triggered from 4.14 and I have not gone back further. Reported-by: Jianlin Shi <jishi(a)redhat.com> Reviewed-by: Stefano Brivio <sbrivio(a)redhat.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/ndisc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/net/ipv6/ndisc.c +++ b/net/ipv6/ndisc.c @@ -1546,7 +1546,8 @@ static void ndisc_fill_redirect_hdr_opti *(opt++) = (rd_len >> 3); opt += 6; - memcpy(opt, ipv6_hdr(orig_skb), rd_len - 8); + skb_copy_bits(orig_skb, skb_network_offset(orig_skb), opt, + rd_len - 8); } void ndisc_send_redirect(struct sk_buff *skb, const struct in6_addr *target) Patches currently in stable-queue which might be from lorenzo.bianconi(a)redhat.com are queue-4.14/ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.patch

7 years, 5 months

1
0
0 0

Patch "ieee802154: 6lowpan: fix possible NULL deref in lowpan_device_event()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ieee802154: 6lowpan: fix possible NULL deref in lowpan_device_event() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ieee802154-6lowpan-fix-possible-null-deref-in-lowpan_device_event.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Mar 28 18:38:30 CEST 2018 From: Eric Dumazet <edumazet(a)google.com> Date: Mon, 5 Mar 2018 08:51:03 -0800 Subject: ieee802154: 6lowpan: fix possible NULL deref in lowpan_device_event() From: Eric Dumazet <edumazet(a)google.com> [ Upstream commit ca0edb131bdf1e6beaeb2b8289fd6b374b74147d ] A tun device type can trivially be set to arbitrary value using TUNSETLINK ioctl(). Therefore, lowpan_device_event() must really check that ieee802154_ptr is not NULL. Fixes: 2c88b5283f60d ("ieee802154: 6lowpan: remove check on null") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: Alexander Aring <alex.aring(a)gmail.com> Cc: Stefan Schmidt <stefan(a)osg.samsung.com> Reported-by: syzbot <syzkaller(a)googlegroups.com> Acked-by: Stefan Schmidt <stefan(a)osg.samsung.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ieee802154/6lowpan/core.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) --- a/net/ieee802154/6lowpan/core.c +++ b/net/ieee802154/6lowpan/core.c @@ -206,9 +206,13 @@ static inline void lowpan_netlink_fini(v static int lowpan_device_event(struct notifier_block *unused, unsigned long event, void *ptr) { - struct net_device *wdev = netdev_notifier_info_to_dev(ptr); + struct net_device *ndev = netdev_notifier_info_to_dev(ptr); + struct wpan_dev *wpan_dev; - if (wdev->type != ARPHRD_IEEE802154) + if (ndev->type != ARPHRD_IEEE802154) + return NOTIFY_DONE; + wpan_dev = ndev->ieee802154_ptr; + if (!wpan_dev) return NOTIFY_DONE; switch (event) { @@ -217,8 +221,8 @@ static int lowpan_device_event(struct no * also delete possible lowpan interfaces which belongs * to the wpan interface. */ - if (wdev->ieee802154_ptr->lowpan_dev) - lowpan_dellink(wdev->ieee802154_ptr->lowpan_dev, NULL); + if (wpan_dev->lowpan_dev) + lowpan_dellink(wpan_dev->lowpan_dev, NULL); break; default: return NOTIFY_DONE; Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.14/ipv6-fix-access-to-non-linear-packet-in-ndisc_fill_redirect_hdr_option.patch queue-4.14/skbuff-fix-not-waking-applications-when-errors-are-enqueued.patch queue-4.14/l2tp-do-not-accept-arbitrary-sockets.patch queue-4.14/tcp-purge-write-queue-upon-aborting-the-connection.patch queue-4.14/net-use-skb_to_full_sk-in-skb_update_prio.patch queue-4.14/ieee802154-6lowpan-fix-possible-null-deref-in-lowpan_device_event.patch queue-4.14/tcp-reset-sk_send_head-in-tcp_write_queue_purge.patch

7 years, 5 months

1
0
0 0

Patch "dpaa_eth: remove duplicate initialization" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dpaa_eth: remove duplicate initialization to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dpaa_eth-remove-duplicate-initialization.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Mar 28 18:38:30 CEST 2018 From: Camelia Groza <camelia.groza(a)nxp.com> Date: Wed, 14 Mar 2018 08:37:30 -0500 Subject: dpaa_eth: remove duplicate initialization From: Camelia Groza <camelia.groza(a)nxp.com> [ Upstream commit 565186362b73226a288830abe595f05f0cec0bbc ] The fd_format has already been initialized at this point. Signed-off-by: Camelia Groza <camelia.groza(a)nxp.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 1 - 1 file changed, 1 deletion(-) --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c @@ -2292,7 +2292,6 @@ static enum qman_cb_dqrr_result rx_defau vaddr = phys_to_virt(addr); prefetch(vaddr + qm_fd_get_offset(fd)); - fd_format = qm_fd_get_format(fd); /* The only FD types that we may receive are contig and S/G */ WARN_ON((fd_format != qm_fd_contig) && (fd_format != qm_fd_sg)); Patches currently in stable-queue which might be from camelia.groza(a)nxp.com are queue-4.14/dpaa_eth-remove-duplicate-increment-of-the-tx_errors-counter.patch queue-4.14/dpaa_eth-remove-duplicate-initialization.patch queue-4.14/dpaa_eth-increment-the-rx-dropped-counter-when-needed.patch

7 years, 5 months

1
0
0 0

Patch "dpaa_eth: remove duplicate increment of the tx_errors counter" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dpaa_eth: remove duplicate increment of the tx_errors counter to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dpaa_eth-remove-duplicate-increment-of-the-tx_errors-counter.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Mar 28 18:38:30 CEST 2018 From: Camelia Groza <camelia.groza(a)nxp.com> Date: Wed, 14 Mar 2018 08:37:32 -0500 Subject: dpaa_eth: remove duplicate increment of the tx_errors counter From: Camelia Groza <camelia.groza(a)nxp.com> [ Upstream commit 82d141cd19d088ee41feafde4a6f86eeb40d93c5 ] The tx_errors counter is incremented by the dpaa_xmit caller. Signed-off-by: Camelia Groza <camelia.groza(a)nxp.com> Signed-off-by: Madalin Bucur <madalin.bucur(a)nxp.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 1 - 1 file changed, 1 deletion(-) --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c @@ -2022,7 +2022,6 @@ static inline int dpaa_xmit(struct dpaa_ } if (unlikely(err < 0)) { - percpu_stats->tx_errors++; percpu_stats->tx_fifo_errors++; return err; } Patches currently in stable-queue which might be from camelia.groza(a)nxp.com are queue-4.14/dpaa_eth-remove-duplicate-increment-of-the-tx_errors-counter.patch queue-4.14/dpaa_eth-remove-duplicate-initialization.patch queue-4.14/dpaa_eth-increment-the-rx-dropped-counter-when-needed.patch

7 years, 5 months

1
0
0 0

Patch "dpaa_eth: increment the RX dropped counter when needed" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dpaa_eth: increment the RX dropped counter when needed to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dpaa_eth-increment-the-rx-dropped-counter-when-needed.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Mar 28 18:38:30 CEST 2018 From: Camelia Groza <camelia.groza(a)nxp.com> Date: Wed, 14 Mar 2018 08:37:31 -0500 Subject: dpaa_eth: increment the RX dropped counter when needed From: Camelia Groza <camelia.groza(a)nxp.com> [ Upstream commit e4d1b37c17d000a3da9368a3e260fb9ea4927c25 ] Signed-off-by: Camelia Groza <camelia.groza(a)nxp.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c @@ -2324,8 +2324,10 @@ static enum qman_cb_dqrr_result rx_defau skb_len = skb->len; - if (unlikely(netif_receive_skb(skb) == NET_RX_DROP)) + if (unlikely(netif_receive_skb(skb) == NET_RX_DROP)) { + percpu_stats->rx_dropped++; return qman_cb_dqrr_consume; + } percpu_stats->rx_packets++; percpu_stats->rx_bytes += skb_len; Patches currently in stable-queue which might be from camelia.groza(a)nxp.com are queue-4.14/dpaa_eth-remove-duplicate-increment-of-the-tx_errors-counter.patch queue-4.14/dpaa_eth-remove-duplicate-initialization.patch queue-4.14/dpaa_eth-increment-the-rx-dropped-counter-when-needed.patch

7 years, 5 months

1
0
0 0

Patch "dpaa_eth: fix error in dpaa_remove()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dpaa_eth: fix error in dpaa_remove() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dpaa_eth-fix-error-in-dpaa_remove.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Mar 28 18:38:30 CEST 2018 From: Madalin Bucur <madalin.bucur(a)nxp.com> Date: Wed, 14 Mar 2018 08:37:29 -0500 Subject: dpaa_eth: fix error in dpaa_remove() From: Madalin Bucur <madalin.bucur(a)nxp.com> [ Upstream commit 88075256ee817041d68c2387f29065b5cb2b342a ] The recent changes that make the driver probing compatible with DSA were not propagated in the dpa_remove() function, breaking the module unload function. Using the proper device to address the issue. Signed-off-by: Madalin Bucur <madalin.bucur(a)nxp.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c @@ -2860,7 +2860,7 @@ static int dpaa_remove(struct platform_d struct device *dev; int err; - dev = &pdev->dev; + dev = pdev->dev.parent; net_dev = dev_get_drvdata(dev); priv = netdev_priv(net_dev); Patches currently in stable-queue which might be from madalin.bucur(a)nxp.com are queue-4.14/dpaa_eth-remove-duplicate-increment-of-the-tx_errors-counter.patch queue-4.14/soc-fsl-qbman-fix-issue-in-qman_delete_cgr_safe.patch queue-4.14/dpaa_eth-fix-error-in-dpaa_remove.patch

7 years, 5 months

1
0
0 0

Patch "devlink: Remove redundant free on error path" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled devlink: Remove redundant free on error path to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: devlink-remove-redundant-free-on-error-path.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Mar 28 18:38:30 CEST 2018 From: Arkadi Sharshevsky <arkadis(a)mellanox.com> Date: Sun, 18 Mar 2018 17:37:22 +0200 Subject: devlink: Remove redundant free on error path From: Arkadi Sharshevsky <arkadis(a)mellanox.com> [ Upstream commit 7fe4d6dcbcb43fe0282d4213fc52be178bb30e91 ] The current code performs unneeded free. Remove the redundant skb freeing during the error path. Fixes: 1555d204e743 ("devlink: Support for pipeline debug (dpipe)") Signed-off-by: Arkadi Sharshevsky <arkadis(a)mellanox.com> Acked-by: Jiri Pirko <jiri(a)mellanox.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/core/devlink.c | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) --- a/net/core/devlink.c +++ b/net/core/devlink.c @@ -1776,7 +1776,7 @@ send_done: if (!nlh) { err = devlink_dpipe_send_and_alloc_skb(&skb, info); if (err) - goto err_skb_send_alloc; + return err; goto send_done; } @@ -1785,7 +1785,6 @@ send_done: nla_put_failure: err = -EMSGSIZE; err_table_put: -err_skb_send_alloc: genlmsg_cancel(skb, hdr); nlmsg_free(skb); return err; @@ -2051,7 +2050,7 @@ static int devlink_dpipe_entries_fill(st table->counters_enabled, &dump_ctx); if (err) - goto err_entries_dump; + return err; send_done: nlh = nlmsg_put(dump_ctx.skb, info->snd_portid, info->snd_seq, @@ -2059,16 +2058,10 @@ send_done: if (!nlh) { err = devlink_dpipe_send_and_alloc_skb(&dump_ctx.skb, info); if (err) - goto err_skb_send_alloc; + return err; goto send_done; } return genlmsg_reply(dump_ctx.skb, info); - -err_entries_dump: -err_skb_send_alloc: - genlmsg_cancel(dump_ctx.skb, dump_ctx.hdr); - nlmsg_free(dump_ctx.skb); - return err; } static int devlink_nl_cmd_dpipe_entries_get(struct sk_buff *skb, @@ -2207,7 +2200,7 @@ send_done: if (!nlh) { err = devlink_dpipe_send_and_alloc_skb(&skb, info); if (err) - goto err_skb_send_alloc; + return err; goto send_done; } return genlmsg_reply(skb, info); @@ -2215,7 +2208,6 @@ send_done: nla_put_failure: err = -EMSGSIZE; err_table_put: -err_skb_send_alloc: genlmsg_cancel(skb, hdr); nlmsg_free(skb); return err; Patches currently in stable-queue which might be from arkadis(a)mellanox.com are queue-4.14/devlink-remove-redundant-free-on-error-path.patch queue-4.14/team-fix-double-free-in-error-path.patch

7 years, 5 months

1
0
0 0

Patch "dccp: check sk for closed state in dccp_sendmsg()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dccp: check sk for closed state in dccp_sendmsg() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dccp-check-sk-for-closed-state-in-dccp_sendmsg.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Mar 28 18:38:30 CEST 2018 From: Alexey Kodanev <alexey.kodanev(a)oracle.com> Date: Tue, 6 Mar 2018 22:57:01 +0300 Subject: dccp: check sk for closed state in dccp_sendmsg() From: Alexey Kodanev <alexey.kodanev(a)oracle.com> [ Upstream commit 67f93df79aeefc3add4e4b31a752600f834236e2 ] dccp_disconnect() sets 'dp->dccps_hc_tx_ccid' tx handler to NULL, therefore if DCCP socket is disconnected and dccp_sendmsg() is called after it, it will cause a NULL pointer dereference in dccp_write_xmit(). This crash and the reproducer was reported by syzbot. Looks like it is reproduced if commit 69c64866ce07 ("dccp: CVE-2017-8824: use-after-free in DCCP code") is applied. Reported-by: syzbot+f99ab3887ab65d70f816(a)syzkaller.appspotmail.com Signed-off-by: Alexey Kodanev <alexey.kodanev(a)oracle.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/dccp/proto.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/net/dccp/proto.c +++ b/net/dccp/proto.c @@ -789,6 +789,11 @@ int dccp_sendmsg(struct sock *sk, struct if (skb == NULL) goto out_release; + if (sk->sk_state == DCCP_CLOSED) { + rc = -ENOTCONN; + goto out_discard; + } + skb_reserve(skb, sk->sk_prot->max_header); rc = memcpy_from_msg(skb_put(skb, len), msg, len); if (rc != 0) Patches currently in stable-queue which might be from alexey.kodanev(a)oracle.com are queue-4.14/sch_netem-fix-skb-leak-in-netem_enqueue.patch queue-4.14/macvlan-filter-out-unsupported-feature-flags.patch queue-4.14/dccp-check-sk-for-closed-state-in-dccp_sendmsg.patch

7 years, 5 months

1
0
0 0

[PATCH 4.4 00/43] 4.4.125-stable review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.125 release. There are 43 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Mar 29 16:27:00 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.125-rc… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 4.4.125-rc1 Daniel Borkmann <daniel(a)iogearbox.net> bpf, x64: increase number of passes Chenbo Feng <fengc(a)google.com> bpf: skip unnecessary capability check Daniel Borkmann <daniel(a)iogearbox.net> kbuild: disable clang's default use of -fmerge-all-constants Nadav Amit <namit(a)vmware.com> staging: lustre: ptlrpc: kfree used instead of kvfree Dan Carpenter <dan.carpenter(a)oracle.com> perf/x86/intel: Don't accidentally clear high bits in bdw_limit_period() Andy Lutomirski <luto(a)kernel.org> x86/entry/64: Don't use IST entry for #BP stack H.J. Lu <hjl.tools(a)gmail.com> x86/boot/64: Verify alignment of the LOAD segment H.J. Lu <hjl.tools(a)gmail.com> x86/build/64: Force the linker to use 2MB page size Linus Torvalds <torvalds(a)linux-foundation.org> kvm/x86: fix icebp instruction handling Linus Torvalds <torvalds(a)linux-foundation.org> tty: vt: fix up tabstops properly Andri Yngvason <andri.yngvason(a)marel.com> can: cc770: Fix use after free in cc770_tx_interrupt() Andri Yngvason <andri.yngvason(a)marel.com> can: cc770: Fix queue stall & dropped RTR reply Andri Yngvason <andri.yngvason(a)marel.com> can: cc770: Fix stalls on rt-linux, remove redundant IRQ ack Dan Carpenter <dan.carpenter(a)oracle.com> staging: ncpfs: memory corruption in ncp_read_kernel() Jagdish Gediya <jagdish.gediya(a)nxp.com> mtd: nand: fsl_ifc: Fix nand waitfunc return value Masami Hiramatsu <mhiramat(a)kernel.org> tracing: probeevent: Fix to support minus offset from symbol Larry Finger <Larry.Finger(a)lwfinger.net> rtlwifi: rtl8723be: Fix loss of signal Arend Van Spriel <arend.vanspriel(a)broadcom.com> brcmfmac: fix P2P_DEVICE ethernet address generation Dan Williams <dan.j.williams(a)intel.com> acpi, numa: fix pxm to online numa node associations Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> drm: udl: Properly check framebuffer mmap offsets Michel Dänzer <michel.daenzer(a)amd.com> drm/radeon: Don't turn off DP sink when disconnected Thomas Hellstrom <thellstrom(a)vmware.com> drm/vmwgfx: Fix a destoy-while-held mutex problem. Toshi Kani <toshi.kani(a)hpe.com> x86/mm: implement free pmd/pte page interfaces Toshi Kani <toshi.kani(a)hpe.com> mm/vmalloc: add interfaces to free unmapped page table Hans de Goede <hdegoede(a)redhat.com> libata: Modify quirks for MX100 to limit NCQ_TRIM quirk to MU01 version Hans de Goede <hdegoede(a)redhat.com> libata: Make Crucial BX100 500GB LPM quirk apply to all firmware versions Hans de Goede <hdegoede(a)redhat.com> libata: Apply NOLPM quirk to Crucial M500 480 and 960GB SSDs Ju Hyung Park <qkrwngud825(a)gmail.com> libata: Enable queued TRIM for Samsung SSD 860 Kai-Heng Feng <kai.heng.feng(a)canonical.com> libata: disable LPM for Crucial BX100 SSD 500GB drive Hans de Goede <hdegoede(a)redhat.com> libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs Eric Biggers <ebiggers(a)google.com> libata: remove WARN() for DMA or PIO command without data Eric Biggers <ebiggers(a)google.com> libata: fix length validation of ATAPI-relayed SCSI commands Takashi Iwai <tiwai(a)suse.de> Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174 Boris Brezillon <boris.brezillon(a)bootlin.com> clk: bcm2835: Protect sections updating shared registers Hans de Goede <hdegoede(a)redhat.com> ahci: Add PCI-id for the Highpoint Rocketraid 644L card Hans de Goede <hdegoede(a)redhat.com> PCI: Add function 1 DMA alias quirk for Highpoint RocketRAID 644L Evgeniy Didin <Evgeniy.Didin(a)synopsys.com> mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs Takashi Iwai <tiwai(a)suse.de> ALSA: hda/realtek - Always immediately update mute LED with pin VREF Takashi Iwai <tiwai(a)suse.de> ALSA: aloop: Fix access to not-yet-ready substream via cable Takashi Iwai <tiwai(a)suse.de> ALSA: aloop: Sync stale timer before release Kirill Marinushkin <k.marinushkin(a)gmail.com> ALSA: usb-audio: Fix parsing descriptor of UAC2 processing unit Michael Nosthoff <committed(a)heine.so> iio: st_pressure: st_accel: pass correct platform data to init NeilBrown <neil(a)brown.name> MIPS: ralink: Remove ralink_halt() ------------- Diffstat: Makefile | 13 ++- arch/arm64/mm/mmu.c | 10 +++ arch/mips/ralink/reset.c | 7 -- arch/x86/Makefile | 9 ++ arch/x86/boot/compressed/misc.c | 4 + arch/x86/entry/entry_64.S | 2 +- arch/x86/include/asm/vmx.h | 1 + arch/x86/kernel/cpu/perf_event_intel.c | 2 +- arch/x86/kernel/traps.c | 24 +++-- arch/x86/kvm/vmx.c | 9 +- arch/x86/mm/pgtable.c | 48 ++++++++++ arch/x86/net/bpf_jit_comp.c | 3 +- drivers/acpi/numa.c | 10 ++- drivers/ata/ahci.c | 4 +- drivers/ata/libata-core.c | 26 +++++- drivers/ata/libata-scsi.c | 4 +- drivers/bluetooth/btusb.c | 2 +- drivers/clk/bcm/clk-bcm2835.c | 4 + drivers/gpu/drm/radeon/radeon_connectors.c | 31 +++---- drivers/gpu/drm/udl/udl_fb.c | 9 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 28 ++++-- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 12 ++- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 5 +- drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 5 +- drivers/iio/accel/st_accel_core.c | 2 +- drivers/iio/pressure/st_pressure_core.c | 2 +- drivers/mmc/host/dw_mmc.c | 6 +- drivers/mtd/nand/fsl_ifc_nand.c | 5 +- drivers/net/can/cc770/cc770.c | 100 +++++++++++++-------- drivers/net/can/cc770/cc770.h | 2 + drivers/net/wireless/brcm80211/brcmfmac/p2p.c | 24 +++-- .../net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 3 +- drivers/pci/quirks.c | 2 + drivers/staging/lustre/lustre/ptlrpc/sec.c | 2 +- drivers/tty/vt/vt.c | 8 +- fs/ncpfs/ncplib_kernel.c | 4 + include/asm-generic/pgtable.h | 10 +++ include/uapi/linux/usb/audio.h | 4 +- kernel/bpf/syscall.c | 2 +- kernel/trace/trace_kprobe.c | 4 +- kernel/trace/trace_probe.c | 8 +- kernel/trace/trace_probe.h | 2 +- lib/ioremap.c | 6 +- sound/drivers/aloop.c | 17 +++- sound/pci/hda/patch_realtek.c | 6 +- 45 files changed, 338 insertions(+), 153 deletions(-)

7 years, 5 months

7
60
0 0

[PATCHv4] irqchip: arm-gic: take gic_lock when updating irq type

by Aniruddha Banerjee

From: Aniruddha Banerjee <aniruddhab(a)nvidia.com> The kernel documentation states that the locking of the irq-chip registers should be handled by the irq-chip driver. In the irq-gic, the accesses to the irqchip are seemingly not protected and multiple writes to SPIs from different irq descriptors do RMW requests without taking the irq-chip lock. When multiple irqs call the request_irq at the same time, there can be a simultaneous write at the gic distributor, leading to a race. Acquire the gic_lock when the irq_type is updated. Cc: stable(a)vger.kernel.org Signed-off-by: Aniruddha Banerjee <aniruddhab(a)nvidia.com> --- Change from V1: * Moved the spinlock from irq-gic to irq-gic common, so that the fix is valid for GIC v1/v2/v3. Change from V2: * Fixup the Signed-off-by line. Change from V3: * Change raw_spin_lock to raw_spin_lock_irqsave and spin_unlock to raw_spin_unlock_irqrestore to protect against a potential deadlock when an interrupt handler changes the trigger type of any interrupt. drivers/irqchip/irq-gic-common.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c index 9ae71804b5dd..1c2ca8d51a70 100644 --- a/drivers/irqchip/irq-gic-common.c +++ b/drivers/irqchip/irq-gic-common.c @@ -21,6 +21,8 @@ #include "irq-gic-common.h" +static DEFINE_RAW_SPINLOCK(irq_controller_lock); + static const struct gic_kvm_info *gic_kvm_info; const struct gic_kvm_info *gic_get_kvm_info(void) @@ -52,11 +54,13 @@ int gic_configure_irq(unsigned int irq, unsigned int type, u32 confoff = (irq / 16) * 4; u32 val, oldval; int ret = 0; + unsigned long flags; /* * Read current configuration register, and insert the config * for "irq", depending on "type". */ + raw_spin_lock_irqsave(&irq_controller_lock, flags); val = oldval = readl_relaxed(base + GIC_DIST_CONFIG + confoff); if (type & IRQ_TYPE_LEVEL_MASK) val &= ~confmask; @@ -64,8 +68,10 @@ int gic_configure_irq(unsigned int irq, unsigned int type, val |= confmask; /* If the current configuration is the same, then we are done */ - if (val == oldval) + if (val == oldval) { + raw_spin_unlock_irqrestore(&irq_controller_lock, flags); return 0; + } /* * Write back the new configuration, and possibly re-enable @@ -83,6 +89,7 @@ int gic_configure_irq(unsigned int irq, unsigned int type, pr_warn("GIC: PPI%d is secure or misconfigured\n", irq - 16); } + raw_spin_unlock_irqrestore(&irq_controller_lock, flags); if (sync_access) sync_access(); -- 2.16.2

7 years, 5 months

2
1
0 0

[PATCH 10/14] iwlwifi: add a bunch of new 9000 PCI IDs

by Luca Coelho

From: Luca Coelho <luciano.coelho(a)intel.com> A lot of new PCI IDs were added for the 9000 series. Add them to the list of supported PCI IDs. Cc: stable(a)vger.kernel.org # 4.13+ Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> --- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 157 +++++++++++++++++++++++++- 1 file changed, 155 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c index e323d3abb6ac..959de2f8bb28 100644 --- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c @@ -8,6 +8,7 @@ * Copyright(c) 2007 - 2014 Intel Corporation. All rights reserved. * Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH * Copyright(c) 2016-2017 Intel Deutschland GmbH + * Copyright(c) 2018 Intel Corporation * * This program is free software; you can redistribute it and/or modify * it under the terms of version 2 of the GNU General Public License as @@ -36,6 +37,7 @@ * Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH * All rights reserved. * Copyright(c) 2017 Intel Deutschland GmbH + * Copyright(c) 2018 Intel Corporation * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions @@ -517,9 +519,9 @@ static const struct pci_device_id iwl_hw_card_ids[] = { {IWL_PCI_DEVICE(0x24FD, 0x9074, iwl8265_2ac_cfg)}, /* 9000 Series */ - {IWL_PCI_DEVICE(0x2526, 0x0000, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x0010, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x0014, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x0018, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x0030, iwl9560_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x0034, iwl9560_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x0038, iwl9560_2ac_cfg)}, @@ -544,11 +546,15 @@ static const struct pci_device_id iwl_hw_card_ids[] = { {IWL_PCI_DEVICE(0x2526, 0x1410, iwl9270_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x1420, iwl9460_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x2526, 0x1610, iwl9270_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x2030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2526, 0x2034, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x2526, 0x4010, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x4030, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x4034, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x2526, 0x40A4, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0xA014, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x4234, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x2526, 0x42A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2526, 0xA014, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x271B, 0x0010, iwl9160_2ac_cfg)}, {IWL_PCI_DEVICE(0x271B, 0x0014, iwl9160_2ac_cfg)}, {IWL_PCI_DEVICE(0x271B, 0x0210, iwl9160_2ac_cfg)}, @@ -569,16 +575,42 @@ static const struct pci_device_id iwl_hw_card_ids[] = { {IWL_PCI_DEVICE(0x2720, 0x0264, iwl9461_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x2720, 0x02A0, iwl9462_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x2720, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x1010, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x1030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x1210, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x2030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x2034, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x2720, 0x4030, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x4034, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x2720, 0x40A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x4234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x42A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x0030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x0034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x0038, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x003C, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x30DC, 0x0060, iwl9460_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x30DC, 0x0064, iwl9461_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x30DC, 0x00A0, iwl9462_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x30DC, 0x00A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x0230, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x0234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x0238, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x023C, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x30DC, 0x0260, iwl9461_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x30DC, 0x0264, iwl9461_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x30DC, 0x02A0, iwl9462_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x30DC, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x1010, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x30DC, 0x1030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x1210, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x30DC, 0x2030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x2034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x4030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x4034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x40A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x4234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x42A4, iwl9462_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x31DC, 0x0030, iwl9560_2ac_cfg_shared_clk)}, {IWL_PCI_DEVICE(0x31DC, 0x0034, iwl9560_2ac_cfg_shared_clk)}, {IWL_PCI_DEVICE(0x31DC, 0x0038, iwl9560_2ac_cfg_shared_clk)}, @@ -595,12 +627,94 @@ static const struct pci_device_id iwl_hw_card_ids[] = { {IWL_PCI_DEVICE(0x31DC, 0x0264, iwl9461_2ac_cfg_shared_clk)}, {IWL_PCI_DEVICE(0x31DC, 0x02A0, iwl9462_2ac_cfg_shared_clk)}, {IWL_PCI_DEVICE(0x31DC, 0x02A4, iwl9462_2ac_cfg_shared_clk)}, + {IWL_PCI_DEVICE(0x31DC, 0x1010, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x31DC, 0x1030, iwl9560_2ac_cfg_shared_clk)}, + {IWL_PCI_DEVICE(0x31DC, 0x1210, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x31DC, 0x2030, iwl9560_2ac_cfg_shared_clk)}, + {IWL_PCI_DEVICE(0x31DC, 0x2034, iwl9560_2ac_cfg_shared_clk)}, {IWL_PCI_DEVICE(0x31DC, 0x4030, iwl9560_2ac_cfg_shared_clk)}, {IWL_PCI_DEVICE(0x31DC, 0x4034, iwl9560_2ac_cfg_shared_clk)}, {IWL_PCI_DEVICE(0x31DC, 0x40A4, iwl9462_2ac_cfg_shared_clk)}, + {IWL_PCI_DEVICE(0x31DC, 0x4234, iwl9560_2ac_cfg_shared_clk)}, + {IWL_PCI_DEVICE(0x31DC, 0x42A4, iwl9462_2ac_cfg_shared_clk)}, {IWL_PCI_DEVICE(0x34F0, 0x0030, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x34F0, 0x0034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x0038, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x003C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x0060, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x0064, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x00A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x00A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x0230, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x0234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x0238, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x023C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x0260, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x0264, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x02A0, iwl9462_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x34F0, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x1010, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x34F0, 0x1030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x1210, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x34F0, 0x2030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x2034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x4030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x4034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x40A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x4234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x42A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x0030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x0034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x0038, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x003C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x0060, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x0064, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x00A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x00A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x0230, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x0234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x0238, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x023C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x0260, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x0264, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x02A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x1010, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x3DF0, 0x1030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x1210, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x3DF0, 0x2030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x2034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x4030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x4034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x40A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x4234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x3DF0, 0x42A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x0030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x0034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x0038, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x003C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x0060, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x0064, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x00A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x00A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x0230, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x0234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x0238, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x023C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x0260, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x0264, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x02A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x1010, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x43F0, 0x1030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x1210, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x43F0, 0x2030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x2034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x4030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x4034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x40A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x4234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x43F0, 0x42A4, iwl9462_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x9DF0, 0x0000, iwl9460_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x9DF0, 0x0010, iwl9460_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x9DF0, 0x0030, iwl9560_2ac_cfg_soc)}, @@ -626,11 +740,44 @@ static const struct pci_device_id iwl_hw_card_ids[] = { {IWL_PCI_DEVICE(0x9DF0, 0x0610, iwl9460_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x9DF0, 0x0710, iwl9460_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x9DF0, 0x0A10, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x1010, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x9DF0, 0x1030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x1210, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x9DF0, 0x2010, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x2030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x2034, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x9DF0, 0x2A10, iwl9460_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x9DF0, 0x4030, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x9DF0, 0x4034, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x9DF0, 0x40A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x4234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x42A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x0030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x0034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x0038, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x003C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x0060, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x0064, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x00A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x00A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x0230, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x0234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x0238, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x023C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x0260, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x0264, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x02A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x1010, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0xA0F0, 0x1030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x1210, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0xA0F0, 0x2030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x2034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x4030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x4034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x40A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x4234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA0F0, 0x42A4, iwl9462_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0xA370, 0x0030, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0xA370, 0x0034, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0xA370, 0x0038, iwl9560_2ac_cfg_soc)}, @@ -647,10 +794,16 @@ static const struct pci_device_id iwl_hw_card_ids[] = { {IWL_PCI_DEVICE(0xA370, 0x0264, iwl9461_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0xA370, 0x02A0, iwl9462_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0xA370, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x1010, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0xA370, 0x1030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x1210, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0xA370, 0x2030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x2034, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0xA370, 0x4030, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0xA370, 0x4034, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0xA370, 0x40A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x4234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x42A4, iwl9462_2ac_cfg_soc)}, /* 22000 Series */ {IWL_PCI_DEVICE(0x2720, 0x0A10, iwl22000_2ac_cfg_hr_cdb)}, -- 2.16.2

7 years, 5 months

1
0
0 0

[PATCHv3] irqchip: arm-gic: take gic_lock when updating irq type

by Aniruddha Banerjee

The kernel documentation states that the locking of the irq-chip registers should be handled by the irq-chip driver. In the irq-gic, the accesses to the irqchip are seemingly not protected and multiple writes to SPIs from different irq descriptors do RMW requests without taking the irq-chip lock. When multiple irqs call the request_irq at the same time, there can be a simultaneous write at the gic distributor, leading to a race. Acquire the gic_lock when the irq_type is updated. Signed-off-by: Aniruddha Banerjee <aniruddhab(a)nvidia.com> --- Changes from V1: * Moved the spinlock from irq-gic to irq-gic common, so that the fix is valid for GIC v1/v2/v3. Change from V2: * Fixup the Signed-off-by line. drivers/irqchip/irq-gic-common.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c index 9ae71804b5dd..73dd39959e6e 100644 --- a/drivers/irqchip/irq-gic-common.c +++ b/drivers/irqchip/irq-gic-common.c @@ -21,6 +21,8 @@ #include "irq-gic-common.h" +static DEFINE_RAW_SPINLOCK(irq_controller_lock); + static const struct gic_kvm_info *gic_kvm_info; const struct gic_kvm_info *gic_get_kvm_info(void) @@ -57,6 +59,7 @@ int gic_configure_irq(unsigned int irq, unsigned int type, * Read current configuration register, and insert the config * for "irq", depending on "type". */ + raw_spin_lock(&irq_controller_lock); val = oldval = readl_relaxed(base + GIC_DIST_CONFIG + confoff); if (type & IRQ_TYPE_LEVEL_MASK) val &= ~confmask; @@ -64,8 +67,10 @@ int gic_configure_irq(unsigned int irq, unsigned int type, val |= confmask; /* If the current configuration is the same, then we are done */ - if (val == oldval) + if (val == oldval) { + raw_spin_unlock(&irq_controller_lock); return 0; + } /* * Write back the new configuration, and possibly re-enable @@ -83,6 +88,7 @@ int gic_configure_irq(unsigned int irq, unsigned int type, pr_warn("GIC: PPI%d is secure or misconfigured\n", irq - 16); } + raw_spin_unlock(&irq_controller_lock); if (sync_access) sync_access(); -- 2.16.2

7 years, 5 months

3
2
0 0

[PATCH] Bluetooth: hci_bcm: Remove DMI quirk for the MINIX Z83-4

by ianwmorrison＠gmail.com

As Interrupt resource specified IRQs are now assumed to be always active-low the DMI quirk for the MINIX Z83-4 is no longer required. Cc: stable(a)vger.kernel.org Signed-off-by: Ian W MORRISON <ianwmorrison(a)gmail.com> --- drivers/bluetooth/hci_bcm.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c index 6828e485bc24..8a011267a4f6 100644 --- a/drivers/bluetooth/hci_bcm.c +++ b/drivers/bluetooth/hci_bcm.c @@ -804,13 +804,6 @@ static const struct dmi_system_id bcm_active_low_irq_dmi_table[] = { DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "ThinkPad 8"), }, }, - { - .ident = "MINIX Z83-4", - .matches = { - DMI_EXACT_MATCH(DMI_SYS_VENDOR, "MINIX"), - DMI_MATCH(DMI_PRODUCT_NAME, "Z83-4"), - }, - }, { } }; -- 2.11.0

7 years, 5 months

2
1
0 0

[PATCH V4] ZBOOT: fix stack protector in compressed boot phase

by Huacai Chen

Call __stack_chk_guard_setup() in decompress_kernel() is too late that stack checking always fails for decompress_kernel() itself. So remove __stack_chk_guard_setup() and initialize __stack_chk_guard before we call decompress_kernel(). Original code comes from ARM but also used for MIPS and SH, so fix them together. If without this fix, compressed booting of these archs will fail because stack checking is enabled by default (>=4.16). V1 -> V2: Fix build on ARM. V2 -> V3: Fix build on SuperH. V3 -> V4: Initialize __stack_chk_guard in C code as a constant. Cc: stable(a)vger.kernel.org Signed-off-by: Huacai Chen <chenhc(a)lemote.com> --- arch/arm/boot/compressed/head.S | 4 ++++ arch/arm/boot/compressed/misc.c | 7 ------- arch/mips/boot/compressed/decompress.c | 7 ------- arch/mips/boot/compressed/head.S | 4 ++++ arch/sh/boot/compressed/head_32.S | 8 ++++++++ arch/sh/boot/compressed/head_64.S | 4 ++++ arch/sh/boot/compressed/misc.c | 7 ------- 7 files changed, 20 insertions(+), 21 deletions(-) diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c index 16a8a80..e8fe51f 100644 --- a/arch/arm/boot/compressed/misc.c +++ b/arch/arm/boot/compressed/misc.c @@ -128,12 +128,7 @@ asmlinkage void __div0(void) error("Attempting division by 0!"); } -unsigned long __stack_chk_guard; - -void __stack_chk_guard_setup(void) -{ - __stack_chk_guard = 0x000a0dff; -} +const unsigned long __stack_chk_guard = 0x000a0dff; void __stack_chk_fail(void) { @@ -150,8 +145,6 @@ decompress_kernel(unsigned long output_start, unsigned long free_mem_ptr_p, { int ret; - __stack_chk_guard_setup(); - output_data = (unsigned char *)output_start; free_mem_ptr = free_mem_ptr_p; free_mem_end_ptr = free_mem_ptr_end_p; diff --git a/arch/mips/boot/compressed/decompress.c b/arch/mips/boot/compressed/decompress.c index fdf99e9..81df904 100644 --- a/arch/mips/boot/compressed/decompress.c +++ b/arch/mips/boot/compressed/decompress.c @@ -76,12 +76,7 @@ void error(char *x) #include "../../../../lib/decompress_unxz.c" #endif -unsigned long __stack_chk_guard; - -void __stack_chk_guard_setup(void) -{ - __stack_chk_guard = 0x000a0dff; -} +const unsigned long __stack_chk_guard = 0x000a0dff; void __stack_chk_fail(void) { @@ -92,8 +87,6 @@ void decompress_kernel(unsigned long boot_heap_start) { unsigned long zimage_start, zimage_size; - __stack_chk_guard_setup(); - zimage_start = (unsigned long)(&__image_begin); zimage_size = (unsigned long)(&__image_end) - (unsigned long)(&__image_begin); diff --git a/arch/sh/boot/compressed/misc.c b/arch/sh/boot/compressed/misc.c index 627ce8e..c15cac9 100644 --- a/arch/sh/boot/compressed/misc.c +++ b/arch/sh/boot/compressed/misc.c @@ -104,12 +104,7 @@ static void error(char *x) while(1); /* Halt */ } -unsigned long __stack_chk_guard; - -void __stack_chk_guard_setup(void) -{ - __stack_chk_guard = 0x000a0dff; -} +const unsigned long __stack_chk_guard = 0x000a0dff; void __stack_chk_fail(void) { @@ -130,8 +125,6 @@ void decompress_kernel(void) { unsigned long output_addr; - __stack_chk_guard_setup(); - #ifdef CONFIG_SUPERH64 output_addr = (CONFIG_MEMORY_START + 0x2000); #else

7 years, 5 months

2
1
0 0

[PATCH] drm/amdgpu/sdma: fix mask in emit_pipeline_sync

by Alex Deucher

Needs to be a 32 bit mask. Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 2 +- drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 2 +- drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c index f48ea0dad875..a7576255cc30 100644 --- a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c +++ b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c @@ -859,7 +859,7 @@ static void cik_sdma_ring_emit_pipeline_sync(struct amdgpu_ring *ring) amdgpu_ring_write(ring, addr & 0xfffffffc); amdgpu_ring_write(ring, upper_32_bits(addr) & 0xffffffff); amdgpu_ring_write(ring, seq); /* reference */ - amdgpu_ring_write(ring, 0xfffffff); /* mask */ + amdgpu_ring_write(ring, 0xffffffff); /* mask */ amdgpu_ring_write(ring, (0xfff << 16) | 4); /* retry count, poll interval */ } diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c index 6452101c7aab..c7190c39c4f5 100644 --- a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c @@ -837,7 +837,7 @@ static void sdma_v2_4_ring_emit_pipeline_sync(struct amdgpu_ring *ring) amdgpu_ring_write(ring, addr & 0xfffffffc); amdgpu_ring_write(ring, upper_32_bits(addr) & 0xffffffff); amdgpu_ring_write(ring, seq); /* reference */ - amdgpu_ring_write(ring, 0xfffffff); /* mask */ + amdgpu_ring_write(ring, 0xffffffff); /* mask */ amdgpu_ring_write(ring, SDMA_PKT_POLL_REGMEM_DW5_RETRY_COUNT(0xfff) | SDMA_PKT_POLL_REGMEM_DW5_INTERVAL(4)); /* retry count, poll interval */ } diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c index ecaef084dab1..be20a387d961 100644 --- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c @@ -1105,7 +1105,7 @@ static void sdma_v3_0_ring_emit_pipeline_sync(struct amdgpu_ring *ring) amdgpu_ring_write(ring, addr & 0xfffffffc); amdgpu_ring_write(ring, upper_32_bits(addr) & 0xffffffff); amdgpu_ring_write(ring, seq); /* reference */ - amdgpu_ring_write(ring, 0xfffffff); /* mask */ + amdgpu_ring_write(ring, 0xffffffff); /* mask */ amdgpu_ring_write(ring, SDMA_PKT_POLL_REGMEM_DW5_RETRY_COUNT(0xfff) | SDMA_PKT_POLL_REGMEM_DW5_INTERVAL(4)); /* retry count, poll interval */ } diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c index 2a8184082cd1..399f876f9cad 100644 --- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c @@ -1121,7 +1121,7 @@ static void sdma_v4_0_ring_emit_pipeline_sync(struct amdgpu_ring *ring) amdgpu_ring_write(ring, addr & 0xfffffffc); amdgpu_ring_write(ring, upper_32_bits(addr) & 0xffffffff); amdgpu_ring_write(ring, seq); /* reference */ - amdgpu_ring_write(ring, 0xfffffff); /* mask */ + amdgpu_ring_write(ring, 0xffffffff); /* mask */ amdgpu_ring_write(ring, SDMA_PKT_POLL_REGMEM_DW5_RETRY_COUNT(0xfff) | SDMA_PKT_POLL_REGMEM_DW5_INTERVAL(4)); /* retry count, poll interval */ } -- 2.13.6

7 years, 5 months

3
2
0 0

[PATCH v2] drm/i915/gvt: Add drm_format_mod update

by Tina Zhang

Add drm_format_mod update, which is omitted. Fixes: e546e281("drm/i915/gvt: Dmabuf support for GVT-g") Cc: stable(a)vger.kernel.org Signed-off-by: Tina Zhang <tina.zhang(a)intel.com> --- drivers/gpu/drm/i915/gvt/dmabuf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c b/drivers/gpu/drm/i915/gvt/dmabuf.c index 459d37c..e332470 100644 --- a/drivers/gpu/drm/i915/gvt/dmabuf.c +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c @@ -321,6 +321,7 @@ static void update_fb_info(struct vfio_device_gfx_plane_info *gvt_dmabuf, struct intel_vgpu_fb_info *fb_info) { gvt_dmabuf->drm_format = fb_info->drm_format; + gvt_dmabuf->drm_format_mod = fb_info->drm_format_mod; gvt_dmabuf->width = fb_info->width; gvt_dmabuf->height = fb_info->height; gvt_dmabuf->stride = fb_info->stride; -- 2.7.4

7 years, 5 months

1
0
0 0

Applied "ASoC: topology: Fix kcontrol name string handling" to the asoc tree

by Mark Brown

The patch ASoC: topology: Fix kcontrol name string handling has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 267e2c6fd7ca3d4076d20f9d52d49dc91addfe9d Mon Sep 17 00:00:00 2001 From: Liam Girdwood <liam.r.girdwood(a)linux.intel.com> Date: Tue, 27 Mar 2018 12:04:04 +0100 Subject: [PATCH] ASoC: topology: Fix kcontrol name string handling Fix the topology kcontrol string handling so that string pointer references are strdup()ed instead of being copied. This fixes issues with kcontrol templates on the stack or ones that are freed. Remember and free the strings too when topology is unloaded. Signed-off-by: Liam Girdwood <liam.r.girdwood(a)linux.intel.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- sound/soc/soc-topology.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c index 01a50413c66f..782c580b7aa3 100644 --- a/sound/soc/soc-topology.c +++ b/sound/soc/soc-topology.c @@ -523,6 +523,7 @@ static void remove_widget(struct snd_soc_component *comp, kfree(se->dobj.control.dtexts[j]); kfree(se); + kfree(w->kcontrol_news[i].name); } kfree(w->kcontrol_news); } else { @@ -540,6 +541,7 @@ static void remove_widget(struct snd_soc_component *comp, */ kfree((void *)kcontrol->private_value); snd_ctl_remove(card, kcontrol); + kfree(w->kcontrol_news[i].name); } kfree(w->kcontrol_news); } @@ -1233,7 +1235,9 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_dmixer_create( dev_dbg(tplg->dev, " adding DAPM widget mixer control %s at %d\n", mc->hdr.name, i); - kc[i].name = mc->hdr.name; + kc[i].name = kstrdup(mc->hdr.name, GFP_KERNEL); + if (kc[i].name == NULL) + goto err_str; kc[i].private_value = (long)sm; kc[i].iface = SNDRV_CTL_ELEM_IFACE_MIXER; kc[i].access = mc->hdr.access; @@ -1278,8 +1282,10 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_dmixer_create( err_str: kfree(sm); err: - for (--i; i >= 0; i--) + for (--i; i >= 0; i--) { kfree((void *)kc[i].private_value); + kfree(kc[i].name); + } kfree(kc); return NULL; } @@ -1310,7 +1316,9 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_denum_create( dev_dbg(tplg->dev, " adding DAPM widget enum control %s\n", ec->hdr.name); - kc[i].name = ec->hdr.name; + kc[i].name = kstrdup(ec->hdr.name, GFP_KERNEL); + if (kc[i].name == NULL) + goto err_se; kc[i].private_value = (long)se; kc[i].iface = SNDRV_CTL_ELEM_IFACE_MIXER; kc[i].access = ec->hdr.access; @@ -1386,6 +1394,7 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_denum_create( kfree(se->dobj.control.dtexts[j]); kfree(se); + kfree(kc[i].name); } err: kfree(kc); @@ -1424,7 +1433,9 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_dbytes_create( "ASoC: adding bytes kcontrol %s with access 0x%x\n", be->hdr.name, be->hdr.access); - kc[i].name = be->hdr.name; + kc[i].name = kstrdup(be->hdr.name, GFP_KERNEL); + if (kc[i].name == NULL) + goto err; kc[i].private_value = (long)sbe; kc[i].iface = SNDRV_CTL_ELEM_IFACE_MIXER; kc[i].access = be->hdr.access; @@ -1454,8 +1465,10 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_dbytes_create( return kc; err: - for (--i; i >= 0; i--) + for (--i; i >= 0; i--) { kfree((void *)kc[i].private_value); + kfree(kc[i].name); + } kfree(kc); return NULL; -- 2.16.2

7 years, 5 months

1
0
0 0

Re: [PATCH] ARM64: dts: meson: reduce odroid-c2 eMMC maximum rate

by Kevin Hilman

On Fri, Mar 2, 2018 at 5:44 AM, Jerome Brunet <jbrunet(a)baylibre.com> wrote: > Different modules maybe installed by the user on the eMMC connector > of the odroid-c2. While the red modules are working without an issue, > it seems some black modules (apparently Samsung based) are having > issue at 200MHz > > While the tuning algorithm introduced in v4.14 enables high speed modes > on every other tested designs, it seems a problem remains for this > particular combination of board and eMMC module. > > Lowering the maximum frequency of the eMMC on this board until we can > figure out a better solution. > > Fixes: d341ca88eead ("mmc: meson-gx: rework tuning function") > Suggested-by: Ellie Reeves <ellierevves(a)gmail.com> > Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> Now in mainline as commit c04ffa71ff49 upstream. The mainline patch has "Cc: stable(a)vger.kernel.org", but it doesn't seem to have appeared in stable yet, and I've verified that it applies cleanly to linux-4.15.y and linux-4.14.y. Kevin > --- > arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts > index 73a030a5ecf3..43475139576c 100644 > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts > @@ -311,7 +311,7 @@ > pinctrl-names = "default", "clk-gate"; > > bus-width = <8>; > - max-frequency = <200000000>; > + max-frequency = <100000000>; > non-removable; > disable-wp; > cap-mmc-highspeed; > -- > 2.14.3 >

7 years, 5 months

2
2
0 0

[PATCH] pwm: rcar: fix a condition to prevent mismatch value setting to duty

by Yoshihiro Shimoda

From: Ryo Kodama <ryo.kodama.vz(a)renesas.com> This patch fixes an issue that is possible to set mismatch value to duty for R-Car PWM if we input the following commands: # cd /sys/class/pwm/<pwmchip>/ # echo 0 > export # cd pwm0 # echo 30 > period # echo 30 > duty_cycle # echo 0 > duty_cycle # cat duty_cycle 0 # echo 1 > enable --> Then, the actual duty_cycle is 30, not 0. So, this patch adds a condition into rcar_pwm_config() to fix this issue. Signed-off-by: Ryo Kodama <ryo.kodama.vz(a)renesas.com> [shimoda: revise the commit log and add Fixes and Cc tags] Fixes: ed6c1476bf7f ("pwm: Add support for R-Car PWM Timer") Cc: Cc: <stable(a)vger.kernel.org> # v4.4+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> --- drivers/pwm/pwm-rcar.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c index 1c85ecc..0fcf94f 100644 --- a/drivers/pwm/pwm-rcar.c +++ b/drivers/pwm/pwm-rcar.c @@ -156,8 +156,12 @@ static int rcar_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm, if (div < 0) return div; - /* Let the core driver set pwm->period if disabled and duty_ns == 0 */ - if (!pwm_is_enabled(pwm) && !duty_ns) + /* + * Let the core driver set pwm->period if disabled and duty_ns == 0. + * But, this driver should prevent to set the new duty_ns if current + * duty_cycle is not set + */ + if (!pwm_is_enabled(pwm) && !duty_ns && !pwm->state.duty_cycle) return 0; rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR); -- 1.9.1

7 years, 5 months

2
1
0 0

+ task_struct-only-use-anon-struct-under-randstruct-plugin.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: task_struct: only use anon struct under randstruct plugin has been added to the -mm tree. Its filename is task_struct-only-use-anon-struct-under-randstruct-plugin.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/task_struct-only-use-anon-struct-u… and later at http://ozlabs.org/~akpm/mmotm/broken-out/task_struct-only-use-anon-struct-u… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Kees Cook <keescook(a)chromium.org> Subject: task_struct: only use anon struct under randstruct plugin The original intent for always adding the anonymous struct in task_struct was to make sure we had compiler coverage. However, this caused pathological padding of 40 bytes at the start of task_struct. Instead, move the anonymous struct to being only used when struct layout randomization is enabled. Link: http://lkml.kernel.org/r/20180327213609.GA2964@beast Fixes: 29e48ce87f1e ("task_struct: Allow randomized") Signed-off-by: Kees Cook <keescook(a)chromium.org> Reported-by: Peter Zijlstra <peterz(a)infradead.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/compiler-clang.h | 3 --- include/linux/compiler-gcc.h | 12 +++--------- 2 files changed, 3 insertions(+), 12 deletions(-) diff -puN include/linux/compiler-clang.h~task_struct-only-use-anon-struct-under-randstruct-plugin include/linux/compiler-clang.h --- a/include/linux/compiler-clang.h~task_struct-only-use-anon-struct-under-randstruct-plugin +++ a/include/linux/compiler-clang.h @@ -17,9 +17,6 @@ */ #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__) -#define randomized_struct_fields_start struct { -#define randomized_struct_fields_end }; - /* all clang versions usable with the kernel support KASAN ABI version 5 */ #define KASAN_ABI_VERSION 5 diff -puN include/linux/compiler-gcc.h~task_struct-only-use-anon-struct-under-randstruct-plugin include/linux/compiler-gcc.h --- a/include/linux/compiler-gcc.h~task_struct-only-use-anon-struct-under-randstruct-plugin +++ a/include/linux/compiler-gcc.h @@ -242,6 +242,9 @@ #if defined(RANDSTRUCT_PLUGIN) && !defined(__CHECKER__) #define __randomize_layout __attribute__((randomize_layout)) #define __no_randomize_layout __attribute__((no_randomize_layout)) +/* This anon struct can add padding, so only enable it under randstruct. */ +#define randomized_struct_fields_start struct { +#define randomized_struct_fields_end } __randomize_layout; #endif #endif /* GCC_VERSION >= 40500 */ @@ -256,15 +259,6 @@ */ #define __visible __attribute__((externally_visible)) -/* - * RANDSTRUCT_PLUGIN wants to use an anonymous struct, but it is only - * possible since GCC 4.6. To provide as much build testing coverage - * as possible, this is used for all GCC 4.6+ builds, and not just on - * RANDSTRUCT_PLUGIN builds. - */ -#define randomized_struct_fields_start struct { -#define randomized_struct_fields_end } __randomize_layout; - #endif /* GCC_VERSION >= 40600 */ _ Patches currently in -mm which might be from keescook(a)chromium.org are taint-convert-to-indexed-initialization.patch taint-consolidate-documentation.patch taint-add-taint-for-randstruct.patch kernelh-introduce-const_max-for-vla-removal.patch remove-false-positive-vlas-when-using-max.patch task_struct-only-use-anon-struct-under-randstruct-plugin.patch test_bitmap-do-not-accidentally-use-stack-vla.patch fork-unconditionally-clear-stack-on-fork.patch exec-pass-stack-rlimit-into-mm-layout-functions.patch exec-introduce-finalize_exec-before-start_thread.patch exec-pin-stack-limit-during-exec.patch exofs-avoid-vla-in-structures.patch

7 years, 5 months

1
0
0 0

[PATCH v1] pwm: mediatek: improve precision in rate calculation

by sean.wang＠mediatek.com

From: Sean Wang <sean.wang(a)mediatek.com> Add a way that turning resolution from in nanosecond into in picosecond to improve noticeably almost 4.5% precision. It's necessary to hold the new resolution with type u64 and thus related operations on u64 are applied instead in those rate calculations. And the patch has a dependency on [1]. [1] http://lists.infradead.org/pipermail/linux-mediatek/2018-March/012225.html Cc: stable(a)vger.kernel.org Fixes: caf065f8fd58 ("pwm: Add MediaTek PWM support") Signed-off-by: Sean Wang <sean.wang(a)mediatek.com> --- drivers/pwm/pwm-mediatek.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c index 796baea..98b0a93 100644 --- a/drivers/pwm/pwm-mediatek.c +++ b/drivers/pwm/pwm-mediatek.c @@ -135,19 +135,25 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm, { struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip); struct clk *clk = pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]; - u32 resolution, clkdiv = 0, reg_width = PWMDWIDTH, + u32 clkdiv = 0, cnt_period, cnt_duty, reg_width = PWMDWIDTH, reg_thres = PWMTHRES; + u64 resolution; int ret; ret = mtk_pwm_clk_enable(chip, pwm); if (ret < 0) return ret; - resolution = NSEC_PER_SEC / clk_get_rate(clk); + /* Using resolution in picosecond gets accuracy higher */ + resolution = (u64)NSEC_PER_SEC * 1000; + do_div(resolution, clk_get_rate(clk)); - while (period_ns / resolution > 8191) { + cnt_period = DIV_ROUND_CLOSEST_ULL((u64)period_ns * 1000, resolution); + while (cnt_period > 8191) { resolution *= 2; clkdiv++; + cnt_period = DIV_ROUND_CLOSEST_ULL((u64)period_ns * 1000, + resolution); } if (clkdiv > PWM_CLK_DIV_MAX) { @@ -165,9 +171,10 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm, reg_thres = PWM45THRES_FIXUP; } + cnt_duty = DIV_ROUND_CLOSEST_ULL((u64)duty_ns * 1000, resolution); mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | clkdiv); - mtk_pwm_writel(pc, pwm->hwpwm, reg_width, period_ns / resolution); - mtk_pwm_writel(pc, pwm->hwpwm, reg_thres, duty_ns / resolution); + mtk_pwm_writel(pc, pwm->hwpwm, reg_width, cnt_period); + mtk_pwm_writel(pc, pwm->hwpwm, reg_thres, cnt_duty); mtk_pwm_clk_disable(chip, pwm); -- 2.7.4

7 years, 5 months

2
1
0 0

Re: [PATCH v3] pwm: mediatek: fix up PWM4 and PWM5 malfunction on MT7623

by Sean Wang

On Fri, 2018-03-02 at 11:57 +0100, Thierry Reding wrote: > On Thu, Mar 01, 2018 at 04:19:12PM +0800, sean.wang(a)mediatek.com wrote: > > From: Sean Wang <sean.wang(a)mediatek.com> > > > > Since the offset for both registers, PWMDWIDTH and PWMTHRES, used to > > control PWM4 or PWM5 are distinct from the other PWMs, whose wrong > > programming on PWM hardware causes waveform cannot be output as expected. > > Thus, the patch adds the extra condition for fixing up the weird case to > > let PWM4 or PWM5 able to work on MT7623. > > > > v1 -> v2: use pwm45_fixup naming instead of pwm45_quirk > > v2 -> v3: add more tags for Reviewed-by, Fixes, and Cc stable > > > > Cc: stable(a)vger.kernel.org > > Fixes: caf065f8fd58 ("pwm: Add MediaTek PWM support") > > Signed-off-by: Sean Wang <sean.wang(a)mediatek.com> > > Reviewed-by: Matthias Brugger <matthias.bgg(a)gmail.com> > > Cc: Zhi Mao <zhi.mao(a)mediatek.com> > > Cc: John Crispin <john(a)phrozen.org> > > Cc: Matthias Brugger <matthias.bgg(a)gmail.com> > > --- > > drivers/pwm/pwm-mediatek.c | 24 +++++++++++++++++++++--- > > 1 file changed, 21 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c > [...] > > @@ -151,9 +156,18 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm, > > return -EINVAL; > > } > > > > + if (pc->soc->pwm45_fixup && pwm->hwpwm > 2) { > > + /* > > + * PWM[4,5] has distinct offset for PWMDWIDTH and PWMTHRES > > + * from the other PWMs on MT7623. > > + */ > > + reg_width = PWM45DWIDTH_FIXUP; > > + reg_thres = PWM45THRES_FIXUP; > > + } > > I don't understand this. According to the condition above the above > would also use the PWM[4,5] "fixup" register offsets with PWM[3]. Should > the condition be pwm->hwpwm > 3? > > Thierry PWM[4,5] are the naming specified in datasheet and kept it as is here and driver or userspace would use index 3 and 4 to have a reference to them respectively.

7 years, 5 months

2
1
0 0

[PATCH] x86/platform/uv/BAU: add APIC idt entry

by Andrew Banman

BAU uses the old alloc_initr_gate method to setup its interrupt. This fails silently as the BAU vector is in the range of APIC vectors that are registerted to the spurious interrupt handler. Then BAU broadcasts are not handled, and the broadcast source CPU hangs. Fixed by updating BAU to use new idt structure. Signed-off-by: Andrew Banman <abanman(a)hpe.com> Acked-by: Mike Travis <mike.travis(a)hpe.com> --- arch/x86/include/asm/hw_irq.h | 1 + arch/x86/kernel/idt.c | 3 +++ arch/x86/platform/uv/tlb_uv.c | 2 -- 3 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h index 6dfe366..a56cd0b 100644 --- a/arch/x86/include/asm/hw_irq.h +++ b/arch/x86/include/asm/hw_irq.h @@ -33,6 +33,7 @@ extern asmlinkage void kvm_posted_intr_nested_ipi(void); extern asmlinkage void error_interrupt(void); extern asmlinkage void irq_work_interrupt(void); +extern asmlinkage void uv_bau_message_intr1(void); extern asmlinkage void spurious_interrupt(void); extern asmlinkage void thermal_interrupt(void); diff --git a/arch/x86/kernel/idt.c b/arch/x86/kernel/idt.c index 99f93a6..c5da34e 100644 --- a/arch/x86/kernel/idt.c +++ b/arch/x86/kernel/idt.c @@ -138,6 +138,9 @@ struct idt_data { # ifdef CONFIG_IRQ_WORK INTG(IRQ_WORK_VECTOR, irq_work_interrupt), # endif +#ifdef CONFIG_X86_UV + INTG(UV_BAU_MESSAGE, uv_bau_message_intr1), +#endif INTG(SPURIOUS_APIC_VECTOR, spurious_interrupt), INTG(ERROR_APIC_VECTOR, error_interrupt), #endif diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c index f44c0bc..5e22845 100644 --- a/arch/x86/platform/uv/tlb_uv.c +++ b/arch/x86/platform/uv/tlb_uv.c @@ -2254,8 +2254,6 @@ static int __init uv_bau_init(void) init_uvhub(uvhub, vector, uv_base_pnode); } - alloc_intr_gate(vector, uv_bau_message_intr1); - for_each_possible_blade(uvhub) { if (uv_blade_nr_possible_cpus(uvhub)) { unsigned long val; -- 1.8.2.1

7 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror