summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-05-17Btrfs: don't abort the current transaction if there is no enough space for ↵Miao Xie
inode cache The filesystem with inode cache was forced to be read-only when we umounted it. Steps to reproduce: # mkfs.btrfs -f ${DEV} # mount -o inode_cache ${DEV} ${MNT} # dd if=/dev/zero of=${MNT}/file1 bs=1M count=8192 # btrfs fi syn ${MNT} # dd if=${MNT}/file1 of=/dev/null bs=1M # rm -f ${MNT}/file1 # btrfs fi syn ${MNT} # umount ${MNT} It is because there was no enough space to do inode cache truncation, and then we aborted the current transaction. But no space error is not a serious problem when we write out the inode cache, and it is safe that we just skip this step if we meet this problem. So we need not abort the current transaction. Reported-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> Tested-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com> Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17Correct allowed raid levels on balance.Andreas Philipp
Raid5 with 3 devices is well defined while the old logic allowed raid5 only with a minimum of 4 devices when converting the block group profile via btrfs balance. Creating a raid5 with just three devices using mkfs.btrfs worked always as expected. This is now fixed and the whole logic is rewritten. Signed-off-by: Andreas Philipp <philipp.andreas@gmail.com> Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17Btrfs: fix possible memory leak in replace_path()Stefan Behrens
In replace_path(), if read_tree_block() fails, we cannot return directly, we should free some allocated memory otherwise memory leak happens. Similar to Wang's "Btrfs: fix possible memory leak in the find_parent_nodes()" patch, the current commit fixes an issue that is related to the "Btrfs: fix all callers of read_tree_block" commit. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de> Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17Btrfs: fix possible memory leak in the find_parent_nodes()Wang Shilong
In the find_parent_nodes(), if read_tree_block() fails, we can not return directly, we should free some allocated memory otherwise memory leak happens. Signed-off-by: Wang Shilong <wangsl-fnst@cn.fujitsu.com> Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17Btrfs: don't allow device replace on RAID5/RAID6Stefan Behrens
This is not yet supported and causes crashes. One sad user reported that it destroyed his filesystem. One failure is in __btrfs_map_block+0xc1f calling kmalloc(0). 0x5f21f is in __btrfs_map_block (fs/btrfs/volumes.c:4923). 4918 num_stripes = map->num_stripes; 4919 max_errors = nr_parity_stripes(map); 4920 4921 raid_map = kmalloc(sizeof(u64) * num_stripes, 4922 GFP_NOFS); 4923 if (!raid_map) { 4924 ret = -ENOMEM; 4925 goto out; 4926 } 4927 There might be more issues. Until this is really tested, don't allow users to start the procedure on RAID5/RAID6 filesystems. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de> Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17Btrfs: handle running extent ops with skinny metadataJosef Bacik
Chris hit a bug where we weren't finding extent records when running extent ops. This is because we use the delayed_ref_head when running the extent op, which means we can't use the ->type checks to see if we are metadata. We also lose the level of the metadata we are working on. So to fix this we can just check the ->is_data section of the extent_op, and we can store the level of the buffer we were modifying in the extent_op. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17Btrfs: remove warn on in free space cache writeoutJosef Bacik
This catches block groups that are too large to properly cache. We deal with this case fine, so the warning just confuses users. Remove the warning. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17Btrfs: don't null pointer deref on abortJosef Bacik
I'm sorry, theres no excuse for this sort of work. We need to use root->leafsize since eb may be NULL. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17btrfs: don't stop searching after encountering the wrong itemGabriel de Perthuis
The search ioctl skips items that are too large for a result buffer, but inline items of a certain size occuring before any search result is found would trigger an overflow and stop the search entirely. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=57641 Cc: stable@vger.kernel.org Signed-off-by: Gabriel de Perthuis <g2p.code+btrfs@gmail.com> Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17gianfar: add missing iounmap() on error in gianfar_ptp_probe()Wei Yongjun
Add the missing iounmap() before return from gianfar_ptp_probe() in the error handling case. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-05-17staging: dwc2: Fix dma-enabled platform devices using a default dma_maskMatthijs Kooijman
Platform devices added through OF usually do not have any dma_mask pointer set. If the hardware advertises DMA support, the driver will expect DMA buffers to be passed in, but the USB core will not do this due to lack of a dma mask, breaking all connectiviy. To fix this, set a default dma_mask by pointing it at the coherent_dma_mask and set their value to a 32 bit mask. This still allows any platform code to set any more specific mask if needed, but makes the driver work for most dma-enabled hardware. It would be great if this patch could be included in 3.10, since it is needed to make the dwc2 driver work on the ralink rt3052 target. Before, the plan was to set up the dma mask in MIPS platform code, but because of a similar change in ehci and the uglyness of the code for that, the plan for that infrastructure was dropped. This patch makes the setting of the dma_mask happen in the same way as the patch Stephen Warren (set device dma_mask without reference to global data). Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-17i2c: suppress lockdep warning on delete_deviceAlexander Sverdlin
i2c: suppress lockdep warning on delete_device Since commit 846f99749ab68bbc7f75c74fec305de675b1a1bf the following lockdep warning is thrown in case i2c device is removed (via delete_device sysfs attribute) which contains subdevices (e.g. i2c multiplexer): ============================================= [ INFO: possible recursive locking detected ] 3.8.7-0-sampleversion-fct #8 Tainted: G O --------------------------------------------- bash/3743 is trying to acquire lock: (s_active#110){++++.+}, at: [<ffffffff802b3048>] sysfs_hash_and_remove+0x58/0xc8 but task is already holding lock: (s_active#110){++++.+}, at: [<ffffffff802b3cb8>] sysfs_write_file+0xc8/0x208 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(s_active#110); lock(s_active#110); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/3743: #0: (&buffer->mutex){+.+.+.}, at: [<ffffffff802b3c3c>] sysfs_write_file+0x4c/0x208 #1: (s_active#110){++++.+}, at: [<ffffffff802b3cb8>] sysfs_write_file+0xc8/0x208 #2: (&adap->userspace_clients_lock/1){+.+.+.}, at: [<ffffffff80454a18>] i2c_sysfs_delete_device+0x90/0x238 #3: (&__lockdep_no_validate__){......}, at: [<ffffffff803dcc24>] device_release_driver+0x24/0x48 stack backtrace: Call Trace: [<ffffffff80575cc8>] dump_stack+0x8/0x34 [<ffffffff801b50fc>] __lock_acquire+0x161c/0x2110 [<ffffffff801b5c3c>] lock_acquire+0x4c/0x70 [<ffffffff802b60cc>] sysfs_addrm_finish+0x19c/0x1e0 [<ffffffff802b3048>] sysfs_hash_and_remove+0x58/0xc8 [<ffffffff802b7d8c>] sysfs_remove_group+0x64/0x148 [<ffffffff803d990c>] device_remove_attrs+0x9c/0x1a8 [<ffffffff803d9b1c>] device_del+0x104/0x1d8 [<ffffffff803d9c18>] device_unregister+0x28/0x70 [<ffffffff8045505c>] i2c_del_adapter+0x1cc/0x328 [<ffffffff8045802c>] i2c_del_mux_adapter+0x14/0x38 [<ffffffffc025c108>] pca954x_remove+0x90/0xe0 [pca954x] [<ffffffff804542f8>] i2c_device_remove+0x80/0xe8 [<ffffffff803dca9c>] __device_release_driver+0x74/0xf8 [<ffffffff803dcc2c>] device_release_driver+0x2c/0x48 [<ffffffff803dbc14>] bus_remove_device+0x13c/0x1d8 [<ffffffff803d9b24>] device_del+0x10c/0x1d8 [<ffffffff803d9c18>] device_unregister+0x28/0x70 [<ffffffff80454b08>] i2c_sysfs_delete_device+0x180/0x238 [<ffffffff802b3cd4>] sysfs_write_file+0xe4/0x208 [<ffffffff8023ddc4>] vfs_write+0xbc/0x160 [<ffffffff8023df6c>] SyS_write+0x54/0xd8 [<ffffffff8013d424>] handle_sys64+0x44/0x64 The problem is already known for USB and PCI subsystems. The reason is that delete_device attribute is defined statically in i2c-core.c and used for all devices in i2c subsystem. Discussion of original USB problem: http://lkml.indiana.edu/hypermail/linux/kernel/1204.3/01160.html Commit 356c05d58af05d582e634b54b40050c73609617b introduced new macro to suppress lockdep warnings for this special case and included workaround for USB code. LKML discussion of the workaround: http://lkml.indiana.edu/hypermail/linux/kernel/1205.1/03634.html As i2c case is in principle the same, the same workaround could be used here. Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nsn.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Tejun Heo <tj@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-05-17i2c: mv64xxx: work around signals causing I2C transactions to be abortedRussell King
Do not use interruptible waits in an I2C driver; if a process uses signals (eg, Xorg uses SIGALRM and SIGPIPE) then these signals can cause the I2C driver to abort a transaction in progress by another driver, which can cause that driver to fail. I2C drivers are not expected to abort transactions on signals. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-05-17i2c: i801: Document feature bits in modinfoJean Delvare
Duplicate the feature bits documentation in modinfo, as not every user will read the driver's source code or documentation file. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-05-17i2c: designware: add Intel BayTrail ACPI IDMika Westerberg
This is the same controller as on Intel Lynxpoint but the ACPI ID is different (8086F41). Add support for this. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-05-17Btrfs: fix off-by-one in fiemapLiu Bo
lock_extent/unlock_extent expect an exclusive end. Tested-by: David Sterba <dsterba@suse.cz> Signed-off-by: Liu Bo <bo.li.liu@oracle.com> Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17btrfs: annotate quota tree for lockdepDavid Sterba
Quota tree has been missing from lockdep annotations, though no warning has been seen in the wild. There's currently one entry that does not belong there, BTRFS_ORPHAN_OBJECTID. No such tree exists, it's probably a copy & paste mistake, the id is defined among tree ids. Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17PCI: acpiphp: Re-enumerate devices when host bridge receives Bus CheckYinghai Lu
When a PCI host bridge device receives a Bus Check notification, we must re-enumerate starting with the bridge to discover changes (devices that have been added or removed). Prior to 668192b678 ("PCI: acpiphp: Move host bridge hotplug to pci_root.c"), this happened in _handle_hotplug_event_bridge(). After that commit, _handle_hotplug_event_bridge() is not installed for host bridges, and the host bridge notify handler, _handle_hotplug_event_root() did not re-enumerate. This patch adds re-enumeration to _handle_hotplug_event_root(). This fixes cases where we don't notice the addition or removal of PCI devices, e.g., the PCI-to-USB ExpressCard in the bugzilla below. [bhelgaas: changelog, references] Reference: https://lkml.kernel.org/r/CAAh6nkmbKR3HTqm5ommevsBwhL_u0N8Rk7Wsms_LfP=nBgKNew@mail.gmail.com Reference: https://bugzilla.kernel.org/show_bug.cgi?id=57961 Reported-by: Gavin Guo <tuffkidtt@gmail.com> Tested-by: Gavin Guo <tuffkidtt@gmail.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> CC: stable@vger.kernel.org # v3.9+
2013-05-17MIPS: ralink: use the dwc2 driver for the rt305x USB controllerMatthijs Kooijman
This sets up the devicetree file for the rt3050 chip series and rt3052 eval board to use the right compatible string for the dwc2 driver. Acked-by: John Crispin <blogic@openwrt.org> Cc: blogic@openwrt.org Cc: linux-mips@linux-mips.org Cc: Matthijs Kooijman <matthijs@stdin.nl> Patchwork: https://patchwork.linux-mips.org/patch/5226/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2013-05-17MIPS: Extract schedule_mfi info from __scheduleTony Wu
schedule_mfi is supposed to be extracted from schedule(), and is used in thread_saved_pc and get_wchan. But, after optimization, schedule() is reduced to a sibling call to __schedule(), and no real frame info can be extracted. One solution is to compile schedule() with -fno-omit-frame-pointer and -fno-optimize-sibling-calls, but that will incur performance degradation. Another solution is to extract info from the real scheduler, __schedule, and this is the approache adopted here. This patch reads the __schedule address by either following the 'j' call in schedule if KALLSYMS is disabled or by using kallsyms_lookup_name to lookup __schedule if KALLSYMS is available, then, extracts schedule_mfi from __schedule frame info. This patch also fixes the "Can't analyze schedule() prologue" warning at boot time. Signed-off-by: Tony Wu <tung7970@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/5237/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2013-05-17MIPS: Fix sibling call handling in get_frame_infoTony Wu
Given a function, get_frame_info() analyzes its instructions to figure out frame size and return address. get_frame_info() works as follows: 1. analyze up to 128 instructions if the function size is unknown 2. search for 'addiu/daddiu sp,sp,-immed' for frame size 3. search for 'sw ra,offset(sp)' for return address 4. end search when it sees jr/jal/jalr This leads to an issue when the given function is a sibling call, example shown as follows. 801ca110 <schedule>: 801ca110: 8f820000 lw v0,0(gp) 801ca114: 8c420000 lw v0,0(v0) 801ca118: 080726f0 j 801c9bc0 <__schedule> 801ca11c: 00000000 nop 801ca120 <io_schedule>: 801ca120: 27bdffe8 addiu sp,sp,-24 801ca124: 3c028022 lui v0,0x8022 801ca128: afbf0014 sw ra,20(sp) In this case, get_frame_info() cannot properly detect schedule's frame info, and eventually returns io_schedule's instead. This patch adds 'j' to the end search condition to workaround sibling call cases. Signed-off-by: Tony Wu <tung7970@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/5236/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2013-05-17USB: ftdi_sio: Add support for Newport CONEX motor driversGomella, Andrew (NIH/NHLBI) [F]
Here are two more devices that use FTDI USB-to-serial chips with new product ID's. The devices are the Newport Conex-AGP and Conex-CC motor controllers. (http://www.newport.com/CONEX-AGP-Integrated-Piezo-Motor-Rotation-Stages-/987623/1033/info.aspx) (http://www.newport.com/CONEX-CC-DC-Servo-Controller-Actuators/934114/1033/info.aspx) usb-devices command yields: P: Vendor=104d ProdID=3002 Rev=06.00 S: Manufacturer=Newport S: Product=CONEX-CC as well as P: Vendor=104d ProdID=3006 Rev=06.00 S: Manufacturer=Newport S: Product=CONEX-AGP Signed-off-by: Andrew Gomella <andrew.gomella@nih.gov> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-17x86, range: fix missing merge during add rangeYinghai Lu
Christian found v3.9 does not work with E350 with EFI is enabled. [ 1.658832] Trying to unpack rootfs image as initramfs... [ 1.679935] BUG: unable to handle kernel paging request at ffff88006e3fd000 [ 1.686940] IP: [<ffffffff813661df>] memset+0x1f/0xb0 [ 1.692010] PGD 1f77067 PUD 1f7a067 PMD 61420067 PTE 0 but early memtest report all memory could be accessed without problem. early page table is set in following sequence: [ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff] [ 0.000000] init_memory_mapping: [mem 0x6e600000-0x6e7fffff] [ 0.000000] init_memory_mapping: [mem 0x6c000000-0x6e5fffff] [ 0.000000] init_memory_mapping: [mem 0x00100000-0x6bffffff] [ 0.000000] init_memory_mapping: [mem 0x6e800000-0x6ea07fff] but later efi_enter_virtual_mode try set mapping again wrongly. [ 0.010644] pid_max: default: 32768 minimum: 301 [ 0.015302] init_memory_mapping: [mem 0x640c5000-0x6e3fcfff] that means it fails with pfn_range_is_mapped. It turns out that we have a bug in add_range_with_merge and it does not merge range properly when new add one fill the hole between two exsiting ranges. In the case when [mem 0x00100000-0x6bffffff] is the hole between [mem 0x00000000-0x000fffff] and [mem 0x6c000000-0x6e7fffff]. Fix the add_range_with_merge by calling itself recursively. Reported-by: "Christian König" <christian.koenig@amd.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Link: http://lkml.kernel.org/r/CAE9FiQVofGoSk7q5-0irjkBxemqK729cND4hov-1QCBJDhxpgQ@mail.gmail.com Cc: <stable@vger.kernel.org> v3.9 Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-05-17MIPS: MSP71xx: remove inline marking of EXPORT_SYMBOL functionsDenis Efremov
EXPORT_SYMBOL and inline directives are contradictory to each other. The patch fixes this inconsistency. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Denis Efremov <yefremov.denis@gmail.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: trivial@kernel.org Cc: ldv-project@linuxtesting.org Patchwork: https://patchwork.linux-mips.org/patch/5227/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2013-05-17MIPS: Make virt_to_phys() work for all unmapped addresses.David Daney
As reported: This problem was discovered when doing BGP traffic with the TCP MD5 option activated, where the following call chain caused a crash: * tcp_v4_rcv * tcp_v4_timewait_ack * tcp_v4_send_ack -> follow stack variable rep.th * tcp_v4_md5_hash_hdr * tcp_md5_hash_header * sg_init_one * sg_set_buf * virt_to_page I noticed that tcp_v4_send_reset uses a similar stack variable and also calls tcp_v4_md5_hash_hdr, so it has the same problem. The networking core can indirectly call virt_to_phys() on stack addresses, if this is done from PID 0, the stack will usually be in CKSEG0, so virt_to_phys() needs to work there as well Signed-off-by: David Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Cc: Jiang Liu <liuj97@gmail.com> Cc: eunb.song@samsung.com Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/5220/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2013-05-17MIPS: Fix build error for crash_dump.c in 3.10-rc1EunBong Song
This patch fixes crash_dump.c build error. Build error logs are as follow. arch/mips/kernel/crash_dump.c: In function 'kdump_buf_page_init': arch/mips/kernel/crash_dump.c:67: error: implicit declaration of function 'kmalloc' arch/mips/kernel/crash_dump.c:67: error: assignment makes pointer from integer without a cast Signed-off-by: EunBong Song <eunb.song@samsung.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/5238/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2013-05-17MIPS: Xway: Fix clk leakLibo Chen
When gptu_r32 fails, we should put clk before returning. Signed-off-by: Libo Chen <libo.chen@huawei.com> Acked-by: John Crispin <blogic@openwrt.org> Cc: grant.likely@linaro.org Cc: rob.herring@calxeda.com, Cc: linux-mips@linux-mips.org Cc: LKML linux-kernel@vger.kernel.org Cc: Andrew Morton akpm@linux-foundation.org Cc: Li Zefan lizefan@huawei.com Patchwork: https://patchwork.linux-mips.org/patch/5247/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2013-05-17ath9k: fix draining aggregation tid buffersFelix Fietkau
After a tx attempt, an A-MPDU subframe can still have fi->retries at 0 (if the retry count wasn't incremented due to powersave). In that case it is still tracked as part of the block ack window, so when draining the tid queue, its sequence number needs to be cleared from the pending frame bitmap. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-05-17ath9k: fix rate handling/reportingFelix Fietkau
This patch fixes some issues introduced in the rate control API rework. When not running aggregation, copy bf->rates into info->control.rates before applying the rate control status to it. In ath_lookup_rate, the rates need to be pulled from bf->rates, not the tx info. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-05-17ath9k: fix aggregation stop/flush handlingFelix Fietkau
When aggregation stop is requested, don't run the mac80211 aggregation stop callback yet, while the session is still blocked. Also, when aggregation flush is requested, don't run the callback at all. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-05-17ath9k_hw: Enable manual peak calibration for AR9485Sujith Manoharan
Manual peak calibration is currently enabled only for AR9462 and AR9565. This is also required for AR9485. The initvals are also modified to disable HW peak calibration. Cc: <stable@vger.kernel.org> Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-05-17rtlwifi: rtl8192cu: Add new USB IDAlbert Pool
This adds the USB ID of the On Networks N300MA, clone of Netgear WNA3100M. Signed-off-by: Albert Pool <albertpool@solcon.nl> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Reported-by: Ana Rey <Anazul77@hotmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-05-17brcmfmac: announce P2P_DEVICE support in wiphy structureArend van Spriel
P2P_DEVICE support was removed from brcmfmac for v3.9 kernel with the commit below: commit 1527c343c12f3a2aae532aa881d12c6fbf8749f4 Author: Arend van Spriel <arend@broadcom.com> Date: Thu Apr 4 12:10:11 2013 +0200 brcmfmac: remove advertising P2P device support However, it got merged into wireless-next. But for 3.10 brcmfmac does support P2P device. Putting it back with this commit. Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-05-17rtlwifi: rtl8188ee: Fix warning when building on big-endian systemsLarry Finger
In http://lkml.indiana.edu/hypermail/linux/kernel/1305.1/index.html, Geert Uytterhoeven reports a new warning when building 3.10-rc1 in this driver. This is caused by using a "#if" test to see if __LITTLE_ENDIAN is set, which fails for all big-endian systems. Change to "ifdef". Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-05-17ath9k: Fix crash on module unloadSujith Manoharan
Make sure that any open relayfs files are closed before unregistering with mac80211, otherwise this crash is seen: [ 1331.097846] BUG: unable to handle kernel paging request at 6b6b6b8b [ 1331.098170] IP: [<c063d0d6>] debugfs_remove+0x26/0x80 [ 1331.098170] *pdpt = 000000002f9aa001 *pde = 0000000000000000 [ 1331.098170] Oops: 0000 [#1] PREEMPT SMP [ 1331.098170] Modules linked in: iptable_raw xt_CT nf_conntrack_ipv4 nf_defrag] [ 1331.098170] Pid: 4794, comm: rmmod Tainted: G WC 3.9.1+ #5 To Be Fi. [ 1331.098170] EIP: 0060:[<c063d0d6>] EFLAGS: 00010202 CPU: 0 [ 1331.098170] EIP is at debugfs_remove+0x26/0x80 [ 1331.098170] EAX: f2f3acd0 EBX: f2f3acd0 ECX: 00000006 EDX: f8622348 [ 1331.098170] ESI: 6b6b6b6b EDI: 00000001 EBP: ee251e14 ESP: ee251e0c [ 1331.098170] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 1331.098170] CR0: 8005003b CR2: 6b6b6b8b CR3: 2e7b7000 CR4: 000007e0 [ 1331.098170] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 1331.098170] DR6: ffff0ff0 DR7: 00000400 [ 1331.098170] Process rmmod (pid: 4794, ti=ee250000 task=efaa2560 task.ti=ee25) [ 1331.098170] Stack: [ 1331.098170] f241e170 0000000a ee251e1c f861394d ee251e28 c04e3088 f241e170 4 [ 1331.098170] c04e30fe f45482b0 ee251e54 c04e3187 f25e86b0 ee251e54 f8618748 0 [ 1331.098170] 0000000a 00000001 ee251e68 f860065b f2509e20 f25085a0 f5b6e8a4 8 [ 1331.098170] Call Trace: [ 1331.098170] [<f861394d>] remove_buf_file_handler+0xd/0x20 [ath9k] [ 1331.098170] [<c04e3088>] relay_remove_buf+0x18/0x30 [ 1331.098170] [<c04e30fe>] relay_close_buf+0x2e/0x40 [ 1331.098170] [<c04e3187>] relay_close+0x77/0xf0 [ 1331.098170] [<f8618748>] ? dpd_exit+0x38/0x40 [ath9k] [ 1331.098170] [<f860065b>] ath9k_deinit_softc+0x8b/0xa0 [ath9k] [ 1331.098170] [<f86006b8>] ath9k_deinit_device+0x48/0x60 [ath9k] [ 1331.098170] [<f86107f1>] ath_pci_remove+0x31/0x50 [ath9k] [ 1331.098170] [<c06dbff8>] pci_device_remove+0x38/0xc0 [ 1331.098170] [<c079daa4>] __device_release_driver+0x64/0xc0 [ 1331.098170] [<c079db97>] driver_detach+0x97/0xa0 [ 1331.098170] [<c079cacc>] bus_remove_driver+0x6c/0xe0 [ 1331.098170] [<c079c197>] ? bus_put+0x17/0x20 [ 1331.098170] [<c079cae3>] ? bus_remove_driver+0x83/0xe0 [ 1331.098170] [<c079e709>] driver_unregister+0x49/0x80 [ 1331.098170] [<c06dc138>] pci_unregister_driver+0x18/0x80 [ 1331.098170] [<f8610602>] ath_pci_exit+0x12/0x20 [ath9k] [ 1331.098170] [<f8619ce0>] ath9k_exit+0x17/0x337 [ath9k] [ 1331.098170] [<c09e537d>] ? mutex_unlock+0xd/0x10 [ 1331.098170] [<c04bd36c>] sys_delete_module+0x17c/0x250 [ 1331.098170] [<c0540dc4>] ? do_munmap+0x244/0x2d0 [ 1331.098170] [<c0540e96>] ? vm_munmap+0x46/0x60 [ 1331.098170] [<c09e8dc4>] ? restore_all+0xf/0xf [ 1331.098170] [<c09ebf50>] ? __do_page_fault+0x4c0/0x4c0 [ 1331.098170] [<c04b18e4>] ? trace_hardirqs_on_caller+0xf4/0x180 [ 1331.098170] [<c09ef28d>] sysenter_do_call+0x12/0x38 [ 1331.098170] Code: 90 8d 74 26 00 55 89 e5 83 ec 08 89 1c 24 89 74 24 04 3e 82 [ 1331.098170] EIP: [<c063d0d6>] debugfs_remove+0x26/0x80 SS:ESP 0068:ee251e0c [ 1331.098170] CR2: 000000006b6b6b8b [ 1331.727971] ---[ end trace b5bb9f2066cef7f9 ]--- Cc: <stable@vger.kernel.org> Acked-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Tested-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-05-17net/wireless: ATH9K should depend on HAS_DMAGeert Uytterhoeven
If NO_DMA=y: drivers/built-in.o: In function `ath9k_beacon_generate': drivers/net/wireless/ath/ath9k/beacon.c:146: undefined reference to `dma_unmap_single' drivers/net/wireless/ath/ath9k/beacon.c:174: undefined reference to `dma_map_single' drivers/net/wireless/ath/ath9k/beacon.c:176: undefined reference to `dma_mapping_error' drivers/built-in.o: In function `ath9k_beacon_remove_slot': drivers/net/wireless/ath/ath9k/beacon.c:252: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `ath_descdma_setup': drivers/net/wireless/ath/ath9k/init.c:382: undefined reference to `dmam_alloc_coherent' drivers/built-in.o: In function `ath_edma_get_buffers': drivers/net/wireless/ath/ath9k/recv.c:616: undefined reference to `dma_sync_single_for_cpu' drivers/built-in.o: In function `ath_get_next_rx_buf': drivers/net/wireless/ath/ath9k/recv.c:740: undefined reference to `dma_sync_single_for_cpu' drivers/built-in.o: In function `ath_rx_edma_cleanup': drivers/net/wireless/ath/ath9k/recv.c:176: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `ath_rx_cleanup': drivers/net/wireless/ath/ath9k/recv.c:340: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `ath_rx_edma_buf_link': drivers/net/wireless/ath/ath9k/recv.c:122: undefined reference to `dma_sync_single_for_cpu' drivers/built-in.o: In function `ath_rx_tasklet': drivers/net/wireless/ath/ath9k/recv.c:1275: undefined reference to `dma_map_single' drivers/net/wireless/ath/ath9k/recv.c:1277: undefined reference to `dma_mapping_error' drivers/net/wireless/ath/ath9k/recv.c:1283: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `ath_rx_edma_init': drivers/net/wireless/ath/ath9k/recv.c:226: undefined reference to `dma_map_single' drivers/net/wireless/ath/ath9k/recv.c:229: undefined reference to `dma_mapping_error' drivers/built-in.o: In function `ath_rx_init': drivers/net/wireless/ath/ath9k/recv.c:303: undefined reference to `dma_map_single' drivers/net/wireless/ath/ath9k/recv.c:306: undefined reference to `dma_mapping_error' drivers/built-in.o: In function `ath_tx_complete_buf': drivers/net/wireless/ath/ath9k/xmit.c:2088: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `ath_txstatus_setup': drivers/net/wireless/ath/ath9k/xmit.c:2344: undefined reference to `dmam_alloc_coherent' drivers/built-in.o: In function `ath_tx_set_retry': drivers/net/wireless/ath/ath9k/xmit.c:307: undefined reference to `dma_sync_single_for_cpu' drivers/built-in.o: In function `ath_tx_setup_buffer': drivers/net/wireless/ath/ath9k/xmit.c:1887: undefined reference to `dma_map_single' drivers/net/wireless/ath/ath9k/xmit.c:1889: undefined reference to `dma_mapping_error' Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Cc: John W. Linville <linville@tuxdriver.com> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-05-17bcma: add more core IDsRafał Miłecki
PCIe and ARM CR4 cores were found on 14e4:43b1 AKA BCM4352. Reported-by: Gabriel Thörnblad <gabriel@thornblad.com> Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-05-17iwlegacy: remove inline marking of EXPORT_SYMBOL functionsDenis Efremov
EXPORT_SYMBOL and inline directives are contradictory to each other. The patch fixes this inconsistency. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Denis Efremov <yefremov.denis@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-05-17Merge branch 'for-john' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
2013-05-17arm64: debug: fix mdscr.ss check when enabling debug exceptionsWill Deacon
When we take an exception at EL1, we only want to enable debug exceptions if we're not currently stepping, otherwise we can easily get stuck in a loop stepping into interrupt handlers. Unfortunately, the current code tests the wrong bit in the mdscr, so fix that. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2013-05-17ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clockVaibhav Hiremath
It is required to enable respective clock-domain before enabling any clock/module inside that clock-domain. During common-clock migration, .clkdm_name field got missed for "clkdiv32k_ick" clock, which leaves "clk_24mhz_clkdm" unused; so it will be disabled even if childs of this clock-domain is enabled, which keeps child modules in idle mode. This fixes the kernel crash observed on AM335xEVM-SK platform, where clkdiv32_ick clock is being used as a gpio debounce clock and since clkdiv32k_ick is in idle mode it leads to below crash - Crash Log: ========== [ 2.598347] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa1ac150 [ 2.606434] Internal error: : 1028 [#1] SMP ARM [ 2.611207] Modules linked in: [ 2.614449] CPU: 0 Not tainted (3.8.4-01382-g1f449cd-dirty #4) [ 2.620973] PC is at _set_gpio_debounce+0x60/0x104 [ 2.626025] LR is at clk_enable+0x30/0x3c Cc: stable@vger.kernel.org # v3.9 Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-05-17ARM: mvebu: Fix ranges entry on XP GP boardEzequiel Garcia
With the latest device tree reorganization which introduced the 'internal-reg' node, now the only region translated is the internal register's. This makes the description of the hardware incomplete, for it lacks the Device Bus childs address space. In order to fix this, it's required to add a 'ranges' entry with a suitable address space to map Device Bus childs, on a per-board basis. This patch fixes the ranges property on the Armada XP GP board. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-05-17Merge tag 'sound-3.10' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A fairly calm update at this time, as seen in the short log, only one fix per person: including, - a few ASoC fixes (da7213 dmic, ux500 AD slot, wm0010 error path) - a copule of HD-audio fixes - a few other misc fixes (MIPS allmodconfig, proc output in usb, old PowerBook support)" * tag 'sound-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: usb-audio: proc: use found syncmaxsize to determine feedback format ALSA: hda - Add headset mic support for another Dell machine ALSA: snd-aoa: Add a layout entry for PowerBook6,5 ALSA: hda - Check the activity of the NID to be powered down sound: Fix make allmodconfig on MIPS correctly ASoC: da7213: Fix setting dmic_samplephase and dmic_clk_rate ASoC: ux500: Swap even/odd AD slot definitions ASoC: wm0010: fix error return code in wm0010_boot()
2013-05-17s390/pgtable: fix ipte notify bitChristian Borntraeger
Dont use the same bit as user referenced. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2013-05-17s390/xpram: mark xpram as non-rotationalChristian Borntraeger
xpram is a memory technology. Lets mark that as non-rotational. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-05-17s390/smp: fix cpu re-scan vs. cpu stateMartin Schwidefsky
The cpu-info array starts with a list of cpus in configured state, followed by the cpus in standby state. The comparison to decide which state a cpu has is incorrect, this causes configured cpus appear as standby cpus. The correct comparison is the index of the new cpu in the cpu-info array vs. the number of configured cpus. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-05-17kmemleak: No need for scanning specific module sectionsSteven Rostedt
As kmemleak now scans all module sections that are allocated, writable and non executable, there's no need to scan individual sections that might reference data. Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Rusty Russell <rusty@rustcorp.com.au>
2013-05-17kmemleak: Scan all allocated, writeable and not executable module sectionsSteven Rostedt
Instead of just picking data sections by name (names that start with .data, .bss or .ref.data), use the section flags and scan all sections that are allocated, writable and not executable. Which should cover all sections of a module that might reference data. Signed-off-by: Steven Rostedt <rostedt@goodmis.org> [catalin.marinas@arm.com: removed unused 'name' variable] [catalin.marinas@arm.com: collapsed 'if' blocks] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Rusty Russell <rusty@rustcorp.com.au>
2013-05-17i2c: designware: always clear interrupts before enabling themMika Westerberg
If the I2C bus is put to a low power state by an ACPI method it might pull the SDA line low (as its power is removed). Once the bus is put to full power state again, the SDA line is pulled back to high. This transition looks like a STOP condition from the controller point-of-view which sets STOP detected bit in its status register causing the driver to fail subsequent transfers. Fix this by always clearing all interrupts before we start a transfer. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
2013-05-17i2c: designware: fix RX FIFO overrunJosef Ahmad
i2c_dw_xfer_msg() pushes a number of bytes to transmit/receive to/from the bus into the TX FIFO. For master-rx transactions, the maximum amount of data that can be received is calculated depending solely on TX and RX FIFO load. This is racy - TX FIFO may contain master-rx data yet to be processed, which will eventually land into the RX FIFO. This data is not taken into account and the function may request more data than the controller is actually capable of storing. This patch ensures the driver takes into account the outstanding master-rx data in TX FIFO to prevent RX FIFO overrun. Signed-off-by: Josef Ahmad <josef.ahmad@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org