3.4.107-rc1 review
Subsystems (5)
Re: [PATCH 3.4 140/176] lib/checksum.c: fix carry in csum_tcpudp_nofold
In reply to Karl BeldanQuoted 8 lines · Karl Beldan
Quoted 7 lines · On Thu, Apr 09, 2015 at 04:46:28PM +0800, [email protected] wrote:
From: karl beldan <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
Quoted 9 lines
Quoted 2 lines
commit
150ae0e94634714b23919f0c333fee28a5b199d5upstream.Hi Zefan,
The above patch introduced a build error for some archs, please consider applying
9ce357795ef208faa0d59894d9d119a7434e37f3"lib/checksum.c: fix build for genericcsum_tcpudp_nofold" as well.
Will fix. Thanks for the review!
PATCH 141/176 caif: remove wrong dev_net_set() call
In reply to [email protected]From: Nicolas Dichtel <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 8997c27ec41127bf57421cc0205413d525421ddc upstream.
src_net points to the netns where the netlink message has been received. This netns may be different from the netns where the interface is created (because the user may add IFLA_NET_NS_[PID|FD]). In this case, src_net is the link netns.
It seems wrong to override the netns in the newlink() handler because if it was not already src_net, it means that the user explicitly asks to create the netdevice in another netns.
--- net/caif/chnl_net.c | 1 - 1 file changed, 1 deletion(-)
net/caif/chnl_net.c +0 -1
@@ -467,7 +467,6 @@ static int ipcaif_newlink(struct net *src_net, struct net_device *dev,ASSERT_RTNL (); caifdev =netdev_priv (dev);caif_netlink_parms (data, &caifdev->conn_req); -dev_net_set (caifdev->netdev, src_net); ret =register_netdevice (dev);if (ret)
Signature · 1 line
1.9.1
PATCH 142/176 MIPS: Fix kernel lockup or crash after CPU offline/online
In reply to [email protected]From: Hemmo Nieminen <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit c7754e75100ed5e3068ac5085747f2bfc386c8d6 upstream.
As printk() invocation can cause e.g. a TLB miss, printk() cannot be called before the exception handlers have been properly initialized. This can happen e.g. when netconsole has been loaded as a kernel module and the TLB table has been cleared when a CPU was offline.
Call cpu_report() in start_secondary() only after the exception handlers have been initialized to fix this.
Without the patch the kernel will randomly either lockup or crash after a CPU is onlined and the console driver is a module.
Patchwork: https://patchwork.linux-mips.org/patch/8953/
--- arch/mips/kernel/smp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/mips/kernel/smp.c +1 -1
@@ -105,10 +105,10 @@ asmlinkage __cpuinit void start_secondary(void) if ((read_c0_tcbind() & TCBIND_CURTC) == 0)#endif /* CONFIG_MIPS_MT_SMTC */ cpu_probe (); -cpu_report ();per_cpu_trap_init ();mips_clockevent_init (); mp_ops->init_secondary (); +cpu_report ();/* * XXX parity protection should be folded in here when it's converted
Signature · 1 line
1.9.1
PATCH 143/176 gpio: sysfs: fix memory leak in gpiod_export_link
In reply to [email protected]From: Johan Hovold <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 0f303db08df0df9bd0966443ad6001e63960af16 upstream.
Fix memory leak in the gpio sysfs interface due to failure to drop reference to device returned by class_find_device when creating a link.
using sysfs links")
--- drivers/gpio/gpiolib.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpio/gpiolib.c +1 -0
@@ -825,6 +825,7 @@ int gpio_export_link(struct device *dev, const char *name, unsigned gpio)if (tdev !=NULL ) { status =sysfs_create_link (&dev->kobj, &tdev->kobj, name); +put_device (tdev); }else { status = -ENODEV ; }
Signature · 1 line
1.9.1
PATCH 144/176 gpio: sysfs: fix memory leak in gpiod_sysfs_set_active_low
In reply to [email protected]From: Johan Hovold <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 49d2ca84e433dab854c7a866bc6add09cfab682d upstream.
Fix memory leak in the gpio sysfs interface due to failure to drop reference to device returned by class_find_device when setting the gpio-line polarity.
in sysfs")
--- drivers/gpio/gpiolib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpio/gpiolib.c +1 -1
@@ -876,7 +876,7 @@ int gpio_sysfs_set_active_low(unsigned gpio, int value) } status =sysfs_set_active_low (desc, dev, value); - +put_device (dev); unlock:mutex_unlock (&sysfs_lock);
Signature · 1 line
1.9.1
PATCH 145/176 MIPS: Fix C0_Pagegrain[IEC] support.
In reply to [email protected]From: David Daney <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 9ead8632bbf454cfc709b6205dc9cd8582fb0d64 upstream.
The following commits:
5890f70f15c52d (MIPS: Use dedicated exception handler if CPU supports RI/XI exceptions) 6575b1d4173eae (MIPS: kernel: cpu-probe: Detect unique RI/XI exceptions)
break the kernel for *all* existing MIPS CPUs that implement the CP0_PageGrain[IEC] bit. They cause the TLB exception handlers to be generated without the legacy execute-inhibit handling, but never set the CP0_PageGrain[IEC] bit to activate the use of dedicated exception vectors for execute-inhibit exceptions. The result is that upon detection of an execute-inhibit violation, we loop forever in the TLB exception handlers instead of sending SIGSEGV to the task.
If we are generating TLB exception handlers expecting separate vectors, we must also enable the CP0_PageGrain[IEC] feature.
The bug was introduced in kernel version 3.17.
Patchwork: http://patchwork.linux-mips.org/patch/8880/
--- arch/mips/mm/tlb-r4k.c | 2 ++ 1 file changed, 2 insertions(+)
arch/mips/mm/tlb-r4k.c +2 -0
@@ -410,6 +410,8 @@ void __cpuinit tlb_init(void)#ifdef CONFIG_64BIT pg |=PG_ELPA ;#endif +if (cpu_has_rixiex) + pg |=PG_IEC ;write_c0_pagegrain (pg); }
Signature · 1 line
1.9.1
PATCH 146/176 net: sctp: fix NULL pointer dereference in af->from_addr_param on malformed packet
In reply to [email protected]From: Daniel Borkmann <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit e40607cbe270a9e8360907cb1e62ddf0736e4864 upstream.
An SCTP server doing ASCONF will panic on malformed INIT ping-of-death in the form of:
------------ INIT[PARAM: SET_PRIMARY_IP] ------------>
While the INIT chunk parameter verification dissects through many things in order to detect malformed input, it misses to actually check parameters inside of parameters. E.g. RFC5061, section 4.2.4 proposes a 'set primary IP address' parameter in ASCONF, which has as a subparameter an address parameter.
So an attacker may send a parameter type other than SCTP_PARAM_IPV4_ADDRESS or SCTP_PARAM_IPV6_ADDRESS, param_type2af() will subsequently return 0 and thus sctp_get_af_specific() returns NULL, too, which we then happily dereference unconditionally through af->from_addr_param().
The trace for the log:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000078 IP: [<ffffffffa01e9c62>] sctp_process_init+0x492/0x990 [sctp] PGD 0 Oops: 0000 [#1] SMP [...] Pid: 0, comm: swapper Not tainted 2.6.32-504.el6.x86_64 #1 Bochs Bochs RIP: 0010:[<ffffffffa01e9c62>] [<ffffffffa01e9c62>] sctp_process_init+0x492/0x990 [sctp] [...] Call Trace: <IRQ> [<ffffffffa01f2add>] ? sctp_bind_addr_copy+0x5d/0xe0 [sctp] [<ffffffffa01e1fcb>] sctp_sf_do_5_1B_init+0x21b/0x340 [sctp] [<ffffffffa01e3751>] sctp_do_sm+0x71/0x1210 [sctp] [<ffffffffa01e5c09>] ? sctp_endpoint_lookup_assoc+0xc9/0xf0 [sctp] [<ffffffffa01e61f6>] sctp_endpoint_bh_rcv+0x116/0x230 [sctp] [<ffffffffa01ee986>] sctp_inq_push+0x56/0x80 [sctp] [<ffffffffa01fcc42>] sctp_rcv+0x982/0xa10 [sctp] [<ffffffffa01d5123>] ? ipt_local_in_hook+0x23/0x28 [iptable_filter] [<ffffffff8148bdc9>] ? nf_iterate+0x69/0xb0 [<ffffffff81496d10>] ? ip_local_deliver_finish+0x0/0x2d0 [<ffffffff8148bf86>] ? nf_hook_slow+0x76/0x120 [<ffffffff81496d10>] ? ip_local_deliver_finish+0x0/0x2d0
[...]
A minimal way to address this is to check for NULL as we do on all other such occasions where we know sctp_get_af_specific() could possibly return with NULL.
--- net/sctp/sm_make_chunk.c | 3 +++ 1 file changed, 3 insertions(+)
net/sctp/sm_make_chunk.c +3 -0
@@ -2570,6 +2570,9 @@ do_addr_param: addr_param = param.v +sizeof (sctp_addip_param_t); af =sctp_get_af_specific (param_type2af (param.p->type)); +if (af ==NULL ) +break ; + af->from_addr_param (&addr, addr_param,htons (asoc->peer.port),0 );
Signature · 1 line
1.9.1
PATCH 147/176 net: sctp: fix passing wrong parameter header to param_type2af in sctp_process_param
In reply to [email protected]From: Saran Maruti Ramanara <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit cfbf654efc6d78dc9812e030673b86f235bf677d upstream.
When making use of RFC5061, section 4.2.4. for setting the primary IP address, we're passing a wrong parameter header to param_type2af(), resulting always in NULL being returned.
At this point, param.p points to a sctp_addip_param struct, containing a sctp_paramhdr (type = 0xc004, length = var), and crr_id as a correlation id. Followed by that, as also presented in RFC5061 section 4.2.4., comes the actual sctp_addr_param, which also contains a sctp_paramhdr, but this time with the correct type SCTP_PARAM_IPV{4,6}_ADDRESS that param_type2af() can make use of. Since we already hold a pointer to addr_param from previous line, just reuse it for param_type2af().
--- net/sctp/sm_make_chunk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/sctp/sm_make_chunk.c +1 -1
@@ -2569,7 +2569,7 @@ do_addr_param: addr_param = param.v +sizeof (sctp_addip_param_t); - af =sctp_get_af_specific (param_type2af (param.p->type)); + af =sctp_get_af_specific (param_type2af (addr_param->p.type));if (af ==NULL )break ;
Signature · 1 line
1.9.1
PATCH 148/176 ASoC: sgtl5000: add delay before first I2C access
In reply to [email protected]From: Eric Nelson <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 58cc9c9a175885bbf6bae3acf18233d0a8229a84 upstream.
To quote from section 1.3.1 of the data sheet:
The SGTL5000 has an internal reset that is deasserted 8 SYS_MCLK cycles after all power rails have been brought up. After this time, communication can start
...
1.0us represents 8 SYS_MCLK cycles at the minimum 8.0 MHz SYS_MCLK.
--- sound/soc/codecs/sgtl5000.c | 3 +++ 1 file changed, 3 insertions(+)
sound/soc/codecs/sgtl5000.c +3 -0
@@ -1238,6 +1238,9 @@ static int sgtl5000_enable_regulators(struct snd_soc_codec *codec)/* wait for all power rails bring up */ udelay (10 ); +/* Need 8 clocks before I2C accesses */ +udelay (1 ); +/* read chip information */ reg =snd_soc_read (codec,SGTL5000_CHIP_ID ); if (((reg & SGTL5000_PARTID_MASK) >> SGTL5000_PARTID_SHIFT) !=
Signature · 1 line
1.9.1
PATCH 149/176 nilfs2: fix deadlock of segment constructor over I_SYNC flag
In reply to [email protected]From: Ryusuke Konishi <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 7ef3ff2fea8bf5e4a21cef47ad87710a3d0fdb52 upstream.
Nilfs2 eventually hangs in a stress test with fsstress program. This issue was caused by the following deadlock over I_SYNC flag between nilfs_segctor_thread() and writeback_sb_inodes():
nilfs_segctor_thread()
nilfs_segctor_thread_construct()
nilfs_segctor_unlock()
nilfs_dispose_list()
iput()
iput_final()
evict()
inode_wait_for_writeback() * wait for I_SYNC flag writeback_sb_inodes()
* set I_SYNC flag on inode->i_state
__writeback_single_inode()
do_writepages()
nilfs_writepages()
nilfs_construct_dsync_segment()
nilfs_segctor_sync()
* wait for completion of segment constructor
inode_sync_complete()
* clear I_SYNC flag after __writeback_single_inode() completed
writeback_sb_inodes() calls do_writepages() for dirty inodes after setting I_SYNC flag on inode->i_state. do_writepages() in turn calls nilfs_writepages(), which can run segment constructor and wait for its completion. On the other hand, segment constructor calls iput(), which can call evict() and wait for the I_SYNC flag on inode_wait_for_writeback().
Since segment constructor doesn't know when I_SYNC will be set, it cannot know whether iput() will block or not unless inode->i_nlink has a non-zero count. We can prevent evict() from being called in iput() by implementing sop->drop_inode(), but it's not preferable to leave inodes with i_nlink == 0 for long periods because it even defers file truncation and inode deallocation. So, this instead resolves the deadlock by calling iput() asynchronously with a workqueue for inodes with i_nlink == 0.
--- fs/nilfs2/nilfs.h | 2 -- fs/nilfs2/segment.c | 44 +++++++++++++++++++++++++++++++++++++++----- fs/nilfs2/segment.h | 5 +++++ 3 files changed, 44 insertions(+), 7 deletions(-)
fs/nilfs2/nilfs.h +0 -2
@@ -128,7 +128,6 @@ enum {* @ti_save: Backup of journal_info field of task_struct * @ti_flags: Flags * @ti_count: Nest level -* @ti_garbage: List of inode to be put when releasing semaphore */ struct nilfs_transaction_info {u32 ti_magic;
@@ -137,7 +136,6 @@ struct nilfs_transaction_info {one of other filesystems has a bug. */ unsigned short ti_flags;unsigned short ti_count; -struct list_head ti_garbage; };/* ti_magic */
fs/nilfs2/segment.c +39 -5
101 lines not on this page · raw message
fs/nilfs2/segment.h +5 -0
@@ -26,6 +26,7 @@#include <linux/types.h> #include <linux/fs.h> #include <linux/buffer_head.h> +#include <linux/workqueue.h> #include <linux/nilfs2_fs.h> #include "nilfs.h"
@@ -92,6 +93,8 @@ struct nilfs_segsum_pointer {* @sc_nblk_inc: Block count of current generation * @sc_dirty_files: List of files to be written * @sc_gc_inodes: List of GC inodes having blocks to be written +* @sc_iput_queue: list of inodes for which iput should be done +* @sc_iput_work: work struct to defer iput call * @sc_freesegs: array of segment numbers to be freed * @sc_nfreesegs: number of segments on @sc_freesegs * @sc_dsync_inode: inode whose data pages are written for a sync operation
@@ -135,6 +138,8 @@ struct nilfs_sc_info {struct list_head sc_dirty_files;struct list_head sc_gc_inodes; +struct list_head sc_iput_queue; +struct work_struct sc_iput_work;__u64 *sc_freesegs;size_t sc_nfreesegs;
Signature · 1 line
1.9.1
PATCH 150/176 Drivers: hv: vmbus: incorrect device name is printed when child device is unregistered
In reply to [email protected]From: Fernando Soto <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 84672369ffb98a51d4ddf74c20a23636da3ad615 upstream.
Whenever a device is unregistered in vmbus_device_unregister (drivers/hv/vmbus_drv.c), the device name in the log message may contain garbage as the memory has already been freed by the time pr_info is called. Log example:
[ 3149.170475] hv_vmbus: child device àõsèè0_5 unregistered
By logging the message just before calling device_unregister, the correct device name is printed:
[ 3145.034652] hv_vmbus: child device vmbus_0_5 unregistered
Also changing register & unregister messages to debug to avoid unnecessarily cluttering the kernel log.
--- drivers/hv/vmbus_drv.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/hv/vmbus_drv.c +4 -4
@@ -681,7 +681,7 @@ int vmbus_device_register(struct hv_device *child_device_obj)if (ret)pr_err ("Unable to register child device\n" );else -pr_info ("child device %s registered\n" , +pr_debug ("child device %s registered\n" ,dev_name (&child_device_obj->device));return ret;
@@ -693,14 +693,14 @@ int vmbus_device_register(struct hv_device *child_device_obj)*/ void vmbus_device_unregister (struct hv_device *device_obj) { +pr_debug ("child device %s unregistered\n" , +dev_name (&device_obj->device)); +/* * Kick off the process of unregistering the device. * This will call vmbus_remove() and eventually vmbus_device_release() */ device_unregister (&device_obj->device); - -pr_info ("child device %s unregistered\n" , -dev_name (&device_obj->device)); }
Signature · 1 line
1.9.1
PATCH 151/176 Bluetooth: sort the list of IDs in the source code
In reply to [email protected]From: Andy Shevchenko <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 0b8800623d3f12dd40a039aa191d52bfa4eef5b4 upstream.
This will help to manage table of supported IDs.
There is no functional change.
--- drivers/bluetooth/ath3k.c | 64 +++++++++++++++++++++++------------------------ drivers/bluetooth/btusb.c | 46 +++++++++++++++++----------------- 2 files changed, 55 insertions(+), 55 deletions(-)
drivers/bluetooth/ath3k.c +32 -32
@@ -62,47 +62,47 @@ static struct usb_device_id ath3k_table[] = { { USB_DEVICE(0x0CF3, 0x3000) },/* Atheros AR3011 with sflash firmware*/ + { USB_DEVICE(0x0489, 0xE027) }, + { USB_DEVICE(0x0489, 0xE03D) }, + { USB_DEVICE(0x0930, 0x0215) }, { USB_DEVICE(0x0CF3, 0x3002) }, { USB_DEVICE(0x0CF3, 0xE019) }, { USB_DEVICE(0x13d3, 0x3304) }, - { USB_DEVICE(0x0930, 0x0215) }, - { USB_DEVICE(0x0489, 0xE03D) }, - { USB_DEVICE(0x0489, 0xE027) },/* Atheros AR9285 Malbec with sflash firmware */ { USB_DEVICE(0x03F0, 0x311D) },/* Atheros AR3012 with sflash firmware*/ + { USB_DEVICE(0x0489, 0xe04d) }, + { USB_DEVICE(0x0489, 0xe04e) }, + { USB_DEVICE(0x0489, 0xe057) }, + { USB_DEVICE(0x0489, 0xe056) }, + { USB_DEVICE(0x04c5, 0x1330) }, + { USB_DEVICE(0x04CA, 0x3004) }, + { USB_DEVICE(0x04CA, 0x3005) }, + { USB_DEVICE(0x04CA, 0x3006) }, + { USB_DEVICE(0x04CA, 0x3008) }, + { USB_DEVICE(0x0930, 0x0219) }, { USB_DEVICE(0x0CF3, 0x0036) }, { USB_DEVICE(0x0CF3, 0x3004) }, { USB_DEVICE(0x0CF3, 0x3008) }, { USB_DEVICE(0x0CF3, 0x311D) }, + { USB_DEVICE(0x0cf3, 0x3121) }, { USB_DEVICE(0x0CF3, 0x817a) }, - { USB_DEVICE(0x13d3, 0x3375) }, - { USB_DEVICE(0x04CA, 0x3004) }, - { USB_DEVICE(0x04CA, 0x3005) }, - { USB_DEVICE(0x04CA, 0x3006) }, - { USB_DEVICE(0x04CA, 0x3008) }, - { USB_DEVICE(0x13d3, 0x3362) }, + { USB_DEVICE(0x0cf3, 0xe003) }, { USB_DEVICE(0x0CF3, 0xE004) }, { USB_DEVICE(0x0CF3, 0xE005) }, - { USB_DEVICE(0x0930, 0x0219) }, - { USB_DEVICE(0x0489, 0xe057) }, + { USB_DEVICE(0x13d3, 0x3362) }, + { USB_DEVICE(0x13d3, 0x3375) }, { USB_DEVICE(0x13d3, 0x3393) }, - { USB_DEVICE(0x0489, 0xe04e) }, - { USB_DEVICE(0x0489, 0xe056) }, - { USB_DEVICE(0x0489, 0xe04d) }, - { USB_DEVICE(0x04c5, 0x1330) }, { USB_DEVICE(0x13d3, 0x3402) }, - { USB_DEVICE(0x0cf3, 0x3121) }, - { USB_DEVICE(0x0cf3, 0xe003) },/* Atheros AR5BBU12 with sflash firmware */ { USB_DEVICE(0x0489, 0xE02C) },/* Atheros AR5BBU22 with sflash firmware */ - { USB_DEVICE(0x0489, 0xE03C) }, { USB_DEVICE(0x0489, 0xE036) }, + { USB_DEVICE(0x0489, 0xE03C) }, { } /* Terminating entry */ };
@@ -115,29 +115,29 @@ MODULE_DEVICE_TABLE(usb, ath3k_table);static struct usb_device_id ath3k_blist_tbl[] = {/* Atheros AR3012 with sflash firmware*/ + {USB_DEVICE (0x0489 ,0xe04e ), .driver_info =BTUSB_ATH3012 }, + {USB_DEVICE (0x0489 ,0xe04d ), .driver_info =BTUSB_ATH3012 }, + {USB_DEVICE (0x0489 ,0xe056 ), .driver_info =BTUSB_ATH3012 }, + {USB_DEVICE (0x0489 ,0xe057 ), .driver_info =BTUSB_ATH3012 }, + {USB_DEVICE (0x04c5 ,0x1330 ), .driver_info =BTUSB_ATH3012 }, + {USB_DEVICE (0x04ca ,0x3004 ), .driver_info =BTUSB_ATH3012 }, + {USB_DEVICE (0x04ca ,0x3005 ), .driver_info =BTUSB_ATH3012 }, + {USB_DEVICE (0x04ca ,0x3006 ), .driver_info =BTUSB_ATH3012 }, + {USB_DEVICE (0x04ca ,0x3008 ), .driver_info =BTUSB_ATH3012 }, + {USB_DEVICE (0x0930 ,0x0219 ), .driver_info =BTUSB_ATH3012 }, {USB_DEVICE (0x0CF3 ,0x0036 ), .driver_info =BTUSB_ATH3012 }, {USB_DEVICE (0x0cf3 ,0x3004 ), .driver_info =BTUSB_ATH3012 }, {USB_DEVICE (0x0cf3 ,0x3008 ), .driver_info =BTUSB_ATH3012 }, {USB_DEVICE (0x0cf3 ,0x311D ), .driver_info =BTUSB_ATH3012 }, + {USB_DEVICE (0x0cf3 ,0x3121 ), .driver_info =BTUSB_ATH3012 }, {USB_DEVICE (0x0CF3 ,0x817a ), .driver_info =BTUSB_ATH3012 }, - {USB_DEVICE (0x13d3 ,0x3375 ), .driver_info =BTUSB_ATH3012 }, - {USB_DEVICE (0x04ca ,0x3004 ), .driver_info =BTUSB_ATH3012 }, - {USB_DEVICE (0x04ca ,0x3005 ), .driver_info =BTUSB_ATH3012 }, - {USB_DEVICE (0x04ca ,0x3006 ), .driver_info =BTUSB_ATH3012 }, - {USB_DEVICE (0x04ca ,0x3008 ), .driver_info =BTUSB_ATH3012 }, - {USB_DEVICE (0x13d3 ,0x3362 ), .driver_info =BTUSB_ATH3012 }, {USB_DEVICE (0x0cf3 ,0xe004 ), .driver_info =BTUSB_ATH3012 }, {USB_DEVICE (0x0cf3 ,0xe005 ), .driver_info =BTUSB_ATH3012 }, - {USB_DEVICE (0x0930 ,0x0219 ), .driver_info =BTUSB_ATH3012 }, - {USB_DEVICE (0x0489 ,0xe057 ), .driver_info =BTUSB_ATH3012 }, + {USB_DEVICE (0x0cf3 ,0xe003 ), .driver_info =BTUSB_ATH3012 }, + {USB_DEVICE (0x13d3 ,0x3362 ), .driver_info =BTUSB_ATH3012 }, + {USB_DEVICE (0x13d3 ,0x3375 ), .driver_info =BTUSB_ATH3012 }, {USB_DEVICE (0x13d3 ,0x3393 ), .driver_info =BTUSB_ATH3012 }, - {USB_DEVICE (0x0489 ,0xe04e ), .driver_info =BTUSB_ATH3012 }, - {USB_DEVICE (0x0489 ,0xe056 ), .driver_info =BTUSB_ATH3012 }, - {USB_DEVICE (0x0489 ,0xe04d ), .driver_info =BTUSB_ATH3012 }, - {USB_DEVICE (0x04c5 ,0x1330 ), .driver_info =BTUSB_ATH3012 }, {USB_DEVICE (0x13d3 ,0x3402 ), .driver_info =BTUSB_ATH3012 }, - {USB_DEVICE (0x0cf3 ,0x3121 ), .driver_info =BTUSB_ATH3012 }, - {USB_DEVICE (0x0cf3 ,0xe003 ), .driver_info =BTUSB_ATH3012 },/* Atheros AR5BBU22 with sflash firmware */ {USB_DEVICE (0x0489 ,0xE03C ), .driver_info =BTUSB_ATH3012 },
drivers/bluetooth/btusb.c +23 -23
91 lines not on this page · raw message
Signature · 1 line
1.9.1
PATCH 152/176 Bluetooth: append new supported device to the list [0b05:17d0]
In reply to [email protected]From: Andy Shevchenko <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit a735f9e22432899cee188d167966782c29246390 upstream.
The device found on Asus Z87 Expert motherboard requires firmware to work correctly.
T: Bus=03 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0b05 ProdID=17d0 Rev=00.02 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
--- drivers/bluetooth/ath3k.c | 2 ++ drivers/bluetooth/btusb.c | 1 + 2 files changed, 3 insertions(+)
drivers/bluetooth/ath3k.c +2 -0
@@ -83,6 +83,7 @@ static struct usb_device_id ath3k_table[] = { { USB_DEVICE(0x04CA, 0x3006) }, { USB_DEVICE(0x04CA, 0x3008) }, { USB_DEVICE(0x0930, 0x0219) }, + { USB_DEVICE(0x0b05, 0x17d0) }, { USB_DEVICE(0x0CF3, 0x0036) }, { USB_DEVICE(0x0CF3, 0x3004) }, { USB_DEVICE(0x0CF3, 0x3008) },
@@ -125,6 +126,7 @@ static struct usb_device_id ath3k_blist_tbl[] = { { USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0CF3, 0x0036), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0cf3, 0x3008), .driver_info = BTUSB_ATH3012 },
drivers/bluetooth/btusb.c +1 -0
@@ -153,6 +153,7 @@ static struct usb_device_id blacklist_table[] = { { USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0cf3, 0x0036), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0cf3, 0x3008), .driver_info = BTUSB_ATH3012 },
Signature · 1 line
1.9.1
PATCH 153/176 Bluetooth: Add support for Intel bootloader devices
In reply to [email protected]From: Marcel Holtmann <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 40df783d1ef1989ac454e3dfcda017270b8950e6 upstream.
Intel Bluetooth devices that boot up in bootloader mode can not be used as generic HCI devices, but their HCI transport is still valuable and so bring that up as raw-only devices.
T: Bus=02 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 14 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=0a5a Rev= 0.00 S: Manufacturer=Intel(R) Corporation S: Product=Intel(R) Wilkins Peak 2x2 S: SerialNumber=001122334455 WP_A0 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
--- drivers/bluetooth/btusb.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/bluetooth/btusb.c +7 -0
@@ -55,6 +55,7 @@ static struct usb_driver btusb_driver;#define BTUSB_BROKEN_ISOC 0x20#define BTUSB_WRONG_SCO_MTU 0x40#define BTUSB_ATH3012 0x80 +#define BTUSB_INTEL_BOOT 0x200static struct usb_device_id btusb_table[] = {/* Generic Bluetooth USB device */
@@ -119,6 +120,9 @@ static struct usb_device_id btusb_table[] = {/* Broadcom devices with vendor specific id */ { USB_VENDOR_AND_INTERFACE_INFO(0x0a5c, 0xff, 0x01, 0x01) }, + /* Intel Bluetooth USB Bootloader (RAM module) */ + { USB_DEVICE(0x8087, 0x0a5a), .driver_info = BTUSB_INTEL_BOOT }, + { }/* Terminating entry */ };
@@ -1051,6 +1055,9 @@ static int btusb_probe(struct usb_interface *intf, hdev->send = btusb_send_frame; hdev->notify = btusb_notify; +if (id->driver_info &BTUSB_INTEL_BOOT ) +set_bit (HCI_QUIRK_RAW_DEVICE , &hdev->quirks); +/* Interface numbers are hardcoded in the specification */ data->isoc =usb_ifnum_to_if (data->udev,1 );
Signature · 1 line
1.9.1
PATCH 154/176 Bluetooth: Ignore isochronous endpoints for Intel USB bootloader
In reply to [email protected]From: Marcel Holtmann <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit d92f2df0565ea04101d6ac04bdc10feeb1d93c94 upstream.
The isochronous endpoints are not valid when the Intel Bluetooth controller boots up in bootloader mode. So just mark these endpoints as broken and then they will not be configured.
--- drivers/bluetooth/btusb.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/bluetooth/btusb.c +2 -1
@@ -121,7 +121,8 @@ static struct usb_device_id btusb_table[] = { { USB_VENDOR_AND_INTERFACE_INFO(0x0a5c, 0xff, 0x01, 0x01) }, /* Intel Bluetooth USB Bootloader (RAM module) */ - { USB_DEVICE(0x8087, 0x0a5a), .driver_info = BTUSB_INTEL_BOOT }, + { USB_DEVICE(0x8087, 0x0a5a), + .driver_info = BTUSB_INTEL_BOOT | BTUSB_BROKEN_ISOC }, { } /* Terminating entry */ };
Signature · 1 line
1.9.1
PATCH 155/176 Bluetooth: Add support for Acer [13D3:3432]
In reply to [email protected]From: Anantha Krishnan <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit fa2f1394fe9c1a217213f02df77812701de6362f upstream.
Add support for the QCA6174 chip.
T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 30 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3432 Rev=00.02
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb--- drivers/bluetooth/ath3k.c | 2 ++ drivers/bluetooth/btusb.c | 1 + 2 files changed, 3 insertions(+)
drivers/bluetooth/ath3k.c +2 -0
@@ -97,6 +97,7 @@ static struct usb_device_id ath3k_table[] = { { USB_DEVICE(0x13d3, 0x3375) }, { USB_DEVICE(0x13d3, 0x3393) }, { USB_DEVICE(0x13d3, 0x3402) }, + { USB_DEVICE(0x13d3, 0x3432) },/* Atheros AR5BBU12 with sflash firmware */ { USB_DEVICE(0x0489, 0xE02C) },
@@ -140,6 +141,7 @@ static struct usb_device_id ath3k_blist_tbl[] = { { USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 }, /* Atheros AR5BBU22 with sflash firmware */ { USB_DEVICE(0x0489, 0xE03C), .driver_info = BTUSB_ATH3012 },
drivers/bluetooth/btusb.c +1 -0
@@ -172,6 +172,7 @@ static struct usb_device_id blacklist_table[] = { { USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 }, /* Atheros AR5BBU12 with sflash firmware */ { USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },
Signature · 1 line
1.9.1
PATCH 156/176 Bluetooth: Add support for Broadcom device of Asus Z97-DELUXE motherboard
In reply to [email protected]From: Marcel Holtmann <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit c2aef6e8cbebd60f79555baeb9266e220f135a44 upstream.
The Asus Z97-DELUXE motherboard contains a Broadcom based Bluetooth controller on the USB bus. However vendor and product ID are listed as ASUSTek Computer.
T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0b05 ProdID=17cf Rev= 1.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=54271E910064 C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
--- drivers/bluetooth/btusb.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/bluetooth/btusb.c +3 -0
@@ -120,6 +120,9 @@ static struct usb_device_id btusb_table[] = {/* Broadcom devices with vendor specific id */ { USB_VENDOR_AND_INTERFACE_INFO(0x0a5c, 0xff, 0x01, 0x01) }, +/* ASUSTek Computer - Broadcom based */ + { USB_VENDOR_AND_INTERFACE_INFO(0x0b05, 0xff, 0x01, 0x01) }, +/* Intel Bluetooth USB Bootloader (RAM module) */ { USB_DEVICE(0x8087, 0x0a5a), .driver_info = BTUSB_INTEL_BOOT | BTUSB_BROKEN_ISOC },
Signature · 1 line
1.9.1
PATCH 157/176 Add a new PID/VID 0227/0930 for AR3012.
In reply to [email protected]From: Vincent Zwanenburg <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 89d2975fa06e66ea0d3665d91f799fb1ce4b8bad upstream.
usb devices info:
T: Bus=01 Lev=02 Prnt=05 Port=00 Cnt=01 Dev#= 20 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0930 ProdID=0227 Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
--- drivers/bluetooth/ath3k.c | 2 ++ drivers/bluetooth/btusb.c | 1 + 2 files changed, 3 insertions(+)
drivers/bluetooth/ath3k.c +2 -0
@@ -83,6 +83,7 @@ static struct usb_device_id ath3k_table[] = { { USB_DEVICE(0x04CA, 0x3006) }, { USB_DEVICE(0x04CA, 0x3008) }, { USB_DEVICE(0x0930, 0x0219) }, + { USB_DEVICE(0x0930, 0x0227) }, { USB_DEVICE(0x0b05, 0x17d0) }, { USB_DEVICE(0x0CF3, 0x0036) }, { USB_DEVICE(0x0CF3, 0x3004) },
@@ -127,6 +128,7 @@ static struct usb_device_id ath3k_blist_tbl[] = { { USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0CF3, 0x0036), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 },
drivers/bluetooth/btusb.c +1 -0
@@ -161,6 +161,7 @@ static struct usb_device_id blacklist_table[] = { { USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0cf3, 0x0036), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 },
Signature · 1 line
1.9.1
PATCH 158/176 Bluetooth: Add support for Acer [0489:e078]
In reply to [email protected]From: Anantha Krishnan <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 4b552bc9edfdc947862af225a0e2521edb5d37a0 upstream.
Add support for the QCA6174 chip.
T: Bus=06 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e078 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb--- drivers/bluetooth/ath3k.c | 2 ++ drivers/bluetooth/btusb.c | 1 + 2 files changed, 3 insertions(+)
drivers/bluetooth/ath3k.c +2 -0
@@ -77,6 +77,7 @@ static struct usb_device_id ath3k_table[] = { { USB_DEVICE(0x0489, 0xe04e) }, { USB_DEVICE(0x0489, 0xe057) }, { USB_DEVICE(0x0489, 0xe056) }, + { USB_DEVICE(0x0489, 0xe078) }, { USB_DEVICE(0x04c5, 0x1330) }, { USB_DEVICE(0x04CA, 0x3004) }, { USB_DEVICE(0x04CA, 0x3005) },
@@ -122,6 +123,7 @@ static struct usb_device_id ath3k_blist_tbl[] = { { USB_DEVICE(0x0489, 0xe04d), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0489, 0xe056), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x0489, 0xe078), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x04c5, 0x1330), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x04ca, 0x3004), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
drivers/bluetooth/btusb.c +1 -0
@@ -155,6 +155,7 @@ static struct usb_device_id blacklist_table[] = { { USB_DEVICE(0x0489, 0xe04e), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0489, 0xe056), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x0489, 0xe078), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x04c5, 0x1330), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x04ca, 0x3004), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
Signature · 1 line
1.9.1
PATCH 159/176 Bluetooth: ath3k: Add support of MCI 13d3:3408 bt device
In reply to [email protected]From: Dmitry Tunin <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 3bb30a7cdf9242aca90d49aa41baebf9458f96f0 upstream.
Add support for Bluetooth MCI WB335 (AR9565) Wi-Fi+bt module. This Bluetooth module requires loading patch and sysconfig by ath3k driver.
T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 20 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3408 Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
--- drivers/bluetooth/ath3k.c | 2 ++ drivers/bluetooth/btusb.c | 1 + 2 files changed, 3 insertions(+)
drivers/bluetooth/ath3k.c +2 -0
@@ -99,6 +99,7 @@ static struct usb_device_id ath3k_table[] = { { USB_DEVICE(0x13d3, 0x3375) }, { USB_DEVICE(0x13d3, 0x3393) }, { USB_DEVICE(0x13d3, 0x3402) }, + { USB_DEVICE(0x13d3, 0x3408) }, { USB_DEVICE(0x13d3, 0x3432) },/* Atheros AR5BBU12 with sflash firmware */
@@ -145,6 +146,7 @@ static struct usb_device_id ath3k_blist_tbl[] = { { USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 },/* Atheros AR5BBU22 with sflash firmware */
drivers/bluetooth/btusb.c +1 -0
@@ -177,6 +177,7 @@ static struct usb_device_id blacklist_table[] = { { USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 },/* Atheros AR5BBU12 with sflash firmware */
Signature · 1 line
1.9.1
PATCH 160/176 Bluetooth: Add USB device 04ca:3010 as Atheros AR3012
In reply to [email protected]From: Janne Heikkinen <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 134d3b3550f050b9bec37111824452064d1ed928 upstream.
Asus X553MA has USB device 04ca:3010 that is Atheros AR3012 or compatible.
Device from /sys/kernel/debug/usb/devices:
T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#= 27 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3010 Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
--- drivers/bluetooth/ath3k.c | 2 ++ drivers/bluetooth/btusb.c | 1 + 2 files changed, 3 insertions(+)
drivers/bluetooth/ath3k.c +2 -0
@@ -83,6 +83,7 @@ static struct usb_device_id ath3k_table[] = { { USB_DEVICE(0x04CA, 0x3005) }, { USB_DEVICE(0x04CA, 0x3006) }, { USB_DEVICE(0x04CA, 0x3008) }, + { USB_DEVICE(0x04CA, 0x3010) }, { USB_DEVICE(0x0930, 0x0219) }, { USB_DEVICE(0x0930, 0x0227) }, { USB_DEVICE(0x0b05, 0x17d0) },
@@ -130,6 +131,7 @@ static struct usb_device_id ath3k_blist_tbl[] = { { USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x04ca, 0x3010), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 },
drivers/bluetooth/btusb.c +1 -0
@@ -161,6 +161,7 @@ static struct usb_device_id blacklist_table[] = { { USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x04ca, 0x3010), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 }, { USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 },
Signature · 1 line
1.9.1
PATCH 161/176 pagemap: do not leak physical addresses to non-privileged userspace
In reply to [email protected]From: "Kirill A. Shutemov" <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit ab676b7d6fbf4b294bf198fb27ade5b0e865c7ce upstream.
As pointed by recent post[1] on exploiting DRAM physical imperfection, /proc/PID/pagemap exposes sensitive information which can be used to do attacks.
This disallows anybody without CAP_SYS_ADMIN to read the pagemap.
[1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
[ Eventually we might want to do anything more finegrained, but for now
this is the simple model. - Linus ]
--- fs/proc/task_mmu.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
fs/proc/task_mmu.c +10 -0
@@ -985,9 +985,19 @@ out: return ret; } +static int pagemap_open (struct inode *inode,struct file *file) +{ +/* do not disclose physical addresses to unprivileged +userspace (closes a rowhammer attack vector) */ +if (!capable (CAP_SYS_ADMIN )) +return -EPERM ; +return 0 ; +} +const struct file_operations proc_pagemap_operations = { .llseek = mem_lseek,/* borrow this */ .read = pagemap_read, + .open = pagemap_open, };#endif /* CONFIG_PROC_PAGE_MONITOR */
Signature · 1 line
1.9.1
PATCH 162/176 Bluetooth: Fix invalid length check in l2cap_information_rsp()
In reply to [email protected]From: Tim Niemeyer <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
first backport commit 6ec88fcb4aa2c33fe2fe2a23c576a7e2581c5c3d changes l2cap_move_channel_confirm_rsp and not the l2cap_information_rsp. So revert this and fix at the correct position.
commit 3f6fa3d489e127ca5a5b298eabac3ff5dbe0e112 upstream.
The length check is invalid since the length varies with type of info response.
This was introduced by the commit cb3b3152b2f5939d67005cff841a1ca748b19888
Because of this, l2cap info rsp is not handled and command reject is sent.
Quoted 1 line
ACL data: handle 11 flags
0x02dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x00b8
Enhanced Retransmission mode
Streaming mode
FCS Option
Fixed Channels
< ACL data: handle 11 flags 0x00 dlen 10
L2CAP(s): Command rej: reason 0
Command not understood
--- net/bluetooth/l2cap_core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/bluetooth/l2cap_core.c +2 -2
@@ -3239,7 +3239,7 @@ static inline int l2cap_information_rsp(struct l2cap_conn *conn,struct l2cap_info_rsp *rsp = (struct l2cap_info_rsp *) data;u16 type, result; -if (cmd_len !=sizeof (*rsp)) +if (cmd_len <sizeof (*rsp))return -EPROTO ; type =__le16_to_cpu (rsp->type);
@@ -3445,7 +3445,7 @@ static inline int l2cap_move_channel_confirm_rsp(struct l2cap_conn *conn,struct l2cap_move_chan_cfm_rsp *rsp = data;u16 icid; -if (cmd_len <sizeof (*rsp)) +if (cmd_len !=sizeof (*rsp))return -EPROTO ; icid =le16_to_cpu (rsp->icid);
Signature · 1 line
1.9.1
PATCH 163/176 jfs: fix readdir regression
In reply to [email protected]From: Dave Kleikamp <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
Upstream commit 44512449, "jfs: fix readdir cookie incompatibility with NFSv4", was backported incorrectly into the stable trees which used the filldir callback (rather than dir_emit). The position is being incorrectly passed to filldir for the . and .. entries.
The still-maintained stable trees that need to be fixed are 3.2.y, 3.4.y and 3.10.y.
https://bugzilla.kernel.org/show_bug.cgi?id=94741
--- fs/jfs/jfs_dtree.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/jfs/jfs_dtree.c +2 -2
@@ -3103,7 +3103,7 @@ int jfs_readdir(struct file *filp, void *dirent, filldir_t filldir)* self "." */ filp->f_pos =1 ; -if (filldir (dirent,"." ,1 ,0 , ip->i_ino, +if (filldir (dirent,"." ,1 ,1 , ip->i_ino,DT_DIR ))return 0 ; }
@@ -3111,7 +3111,7 @@ int jfs_readdir(struct file *filp, void *dirent, filldir_t filldir)* parent ".." */ filp->f_pos =2 ; -if (filldir (dirent,".." ,2 ,1 ,PARENT (ip),DT_DIR )) +if (filldir (dirent,".." ,2 ,2 ,PARENT (ip),DT_DIR ))return 0 ;/*
Signature · 1 line
1.9.1
PATCH 164/176 ipvs: rerouting to local clients is not needed anymore
In reply to [email protected]From: Julian Anastasov <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 579eb62ac35845686a7c4286c0a820b4eb1f96aa upstream.
commit f5a41847acc5 ("ipvs: move ip_route_me_harder for ICMP") from 2.6.37 introduced ip_route_me_harder() call for responses to local clients, so that we can provide valid rt_src after SNAT. It was used by TCP to provide valid daddr for ip_send_reply(). After commit 0a5ebb8000c5 ("ipv4: Pass explicit daddr arg to ip_send_reply()." from 3.0 this rerouting is not needed anymore and should be avoided, especially in LOCAL_IN.
Fixes 3.12.33 crash in xfrm reported by Florian Wiessner:
"3.12.33 - BUG xfrm_selector_match+0x25/0x2f6"
--- net/netfilter/ipvs/ip_vs_core.c | 32 +++++++++++++++++++++----------- 1 file changed, 21 insertions(+), 11 deletions(-)
net/netfilter/ipvs/ip_vs_core.c +21 -11
@@ -662,16 +662,24 @@ static inline int ip_vs_gather_frags_v6(struct sk_buff *skb, u_int32_t user) }#endif -static int ip_vs_route_me_harder (int af,struct sk_buff *skb) +static int ip_vs_route_me_harder (int af,struct sk_buff *skb, +unsigned int hooknum) { +if (!sysctl_snat_reroute (skb)) +return 0 ; +/* Reroute replies only to remote clients (FORWARD and LOCAL_OUT) */ +if (NF_INET_LOCAL_IN == hooknum) +return 0 ;#ifdef CONFIG_IP_VS_IPV6 if (af ==AF_INET6 ) { -if (sysctl_snat_reroute (skb) &&ip6_route_me_harder (skb) !=0 ) +struct dst_entry *dst =skb_dst (skb); + +if (dst->dev && !(dst->dev->flags &IFF_LOOPBACK ) && +ip6_route_me_harder (skb) !=0 )return 1 ; } else#endif -if ((sysctl_snat_reroute (skb) || -skb_rtable (skb)->rt_flags &RTCF_LOCAL ) && +if (!(skb_rtable (skb)->rt_flags &RTCF_LOCAL ) &&ip_route_me_harder (skb,RTN_LOCAL ) !=0 )return 1 ;
@@ -782,7 +790,8 @@ static int handle_response_icmp(int af, struct sk_buff *skb,union nf_inet_addr *snet, __u8 protocol, struct ip_vs_conn *cp, struct ip_vs_protocol *pp, - unsigned int offset, unsigned int ihl) + unsigned int offset, unsigned int ihl, + unsigned int hooknum) { unsigned int verdict = NF_DROP;
@@ -812,7 +821,7 @@ static int handle_response_icmp(int af, struct sk_buff *skb,#endif ip_vs_nat_icmp (skb, pp, cp,1 ); -if (ip_vs_route_me_harder (af, skb)) +if (ip_vs_route_me_harder (af, skb, hooknum)) goto out;/* do the statistics and put it back */
@@ -908,7 +917,7 @@ static int ip_vs_out_icmp(struct sk_buff *skb, int *related, snet.ip = iph->saddr;return handle_response_icmp (AF_INET , skb, &snet, cih->protocol, cp, - pp, offset, ihl); + pp, offset, ihl, hooknum); }#ifdef CONFIG_IP_VS_IPV6
@@ -985,7 +994,8 @@ static int ip_vs_out_icmp_v6(struct sk_buff *skb, int *related, snet.in6 = iph->saddr;return handle_response_icmp (AF_INET6 , skb, &snet, cih->nexthdr, cp, - pp, offset, sizeof(struct ipv6hdr)); + pp, offset,sizeof (struct ipv6hdr ), + hooknum); }#endif
@@ -1018,7 +1028,7 @@ static inline int is_tcp_reset(const struct sk_buff *skb, int nh_len)*/ static unsigned int handle_response (int af,struct sk_buff *skb,struct ip_vs_proto_data *pd, -struct ip_vs_conn *cp,int ihl) +struct ip_vs_conn *cp,int ihl,unsigned int hooknum) {struct ip_vs_protocol *pp = pd->pp;
@@ -1056,7 +1066,7 @@ handle_response(int af, struct sk_buff *skb, struct ip_vs_proto_data *pd,* if it came from this machine itself. So re-compute * the routing information. */ -if (ip_vs_route_me_harder (af, skb)) +if (ip_vs_route_me_harder (af, skb, hooknum)) goto drop;IP_VS_DBG_PKT (10 , af, pp, skb,0 ,"After SNAT" );
@@ -1169,7 +1179,7 @@ ip_vs_out(unsigned int hooknum, struct sk_buff *skb, int af) cp = pp->conn_out_get (af, skb, &iph, iph.len,0 );if (likely (cp)) -return handle_response (af, skb, pd, cp, iph.len); +return handle_response (af, skb, pd, cp, iph.len, hooknum); if (sysctl_nat_icmp_send(net) && (pp->protocol == IPPROTO_TCP || pp->protocol == IPPROTO_UDP ||
Signature · 1 line
1.9.1
PATCH 165/176 staging: comedi: cb_pcidas64: fix incorrect AI range code handling
In reply to [email protected]From: Ian Abbott <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit be8e89087ec2d2c8a1ad1e3db64bf4efdfc3c298 upstream.
The hardware range code values and list of valid ranges for the AI subdevice is incorrect for several supported boards. The hardware range code values for all boards except PCI-DAS4020/12 is determined by calling ai_range_bits_6xxx() based on the maximum voltage of the range and whether it is bipolar or unipolar, however it only returns the correct hardware range code for the PCI-DAS60xx boards. For PCI-DAS6402/16 (and /12) it returns the wrong code for the unipolar ranges. For PCI-DAS64/Mx/16 it returns the wrong code for all the ranges and the comedi range table is incorrect.
Change ai_range_bits_6xxx() to use a look-up table pointed to by new member ai_range_codes of struct pcidas64_board to map the comedi range table indices to the hardware range codes. Use a new comedi range table for the PCI-DAS64/Mx/16 boards (and the commented out variants).
--- drivers/staging/comedi/drivers/cb_pcidas64.c | 123 ++++++++++++++++----------- 1 file changed, 75 insertions(+), 48 deletions(-)
drivers/staging/comedi/drivers/cb_pcidas64.c +75 -48
@@ -423,6 +423,29 @@ static const struct comedi_lrange ai_ranges_64xx = { } }; +static const uint8_t ai_range_code_64xx[8 ] = { +0x0 ,0x1 ,0x2 ,0x3 ,/* bipolar 10, 5, 2,5, 1.25 */ +0x8 ,0x9 ,0xa ,0xb /* unipolar 10, 5, 2.5, 1.25 */ +}; + +/* analog input ranges for 64-Mx boards */ +static const struct comedi_lrange ai_ranges_64_mx = { +7 , { +BIP_RANGE (5 ), +BIP_RANGE (2.5 ), +BIP_RANGE (1.25 ), +BIP_RANGE (0.625 ), +UNI_RANGE (5 ), +UNI_RANGE (2.5 ), +UNI_RANGE (1.25 ) + } +}; + +static const uint8_t ai_range_code_64_mx[7 ] = { +0x0 ,0x1 ,0x2 ,0x3 ,/* bipolar 5, 2.5, 1.25, 0.625 */ +0x9 ,0xa ,0xb /* unipolar 5, 2.5, 1.25 */ +}; +/* analog input ranges for 60xx boards */ static const struct comedi_lrange ai_ranges_60xx = {4 ,
@@ -434,6 +457,10 @@ static const struct comedi_lrange ai_ranges_60xx = { } }; +static const uint8_t ai_range_code_60xx[4 ] = { +0x0 ,0x1 ,0x4 ,0x7 /* bipolar 10, 5, 0.5, 0.05 */ +}; +/* analog input ranges for 6030, etc boards */ static const struct comedi_lrange ai_ranges_6030 = {14 ,
@@ -455,6 +482,11 @@ static const struct comedi_lrange ai_ranges_6030 = { } }; +static const uint8_t ai_range_code_6030[14 ] = { +0x0 ,0x1 ,0x2 ,0x3 ,0x4 ,0x5 ,0x6 ,/* bip 10, 5, 2, 1, 0.5, 0.2, 0.1 */ +0x9 ,0xa ,0xb ,0xc ,0xd ,0xe ,0xf /* uni 10, 5, 2, 1, 0.5, 0.2, 0.1 */ +}; +/* analog input ranges for 6052, etc boards */ static const struct comedi_lrange ai_ranges_6052 = {15 ,
@@ -477,6 +509,11 @@ static const struct comedi_lrange ai_ranges_6052 = { } }; +static const uint8_t ai_range_code_6052[15 ] = { +0x0 ,0x1 ,0x2 ,0x3 ,0x4 ,0x5 ,0x6 ,0x7 ,/* bipolar 10 ... 0.05 */ +0x9 ,0xa ,0xb ,0xc ,0xd ,0xe ,0xf /* unipolar 10 ... 0.1 */ +}; +/* analog input ranges for 4020 board */ static const struct comedi_lrange ai_ranges_4020 = {2 ,
@@ -561,6 +598,7 @@ struct pcidas64_board {int ai_bits;/* analog input resolution */ int ai_speed;/* fastest conversion period in ns */ const struct comedi_lrange *ai_range_table; +const uint8_t *ai_range_code;int ao_nchan;/* number of analog out channels */ int ao_bits;/* analog output resolution */ int ao_scan_speed;/* analog output speed (for a scan, not conversion) */
@@ -619,6 +657,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_scan_speed = 10000, .layout = LAYOUT_64XX, .ai_range_table = &ai_ranges_64xx, + .ai_range_code = ai_range_code_64xx, .ao_range_table = &ao_ranges_64xx, .ao_range_code = ao_range_code_64xx, .ai_fifo = &ai_fifo_64xx,
@@ -635,6 +674,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_scan_speed = 10000, .layout = LAYOUT_64XX, .ai_range_table = &ai_ranges_64xx, + .ai_range_code = ai_range_code_64xx, .ao_range_table = &ao_ranges_64xx, .ao_range_code = ao_range_code_64xx, .ai_fifo = &ai_fifo_64xx,
@@ -650,7 +690,8 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_bits = 16, .ao_scan_speed = 10000, .layout = LAYOUT_64XX, - .ai_range_table = &ai_ranges_64xx, + .ai_range_table = &ai_ranges_64_mx, + .ai_range_code = ai_range_code_64_mx, .ao_range_table = &ao_ranges_64xx, .ao_range_code = ao_range_code_64xx, .ai_fifo = &ai_fifo_64xx,
@@ -666,7 +707,8 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_bits = 16, .ao_scan_speed = 10000, .layout = LAYOUT_64XX, - .ai_range_table = &ai_ranges_64xx, + .ai_range_table = &ai_ranges_64_mx, + .ai_range_code = ai_range_code_64_mx, .ao_range_table = &ao_ranges_64xx, .ao_range_code = ao_range_code_64xx, .ai_fifo = &ai_fifo_64xx,
@@ -682,7 +724,8 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_bits = 16, .ao_scan_speed = 10000, .layout = LAYOUT_64XX, - .ai_range_table = &ai_ranges_64xx, + .ai_range_table = &ai_ranges_64_mx, + .ai_range_code = ai_range_code_64_mx, .ao_range_table = &ao_ranges_64xx, .ao_range_code = ao_range_code_64xx, .ai_fifo = &ai_fifo_64xx,
@@ -698,6 +741,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_bits = 16, .layout = LAYOUT_60XX, .ai_range_table = &ai_ranges_60xx, + .ai_range_code = ai_range_code_60xx, .ao_range_table = &ao_ranges_60xx, .ao_range_code = ao_range_code_60xx, .ai_fifo = &ai_fifo_60xx,
@@ -714,6 +758,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_scan_speed = 100000, .layout = LAYOUT_60XX, .ai_range_table = &ai_ranges_60xx, + .ai_range_code = ai_range_code_60xx, .ao_range_table = &ao_ranges_60xx, .ao_range_code = ao_range_code_60xx, .ai_fifo = &ai_fifo_60xx,
@@ -729,6 +774,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_scan_speed = 100000, .layout = LAYOUT_60XX, .ai_range_table = &ai_ranges_60xx, + .ai_range_code = ai_range_code_60xx, .ao_range_table = &ao_ranges_60xx, .ao_range_code = ao_range_code_60xx, .ai_fifo = &ai_fifo_60xx,
@@ -745,6 +791,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_scan_speed = 100000, .layout = LAYOUT_60XX, .ai_range_table = &ai_ranges_60xx, + .ai_range_code = ai_range_code_60xx, .ao_range_table = &ao_ranges_60xx, .ao_range_code = ao_range_code_60xx, .ai_fifo = &ai_fifo_60xx,
@@ -761,6 +808,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_scan_speed = 10000, .layout = LAYOUT_60XX, .ai_range_table = &ai_ranges_6030, + .ai_range_code = ai_range_code_6030, .ao_range_table = &ao_ranges_6030, .ao_range_code = ao_range_code_6030, .ai_fifo = &ai_fifo_60xx,
@@ -777,6 +825,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_scan_speed = 10000, .layout = LAYOUT_60XX, .ai_range_table = &ai_ranges_6030, + .ai_range_code = ai_range_code_6030, .ao_range_table = &ao_ranges_6030, .ao_range_code = ao_range_code_6030, .ai_fifo = &ai_fifo_60xx,
@@ -791,6 +840,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_nchan = 0, .layout = LAYOUT_60XX, .ai_range_table = &ai_ranges_6030, + .ai_range_code = ai_range_code_6030, .ai_fifo = &ai_fifo_60xx, .has_8255 = 0, },
@@ -803,6 +853,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_nchan = 0, .layout = LAYOUT_60XX, .ai_range_table = &ai_ranges_6030, + .ai_range_code = ai_range_code_6030, .ai_fifo = &ai_fifo_60xx, .has_8255 = 0, },
@@ -816,6 +867,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_scan_speed = 0, .layout = LAYOUT_60XX, .ai_range_table = &ai_ranges_60xx, + .ai_range_code = ai_range_code_60xx, .ai_fifo = &ai_fifo_60xx, .has_8255 = 0, },
@@ -830,6 +882,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_scan_speed = 100000, .layout = LAYOUT_60XX, .ai_range_table = &ai_ranges_60xx, + .ai_range_code = ai_range_code_60xx, .ao_range_table = &ao_ranges_60xx, .ao_range_code = ao_range_code_60xx, .ai_fifo = &ai_fifo_60xx,
@@ -846,6 +899,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_scan_speed = 100000, .layout = LAYOUT_60XX, .ai_range_table = &ai_ranges_60xx, + .ai_range_code = ai_range_code_60xx, .ao_range_table = &ao_ranges_60xx, .ao_range_code = ao_range_code_60xx, .ai_fifo = &ai_fifo_60xx,
@@ -862,6 +916,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_scan_speed = 1000, .layout = LAYOUT_60XX, .ai_range_table = &ai_ranges_6052, + .ai_range_code = ai_range_code_6052, .ao_range_table = &ao_ranges_6030, .ao_range_code = ao_range_code_6030, .ai_fifo = &ai_fifo_60xx,
@@ -878,6 +933,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_scan_speed = 3333, .layout = LAYOUT_60XX, .ai_range_table = &ai_ranges_6052, + .ai_range_code = ai_range_code_6052, .ao_range_table = &ao_ranges_6030, .ao_range_code = ao_range_code_6030, .ai_fifo = &ai_fifo_60xx,
@@ -894,6 +950,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_scan_speed = 1000, .layout = LAYOUT_60XX, .ai_range_table = &ai_ranges_6052, + .ai_range_code = ai_range_code_6052, .ao_range_table = &ao_ranges_6030, .ao_range_code = ao_range_code_6030, .ai_fifo = &ai_fifo_60xx,
@@ -910,6 +967,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_scan_speed = 1000, .layout = LAYOUT_60XX, .ai_range_table = &ai_ranges_6052, + .ai_range_code = ai_range_code_6052, .ao_range_table = &ao_ranges_6030, .ao_range_code = ao_range_code_6030, .ai_fifo = &ai_fifo_60xx,
@@ -942,6 +1000,7 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_scan_speed = 10000, .layout = LAYOUT_64XX, .ai_range_table = &ai_ranges_64xx, + .ai_range_code = ai_range_code_64xx, .ai_fifo = ai_fifo_64xx, .has_8255 = 1, },
@@ -954,7 +1013,8 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_nchan = 0, .ao_scan_speed = 10000, .layout = LAYOUT_64XX, - .ai_range_table = &ai_ranges_64xx, + .ai_range_table = &ai_ranges_64_mx, + .ai_range_code = ai_range_code_64_mx, .ai_fifo = ai_fifo_64xx, .has_8255 = 1, },
@@ -967,7 +1027,8 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_nchan = 0, .ao_scan_speed = 10000, .layout = LAYOUT_64XX, - .ai_range_table = &ai_ranges_64xx, + .ai_range_table = &ai_ranges_64_mx, + .ai_range_code = ai_range_code_64_mx, .ai_fifo = ai_fifo_64xx, .has_8255 = 1, },
@@ -980,7 +1041,8 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_nchan = 0, .ao_scan_speed = 10000, .layout = LAYOUT_64XX, - .ai_range_table = &ai_ranges_64xx, + .ai_range_table = &ai_ranges_64_mx, + .ai_range_code = ai_range_code_64_mx, .ai_fifo = ai_fifo_64xx, .has_8255 = 1, },
@@ -993,7 +1055,8 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_nchan = 2, .ao_scan_speed = 10000, .layout = LAYOUT_64XX, - .ai_range_table = &ai_ranges_64xx, + .ai_range_table = &ai_ranges_64_mx, + .ai_range_code = ai_range_code_64_mx, .ai_fifo = ai_fifo_64xx, .has_8255 = 1, },
@@ -1006,7 +1069,8 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_nchan = 2, .ao_scan_speed = 10000, .layout = LAYOUT_64XX, - .ai_range_table = &ai_ranges_64xx, + .ai_range_table = &ai_ranges_64_mx, + .ai_range_code = ai_range_code_64_mx, .ai_fifo = ai_fifo_64xx, .has_8255 = 1, },
@@ -1019,7 +1083,8 @@ static const struct pcidas64_board pcidas64_boards[] = { .ao_nchan = 2, .ao_scan_speed = 10000, .layout = LAYOUT_64XX, - .ai_range_table = &ai_ranges_64xx, + .ai_range_table = &ai_ranges_64_mx, + .ai_range_code = ai_range_code_64_mx, .ai_fifo = ai_fifo_64xx, .has_8255 = 1, },
@@ -1257,45 +1322,7 @@ module_exit(driver_cb_pcidas_cleanup_module);static unsigned int ai_range_bits_6xxx (const struct comedi_device *dev,unsigned int range_index) { -const struct comedi_krange *range = - &board (dev)->ai_range_table->range[range_index]; -unsigned int bits =0 ; - -switch (range->max) { -case 10000000 : - bits =0x000 ; -break ; -case 5000000 : - bits =0x100 ; -break ; -case 2000000 : -case 2500000 : - bits =0x200 ; -break ; -case 1000000 : -case 1250000 : - bits =0x300 ; -break ; -case 500000 : - bits =0x400 ; -break ; -case 200000 : -case 250000 : - bits =0x500 ; -break ; -case 100000 : - bits =0x600 ; -break ; -case 50000 : - bits =0x700 ; -break ; -default : -comedi_error (dev,"bug! in ai_range_bits_6xxx" ); -break ; - } -if (range->min ==0 ) - bits +=0x900 ; -return bits; +return board (dev)->ai_range_code[range_index] <<8 ; } static unsigned int hw_revision(const struct comedi_device *dev,
Signature · 1 line
1.9.1
PATCH 166/176 Bluetooth: ath3k: workaround the compatibility issue with xHCI controller
In reply to [email protected]From: Adam Lee <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit c561a5753dd631920c4459a067d22679b3d110d6 upstream.
ath3k devices fail to load firmwares on xHCI buses, but work well on EHCI, this might be a compatibility issue between xHCI and ath3k chips. As my testing result, those chips will work on xHCI buses again with this patch.
This workaround is from Qualcomm, they also did some workarounds in Windows driver.
--- drivers/bluetooth/ath3k.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/bluetooth/ath3k.c +8 -0
@@ -161,6 +161,8 @@ static struct usb_device_id ath3k_blist_tbl[] = {#define USB_REQ_DFU_DNLOAD 1#define BULK_SIZE 4096#define FW_HDR_SIZE 20 +#define TIMEGAP_USEC_MIN 50 +#define TIMEGAP_USEC_MAX 100static int ath3k_load_firmware (struct usb_device *udev,const struct firmware *firmware)
@@ -191,6 +193,9 @@ static int ath3k_load_firmware(struct usb_device *udev, count -=20 ;while (count) { +/* workaround the compatibility issue with xHCI controller*/ +usleep_range (TIMEGAP_USEC_MIN ,TIMEGAP_USEC_MAX ); + size =min_t (uint, count,BULK_SIZE ); pipe =usb_sndbulkpipe (udev,0x02 );memcpy (send_buf, firmware->data + sent, size);
@@ -267,6 +272,9 @@ static int ath3k_load_fwfile(struct usb_device *udev, count -= size;while (count) { +/* workaround the compatibility issue with xHCI controller*/ +usleep_range (TIMEGAP_USEC_MIN ,TIMEGAP_USEC_MAX ); + size =min_t (uint, count,BULK_SIZE ); pipe =usb_sndbulkpipe (udev,0x02 );
Signature · 1 line
1.9.1
PATCH 167/176 sched/rt: Reduce rq lock contention by eliminating locking of non-feasible target
In reply to [email protected]From: Tim Chen <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 80e3d87b2c5582db0ab5e39610ce3707d97ba409 upstream.
This patch adds checks that prevens futile attempts to move rt tasks to a CPU with active tasks of equal or higher priority.
This reduces run queue lock contention and improves the performance of a well known OLTP benchmark by 0.7%.
--- kernel/sched/rt.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)
kernel/sched/rt.c +16 -1
@@ -1293,7 +1293,12 @@ select_task_rq_rt(struct task_struct *p, int sd_flag, int flags) (p->rt.nr_cpus_allowed > 1)) {int target =find_lowest_rq (p); -if (target !=-1 ) +/* +* Don't bother moving it if the destination CPU is +* not running a lower priority task. +*/ +if (target !=-1 && + p->prio <cpu_rq (target)->rt.highest_prio.curr) cpu = target; }rcu_read_unlock ();
@@ -1570,6 +1575,16 @@ static struct rq *find_lock_lowest_rq(struct task_struct *task, struct rq *rq) lowest_rq =cpu_rq (cpu); +if (lowest_rq->rt.highest_prio.curr <= task->prio) { +/* +* Target rq has tasks of equal or higher priority, +* retrying does not release any lock and is unlikely +* to yield a different result. +*/ + lowest_rq =NULL ; +break ; + } +/* if the prio of this runqueue changed, try again */ if (double_lock_balance (rq, lowest_rq)) {/*
Signature · 1 line
1.9.1
PATCH 168/176 net:socket: set msg_namelen to 0 if msg_name is passed as NULL in msghdr struct from userland.
In reply to [email protected]From: Ani Sinha <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 6a2a2b3ae0759843b22c929881cc184b00cc63ff upstream.
Linux manpage for recvmsg and sendmsg calls does not explicitly mention setting msg_namelen to 0 when msg_name passed set as NULL. When developers don't set msg_namelen member in msghdr, it might contain garbage value which will fail the validation check and sendmsg and recvmsg calls from kernel will return EINVAL. This will break old binaries and any code for which there is no access to source code.
To fix this, we set msg_namelen to 0 when msg_name is passed as NULL from userland.
--- net/socket.c | 3 +++ 1 file changed, 3 insertions(+)
net/socket.c +3 -0
@@ -1908,6 +1908,9 @@ static int copy_msghdr_from_user(struct msghdr *kmsg,if (copy_from_user (kmsg, umsg,sizeof (struct msghdr )))return -EFAULT ; +if (kmsg->msg_name ==NULL ) + kmsg->msg_namelen =0 ; +if (kmsg->msg_namelen <0 )return -EINVAL ;
Signature · 1 line
1.9.1
PATCH 169/176 fsnotify: next_i is freed during fsnotify_unmount_inodes.
In reply to [email protected]From: Jerry Hoemann <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 6424babfd68dd8a83d9c60a5242d27038856599f upstream.
During file system stress testing on 3.10 and 3.12 based kernels, the umount command occasionally hung in fsnotify_unmount_inodes in the section of code:
spin_lock(&inode->i_lock);
if (inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW)) {
spin_unlock(&inode->i_lock);
continue;
}As this section of code holds the global inode_sb_list_lock, eventually the system hangs trying to acquire the lock.
Multiple crash dumps showed:
The inode->i_state == 0x60 and i_count == 0 and i_sb_list would point back at itself. As this is not the value of list upon entry to the function, the kernel never exits the loop.
To help narrow down problem, the call to list_del_init in inode_sb_list_del was changed to list_del. This poisons the pointers in the i_sb_list and causes a kernel to panic if it transverse a freed inode.
Subsequent stress testing paniced in fsnotify_unmount_inodes at the bottom of the list_for_each_entry_safe loop showing next_i had become free.
We believe the root cause of the problem is that next_i is being freed during the window of time that the list_for_each_entry_safe loop temporarily releases inode_sb_list_lock to call fsnotify and fsnotify_inode_delete.
The code in fsnotify_unmount_inodes attempts to prevent the freeing of inode and next_i by calling __iget. However, the code doesn't do the __iget call on next_i
if i_count == 0 or if i_state & (I_FREEING | I_WILL_FREE)
The patch addresses this issue by advancing next_i in the above two cases until we either find a next_i which we can __iget or we reach the end of the list. This makes the handling of next_i more closely match the handling of the variable "inode."
The time to reproduce the hang is highly variable (from hours to days.) We ran the stress test on a 3.10 kernel with the proposed patch for a week without failure.
During list_for_each_entry_safe, next_i is becoming free causing the loop to never terminate. Advance next_i in those cases where __iget is not done.
--- fs/notify/inode_mark.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-)
fs/notify/inode_mark.c +11 -6
@@ -282,20 +282,25 @@ void fsnotify_unmount_inodes(struct list_head *list)spin_unlock (&inode->i_lock);/* In case the dropping of a reference would nuke next_i. */ -if ((&next_i->i_sb_list != list) && -atomic_read (&next_i->i_count)) { +while (&next_i->i_sb_list != list) {spin_lock (&next_i->i_lock); -if (!(next_i->i_state & (I_FREEING |I_WILL_FREE ))) { +if (!(next_i->i_state & (I_FREEING |I_WILL_FREE )) && +atomic_read (&next_i->i_count)) {__iget (next_i); need_iput = next_i; +spin_unlock (&next_i->i_lock); +break ; }spin_unlock (&next_i->i_lock); + next_i =list_entry (next_i->i_sb_list.next, + struct inode, i_sb_list); }/* -* We can safely drop inode_sb_list_lock here because we hold -* references on both inode and next_i. Also no new inodes -* will be added since the umount has begun. +* We can safely drop inode_sb_list_lock here because either +* we actually hold references on both inode and next_i or +* end of list. Also no new inodes will be added since the +* umount has begun. */ spin_unlock (&inode_sb_list_lock);
Signature · 1 line
1.9.1
PATCH 170/176 x86, cpu, amd: Add workaround for family 16h, erratum 793
In reply to [email protected]From: Borislav Petkov <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 3b56496865f9f7d9bcb2f93b44c63f274f08e3b6 upstream.
This adds the workaround for erratum 793 as a precaution in case not every BIOS implements it. This addresses CVE-2013-6885.
Erratum text:
[Revision Guide for AMD Family 16h Models 00h-0Fh Processors, document 51810 Rev. 3.04 November 2013]
793 Specific Combination of Writes to Write Combined Memory Types and Locked Instructions May Cause Core Hang
Description
Under a highly specific and detailed set of internal timing conditions, a locked instruction may trigger a timing sequence whereby the write to a write combined memory type is not flushed, causing the locked instruction to stall indefinitely.
Potential Effect on System
Processor core hang.
Suggested Workaround
BIOS should set MSR
C001_1020[15] = 1b.
Fix Planned
No fix planned
[ hpa: updated description, fixed typo in MSR name ]
[bwh: Backported to 3.2:
- Adjust filename
- Venkatesh Srinivas pointed out we should use {rd,wr}msrl_safe() to avoid crashing on KVM. This was fixed upstream by commit 8f86a7373a1c ("x86, AMD: Convert to the new bit access MSR accessors") but that's too much trouble to backport. Here we must use {rd,wr}msrl_amd_safe().]
--- arch/x86/include/asm/msr-index.h | 1 + arch/x86/kernel/cpu/amd.c | 10 ++++++++++ 2 files changed, 11 insertions(+)
arch/x86/include/asm/msr-index.h +1 -0
@@ -130,6 +130,7 @@#define MSR_AMD64_PATCH_LOADER 0xc0010020#define MSR_AMD64_OSVW_ID_LENGTH 0xc0010140#define MSR_AMD64_OSVW_STATUS 0xc0010141 +#define MSR_AMD64_LS_CFG 0xc0011020#define MSR_AMD64_DC_CFG 0xc0011022#define MSR_AMD64_IBSFETCHCTL 0xc0011030#define MSR_AMD64_IBSFETCHLINAD 0xc0011031
arch/x86/kernel/cpu/amd.c +10 -0
@@ -417,6 +417,16 @@ static void __cpuinit early_init_amd_mc(struct cpuinfo_x86 *c) c->x86_coreid_bits = bits;#endif + +/* F16h erratum 793, CVE-2013-6885 */ +if (c->x86 ==0x16 && c->x86_model <=0xf ) { +u64 val; + +if (!rdmsrl_amd_safe (MSR_AMD64_LS_CFG , &val) && + !(val &BIT (15 ))) +wrmsrl_amd_safe (MSR_AMD64_LS_CFG , val |BIT (15 )); + } + }static void __cpuinit bsp_init_amd (struct cpuinfo_x86 *c)
Signature · 1 line
1.9.1
PATCH 171/176 s390/3215: fix tty output containing tabs
In reply to [email protected]From: Martin Schwidefsky <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit e512d56c799517f33b301d81e9a5e0ebf30c2d1e upstream.
git commit 37f81fa1f63ad38e16125526bb2769ae0ea8d332 "n_tty: do O_ONLCR translation as a single write" surfaced a bug in the 3215 device driver. In combination this broke tab expansion for tty ouput.
The cause is an asymmetry in the behaviour of tty3215_ops->write vs tty3215_ops->put_char. The put_char function scans for '\t' but the write function does not.
As the driver has logic for the '\t' expansion remove XTABS from c_oflag of the initial termios as well.
--- drivers/s390/char/con3215.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-)
drivers/s390/char/con3215.c +17 -3
@@ -997,12 +997,26 @@ static int tty3215_write(struct tty_struct * tty, const unsigned char *buf, int count) {struct raw3215_info *raw; +int i, written;if (!tty)return 0 ; raw = (struct raw3215_info *) tty->driver_data; -raw3215_write (raw, buf, count); -return count; + written = count; +while (count >0 ) { +for (i =0 ; i < count; i++) +if (buf[i] =='\t' || buf[i] =='\n' ) +break ; +raw3215_write (raw, buf, i); + count -= i; + buf += i; +if (count >0 ) { +raw3215_putchar (raw, *buf); + count--; + buf++; + } + } +return written; }/*
@@ -1149,7 +1163,7 @@ static int __init tty3215_init(void) driver->subtype =SYSTEM_TYPE_TTY ; driver->init_termios = tty_std_termios; driver->init_termios.c_iflag =IGNBRK |IGNPAR ; - driver->init_termios.c_oflag =ONLCR |XTABS ; + driver->init_termios.c_oflag =ONLCR ; driver->init_termios.c_lflag =ISIG ; driver->flags =TTY_DRIVER_REAL_RAW ;tty_set_operations (driver, &tty3215_ops);
Signature · 1 line
1.9.1
PATCH 172/176 ntp: Fixup adjtimex freq validation on 32-bit systems
In reply to [email protected]From: John Stultz <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 29183a70b0b828500816bd794b3fe192fce89f73 upstream.
Additional validation of adjtimex freq values to avoid potential multiplication overflows were added in commit 5e5aeb4367b (time: adjtimex: Validate the ADJ_FREQUENCY values)
Unfortunately the patch used LONG_MAX/MIN instead of LLONG_MAX/MIN, which was fine on 64-bit systems, but being much smaller on 32-bit systems caused false positives resulting in most direct frequency adjustments to fail w/ EINVAL.
ntpd only does direct frequency adjustments at startup, so the issue was not as easily observed there, but other time sync applications like ptpd and chrony were more effected by the bug.
See bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=92481
https://bugzilla.redhat.com/show_bug.cgi?id=1188074
This patch changes the checks to use LLONG_MAX for clarity, and additionally the checks are disabled on 32-bit systems since LLONG_MAX/PPM_SCALE is always larger then the 32-bit long freq value, so multiplication overflows aren't possible there.
--- kernel/time/ntp.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
kernel/time/ntp.c +7 -3
@@ -660,10 +660,14 @@ int do_adjtimex(struct timex *txc)return result; } -if (txc->modes &ADJ_FREQUENCY ) { -if (LONG_MIN /PPM_SCALE > txc->freq) +/* +* Check for potential multiplication overflows that can +* only happen on 64-bit systems: +*/ +if ((txc->modes &ADJ_FREQUENCY ) && (BITS_PER_LONG ==64 )) { +if (LLONG_MIN /PPM_SCALE > txc->freq)return -EINVAL ; -if (LONG_MAX /PPM_SCALE < txc->freq) +if (LLONG_MAX /PPM_SCALE < txc->freq)return -EINVAL ; }
Signature · 1 line
1.9.1
PATCH 173/176 spi: dw: revisit FIFO size detection again
In reply to [email protected]From: Andy Shevchenko <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 9d239d353c319f9ff884c287ce47feb7cdf60ddc upstream.
The commit d297933cc7fc (spi: dw: Fix detecting FIFO depth) tries to fix the logic of the FIFO detection based on the description on the comments. However, there is a slight difference between numbers in TX Level and TX FIFO size.
So, by specification the FIFO size would be in a range 2-256 bytes. From TX Level prospective it means we can set threshold in the range 0-(FIFO size - 1) bytes. Hence there are currently two issues:
a) FIFO size 2 bytes is actually skipped since TX Level is 1 bit and could be
either 0 or 1 byte;
b) FIFO size is incorrectly decreased by 1 which already done by meaning of TX Level register.
This patch fixes it eventually right.
--- drivers/spi/spi-dw.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/spi/spi-dw.c +2 -2
@@ -780,13 +780,13 @@ static void spi_hw_init(struct dw_spi *dws)*/ if (!dws->fifo_len) {u32 fifo; -for (fifo =2 ; fifo <=256 ; fifo++) { +for (fifo =1 ; fifo <256 ; fifo++) {dw_writew (dws,DW_SPI_TXFLTR , fifo);if (fifo !=dw_readw (dws,DW_SPI_TXFLTR ))break ; } - dws->fifo_len = (fifo ==2 ) ?0 : fifo -1 ; + dws->fifo_len = (fifo ==1 ) ?0 : fifo;dw_writew (dws,DW_SPI_TXFLTR ,0 ); } }
Signature · 1 line
1.9.1
PATCH 174/176 nilfs2: fix deadlock of segment constructor during recovery
In reply to [email protected]From: Ryusuke Konishi <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 283ee1482f349d6c0c09dfb725db5880afc56813 upstream.
According to a report from Yuxuan Shui, nilfs2 in kernel 3.19 got stuck during recovery at mount time. The code path that caused the deadlock was as follows:
nilfs_fill_super()
load_nilfs()
nilfs_salvage_orphan_logs()
* Do roll-forwarding, attach segment constructor for recovery, and kick it.
nilfs_segctor_thread()
nilfs_segctor_thread_construct()
* A lock is held with nilfs_transaction_lock() nilfs_segctor_do_construct() nilfs_segctor_drop_written_files()
iput()
iput_final()
write_inode_now()
writeback_single_inode()
__writeback_single_inode()
do_writepages()
nilfs_writepage()
nilfs_construct_dsync_segment()
nilfs_transaction_lock() --> deadlock
This can happen if commit 7ef3ff2fea8b ("nilfs2: fix deadlock of segment constructor over I_SYNC flag") is applied and roll-forward recovery was performed at mount time. The roll-forward recovery can happen if datasync write is done and the file system crashes immediately after that. For instance, we can reproduce the issue with the following steps:
< nilfs2 is mounted on /nilfs (device: /dev/sdb1) >
# dd if=/dev/zero of=/nilfs/test bs=4k count=1 && sync # dd if=/dev/zero of=/nilfs/test conv=notrunc oflag=dsync bs=4k count=1 && reboot -nfh < the system will immediately reboot > # mount -t nilfs2 /dev/sdb1 /nilfs
The deadlock occurs because iput() can run segment constructor through writeback_single_inode() if MS_ACTIVE flag is not set on sb->s_flags. The above commit changed segment constructor so that it calls iput() asynchronously for inodes with i_nlink == 0, but that change was imperfect.
This fixes the another deadlock by deferring iput() in segment constructor even for the case that mount is not finished, that is, for the case that MS_ACTIVE flag is not set.
--- fs/nilfs2/segment.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
fs/nilfs2/segment.c +4 -3
@@ -1903,6 +1903,7 @@ static void nilfs_segctor_drop_written_files(struct nilfs_sc_info *sci, struct the_nilfs *nilfs) {struct nilfs_inode_info *ii, *n; +int during_mount = !(sci->sc_super->s_flags &MS_ACTIVE );int defer_iput = false;spin_lock (&nilfs->ns_inode_lock);
@@ -1915,10 +1916,10 @@ static void nilfs_segctor_drop_written_files(struct nilfs_sc_info *sci,brelse (ii->i_bh); ii->i_bh =NULL ;list_del_init (&ii->i_dirty); -if (!ii->vfs_inode.i_nlink) { +if (!ii->vfs_inode.i_nlink || during_mount) {/* -* Defer calling iput() to avoid a deadlock -* over I_SYNC flag for inodes with i_nlink == 0 +* Defer calling iput() to avoid deadlocks if +* i_nlink == 0 or mount is not yet finished. */ list_add_tail (&ii->i_dirty, &sci->sc_iput_queue); defer_iput = true;
Signature · 1 line
1.9.1
PATCH 175/176 net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour
In reply to [email protected]From: Catalin Marinas <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 91edd096e224941131f896b86838b1e59553696a upstream.
Commit db31c55a6fb2 (net: clamp ->msg_namelen instead of returning an error) introduced the clamping of msg_namelen when the unsigned value was larger than sizeof(struct sockaddr_storage). This caused a msg_namelen of -1 to be valid. The native code was subsequently fixed by commit dbb490b96584 (net: socket: error on a negative msg_namelen).
In addition, the native code sets msg_namelen to 0 when msg_name is NULL. This was done in commit (6a2a2b3ae075 net:socket: set msg_namelen to 0 if msg_name is passed as NULL in msghdr struct from userland) and subsequently updated by 08adb7dabd48 (fold verify_iovec() into copy_msghdr_from_user()).
This patch brings the get_compat_msghdr() in line with copy_msghdr_from_user().
--- net/compat.c | 7 +++++++ 1 file changed, 7 insertions(+)
net/compat.c +7 -0
@@ -71,6 +71,13 @@ int get_compat_msghdr(struct msghdr *kmsg, struct compat_msghdr __user *umsg)__get_user (kmsg->msg_controllen, &umsg->msg_controllen) || __get_user(kmsg->msg_flags, &umsg->msg_flags)) return -EFAULT; + +if (!tmp1) + kmsg->msg_namelen =0 ; + +if (kmsg->msg_namelen <0 ) +return -EINVAL ; +if (kmsg->msg_namelen >sizeof (struct sockaddr_storage )) kmsg->msg_namelen =sizeof (struct sockaddr_storage ); kmsg->msg_name =compat_ptr (tmp1);
Signature · 1 line
1.9.1
PATCH 176/176 mm: fix anon_vma->degree underflow in anon_vma endless growing prevention
In reply to [email protected]From: Leon Yu <[email protected]>
3.4.107-rc1 review patch. If anyone has any objections, please let me know.
------------------
commit 3fe89b3e2a7bbf3e97657104b9b33a9d81b950b3 upstream.
I have constantly stumbled upon "kernel BUG at mm/rmap.c:399!" after upgrading to 3.19 and had no luck with 4.0-rc1 neither.
So, after looking into new logic introduced by commit 7a3ef208e662 ("mm:
prevent endless growth of anon_vma hierarchy"), I found chances are that unlink_anon_vmas() is called without incrementing dst->anon_vma->degree in anon_vma_clone() due to allocation failure. If dst->anon_vma is not NULL in error path, its degree will be incorrectly decremented in unlink_anon_vmas() and eventually underflow when exiting as a result of another call to unlink_anon_vmas(). That's how "kernel BUG at mm/rmap.c:399!" is triggered for me.
This patch fixes the underflow by dropping dst->anon_vma when allocation fails. It's safe to do so regardless of original value of dst->anon_vma because dst->anon_vma doesn't have valid meaning if anon_vma_clone() fails. Besides, callers don't care dst->anon_vma in such case neither.
Also suggested by Michal Hocko, we can clean up vma_adjust() a bit as anon_vma_clone() now does the work.
--- mm/mmap.c | 4 +--- mm/rmap.c | 7 +++++++ 2 files changed, 8 insertions(+), 3 deletions(-)
mm/mmap.c +1 -3
@@ -571,10 +571,8 @@ again: remove_next = 1 + (end > next->vm_end); importer->anon_vma = exporter->anon_vma; error =anon_vma_clone (importer, exporter); -if (error) { - importer->anon_vma =NULL ; +if (error)return error; - } } }
mm/rmap.c +7 -0
@@ -292,6 +292,13 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src)return 0 ; enomem_failure: +/* +* dst->anon_vma is dropped here otherwise its degree can be incorrectly +* decremented in unlink_anon_vmas(). +* We can safely do this because callers of anon_vma_clone() don't care +* about dst->anon_vma if anon_vma_clone() failed. +*/ + dst->anon_vma =NULL ;unlink_anon_vmas (dst);return -ENOMEM ; }
Signature · 1 line
1.9.1
Quoted 10 lines · On Thu, Apr 09, 2015 at 04:43:48PM +0800, [email protected] wrote:
From: Zefan Li <[email protected]>
This is the start of the stable review cycle for the 3.4.107 release. There are 176 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 Apr 9 16:25:15 CST 2015. Anything received after that time might be too late.
Build results:
total: 105 pass: 86 fail: 19 Failed builds: arm:omap1_defconfig arm:at91rm9200_defconfig i386:allyesconfig mips:defconfig mips:allmodconfig mips:bcm47xx_defconfig mips:bcm63xx_defconfig mips:nlm_xlp_defconfig mips:ar7_defconfig mips:fuloong2e_defconfig mips:e55_defconfig mips:powertv_defconfig mips:malta_defconfig s390:defconfig score:defconfig sparc64:allmodconfig tile:tilegx_defconfig x86_64:allyesconfig xtensa:allmodconfig
Qemu test results:
total: 23 pass: 14 fail: 9 Failed tests: arm:arm_versatile_defconfig mips:mips_malta_defconfig mips:mips_malta_smp_defconfig mips:mipsel_malta_defconfig mips:mipsel_malta_smp_defconfig mips64:mips_malta64_defconfig mips64:mips_malta64_smp_defconfig x86:x86_pc_defconfig x86:x86_pc_nosmp_defconfig
Unexpected build errors:
drivers/usb/serial/console.c: In function 'usb_console_setup':drivers/usb/serial/console.c:151:4: error: expected ';' before 'if'
---arch/mips/mm/tlb-r4k.c: In function 'tlb_init':arch/mips/mm/tlb-r4k.c:413:7: error: 'cpu_has_rixiex' undeclared (first use in this function) arch/mips/mm/tlb-r4k.c:414:10: error: 'PG_IEC' undeclared (first use in this function)
---arch/s390/mm/fault.c: In function 'do_fault_error':arch/s390/mm/fault.c:243:25: error: 'int_code' undeclared (first use in this function) arch/s390/mm/fault.c:243:35: error: 'trans_exc_code' undeclared (first use in this function) arch/s390/mm/fault.c:243:5: error: too many arguments to function 'do_no_context' arch/s390/mm/fault.c:159:22: note: declared herearch/s390/mm/fault.c:246:9: error: too many arguments to function 'do_sigsegv' arch/s390/mm/fault.c:148:22: note: declared here
Let me know if you need me to bisect.
Guenter
Quoted 55 lines
Build results:
total: 105 pass: 86 fail: 19 Failed builds: arm:omap1_defconfig arm:at91rm9200_defconfig i386:allyesconfig mips:defconfig mips:allmodconfig mips:bcm47xx_defconfig mips:bcm63xx_defconfig mips:nlm_xlp_defconfig mips:ar7_defconfig mips:fuloong2e_defconfig mips:e55_defconfig mips:powertv_defconfig mips:malta_defconfig s390:defconfig score:defconfig sparc64:allmodconfig tile:tilegx_defconfig x86_64:allyesconfig xtensa:allmodconfigQemu test results:
total: 23 pass: 14 fail: 9 Failed tests: arm:arm_versatile_defconfig mips:mips_malta_defconfig mips:mips_malta_smp_defconfig mips:mipsel_malta_defconfig mips:mipsel_malta_smp_defconfig mips64:mips_malta64_defconfig mips64:mips_malta64_smp_defconfig x86:x86_pc_defconfig x86:x86_pc_nosmp_defconfigUnexpected build errors:
drivers/usb/serial/console.c: In function 'usb_console_setup':drivers/usb/serial/console.c:151:4: error: expected ';' before 'if'---
arch/mips/mm/tlb-r4k.c: In function 'tlb_init':arch/mips/mm/tlb-r4k.c:413:7: error: 'cpu_has_rixiex' undeclared (first use in this function)arch/mips/mm/tlb-r4k.c:414:10: error: 'PG_IEC' undeclared (first use in this function)---
arch/s390/mm/fault.c: In function 'do_fault_error':arch/s390/mm/fault.c:243:25: error: 'int_code' undeclared (first use in this function)arch/s390/mm/fault.c:243:35: error: 'trans_exc_code' undeclared (first use in this function)arch/s390/mm/fault.c:243:5: error: too many arguments to function 'do_no_context'arch/s390/mm/fault.c:159:22: note: declared herearch/s390/mm/fault.c:246:9: error: too many arguments to function 'do_sigsegv'arch/s390/mm/fault.c:148:22: note: declared here
Quoted 2 lines
Let me know if you need me to bisect.
Thanks for testing.
All should be fixed. Could you give it another try?
Quoted 55 lines · Zefan Li
Quoted 55 lines
Build results:
total: 105 pass: 86 fail: 19 Failed builds: arm:omap1_defconfig arm:at91rm9200_defconfig i386:allyesconfig mips:defconfig mips:allmodconfig mips:bcm47xx_defconfig mips:bcm63xx_defconfig mips:nlm_xlp_defconfig mips:ar7_defconfig mips:fuloong2e_defconfig mips:e55_defconfig mips:powertv_defconfig mips:malta_defconfig s390:defconfig score:defconfig sparc64:allmodconfig tile:tilegx_defconfig x86_64:allyesconfig xtensa:allmodconfigQemu test results:
total: 23 pass: 14 fail: 9 Failed tests: arm:arm_versatile_defconfig mips:mips_malta_defconfig mips:mips_malta_smp_defconfig mips:mipsel_malta_defconfig mips:mipsel_malta_smp_defconfig mips64:mips_malta64_defconfig mips64:mips_malta64_smp_defconfig x86:x86_pc_defconfig x86:x86_pc_nosmp_defconfigUnexpected build errors:
drivers/usb/serial/console.c: In function 'usb_console_setup':drivers/usb/serial/console.c:151:4: error: expected ';' before 'if'---
arch/mips/mm/tlb-r4k.c: In function 'tlb_init':arch/mips/mm/tlb-r4k.c:413:7: error: 'cpu_has_rixiex' undeclared (first use in this function)arch/mips/mm/tlb-r4k.c:414:10: error: 'PG_IEC' undeclared (first use in this function)---
arch/s390/mm/fault.c: In function 'do_fault_error':arch/s390/mm/fault.c:243:25: error: 'int_code' undeclared (first use in this function)arch/s390/mm/fault.c:243:35: error: 'trans_exc_code' undeclared (first use in this function)arch/s390/mm/fault.c:243:5: error: too many arguments to function 'do_no_context'arch/s390/mm/fault.c:159:22: note: declared herearch/s390/mm/fault.c:246:9: error: too many arguments to function 'do_sigsegv'arch/s390/mm/fault.c:148:22: note: declared here
Quoted 7 lines
Quoted 2 lines
Let me know if you need me to bisect.
Thanks for testing.
All should be fixed. Could you give it another try?
Here are the current build and test results:
Build results:
total: 105 pass: 102 fail: 3
Failed builds:
score:defconfig
sparc64:allmodconfig
xtensa:allmodconfig
Qemu test results:
total: 23 pass: 22 fail: 1
Failed tests:
arm:arm_versatile_defconfig
Results are as expected.
Guenter