wireguard-linux/arch/xtensa/platforms/iss/simdisk.c, branch jd/orphan-parallel

xtensa/simdisk: remove the call to check_disk_change

2020-07-08T22:20:01Z

The simdisk driver doesn't support event notifications, which means that check_disk_change is a no-op. Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe

block: move ->make_request_fn to struct block_device_operations

2020-07-01T13:27:24Z

The make_request_fn is a little weird in that it sits directly in struct request_queue instead of an operation vector. Replace it with a block_device_operations method called submit_bio (which describes much better what it does). Also remove the request_queue argument to it, as the queue can be derived pretty trivially from the bio. Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe

simdisk: stop using ->queuedata

2020-07-01T13:27:23Z

Instead of setting up the queuedata as well just use one private data field. Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe

block: simplify queue allocation

2020-03-27T16:23:43Z

Current make_request based drivers use either blk_alloc_queue_node or blk_alloc_queue to allocate a queue, and then set up the make_request_fn function pointer and a few parameters using the blk_queue_make_request helper. Simplify this by passing the make_request pointer to blk_alloc_queue, and while at it merge the _node variant into the main helper by always passing a node_id, and remove the superfluous gfp_mask parameter. A lower-level __blk_alloc_queue is kept for the blk-mq case. Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe

proc: convert everything to "struct proc_ops"

2020-02-04T03:05:26Z

The most notable change is DEFINE_SHOW_ATTRIBUTE macro split in seq_file.h. Conversion rule is: llseek => proc_lseek unlocked_ioctl => proc_ioctl xxx => proc_xxx delete ".owner = THIS_MODULE" line [akpm@linux-foundation.org: fix drivers/isdn/capi/kcapi_proc.c] [sfr@canb.auug.org.au: fix kernel/sched/psi.c] Link: http://lkml.kernel.org/r/20200122180545.36222f50@canb.auug.org.au Link: http://lkml.kernel.org/r/20191225172546.GB13378@avx2 Signed-off-by: Alexey Dobriyan Signed-off-by: Stephen Rothwell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

xtensa: set proper error code for simdisk_setup()

2019-05-06T21:36:44Z

Change error code to -ENOMEM from -EIO because the error is related to memory allocating. Signed-off-by: Chengguang Xu Message-Id: <1557066367-4783-2-git-send-email-cgxu519@gmail.com> Signed-off-by: Max Filippov

xtensa: fix incorrect fd close in error case of simdisk_setup()

2019-05-06T21:36:43Z

dev->fd is opened in attach operation, so should not close dev->fd in error case of simdisk_setup(). Signed-off-by: Chengguang Xu Message-Id: <1557066367-4783-1-git-send-email-cgxu519@gmail.com> Signed-off-by: Max Filippov

block: Move SECTOR_SIZE and SECTOR_SHIFT definitions into

2018-03-17T20:45:23Z

It happens often while I'm preparing a patch for a block driver that I'm wondering: is a definition of SECTOR_SIZE and/or SECTOR_SHIFT available for this driver? Do I have to introduce definitions of these constants before I can use these constants? To avoid this confusion, move the existing definitions of SECTOR_SIZE and SECTOR_SHIFT into the header file such that these become available for all block drivers. Make the SECTOR_SIZE definition in the uapi msdos_fs.h header file conditional to avoid that including that header file after causes the compiler to complain about a SECTOR_SIZE redefinition. Note: the SECTOR_SIZE / SECTOR_SHIFT / SECTOR_BITS definitions have not been removed from uapi header files nor from NAND drivers in which these constants are used for another purpose than converting block layer offsets and sizes into a number of sectors. Cc: David S. Miller Cc: Mike Snitzer Cc: Dan Williams Cc: Minchan Kim Cc: Nitin Gupta Reviewed-by: Sergey Senozhatsky Reviewed-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn Reviewed-by: Martin K. Petersen Signed-off-by: Bart Van Assche Signed-off-by: Jens Axboe

xtensa/simdisk: fix compile error

2017-11-11T02:55:57Z

Fixes: d004a5e7d4dd ("block: remove __bio_kmap_atomic") Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe

block: remove __bio_kmap_atomic

2017-11-11T02:53:25Z

This helper doesn't buy us much over calling kmap_atomic directly. In fact in the only caller it does a bit of useless work as the caller already has the bvec at hand, and said caller would even buggy for a multi-segment bio due to the use of this helper. So just remove it. Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe