aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-01-31net: mii_timestamper: fix static allocation by PHY driverMichael Walle2-1/+14
If phydev->mii_ts is set by the PHY driver, it will always be overwritten in of_mdiobus_register_phy(). Fix it. Also make sure, that the unregister() doesn't do anything if the mii_timestamper was provided by the PHY driver. Fixes: 1dca22b18421 ("net: mdio: of: Register discovered MII time stampers.") Signed-off-by: Michael Walle <[email protected]> Acked-by: Richard Cochran <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-01-31net: mdio: of: fix potential NULL pointer derefernceMichael Walle1-3/+6
of_find_mii_timestamper() returns NULL if no timestamper is found. Therefore, guard the unregister_mii_timestamper() calls. Fixes: 1dca22b18421 ("net: mdio: of: Register discovered MII time stampers.") Signed-off-by: Michael Walle <[email protected]> Acked-by: Richard Cochran <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-01-31ALSA: pcm: Fix sparse warnings wrt snd_pcm_state_tTakashi Iwai3-72/+127
Since we have a bitwise definition of snd_pcm_state_t and use it for certain struct fields, a few new (and years old) sparse warnings came up. This patch is an attempt to cover them. - The state fields in snd_pcm_mmap_status* and co are all defined as snd_pcm_state_t type now - The PCM action callbacks take snd_pcm_state_t argument as well; some actions taking special values got the explicit cast and comments - For the PCM action that doesn't need an extra argument receives ACTION_ARG_IGNORE instead of ambiguous 0 While we're at it, the boolean argument is also properly changed to bool and true/false, as well as a slight refactoring of PCM pause helper function to make easier to read. No functional changes, just shutting up chatty sparse. Fixes: 46b770f720bd ("ALSA: uapi: Fix sparse warning") Reported-by: kbuild test robot <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-01-31Btrfs: send, fix emission of invalid clone operations within the same fileFilipe Manana1-1/+2
When doing an incremental send and a file has extents shared with itself at different file offsets, it's possible for send to emit clone operations that will fail at the destination because the source range goes beyond the file's current size. This happens when the file size has increased in the send snapshot, there is a hole between the shared extents and both shared extents are at file offsets which are greater the file's size in the parent snapshot. Example: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt/sdb $ xfs_io -f -c "pwrite -S 0xf1 0 64K" /mnt/sdb/foobar $ btrfs subvolume snapshot -r /mnt/sdb /mnt/sdb/base $ btrfs send -f /tmp/1.snap /mnt/sdb/base # Create a 320K extent at file offset 512K. $ xfs_io -c "pwrite -S 0xab 512K 64K" /mnt/sdb/foobar $ xfs_io -c "pwrite -S 0xcd 576K 64K" /mnt/sdb/foobar $ xfs_io -c "pwrite -S 0xef 640K 64K" /mnt/sdb/foobar $ xfs_io -c "pwrite -S 0x64 704K 64K" /mnt/sdb/foobar $ xfs_io -c "pwrite -S 0x73 768K 64K" /mnt/sdb/foobar # Clone part of that 320K extent into a lower file offset (192K). # This file offset is greater than the file's size in the parent # snapshot (64K). Also the clone range is a bit behind the offset of # the 320K extent so that we leave a hole between the shared extents. $ xfs_io -c "reflink /mnt/sdb/foobar 448K 192K 192K" /mnt/sdb/foobar $ btrfs subvolume snapshot -r /mnt/sdb /mnt/sdb/incr $ btrfs send -p /mnt/sdb/base -f /tmp/2.snap /mnt/sdb/incr $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt/sdc $ btrfs receive -f /tmp/1.snap /mnt/sdc $ btrfs receive -f /tmp/2.snap /mnt/sdc ERROR: failed to clone extents to foobar: Invalid argument The problem is that after processing the extent at file offset 256K, which refers to the first 128K of the 320K extent created by the buffered write operations, we have 'cur_inode_next_write_offset' set to 384K, which corresponds to the end offset of the partially shared extent (256K + 128K) and to the current file size in the receiver. Then when we process the extent at offset 512K, we do extent backreference iteration to figure out if we can clone the extent from some other inode or from the same inode, and we consider the extent at offset 256K of the same inode as a valid source for a clone operation, which is not correct because at that point the current file size in the receiver is 384K, which corresponds to the end of last processed extent (at file offset 256K), so using a clone source range from 256K to 256K + 320K is invalid because that goes past the current size of the file (384K) - this makes the receiver get an -EINVAL error when attempting the clone operation. So fix this by excluding clone sources that have a range that goes beyond the current file size in the receiver when iterating extent backreferences. A test case for fstests follows soon. Fixes: 11f2069c113e02 ("Btrfs: send, allow clone operations within the same file") CC: [email protected] # 5.5+ Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: David Sterba <[email protected]>
2020-01-31btrfs: do not do delalloc reservation under page lockJosef Bacik1-16/+60
We ran into a deadlock in production with the fixup worker. The stack traces were as follows: Thread responsible for the writeout, waiting on the page lock [<0>] io_schedule+0x12/0x40 [<0>] __lock_page+0x109/0x1e0 [<0>] extent_write_cache_pages+0x206/0x360 [<0>] extent_writepages+0x40/0x60 [<0>] do_writepages+0x31/0xb0 [<0>] __writeback_single_inode+0x3d/0x350 [<0>] writeback_sb_inodes+0x19d/0x3c0 [<0>] __writeback_inodes_wb+0x5d/0xb0 [<0>] wb_writeback+0x231/0x2c0 [<0>] wb_workfn+0x308/0x3c0 [<0>] process_one_work+0x1e0/0x390 [<0>] worker_thread+0x2b/0x3c0 [<0>] kthread+0x113/0x130 [<0>] ret_from_fork+0x35/0x40 [<0>] 0xffffffffffffffff Thread of the fixup worker who is holding the page lock [<0>] start_delalloc_inodes+0x241/0x2d0 [<0>] btrfs_start_delalloc_roots+0x179/0x230 [<0>] btrfs_alloc_data_chunk_ondemand+0x11b/0x2e0 [<0>] btrfs_check_data_free_space+0x53/0xa0 [<0>] btrfs_delalloc_reserve_space+0x20/0x70 [<0>] btrfs_writepage_fixup_worker+0x1fc/0x2a0 [<0>] normal_work_helper+0x11c/0x360 [<0>] process_one_work+0x1e0/0x390 [<0>] worker_thread+0x2b/0x3c0 [<0>] kthread+0x113/0x130 [<0>] ret_from_fork+0x35/0x40 [<0>] 0xffffffffffffffff Thankfully the stars have to align just right to hit this. First you have to end up in the fixup worker, which is tricky by itself (my reproducer does DIO reads into a MMAP'ed region, so not a common operation). Then you have to have less than a page size of free data space and 0 unallocated space so you go down the "commit the transaction to free up pinned space" path. This was accomplished by a random balance that was running on the host. Then you get this deadlock. I'm still in the process of trying to force the deadlock to happen on demand, but I've hit other issues. I can still trigger the fixup worker path itself so this patch has been tested in that regard, so the normal case is fine. Fixes: 87826df0ec36 ("btrfs: delalloc for page dirtied out-of-band in fixup worker") Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2020-01-31btrfs: drop the -EBUSY case in __extent_writepage_ioJosef Bacik1-5/+1
Now that we only return 0 or -EAGAIN from btrfs_writepage_cow_fixup, we do not need this -EBUSY case. Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2020-01-31Btrfs: keep pages dirty when using btrfs_writepage_fixup_workerChris Mason1-17/+44
For COW, btrfs expects pages dirty pages to have been through a few setup steps. This includes reserving space for the new block allocations and marking the range in the state tree for delayed allocation. A few places outside btrfs will dirty pages directly, especially when unmapping mmap'd pages. In order for these to properly go through COW, we run them through a fixup worker to wait for stable pages, and do the delalloc prep. 87826df0ec36 added a window where the dirty pages were cleaned, but pending more action from the fixup worker. We clear_page_dirty_for_io() before we call into writepage, so the page is no longer dirty. The commit changed it so now we leave the page clean between unlocking it here and the fixup worker starting at some point in the future. During this window, page migration can jump in and relocate the page. Once our fixup work actually starts, it finds page->mapping is NULL and we end up freeing the page without ever writing it. This leads to crc errors and other exciting problems, since it screws up the whole statemachine for waiting for ordered extents. The fix here is to keep the page dirty while we're waiting for the fixup worker to get to work. This is accomplished by returning -EAGAIN from btrfs_writepage_cow_fixup if we queued the page up for fixup, which will cause the writepage function to redirty the page. Because we now expect the page to be dirty once it gets to the fixup worker we must adjust the error cases to call clear_page_dirty_for_io() on the page. That is the bulk of the patch, but it is not the fix, the fix is the -EAGAIN from btrfs_writepage_cow_fixup. We cannot separate these two changes out because the error conditions change with the new expectations. Signed-off-by: Chris Mason <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2020-01-31btrfs: take overcommit into account in inc_block_group_roJosef Bacik3-19/+39
inc_block_group_ro does a calculation to see if we have enough room left over if we mark this block group as read only in order to see if it's ok to mark the block group as read only. The problem is this calculation _only_ works for data, where our used is always less than our total. For metadata we will overcommit, so this will almost always fail for metadata. Fix this by exporting btrfs_can_overcommit, and then see if we have enough space to remove the remaining free space in the block group we are trying to mark read only. If we do then we can mark this block group as read only. Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2020-01-31btrfs: fix force usage in inc_block_group_roJosef Bacik1-2/+2
For some reason we've translated the do_chunk_alloc that goes into btrfs_inc_block_group_ro to force in inc_block_group_ro, but these are two different things. force for inc_block_group_ro is used when we are forcing the block group read only no matter what, for example when the underlying chunk is marked read only. We need to not do the space check here as this block group needs to be read only. btrfs_inc_block_group_ro() has a do_chunk_alloc flag that indicates that we need to pre-allocate a chunk before marking the block group read only. This has nothing to do with forcing, and in fact we _always_ want to do the space check in this case, so unconditionally pass false for force in this case. Then fixup inc_block_group_ro to honor force as it's expected and documented to do. Reviewed-by: Nikolay Borisov <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2020-01-31btrfs: Correctly handle empty trees in find_first_clear_extent_bitNikolay Borisov2-14/+27
Raviu reported that running his regular fs_trim segfaulted with the following backtrace: [ 237.525947] assertion failed: prev, in ../fs/btrfs/extent_io.c:1595 [ 237.525984] ------------[ cut here ]------------ [ 237.525985] kernel BUG at ../fs/btrfs/ctree.h:3117! [ 237.525992] invalid opcode: 0000 [#1] SMP PTI [ 237.525998] CPU: 4 PID: 4423 Comm: fstrim Tainted: G U OE 5.4.14-8-vanilla #1 [ 237.526001] Hardware name: ASUSTeK COMPUTER INC. [ 237.526044] RIP: 0010:assfail.constprop.58+0x18/0x1a [btrfs] [ 237.526079] Call Trace: [ 237.526120] find_first_clear_extent_bit+0x13d/0x150 [btrfs] [ 237.526148] btrfs_trim_fs+0x211/0x3f0 [btrfs] [ 237.526184] btrfs_ioctl_fitrim+0x103/0x170 [btrfs] [ 237.526219] btrfs_ioctl+0x129a/0x2ed0 [btrfs] [ 237.526227] ? filemap_map_pages+0x190/0x3d0 [ 237.526232] ? do_filp_open+0xaf/0x110 [ 237.526238] ? _copy_to_user+0x22/0x30 [ 237.526242] ? cp_new_stat+0x150/0x180 [ 237.526247] ? do_vfs_ioctl+0xa4/0x640 [ 237.526278] ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs] [ 237.526283] do_vfs_ioctl+0xa4/0x640 [ 237.526288] ? __do_sys_newfstat+0x3c/0x60 [ 237.526292] ksys_ioctl+0x70/0x80 [ 237.526297] __x64_sys_ioctl+0x16/0x20 [ 237.526303] do_syscall_64+0x5a/0x1c0 [ 237.526310] entry_SYSCALL_64_after_hwframe+0x49/0xbe That was due to btrfs_fs_device::aloc_tree being empty. Initially I thought this wasn't possible and as a percaution have put the assert in find_first_clear_extent_bit. Turns out this is indeed possible and could happen when a file system with SINGLE data/metadata profile has a 2nd device added. Until balance is run or a new chunk is allocated on this device it will be completely empty. In this case find_first_clear_extent_bit should return the full range [0, -1ULL] and let the caller handle this i.e for trim the end will be capped at the size of actual device. Link: https://lore.kernel.org/linux-btrfs/izW2WNyvy1dEDweBICizKnd2KDwDiDyY2EYQr4YCwk7pkuIpthx-JRn65MPBde00ND6V0_Lh8mW0kZwzDiLDv25pUYWxkskWNJnVP0kgdMA=@protonmail.com/ Fixes: 45bfcfc168f8 ("btrfs: Implement find_first_clear_extent_bit") CC: [email protected] # 5.2+ Signed-off-by: Nikolay Borisov <[email protected]> Signed-off-by: David Sterba <[email protected]>
2020-01-31btrfs: flush write bio if we loop in extent_write_cache_pagesJosef Bacik1-1/+10
There exists a deadlock with range_cyclic that has existed forever. If we loop around with a bio already built we could deadlock with a writer who has the page locked that we're attempting to write but is waiting on a page in our bio to be written out. The task traces are as follows PID: 1329874 TASK: ffff889ebcdf3800 CPU: 33 COMMAND: "kworker/u113:5" #0 [ffffc900297bb658] __schedule at ffffffff81a4c33f #1 [ffffc900297bb6e0] schedule at ffffffff81a4c6e3 #2 [ffffc900297bb6f8] io_schedule at ffffffff81a4ca42 #3 [ffffc900297bb708] __lock_page at ffffffff811f145b #4 [ffffc900297bb798] __process_pages_contig at ffffffff814bc502 #5 [ffffc900297bb8c8] lock_delalloc_pages at ffffffff814bc684 #6 [ffffc900297bb900] find_lock_delalloc_range at ffffffff814be9ff #7 [ffffc900297bb9a0] writepage_delalloc at ffffffff814bebd0 #8 [ffffc900297bba18] __extent_writepage at ffffffff814bfbf2 #9 [ffffc900297bba98] extent_write_cache_pages at ffffffff814bffbd PID: 2167901 TASK: ffff889dc6a59c00 CPU: 14 COMMAND: "aio-dio-invalid" #0 [ffffc9003b50bb18] __schedule at ffffffff81a4c33f #1 [ffffc9003b50bba0] schedule at ffffffff81a4c6e3 #2 [ffffc9003b50bbb8] io_schedule at ffffffff81a4ca42 #3 [ffffc9003b50bbc8] wait_on_page_bit at ffffffff811f24d6 #4 [ffffc9003b50bc60] prepare_pages at ffffffff814b05a7 #5 [ffffc9003b50bcd8] btrfs_buffered_write at ffffffff814b1359 #6 [ffffc9003b50bdb0] btrfs_file_write_iter at ffffffff814b5933 #7 [ffffc9003b50be38] new_sync_write at ffffffff8128f6a8 #8 [ffffc9003b50bec8] vfs_write at ffffffff81292b9d #9 [ffffc9003b50bf00] ksys_pwrite64 at ffffffff81293032 I used drgn to find the respective pages we were stuck on page_entry.page 0xffffea00fbfc7500 index 8148 bit 15 pid 2167901 page_entry.page 0xffffea00f9bb7400 index 7680 bit 0 pid 1329874 As you can see the kworker is waiting for bit 0 (PG_locked) on index 7680, and aio-dio-invalid is waiting for bit 15 (PG_writeback) on index 8148. aio-dio-invalid has 7680, and the kworker epd looks like the following crash> struct extent_page_data ffffc900297bbbb0 struct extent_page_data { bio = 0xffff889f747ed830, tree = 0xffff889eed6ba448, extent_locked = 0, sync_io = 0 } Probably worth mentioning as well that it waits for writeback of the page to complete while holding a lock on it (at prepare_pages()). Using drgn I walked the bio pages looking for page 0xffffea00fbfc7500 which is the one we're waiting for writeback on bio = Object(prog, 'struct bio', address=0xffff889f747ed830) for i in range(0, bio.bi_vcnt.value_()): bv = bio.bi_io_vec[i] if bv.bv_page.value_() == 0xffffea00fbfc7500: print("FOUND IT") which validated what I suspected. The fix for this is simple, flush the epd before we loop back around to the beginning of the file during writeout. Fixes: b293f02e1423 ("Btrfs: Add writepages support") CC: [email protected] # 4.4+ Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: David Sterba <[email protected]>
2020-01-31Btrfs: fix race between adding and putting tree mod seq elements and nodesFilipe Manana5-16/+8
There is a race between adding and removing elements to the tree mod log list and rbtree that can lead to use-after-free problems. Consider the following example that explains how/why the problems happens: 1) Task A has mod log element with sequence number 200. It currently is the only element in the mod log list; 2) Task A calls btrfs_put_tree_mod_seq() because it no longer needs to access the tree mod log. When it enters the function, it initializes 'min_seq' to (u64)-1. Then it acquires the lock 'tree_mod_seq_lock' before checking if there are other elements in the mod seq list. Since the list it empty, 'min_seq' remains set to (u64)-1. Then it unlocks the lock 'tree_mod_seq_lock'; 3) Before task A acquires the lock 'tree_mod_log_lock', task B adds itself to the mod seq list through btrfs_get_tree_mod_seq() and gets a sequence number of 201; 4) Some other task, name it task C, modifies a btree and because there elements in the mod seq list, it adds a tree mod elem to the tree mod log rbtree. That node added to the mod log rbtree is assigned a sequence number of 202; 5) Task B, which is doing fiemap and resolving indirect back references, calls btrfs get_old_root(), with 'time_seq' == 201, which in turn calls tree_mod_log_search() - the search returns the mod log node from the rbtree with sequence number 202, created by task C; 6) Task A now acquires the lock 'tree_mod_log_lock', starts iterating the mod log rbtree and finds the node with sequence number 202. Since 202 is less than the previously computed 'min_seq', (u64)-1, it removes the node and frees it; 7) Task B still has a pointer to the node with sequence number 202, and it dereferences the pointer itself and through the call to __tree_mod_log_rewind(), resulting in a use-after-free problem. This issue can be triggered sporadically with the test case generic/561 from fstests, and it happens more frequently with a higher number of duperemove processes. When it happens to me, it either freezes the VM or it produces a trace like the following before crashing: [ 1245.321140] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI [ 1245.321200] CPU: 1 PID: 26997 Comm: pool Not tainted 5.5.0-rc6-btrfs-next-52 #1 [ 1245.321235] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 [ 1245.321287] RIP: 0010:rb_next+0x16/0x50 [ 1245.321307] Code: .... [ 1245.321372] RSP: 0018:ffffa151c4d039b0 EFLAGS: 00010202 [ 1245.321388] RAX: 6b6b6b6b6b6b6b6b RBX: ffff8ae221363c80 RCX: 6b6b6b6b6b6b6b6b [ 1245.321409] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8ae221363c80 [ 1245.321439] RBP: ffff8ae20fcc4688 R08: 0000000000000002 R09: 0000000000000000 [ 1245.321475] R10: ffff8ae20b120910 R11: 00000000243f8bb1 R12: 0000000000000038 [ 1245.321506] R13: ffff8ae221363c80 R14: 000000000000075f R15: ffff8ae223f762b8 [ 1245.321539] FS: 00007fdee1ec7700(0000) GS:ffff8ae236c80000(0000) knlGS:0000000000000000 [ 1245.321591] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1245.321614] CR2: 00007fded4030c48 CR3: 000000021da16003 CR4: 00000000003606e0 [ 1245.321642] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1245.321668] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1245.321706] Call Trace: [ 1245.321798] __tree_mod_log_rewind+0xbf/0x280 [btrfs] [ 1245.321841] btrfs_search_old_slot+0x105/0xd00 [btrfs] [ 1245.321877] resolve_indirect_refs+0x1eb/0xc60 [btrfs] [ 1245.321912] find_parent_nodes+0x3dc/0x11b0 [btrfs] [ 1245.321947] btrfs_check_shared+0x115/0x1c0 [btrfs] [ 1245.321980] ? extent_fiemap+0x59d/0x6d0 [btrfs] [ 1245.322029] extent_fiemap+0x59d/0x6d0 [btrfs] [ 1245.322066] do_vfs_ioctl+0x45a/0x750 [ 1245.322081] ksys_ioctl+0x70/0x80 [ 1245.322092] ? trace_hardirqs_off_thunk+0x1a/0x1c [ 1245.322113] __x64_sys_ioctl+0x16/0x20 [ 1245.322126] do_syscall_64+0x5c/0x280 [ 1245.322139] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1245.322155] RIP: 0033:0x7fdee3942dd7 [ 1245.322177] Code: .... [ 1245.322258] RSP: 002b:00007fdee1ec6c88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 1245.322294] RAX: ffffffffffffffda RBX: 00007fded40210d8 RCX: 00007fdee3942dd7 [ 1245.322314] RDX: 00007fded40210d8 RSI: 00000000c020660b RDI: 0000000000000004 [ 1245.322337] RBP: 0000562aa89e7510 R08: 0000000000000000 R09: 00007fdee1ec6d44 [ 1245.322369] R10: 0000000000000073 R11: 0000000000000246 R12: 00007fdee1ec6d48 [ 1245.322390] R13: 00007fdee1ec6d40 R14: 00007fded40210d0 R15: 00007fdee1ec6d50 [ 1245.322423] Modules linked in: .... [ 1245.323443] ---[ end trace 01de1e9ec5dff3cd ]--- Fix this by ensuring that btrfs_put_tree_mod_seq() computes the minimum sequence number and iterates the rbtree while holding the lock 'tree_mod_log_lock' in write mode. Also get rid of the 'tree_mod_seq_lock' lock, since it is now redundant. Fixes: bd989ba359f2ac ("Btrfs: add tree modification log functions") Fixes: 097b8a7c9e48e2 ("Btrfs: join tree mod log code with the code holding back delayed refs") CC: [email protected] # 4.4+ Reviewed-by: Josef Bacik <[email protected]> Reviewed-by: Nikolay Borisov <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: David Sterba <[email protected]>
2020-01-31selftests: KVM: testing the local IRQs resetsPierre Morel1-0/+42
Local IRQs are reset by a normal cpu reset. The initial cpu reset and the clear cpu reset, as superset of the normal reset, both clear the IRQs too. Let's inject an interrupt to a vCPU before calling a reset and see if it is gone after the reset. We choose to inject only an emergency interrupt at this point and can extend the test to other types of IRQs later. Signed-off-by: Pierre Morel <[email protected]> Signed-off-by: Janosch Frank <[email protected]> [minor fixups] Reviewed-by: Cornelia Huck <[email protected]> Reviewed-by: Thomas Huth <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Borntraeger <[email protected]>
2020-01-31selftests: KVM: s390x: Add reset testsJanosch Frank2-0/+156
Test if the registers end up having the correct values after a normal, initial and clear reset. Signed-off-by: Janosch Frank <[email protected]> Reviewed-by: Thomas Huth <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Borntraeger <[email protected]>
2020-01-31selftests: KVM: Add fpu and one reg set/get library functionsJanosch Frank2-0/+42
Add library access to more registers. Signed-off-by: Janosch Frank <[email protected]> Reviewed-by: Thomas Huth <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Borntraeger <[email protected]>
2020-01-31KVM: s390: Add new reset vcpu APIJanosch Frank3-27/+105
The architecture states that we need to reset local IRQs for all CPU resets. Because the old reset interface did not support the normal CPU reset we never did that on a normal reset. Let's implement an interface for the missing normal and clear resets and reset all local IRQs, registers and control structures as stated in the architecture. Userspace might already reset the registers via the vcpu run struct, but as we need the interface for the interrupt clearing part anyway, we implement the resets fully and don't rely on userspace to reset the rest. Signed-off-by: Janosch Frank <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Reviewed-by: Christian Borntraeger <[email protected]> Reviewed-by: Thomas Huth <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Borntraeger <[email protected]>
2020-01-31KVM: s390: Cleanup initial cpu resetJanosch Frank2-11/+12
The code seems to be quite old and uses lots of unneeded spaces for alignment, which doesn't really help with readability. Let's: * Get rid of the extra spaces * Remove the ULs as they are not needed on 0s * Define constants for the CR 0 and 14 initial values * Use the sizeof of the gcr array to memset it to 0 Signed-off-by: Janosch Frank <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Reviewed-by: Thomas Huth <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Borntraeger <[email protected]>
2020-01-31KVM: s390: do not clobber registers during guest reset/store statusChristian Borntraeger1-4/+2
The initial CPU reset clobbers the userspace fpc and the store status ioctl clobbers the guest acrs + fpr. As these calls are only done via ioctl (and not via vcpu_run), no CPU context is loaded, so we can (and must) act directly on the sync regs, not on the thread context. Cc: [email protected] Fixes: e1788bb995be ("KVM: s390: handle floating point registers in the run ioctl not in vcpu_put/load") Fixes: 31d8b8d41a7e ("KVM: s390: handle access registers in the run ioctl not in vcpu_put/load") Signed-off-by: Christian Borntraeger <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Janosch Frank <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Borntraeger <[email protected]>
2020-01-31KVM: s390: ENOTSUPP -> EOPNOTSUPP fixupsChristian Borntraeger1-3/+3
There is no ENOTSUPP for userspace. Reported-by: Julian Wiedmann <[email protected]> Fixes: 519783935451 ("KVM: s390: introduce ais mode modify function") Fixes: 2c1a48f2e5ed ("KVM: S390: add new group for flic") Reviewed-by: Cornelia Huck <[email protected]> Reviewed-by: Thomas Huth <[email protected]> Signed-off-by: Christian Borntraeger <[email protected]>
2020-01-31powerpc: configs: Cleanup old Kconfig optionsKrzysztof Kozlowski11-14/+0
CONFIG_ENABLE_WARN_DEPRECATED is gone since commit 771c035372a0 ("deprecate the '__deprecated' attribute warnings entirely and for good"). CONFIG_IOSCHED_DEADLINE and CONFIG_IOSCHED_CFQ are gone since commit f382fb0bcef4 ("block: remove legacy IO schedulers"). The IOSCHED_DEADLINE was replaced by MQ_IOSCHED_DEADLINE and it will be now enabled by default (along with MQ_IOSCHED_KYBER). Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-31powerpc/configs/skiroot: Enable some more hardening optionsMichael Ellerman1-0/+8
Enable more hardening options. Note BUG_ON_DATA_CORRUPTION selects DEBUG_LIST and is essentially just a synonym for it. DEBUG_SG, DEBUG_NOTIFIERS, DEBUG_LIST, DEBUG_CREDENTIALS and SCHED_STACK_END_CHECK should all be low overhead and just add a few extra checks. SLAB_FREELIST_RANDOM, and SLUB_DEBUG_ON will add some overhead to the SLAB allocator, but nothing that should be meaningful for skiroot. Unselecting SLAB_MERGE_DEFAULT causes the SLAB to use more memory, but the skiroot kernel shouldn't be memory constrained on any of our systems, all it does is run a small bootloader. Disabling merging has some security/robustness benefit as it means a user-after-free or overflow will be limited to the objects in that slab, rather than potentially affecting objects from unrelated slabs that have been merged. Note also that slab merging is disabled anyway by enabling SLUB_DEBUG_ON, because of the SLAB_NEVER_MERGE mask. Signed-off-by: Michael Ellerman <[email protected]> Acked-by: Joel Stanley <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-31powerpc/configs/skiroot: Disable xmon default & enable reboot on panicMichael Ellerman1-1/+2
If the skiroot kernel crashes we don't want it sitting at an xmon prompt forever. Instead it's more helpful to reboot and bring the boot loader back up, and if the crash was transient we can then boot successfully. Similarly if we panic we should reboot, with a short timeout in case someone is watching the console. Signed-off-by: Michael Ellerman <[email protected]> Acked-by: Joel Stanley <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-31powerpc/configs/skiroot: Enable security featuresJoel Stanley1-1/+11
This turns on HARDENED_USERCOPY with HARDENED_USERCOPY_PAGESPAN, and FORTIFY_SOURCE. It also enables SECURITY_LOCKDOWN_LSM with _EARLY and LOCK_DOWN_KERNEL_FORCE_INTEGRITY options enabled. This still allows xmon to be used in read-only mode. MODULE_SIG is selected by lockdown, so it is still enabled. Because we're setting LOCK_DOWN_KERNELFORCE_INTEGRITY=y we also need to enable KEXEC_FILE=y so that kexec continues to work. Signed-off-by: Joel Stanley <[email protected]> [mpe: Switch to lockdown integrity mode per oohal, enable KEXEC_FILE as reported by jms] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-31powerpc/configs/skiroot: Update for symbol movement onlyMichael Ellerman1-21/+21
Signed-off-by: Michael Ellerman <[email protected]> Acked-by: Joel Stanley <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-31powerpc/configs/skiroot: Drop default n CONFIG_CRYPTO_ECHAINIVMichael Ellerman1-1/+0
It's default n so we don't need to disable it. Signed-off-by: Michael Ellerman <[email protected]> Acked-by: Joel Stanley <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-31powerpc/configs/skiroot: Drop HID_LOGITECHMichael Ellerman1-1/+0
Commit bdd08fff4915 ("HID: logitech: Add depends on LEDS_CLASS to Logitech Kconfig entry") made HID_LOGITECH depend on LEDS_CLASS which we do not enable, meaning we are not actually enabling those drivers any more. The Kconfig help text suggests USB HID compliant Logictech devices will continue to work without HID_LOGITECH, so just drop it. Signed-off-by: Michael Ellerman <[email protected]> Acked-by: Joel Stanley <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-31powerpc/configs: Drop NET_VENDOR_HP which moved to stagingMichael Ellerman2-2/+0
The HP network driver moved to staging in commit 52340b82cf1a ("hp100: Move 100BaseVG AnyLAN driver to staging") meaning we don't need to disable it any more in our defconfigs. Signed-off-by: Michael Ellerman <[email protected]> Acked-by: Joel Stanley <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-31powerpc/configs: NET_CADENCE became NET_VENDOR_CADENCEMichael Ellerman1-1/+0
The NET_CADENCE symbol was renamed to NET_VENDOR_CADENCE, so we don't need to disable the former, see commit 0df5f81c481e ("net: ethernet: Add missing VENDOR to Cadence and Packet Engines symbols"). Signed-off-by: Michael Ellerman <[email protected]> Acked-by: Joel Stanley <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-31powerpc/configs: Drop CONFIG_QLGE which moved to stagingMichael Ellerman5-5/+0
The QLGE driver moved to staging in commit 955315b0dc8c ("qlge: Move drivers/net/ethernet/qlogic/qlge/ to drivers/staging/qlge/"), meaning our defconfigs that enable it have no effect as we don't enable CONFIG_STAGING. It sounds like the device is obsolete, so drop the driver. Signed-off-by: Michael Ellerman <[email protected]> Acked-by: Joel Stanley <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-31power: avs: qcom-cpr: Avoid clang -Wsometimes-uninitialized in cpr_scaleNathan Chancellor1-2/+2
Clang warns (trimmed for brevity): ../drivers/power/avs/qcom-cpr.c:570:13: warning: variable 'reg_mask' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] ../drivers/power/avs/qcom-cpr.c:520:13: warning: variable 'new_uV' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] Due to the fact that Clang's static analysis happens before any optimization passes are taken into account, it cannot see that both branches in the if statement must be taken because dir cannot be something other than UP or DOWN due to the check at the top of this function. Change the else if condition to else to fix this false positive. Fixes: bf6910abf548 ("power: avs: Add support for CPR (Core Power Reduction)") Link: https://github.com/ClangBuiltLinux/linux/issues/840 Signed-off-by: Nathan Chancellor <[email protected]> Acked-by: Kevin Hilman <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-01-31power: avs: qcom-cpr: add unspecified HAS_IOMEM dependencyBrendan Higgins1-1/+1
Currently CONFIG_QCOM_CPR=y implicitly depends on CONFIG_HAS_IOMEM=y; consequently, on architectures without IOMEM we get the following build error: /usr/bin/ld: drivers/power/avs/qcom-cpr.o: in function `cpr_probe': drivers/power/avs/qcom-cpr.c:1690: undefined reference to `devm_ioremap_resource' Fix the build error by adding the unspecified dependency. Signed-off-by: Brendan Higgins <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-01-31PM / AVS: rockchip-io: fix the supply naming for the emmc supply on px30Heiko Stuebner1-3/+3
The supply going to the emmc/flash is named vccio6, not vccio0 and while the code does this correctly already, the comments and error output do not. So just change these values to the correct ones. Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-01-31power: avs: qcom-cpr: add a printout after the driver has been initializedNiklas Cassel1-2/+3
In order to easier inform the user that the driver has been initialized successfully, add a printout after the driver has been initialized. At the same time, remove a dev_dbg() that is now redundant. Signed-off-by: Niklas Cassel <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-01-31thermal: stm32: fix spelling mistake "preprare" -> "prepare"Colin Ian King1-1/+1
There is a spelling mistake in a dev_err error message. Fix it. Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Daniel Lezcano <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-31Documentation: cpu-idle-cooling: fix a SEVERE docs build failureRandy Dunlap1-0/+5
Sphinx ('make htmldocs') stops with a SEVERE error: Sphinx parallel build error: SystemMessage: /home/rdunlap/lnx/next/linux-next-20200120/Documentation/driver-api/thermal/cpu-idle-cooling.rst:69: (SEVERE/4) Unexpected section title. ^ | so fix the .rst file so that the SEVERE build error does not happen. Also fix another minor formatting warning (unexpected unindent). Signed-off-by: Randy Dunlap <[email protected]> Cc: Zhang Rui <[email protected]> Cc: Daniel Lezcano <[email protected]> Cc: Amit Kucheria <[email protected]> Cc: [email protected] Signed-off-by: Daniel Lezcano <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-31Merge branches 'pm-cpufreq' and 'pm-core'Rafael J. Wysocki12-125/+156
* pm-cpufreq: cpufreq: Avoid creating excessively large stack frames * pm-core: PM: core: Fix handling of devices deleted during system-wide resume
2020-01-31powerpc: Do not consider weak unresolved symbol relocations as badAlexandre Ghiti2-10/+14
Commit 8580ac9404f6 ("bpf: Process in-kernel BTF") introduced two weak symbols that may be unresolved at link time which result in an absolute relocation to 0. relocs_check.sh emits the following warning: "WARNING: 2 bad relocations c000000001a41478 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_start c000000001a41480 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_end" whereas those relocations are legitimate even for a relocatable kernel compiled with -pie option. relocs_check.sh already excluded some weak unresolved symbols explicitly: remove those hardcoded symbols and add some logic that parses the symbols using nm, retrieves all the weak unresolved symbols and excludes those from the list of the potential bad relocations. Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Alexandre Ghiti <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-01-31perf maps: Add missing unlock to maps__insert() error caseCengiz Can1-0/+1
`tools/perf/util/map.c` has a function named `maps__insert` that acquires a write lock if its in multithread context. Even though this lock is released when function successfully completes, there's a branch that is executed when `maps_by_name == NULL` that returns from this function without releasing the write lock. Added an `up_write` to release the lock when this happens. Fixes: a7c2b572e217 ("perf map_groups: Auto sort maps by name, if needed") Signed-off-by: Cengiz Can <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2020-01-31perf probe: Add ustring support for perf probe commandThomas Richter1-1/+2
Kernel commit 88903c464321 ("tracing/probe: Add ustring type for user-space string") adds support for user-space strings when type 'ustring' is specified. Here is an example using sysfs command line interface for kprobes: Function to probe: struct filename * getname_flags(const char __user *filename, int flags, int *empty) Setup: # cd /sys/kernel/debug/tracing/ # echo 'p:tmr1 getname_flags +0(%r2):ustring' > kprobe_events # cat events/kprobes/tmr1/format | fgrep print print fmt: "(%lx) arg1=\"%s\"", REC->__probe_ip, REC->arg1 # echo 1 > events/kprobes/tmr1/enable # touch /tmp/111 # echo 0 > events/kprobes/tmr1/enable # cat trace|fgrep /tmp/111 touch-5846 [005] d..2 255520.717960: tmr1:\ (getname_flags+0x0/0x400) arg1="/tmp/111" Doing the same with the perf tool fails. Using type 'string' succeeds: # perf probe "vfs_getname=getname_flags:72 pathname=filename:string" Added new event: probe:vfs_getname (on getname_flags:72 with pathname=filename:string) .... # perf probe -d probe:vfs_getname Removed event: probe:vfs_getname However using type 'ustring' fails (output before): # perf probe "vfs_getname=getname_flags:72 pathname=filename:ustring" Failed to write event: Invalid argument Error: Failed to add events. # Fix this by adding type 'ustring' in function convert_variable_type(). Using ustring succeeds (output after): # ./perf probe "vfs_getname=getname_flags:72 pathname=filename:ustring" Added new event: probe:vfs_getname (on getname_flags:72 with pathname=filename:ustring) You can now use it in all perf tools, such as: perf record -e probe:vfs_getname -aR sleep 1 # Note: This issue also exists on x86, it is not s390 specific. Signed-off-by: Thomas Richter <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Vasily Gorbik <[email protected]> Cc: [email protected] Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2020-01-31i2c: cros-ec-tunnel: Fix ACPI identifierRaul E Rangel1-1/+1
The initial patch was using the incorrect identifier. Fixes: 9af1563a5486 ("i2c: cros-ec-tunnel: Make the device acpi compatible") Signed-off-by: Raul E Rangel <[email protected]> Acked-by: Enric Balletbo i Serra <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2020-01-31i2c: cros-ec-tunnel: Fix slave device enumerationAkshu Agrawal1-0/+1
During adding of the adapter the slave device registration use to fail as the acpi companion field was not populated. Fixes: 9af1563a5486 ("i2c: cros-ec-tunnel: Make the device acpi compatible") Signed-off-by: Akshu Agrawal <[email protected]> Acked-by: Raul E Rangel <[email protected]> Reviewed-by: Enric Balletbo i Serra <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2020-01-31Merge branch 'ttm-prot-fix' of git://people.freedesktop.org/~thomash/linux ↵Dave Airlie4-12/+63
into drm-next A small fix for the long-standing ttm vm page protection hack. Sent as a separate PR as it touches mm, has all acks in place. Signed-off-by: Dave Airlie <[email protected]> From: Thomas Hellström (VMware) <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-31m68k: configs: Cleanup old Kconfig IO scheduler optionsKrzysztof Kozlowski8-15/+0
CONFIG_IOSCHED_DEADLINE and CONFIG_IOSCHED_CFQ are gone since commit f382fb0bcef4 ("block: remove legacy IO schedulers"). The IOSCHED_DEADLINE was replaced by MQ_IOSCHED_DEADLINE and it will be now enabled by default (along with MQ_IOSCHED_KYBER). Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Greg Ungerer <[email protected]>
2020-01-30clk: qoriq: add ls1088a hwaccel clocks supportYangbo Lu1-0/+29
This patch is to add hwaccel clocks information for ls1088a. Signed-off-by: Yangbo Lu <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]>
2020-01-30clk: ls1028a: Add clock driver for Display output interfaceWen He3-0/+297
Add clock driver for QorIQ LS1028A Display output interfaces(LCD, DPHY), as implemented in TSMC CLN28HPM PLL, this PLL supports the programmable integer division and range of the display output pixel clock's 27-594MHz. Signed-off-by: Wen He <[email protected]> Signed-off-by: Michael Walle <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]>
2020-01-30dt/bindings: clk: Add YAML schemas for LS1028A Display Clock bindingsWen He1-0/+54
LS1028A has a clock domain PXLCLK0 used for provide pixel clocks to Display output interface. Add a YAML schema for this. Signed-off-by: Wen He <[email protected]> Signed-off-by: Michael Walle <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]>
2020-01-30runqslower: Fix MakefileYulia Kartseva1-1/+1
Fix undefined reference linker errors when building runqslower with gcc 7.4.0 on Ubuntu 18.04. The issue is with misplaced -lelf, -lz options in Makefile: $(Q)$(CC) $(CFLAGS) -lelf -lz $^ -o $@ -lelf, -lz options should follow the list of target dependencies: $(Q)$(CC) $(CFLAGS) $^ -lelf -lz -o $@ or after substitution cc -g -Wall runqslower.o libbpf.a -lelf -lz -o runqslower The current order of gcc params causes failure in libelf symbols resolution, e.g. undefined reference to `elf_memory' Fixes: 9c01546d26d2 ("tools/bpf: Add runqslower tool to tools/bpf") Signed-off-by: Julia Kartseva <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Acked-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/908498f794661c44dca54da9e09dc0c382df6fcb.1580425879.git.hex@fb.com
2020-01-30Merge tag 'mpx-for-linus' of ↵Linus Torvalds24-1697/+2
git://git.kernel.org/pub/scm/linux/kernel/git/daveh/x86-mpx Pull x86 MPX removal from Dave Hansen: "MPX requires recompiling applications, which requires compiler support. Unfortunately, GCC 9.1 is expected to be be released without support for MPX. This means that there was only a relatively small window where folks could have ever used MPX. It failed to gain wide adoption in the industry, and Linux was the only mainstream OS to ever support it widely. Support for the feature may also disappear on future processors. This set completes the process that we started during the 5.4 merge window when the MPX prctl()s were removed. XSAVE support is left in place, which allows MPX-using KVM guests to continue to function" * tag 'mpx-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/daveh/x86-mpx: x86/mpx: remove MPX from arch/x86 mm: remove arch_bprm_mm_init() hook x86/mpx: remove bounds exception code x86/mpx: remove build infrastructure x86/alternatives: add missing insn.h include
2020-01-30xtensa: configs: Cleanup old Kconfig IO scheduler optionsKrzysztof Kozlowski6-12/+0
CONFIG_IOSCHED_DEADLINE and CONFIG_IOSCHED_CFQ are gone since commit f382fb0bcef4 ("block: remove legacy IO schedulers"). The IOSCHED_DEADLINE was replaced by MQ_IOSCHED_DEADLINE and it will be now enabled by default (along with MQ_IOSCHED_KYBER). Signed-off-by: Krzysztof Kozlowski <[email protected]> Message-Id: <[email protected]> Signed-off-by: Max Filippov <[email protected]>
2020-01-30Merge tag 'mtd/for-5.6' of ↵Linus Torvalds26-162/+286
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull MTD updates from Miquel Raynal: "MTD core - block2mtd: page index should use pgoff_t - maps: physmap: minimal Runtime PM support - maps: pcmciamtd: avoid possible sleep-in-atomic-context bugs - concat: Fix a comment referring to an unknown symbol Raw NAND: - Macronix: Use match_string() helper - Atmel: switch to using devm_fwnode_gpiod_get() - Denali: rework the SKIP_BYTES feature and add reset controlling - Brcmnand: set appropriate DMA mask - Cadence: add unspecified HAS_IOMEM dependency - Various cleanup. Onenand: - Rename Samsung and Omap2 drivers to avoid possible build warnings - Enable compile testing - Various build issues - Kconfig cleanup SPI-NAND: - Support for Toshiba TC58CVG2S0HRAIJ SPI-NOR: - Add support for TB selection using SR bit 6, - Add support for few flashes" * tag 'mtd/for-5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (41 commits) mtd: concat: Fix a comment referring to an unknown symbol mtd: rawnand: add unspecified HAS_IOMEM dependency mtd: block2mtd: page index should use pgoff_t mtd: maps: physmap: Add minimal Runtime PM support mtd: maps: pcmciamtd: fix possible sleep-in-atomic-context bugs in pcmciamtd_set_vpp() mtd: onenand: Rename omap2 driver to avoid a build warning mtd: onenand: Use a better name for samsung driver mtd: rawnand: atmel: switch to using devm_fwnode_gpiod_get() mtd: spinand: add support for Toshiba TC58CVG2S0HRAIJ mtd: rawnand: macronix: Use match_string() helper to simplify the code mtd: sharpslpart: Fix unsigned comparison to zero mtd: onenand: Enable compile testing of OMAP and Samsung drivers mtd: onenand: samsung: Fix printing format for size_t on 64-bit mtd: onenand: samsung: Fix pointer cast -Wpointer-to-int-cast warnings on 64 bit mtd: rawnand: denali: remove hard-coded DENALI_DEFAULT_OOB_SKIP_BYTES mtd: rawnand: denali_dt: add reset controlling dt-bindings: mtd: denali_dt: document reset property mtd: rawnand: denali_dt: Add support for configuring SPARE_AREA_SKIP_BYTES mtd: rawnand: denali_dt: error out if platform has no associated data mtd: rawnand: brcmnand: Set appropriate DMA mask ...
Powered by cgit, Gruvboxed by Blaster4385.