devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Stephen Warren <swarren@nvidia.com>
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Stephen Warren <swarren@nvidia.com>
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Btrfs has been pointer tagging bi_private and using bi_bdev
to store the stripe index and mirror number of failed IOs.
As bios bubble back up through the call chain, we use these
to decide if and how to retry our IOs. They are also used
to count IO failures on a per device basis.
Recently a bio tracepoint was added lead to crashes because
we were abusing bi_bdev.
This commit adds a btrfs bioset, and creates explicit fields
for the mirror number and stripe index. The plan is to
extend this structure for all of the fields currently in
struct btrfs_bio, which will mean one less kmalloc in
our IO path.
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Reported-by: Tejun Heo <tj@kernel.org>
If we fail to load the chunk tree we'll call free_root_pointers, except we may
not have assigned the roots for the dev_root/extent_root/csum_root yet, so we
could NULL pointer deref at this point. Just add checks to make sure these
roots are set to keep us from panicing. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
The quota_tree was set up to use the empty_block_rsv before
which would be problematic when the filesystem is filled up
and ENOSPC happens during internal operations while the quota
tree is updated and COWed (when the btrfs_qgroup_info_item
items) are written. In fact, use_block_rsv() which is used
in btrfs_cow_block() falls back to the global_block_rsv in
this case. But just in order to make it more clear what is
happening, change it to explicitly use the global_block_rsv.
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
end_bio_extent_readpage computes whole_page based on bv_offset and
bv_len, without taking into account that blk_update_request may modify
them when some of the blocks to be read into a page produce a read
error. This would cause the read to unlock only part of the file
range associated with the page, which would in turn leave the entire
page locked, which would not only keep the process blocked instead of
returning -EIO to it, but also prevent any further access to the file.
It turns out that btrfs always issues whole-page reads and writes.
The special handling of non-whole_page appears to be a mistake or a
left-over from a time when this wasn't the case. Indeed,
end_bio_extent_writepage distinguished between whole_page and
non-whole_page writes but behaved identically in both cases!
I've replaced the whole_page computations with warnings, just to be
sure that we're not issuing partial page reads or writes. The
warnings should probably just go away some time.
Signed-off-by: Alexandre Oliva <oliva@gnu.org>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
btrfs_invalidate_inodes() may sleep, so we should not invoke it in the
spin lock context. Fix it.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
We have checked if ->node is NULL or not, so it is unnecessary to
use BUG_ON() to check again. Remove it.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
The root node of the rb-tree may be changed, so we should get it under
the lock. Fix it.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
inode_tree_del() will move the tree root into the dead root list, and
then the tree will be destroyed by the cleaner. So if we remove the
delayed node which is cached in the inode after inode_tree_del(),
we may access a freed tree root. Fix it.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
We need to set return value explicitly, otherwise we'll lose the error
value.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Before applying this patch, we reserved the space for the global reserve
by the minimum unit if we found it is empty, it was unreasonable and
inefficient, because if the global reserve space was depleted, it implied
that the size of the global reserve was too small. In this case, we shoud
update the global reserve and fill it.
Cc: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
If the type of the space we need is different with the global reserve, we
can not steal the space from the global reserve, because we can not allocate
the space from the free space cache that the global reserve points to.
Cc: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
It is very likely that there are lots of subvolumes/snapshots in the filesystem,
so if we use global block reservation to do inode cache truncation, we may hog
all the free space that is reserved in global rsv. So it is better that we do
the free space reservation for inode cache truncation by ourselves.
Cc: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
i2c: suppress lockdep warning on delete_device
Since commit 846f99749a 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 356c05d58a 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>
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>
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>
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>
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>
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>
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+
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>
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>
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>
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>
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>
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>
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)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJRlf1dAAoJEGwxgFQ9KSmkkN4P/R+JSjE7igXAARpCzBZUNHRX
XpTEs/6wSHVujo5KNhe3KN+F/1WHxVJu8x9kPIkZCGmWvLRS/y1XKgDgJjqRPYqO
Sx47G6ZIXDyn7KUFnEOZnE7j9kmwxezL4TE9k4vMfxGPINVNX8hvSpsXMwwCtZZL
1IUFbV305yvjrcerffQBUVhLcPb8Z3/rYmEZsOD0ITzoww6Z2K7bNPqDEKYlav0r
cuVLRX1Tc38j4BdHBsuaOmTlYdB7UWjfmYfVhAhyDu72F46RUBQhoncGyfyayvg4
uqkSKBRCM7APjuc5zYyO70C5ZB3dt8EXuF45/Np6rllqL9luNYsqFXO/TtrfFoz/
PFCxWW89+203GEcAn5IMn2k/eDX+dv9V0mc+TuhvGXC+Dls/DPz8o/BZ1ELnqKOu
y+YENGIIA72OteP2JEi8Q0VmmRh9PN0Eg2b72AnOyrSzs4+8s8I09Nt86I7jN/ya
ROLlR7B2cG+Zop58mqMceN3GAs9UvWLzKAeVhxVf1+UOFSiJsmcmiH25Rj72uKOG
yRW36ShCxu0xMr+RgiiGI1jdpqzYLQ0aEVxTpnexIi+ibGbmns5GT+z+VMJfT9Uz
5QfXmJd6kxeyomjdiCzqT42wEJsFgRNoNjL+NPLFPPWKZ3PrAEQl3/hAX4Qe4g2h
WAwJn9WrjLuWuRxVErCe
=p+Ok
-----END PGP SIGNATURE-----
Merge tag 'sound-3.10' of 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()
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>
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>
