* linux-next: manual merge of the scsi-mkp tree with the block tree
@ 2016-11-09 2:54 Stephen Rothwell
2016-11-11 19:55 ` Martin K. Petersen
0 siblings, 1 reply; 14+ messages in thread
From: Stephen Rothwell @ 2016-11-09 2:54 UTC (permalink / raw)
To: Martin K. Petersen, Jens Axboe
Cc: linux-next, linux-kernel, Christoph Hellwig
Hi Martin,
Today's linux-next merge of the scsi-mkp tree got conflicts in:
drivers/scsi/ufs/ufshcd.c
between commit:
e806402130c9 ("block: split out request-only flags into a new namespace")
from the block tree and commit:
dcea0bfbc4cb ("scsi: ufs: fix sense buffer size to 18 bytes")
from the scsi-mkp tree.
This latter commit also exists as commit 2266d5678ad1 in the scsi tree,
but unfortunately, the scsi-mkp tree was rebased overnight, so now the
two patches are not the same commit :-( A significant path of what was
rebased overnight has already been merged into the scsi tree ... so
please tidy up your tree WRT the scsi tree. This conflict would not
exist if the rebase had not been done.
I fixed it up (it is also fixed in the scsi tree merge and so just
taking that version of the resolution works) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: linux-next: manual merge of the scsi-mkp tree with the block tree
2016-11-09 2:54 linux-next: manual merge of the scsi-mkp tree with the block tree Stephen Rothwell
@ 2016-11-11 19:55 ` Martin K. Petersen
2016-11-17 2:44 ` Stephen Rothwell
0 siblings, 1 reply; 14+ messages in thread
From: Martin K. Petersen @ 2016-11-11 19:55 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Martin K. Petersen, Jens Axboe, linux-next, linux-kernel,
Christoph Hellwig
>>>>> "Stephen" == Stephen Rothwell <sfr@canb.auug.org.au> writes:
Stephen,
Stephen> This latter commit also exists as commit 2266d5678ad1 in the
Stephen> scsi tree, but unfortunately, the scsi-mkp tree was rebased
Stephen> overnight, so now the two patches are not the same commit :-( A
Stephen> significant path of what was rebased overnight has already been
Stephen> merged into the scsi tree ... so please tidy up your tree WRT
Stephen> the scsi tree. This conflict would not exist if the rebase had
Stephen> not been done.
James' tree is usually a week or two behind mine. I almost never rebase
mid-cycle but in this case we had a data corruption bug fix that went to
Linus for 4.9 that a driver update depended on.
In any case. It seems like the fact that the two SCSI trees may be out
of sync could be an ongoing problem. So maybe you should just drop my
tree again. I was just hoping to get visibility into potential merge
problems sooner...
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: linux-next: manual merge of the scsi-mkp tree with the block tree
2016-11-11 19:55 ` Martin K. Petersen
@ 2016-11-17 2:44 ` Stephen Rothwell
0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2016-11-17 2:44 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Jens Axboe, linux-next, linux-kernel, Christoph Hellwig
Hi Martin,
On Fri, 11 Nov 2016 14:55:24 -0500 "Martin K. Petersen" <martin.petersen@oracle.com> wrote:
>
> In any case. It seems like the fact that the two SCSI trees may be out
> of sync could be an ongoing problem. So maybe you should just drop my
> tree again. I was just hoping to get visibility into potential merge
> problems sooner...
I'll keep it for now and see how it goes ...
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: linux-next: manual merge of the scsi-mkp tree with the block tree
2024-04-18 4:55 Stephen Rothwell
2024-04-18 5:57 ` Christoph Hellwig
@ 2024-04-26 6:01 ` Stephen Rothwell
1 sibling, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2024-04-26 6:01 UTC (permalink / raw)
To: Jens Axboe, James Bottomley
Cc: Martin K. Petersen, Christoph Hellwig, Damien Le Moal,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 3582 bytes --]
Hi all,
On Thu, 18 Apr 2024 14:55:54 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the scsi-mkp tree got conflicts in:
>
> block/blk-settings.c
> include/linux/blkdev.h
>
> between commit:
>
> e4eb37cc0f3e ("block: Remove elevator required features")
>
> from the block tree and commit:
>
> ec84ca4025c0 ("scsi: block: Remove now unused queue limits helpers")
>
> from the scsi-mkp tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc block/blk-settings.c
> index 8e1d7ed52fef,292aadf8d807..000000000000
> --- a/block/blk-settings.c
> +++ b/block/blk-settings.c
> @@@ -1048,28 -822,22 +825,6 @@@ void blk_queue_write_cache(struct reque
> }
> EXPORT_SYMBOL_GPL(blk_queue_write_cache);
>
> --/**
> - * blk_queue_can_use_dma_map_merging - configure queue for merging segments.
> - * @q: the request queue for the device
> - * @dev: the device pointer for dma
> - * blk_queue_required_elevator_features - Set a queue required elevator features
> - * @q: the request queue for the target device
> - * @features: Required elevator features OR'ed together
> -- *
> - * Tell the block layer about merging the segments by dma map of @q.
> - * Tell the block layer that for the device controlled through @q, only the
> - * only elevators that can be used are those that implement at least the set of
> - * features specified by @features.
> -- */
> - bool blk_queue_can_use_dma_map_merging(struct request_queue *q,
> - struct device *dev)
> -void blk_queue_required_elevator_features(struct request_queue *q,
> - unsigned int features)
> --{
> - unsigned long boundary = dma_get_merge_boundary(dev);
> -
> - if (!boundary)
> - return false;
> -
> - /* No need to update max_segment_size. see blk_queue_virt_boundary() */
> - blk_queue_virt_boundary(q, boundary);
> -
> - return true;
> - q->required_elevator_features = features;
> --}
> - EXPORT_SYMBOL_GPL(blk_queue_can_use_dma_map_merging);
> -EXPORT_SYMBOL_GPL(blk_queue_required_elevator_features);
> --
> /**
> * disk_set_zoned - inidicate a zoned device
> * @disk: gendisk to configure
> diff --cc include/linux/blkdev.h
> index 2c535af79529,e3c7082efa39..000000000000
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@@ -924,9 -942,15 +926,6 @@@ disk_alloc_independent_access_ranges(st
> void disk_set_independent_access_ranges(struct gendisk *disk,
> struct blk_independent_access_ranges *iars);
>
> - extern bool blk_queue_can_use_dma_map_merging(struct request_queue *q,
> - struct device *dev);
> -/*
> - * Elevator features for blk_queue_required_elevator_features:
> - */
> -/* Supports zoned block devices sequential write constraint */
> -#define ELEVATOR_F_ZBD_SEQ_WRITE (1U << 0)
> -
> -extern void blk_queue_required_elevator_features(struct request_queue *q,
> - unsigned int features);
> --
> bool __must_check blk_get_queue(struct request_queue *);
> extern void blk_put_queue(struct request_queue *);
>
This is now a conflict between the scsi tree and the block tree.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: linux-next: manual merge of the scsi-mkp tree with the block tree
2024-04-18 4:55 Stephen Rothwell
@ 2024-04-18 5:57 ` Christoph Hellwig
2024-04-26 6:01 ` Stephen Rothwell
1 sibling, 0 replies; 14+ messages in thread
From: Christoph Hellwig @ 2024-04-18 5:57 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Martin K. Petersen, Jens Axboe, Christoph Hellwig,
Damien Le Moal, Linux Kernel Mailing List,
Linux Next Mailing List
Thanks Stephen,
the conflict resolution looks good to me.
^ permalink raw reply [flat|nested] 14+ messages in thread
* linux-next: manual merge of the scsi-mkp tree with the block tree
@ 2024-04-18 4:55 Stephen Rothwell
2024-04-18 5:57 ` Christoph Hellwig
2024-04-26 6:01 ` Stephen Rothwell
0 siblings, 2 replies; 14+ messages in thread
From: Stephen Rothwell @ 2024-04-18 4:55 UTC (permalink / raw)
To: Martin K. Petersen, Jens Axboe
Cc: Christoph Hellwig, Damien Le Moal, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 3254 bytes --]
Hi all,
Today's linux-next merge of the scsi-mkp tree got conflicts in:
block/blk-settings.c
include/linux/blkdev.h
between commit:
e4eb37cc0f3e ("block: Remove elevator required features")
from the block tree and commit:
ec84ca4025c0 ("scsi: block: Remove now unused queue limits helpers")
from the scsi-mkp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc block/blk-settings.c
index 8e1d7ed52fef,292aadf8d807..000000000000
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@@ -1048,28 -822,22 +825,6 @@@ void blk_queue_write_cache(struct reque
}
EXPORT_SYMBOL_GPL(blk_queue_write_cache);
--/**
- * blk_queue_can_use_dma_map_merging - configure queue for merging segments.
- * @q: the request queue for the device
- * @dev: the device pointer for dma
- * blk_queue_required_elevator_features - Set a queue required elevator features
- * @q: the request queue for the target device
- * @features: Required elevator features OR'ed together
-- *
- * Tell the block layer about merging the segments by dma map of @q.
- * Tell the block layer that for the device controlled through @q, only the
- * only elevators that can be used are those that implement at least the set of
- * features specified by @features.
-- */
- bool blk_queue_can_use_dma_map_merging(struct request_queue *q,
- struct device *dev)
-void blk_queue_required_elevator_features(struct request_queue *q,
- unsigned int features)
--{
- unsigned long boundary = dma_get_merge_boundary(dev);
-
- if (!boundary)
- return false;
-
- /* No need to update max_segment_size. see blk_queue_virt_boundary() */
- blk_queue_virt_boundary(q, boundary);
-
- return true;
- q->required_elevator_features = features;
--}
- EXPORT_SYMBOL_GPL(blk_queue_can_use_dma_map_merging);
-EXPORT_SYMBOL_GPL(blk_queue_required_elevator_features);
--
/**
* disk_set_zoned - inidicate a zoned device
* @disk: gendisk to configure
diff --cc include/linux/blkdev.h
index 2c535af79529,e3c7082efa39..000000000000
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@@ -924,9 -942,15 +926,6 @@@ disk_alloc_independent_access_ranges(st
void disk_set_independent_access_ranges(struct gendisk *disk,
struct blk_independent_access_ranges *iars);
- extern bool blk_queue_can_use_dma_map_merging(struct request_queue *q,
- struct device *dev);
-/*
- * Elevator features for blk_queue_required_elevator_features:
- */
-/* Supports zoned block devices sequential write constraint */
-#define ELEVATOR_F_ZBD_SEQ_WRITE (1U << 0)
-
-extern void blk_queue_required_elevator_features(struct request_queue *q,
- unsigned int features);
--
bool __must_check blk_get_queue(struct request_queue *);
extern void blk_put_queue(struct request_queue *);
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: linux-next: manual merge of the scsi-mkp tree with the block tree
2022-02-21 21:59 broonie
2022-02-22 5:57 ` Jinpu Wang
@ 2022-03-01 7:31 ` Stephen Rothwell
1 sibling, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2022-03-01 7:31 UTC (permalink / raw)
To: Jens Axboe
Cc: broonie, Martin K . Petersen, Christoph Hellwig, Gioh Kim,
Jack Wang, Linux Kernel Mailing List, Linux Next Mailing List,
Md Haris Iqbal, James Bottomley
[-- Attachment #1: Type: text/plain, Size: 2586 bytes --]
Hi all,
On Mon, 21 Feb 2022 21:59:11 +0000 broonie@kernel.org wrote:
>
> Today's linux-next merge of the scsi-mkp tree got a conflict in:
>
> drivers/block/rnbd/rnbd-clt.c
>
> between commit:
>
> 448025c103938 ("block/rnbd: client device does not care queue/rotational")
>
> from the block tree and commit:
>
> e8e9884730b36 ("scsi: rnbd: Remove WRITE_SAME support")
>
> from the scsi-mkp tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc drivers/block/rnbd/rnbd-clt.c
> index 1f63f308eb394,dc192d2738854..0000000000000
> --- a/drivers/block/rnbd/rnbd-clt.c
> +++ b/drivers/block/rnbd/rnbd-clt.c
> @@@ -1606,13 -1607,13 +1603,13 @@@ struct rnbd_clt_dev *rnbd_clt_map_devic
> }
>
> rnbd_clt_info(dev,
> - "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_write_same_sectors: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, wc: %d, fua: %d)\n",
> - "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, rotational: %d, wc: %d, fua: %d)\n",
> ++ "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, wc: %d, fua: %d)\n",
> dev->gd->disk_name, dev->nsectors,
> dev->logical_block_size, dev->physical_block_size,
> - dev->max_write_same_sectors, dev->max_discard_sectors,
> + dev->max_discard_sectors,
> dev->discard_granularity, dev->discard_alignment,
> dev->secure_discard, dev->max_segments,
> - dev->max_hw_sectors, dev->rotational, dev->wc, dev->fua);
> + dev->max_hw_sectors, dev->wc, dev->fua);
>
> mutex_unlock(&dev->lock);
> rnbd_clt_put_sess(sess);
This is now a conflict between the scsi tree and the block tree.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: linux-next: manual merge of the scsi-mkp tree with the block tree
2022-02-21 22:06 broonie
@ 2022-03-01 7:29 ` Stephen Rothwell
0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2022-03-01 7:29 UTC (permalink / raw)
To: Jens Axboe, James Bottomley
Cc: broonie, Martin K . Petersen, Chaitanya Kulkarni,
Christoph Hellwig, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]
Hi all,
On Mon, 21 Feb 2022 22:06:22 +0000 broonie@kernel.org wrote:
>
> Today's linux-next merge of the scsi-mkp tree got a conflict in:
>
> block/blk-lib.c
>
> between commit:
>
> 0a3140ea0fae3 ("block: pass a block_device and opf to blk_next_bio")
>
> from the block tree and commit:
>
> 2988062985d59 ("scsi: block: Remove REQ_OP_WRITE_SAME support")
>
> from the scsi-mkp tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc block/blk-lib.c
> index fc6ea52e74824,bf5254ccdb5f8..0000000000000
> --- a/block/blk-lib.c
> +++ b/block/blk-lib.c
>
> (took the deletion of _WRITE_SAME from scsi-mkp)
This is now a conflict between the scsi tree and the block tree.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: linux-next: manual merge of the scsi-mkp tree with the block tree
2022-02-21 21:59 broonie
@ 2022-02-22 5:57 ` Jinpu Wang
2022-03-01 7:31 ` Stephen Rothwell
1 sibling, 0 replies; 14+ messages in thread
From: Jinpu Wang @ 2022-02-22 5:57 UTC (permalink / raw)
To: broonie
Cc: Martin K . Petersen, Christoph Hellwig, Gioh Kim, Jens Axboe,
Linux Kernel Mailing List, Linux Next Mailing List,
Md Haris Iqbal
On Mon, Feb 21, 2022 at 10:59 PM <broonie@kernel.org> wrote:
>
> Hi all,
>
> Today's linux-next merge of the scsi-mkp tree got a conflict in:
>
> drivers/block/rnbd/rnbd-clt.c
>
> between commit:
>
> 448025c103938 ("block/rnbd: client device does not care queue/rotational")
>
> from the block tree and commit:
>
> e8e9884730b36 ("scsi: rnbd: Remove WRITE_SAME support")
>
> from the scsi-mkp tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Hi Broonie,
Thanks for fixing it up, it looks good. We will pay attention on this next time!
Regards!
Jinpu Wang
>
> diff --cc drivers/block/rnbd/rnbd-clt.c
> index 1f63f308eb394,dc192d2738854..0000000000000
> --- a/drivers/block/rnbd/rnbd-clt.c
> +++ b/drivers/block/rnbd/rnbd-clt.c
> @@@ -1606,13 -1607,13 +1603,13 @@@ struct rnbd_clt_dev *rnbd_clt_map_devic
> }
>
> rnbd_clt_info(dev,
> - "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_write_same_sectors: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, wc: %d, fua: %d)\n",
> - "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, rotational: %d, wc: %d, fua: %d)\n",
> ++ "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, wc: %d, fua: %d)\n",
> dev->gd->disk_name, dev->nsectors,
> dev->logical_block_size, dev->physical_block_size,
> - dev->max_write_same_sectors, dev->max_discard_sectors,
> + dev->max_discard_sectors,
> dev->discard_granularity, dev->discard_alignment,
> dev->secure_discard, dev->max_segments,
> - dev->max_hw_sectors, dev->rotational, dev->wc, dev->fua);
> + dev->max_hw_sectors, dev->wc, dev->fua);
>
> mutex_unlock(&dev->lock);
> rnbd_clt_put_sess(sess);
^ permalink raw reply [flat|nested] 14+ messages in thread
* linux-next: manual merge of the scsi-mkp tree with the block tree
@ 2022-02-21 22:06 broonie
2022-03-01 7:29 ` Stephen Rothwell
0 siblings, 1 reply; 14+ messages in thread
From: broonie @ 2022-02-21 22:06 UTC (permalink / raw)
To: Martin K . Petersen
Cc: Chaitanya Kulkarni, Christoph Hellwig, Jens Axboe,
Linux Kernel Mailing List, Linux Next Mailing List
Hi all,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
block/blk-lib.c
between commit:
0a3140ea0fae3 ("block: pass a block_device and opf to blk_next_bio")
from the block tree and commit:
2988062985d59 ("scsi: block: Remove REQ_OP_WRITE_SAME support")
from the scsi-mkp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc block/blk-lib.c
index fc6ea52e74824,bf5254ccdb5f8..0000000000000
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
(took the deletion of _WRITE_SAME from scsi-mkp)
^ permalink raw reply [flat|nested] 14+ messages in thread
* linux-next: manual merge of the scsi-mkp tree with the block tree
@ 2022-02-21 21:59 broonie
2022-02-22 5:57 ` Jinpu Wang
2022-03-01 7:31 ` Stephen Rothwell
0 siblings, 2 replies; 14+ messages in thread
From: broonie @ 2022-02-21 21:59 UTC (permalink / raw)
To: Martin K . Petersen
Cc: Christoph Hellwig, Gioh Kim, Jack Wang, Jens Axboe,
Linux Kernel Mailing List, Linux Next Mailing List,
Md Haris Iqbal
Hi all,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
drivers/block/rnbd/rnbd-clt.c
between commit:
448025c103938 ("block/rnbd: client device does not care queue/rotational")
from the block tree and commit:
e8e9884730b36 ("scsi: rnbd: Remove WRITE_SAME support")
from the scsi-mkp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc drivers/block/rnbd/rnbd-clt.c
index 1f63f308eb394,dc192d2738854..0000000000000
--- a/drivers/block/rnbd/rnbd-clt.c
+++ b/drivers/block/rnbd/rnbd-clt.c
@@@ -1606,13 -1607,13 +1603,13 @@@ struct rnbd_clt_dev *rnbd_clt_map_devic
}
rnbd_clt_info(dev,
- "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_write_same_sectors: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, wc: %d, fua: %d)\n",
- "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, rotational: %d, wc: %d, fua: %d)\n",
++ "map_device: Device mapped as %s (nsectors: %zu, logical_block_size: %d, physical_block_size: %d, max_discard_sectors: %d, discard_granularity: %d, discard_alignment: %d, secure_discard: %d, max_segments: %d, max_hw_sectors: %d, wc: %d, fua: %d)\n",
dev->gd->disk_name, dev->nsectors,
dev->logical_block_size, dev->physical_block_size,
- dev->max_write_same_sectors, dev->max_discard_sectors,
+ dev->max_discard_sectors,
dev->discard_granularity, dev->discard_alignment,
dev->secure_discard, dev->max_segments,
- dev->max_hw_sectors, dev->rotational, dev->wc, dev->fua);
+ dev->max_hw_sectors, dev->wc, dev->fua);
mutex_unlock(&dev->lock);
rnbd_clt_put_sess(sess);
^ permalink raw reply [flat|nested] 14+ messages in thread
* linux-next: manual merge of the scsi-mkp tree with the block tree
@ 2021-01-27 6:58 Stephen Rothwell
0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2021-01-27 6:58 UTC (permalink / raw)
To: Martin K. Petersen, Jens Axboe
Cc: Douglas Gilbert, Guoqing Jiang, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 10820 bytes --]
Hi all,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
drivers/scsi/sg.c
between commit:
8eeed0b554b9 ("block: remove unnecessary argument from blk_execute_rq_nowait")
from the block tree and vaious commits from the scsi-mkp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/scsi/sg.c
index 4383d93110f8,c5a34bb91335..000000000000
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@@ -437,73 -858,243 +858,242 @@@ sg_rq_state_chg(struct sg_request *srp
return 0;
}
- static ssize_t
- sg_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos)
+ /*
+ * All writes and submits converge on this function to launch the SCSI
+ * command/request (via blk_execute_rq_nowait). Returns a pointer to a
+ * sg_request object holding the request just issued or a negated errno
+ * value twisted by ERR_PTR.
+ */
+ static struct sg_request *
+ sg_common_write(struct sg_fd *sfp, struct sg_comm_wr_t *cwrp)
{
- Sg_device *sdp;
- Sg_fd *sfp;
- Sg_request *srp;
- int req_pack_id = -1;
- sg_io_hdr_t *hp;
- struct sg_header *old_hdr;
- int retval;
+ bool at_head;
+ int res = 0;
+ int dxfr_len, dir, cmd_len;
+ int pack_id = SG_PACK_ID_WILDCARD;
+ u32 rq_flags;
+ struct sg_device *sdp = sfp->parentdp;
+ struct sg_request *srp;
+ struct sg_io_hdr *hi_p;
+
+ hi_p = cwrp->h3p;
+ dir = hi_p->dxfer_direction;
+ dxfr_len = hi_p->dxfer_len;
+ rq_flags = hi_p->flags;
+ pack_id = hi_p->pack_id;
+ if (dxfr_len >= SZ_256M)
+ return ERR_PTR(-EINVAL);
+
+ srp = sg_setup_req(sfp, dxfr_len, cwrp);
+ if (IS_ERR(srp))
+ return srp;
+ srp->rq_flags = rq_flags;
+ srp->pack_id = pack_id;
+
+ cmd_len = hi_p->cmd_len;
+ memcpy(&srp->s_hdr3, hi_p, sizeof(srp->s_hdr3));
+ srp->cmd_opcode = cwrp->cmnd[0];/* hold opcode of command for debug */
+ SG_LOG(4, sfp, "%s: opcode=0x%02x, cdb_sz=%d, pack_id=%d\n", __func__,
+ (int)cwrp->cmnd[0], cmd_len, pack_id);
+
+ res = sg_start_req(srp, cwrp->cmnd, cmd_len, dir);
+ if (res < 0) /* probably out of space --> -ENOMEM */
+ goto err_out;
+ if (unlikely(SG_IS_DETACHING(sdp))) {
+ res = -ENODEV;
+ goto err_out;
+ }
+ if (unlikely(test_bit(SG_FRQ_BLK_PUT_REQ, srp->frq_bm) || !srp->rq)) {
+ res = -EIDRM; /* this failure unexpected but observed */
+ goto err_out;
+ }
+ if (xa_get_mark(&sfp->srp_arr, srp->rq_idx, SG_XA_RQ_FREE)) {
+ SG_LOG(1, sfp, "%s: ahhh, request erased!!!\n", __func__);
+ res = -ENODEV;
+ goto err_out;
+ }
+ srp->rq->timeout = cwrp->timeout;
+ kref_get(&sfp->f_ref); /* sg_rq_end_io() does kref_put(). */
+ res = sg_rq_state_chg(srp, SG_RS_BUSY, SG_RS_INFLIGHT, false,
+ __func__);
+ if (res)
+ goto err_out;
+ srp->start_ns = ktime_get_boottime_ns();
+ srp->duration = 0;
+
+ if (srp->s_hdr3.interface_id == '\0')
+ at_head = true; /* backward compatibility: v1+v2 interfaces */
+ else if (test_bit(SG_FFD_Q_AT_TAIL, sfp->ffd_bm))
+ /* cmd flags can override sfd setting */
+ at_head = !!(srp->rq_flags & SG_FLAG_Q_AT_HEAD);
+ else /* this sfd is defaulting to head */
+ at_head = !(srp->rq_flags & SG_FLAG_Q_AT_TAIL);
+ if (!test_bit(SG_FRQ_SYNC_INVOC, srp->frq_bm))
+ atomic_inc(&sfp->submitted);
- blk_execute_rq_nowait(sdp->device->request_queue, sdp->disk,
- srp->rq, at_head, sg_rq_end_io);
++ blk_execute_rq_nowait(sdp->disk, srp->rq, at_head, sg_rq_end_io);
+ return srp;
+ err_out:
+ sg_finish_scsi_blk_rq(srp);
+ sg_deact_request(sfp, srp);
+ return ERR_PTR(res);
+ }
- /*
- * This could cause a response to be stranded. Close the associated
- * file descriptor to free up any resources being held.
- */
- retval = sg_check_file_access(filp, __func__);
- if (retval)
- return retval;
+ /*
+ * This function is called by wait_event_interruptible in sg_read() and
+ * sg_ctl_ioreceive(). wait_event_interruptible will return if this one
+ * returns true (or an event like a signal (e.g. control-C) occurs).
+ */
- if ((!(sfp = (Sg_fd *) filp->private_data)) || (!(sdp = sfp->parentdp)))
- return -ENXIO;
- SCSI_LOG_TIMEOUT(3, sg_printk(KERN_INFO, sdp,
- "sg_read: count=%d\n", (int) count));
+ static inline bool
+ sg_get_ready_srp(struct sg_fd *sfp, struct sg_request **srpp, int pack_id)
+ {
+ struct sg_request *srp;
- if (sfp->force_packid)
- retval = get_sg_io_pack_id(&req_pack_id, buf, count);
- if (retval)
- return retval;
+ if (unlikely(SG_IS_DETACHING(sfp->parentdp))) {
+ *srpp = NULL;
+ return true;
+ }
+ srp = sg_find_srp_by_id(sfp, pack_id);
+ *srpp = srp;
+ return !!srp;
+ }
- srp = sg_get_rq_mark(sfp, req_pack_id);
- if (!srp) { /* now wait on packet to arrive */
- if (atomic_read(&sdp->detaching))
- return -ENODEV;
- if (filp->f_flags & O_NONBLOCK)
- return -EAGAIN;
- retval = wait_event_interruptible(sfp->read_wait,
- (atomic_read(&sdp->detaching) ||
- (srp = sg_get_rq_mark(sfp, req_pack_id))));
- if (atomic_read(&sdp->detaching))
- return -ENODEV;
- if (retval)
- /* -ERESTARTSYS as signal hit process */
- return retval;
+ /*
+ * Returns number of bytes copied to user space provided sense buffer or
+ * negated errno value.
+ */
+ static int
+ sg_copy_sense(struct sg_request *srp)
+ {
+ int sb_len_ret = 0;
+ int scsi_stat;
+
+ /* If need be, copy the sense buffer to the user space */
+ scsi_stat = srp->rq_result & 0xff;
+ if ((scsi_stat & SAM_STAT_CHECK_CONDITION) ||
+ (driver_byte(srp->rq_result) & DRIVER_SENSE)) {
+ int sb_len = min_t(int, SCSI_SENSE_BUFFERSIZE, srp->sense_len);
+ int mx_sb_len = srp->s_hdr3.mx_sb_len;
+ u8 *sbp = srp->sense_bp;
+ void __user *up = srp->s_hdr3.sbp;
+
+ srp->sense_bp = NULL;
+ if (up && mx_sb_len > 0 && sbp) {
+ sb_len = min_t(int, mx_sb_len, sb_len);
+ /* Additional sense length field */
+ sb_len_ret = 8 + (int)sbp[7];
+ sb_len_ret = min_t(int, sb_len_ret, sb_len);
+ if (copy_to_user(up, sbp, sb_len_ret))
+ sb_len_ret = -EFAULT;
+ } else {
+ sb_len_ret = 0;
+ }
+ mempool_free(sbp, sg_sense_pool);
}
- if (srp->header.interface_id != '\0')
- return sg_new_read(sfp, buf, count, srp);
+ return sb_len_ret;
+ }
- hp = &srp->header;
- old_hdr = kzalloc(SZ_SG_HEADER, GFP_KERNEL);
- if (!old_hdr)
- return -ENOMEM;
+ static int
+ sg_rec_state_v3(struct sg_fd *sfp, struct sg_request *srp)
+ {
+ int sb_len_wr;
+ u32 rq_res = srp->rq_result;
+
+ sb_len_wr = sg_copy_sense(srp);
+ if (sb_len_wr < 0)
+ return sb_len_wr;
+ if (rq_res & SG_ML_RESULT_MSK)
+ srp->rq_info |= SG_INFO_CHECK;
+ if (unlikely(SG_IS_DETACHING(sfp->parentdp)))
+ srp->rq_info |= SG_INFO_DEVICE_DETACHING;
+ return 0;
+ }
+
+ static ssize_t
+ sg_receive_v3(struct sg_fd *sfp, struct sg_request *srp, size_t count,
+ void __user *p)
+ {
+ int err, err2;
+ int rq_result = srp->rq_result;
+ struct sg_io_hdr hdr3;
+ struct sg_io_hdr *hp = &hdr3;
- old_hdr->reply_len = (int) hp->timeout;
- old_hdr->pack_len = old_hdr->reply_len; /* old, strange behaviour */
- old_hdr->pack_id = hp->pack_id;
- old_hdr->twelve_byte =
- ((srp->data.cmd_opcode >= 0xc0) && (12 == hp->cmd_len)) ? 1 : 0;
- old_hdr->target_status = hp->masked_status;
- old_hdr->host_status = hp->host_status;
- old_hdr->driver_status = hp->driver_status;
- if ((CHECK_CONDITION & hp->masked_status) ||
- (DRIVER_SENSE & hp->driver_status))
- memcpy(old_hdr->sense_buffer, srp->sense_b,
- sizeof (old_hdr->sense_buffer));
- switch (hp->host_status) {
- /* This setup of 'result' is for backward compatibility and is best
- ignored by the user who should use target, host + driver status */
+ if (in_compat_syscall()) {
+ if (count < sizeof(struct compat_sg_io_hdr)) {
+ err = -EINVAL;
+ goto err_out;
+ }
+ } else if (count < SZ_SG_IO_HDR) {
+ err = -EINVAL;
+ goto err_out;
+ }
+ SG_LOG(3, sfp, "%s: srp=0x%pK\n", __func__, srp);
+ err = sg_rec_state_v3(sfp, srp);
+ memset(hp, 0, sizeof(*hp));
+ memcpy(hp, &srp->s_hdr3, sizeof(srp->s_hdr3));
+ hp->sb_len_wr = srp->sense_len;
+ hp->info = srp->rq_info;
+ hp->resid = srp->in_resid;
+ hp->duration = srp->duration;
+ hp->status = rq_result & 0xff;
+ hp->masked_status = status_byte(rq_result);
+ hp->msg_status = msg_byte(rq_result);
+ hp->host_status = host_byte(rq_result);
+ hp->driver_status = driver_byte(rq_result);
+ err2 = put_sg_io_hdr(hp, p);
+ err = err ? err : err2;
+ err2 = sg_rq_state_chg(srp, atomic_read(&srp->rq_st), SG_RS_RCV_DONE,
+ false, __func__);
+ if (err2)
+ err = err ? err : err2;
+ err_out:
+ sg_finish_scsi_blk_rq(srp);
+ sg_deact_request(sfp, srp);
+ return err;
+ }
+
+ /*
+ * Completes a v3 request/command. Called from sg_read {v2 or v3},
+ * ioctl(SG_IO) {for v3}, or from ioctl(SG_IORECEIVE) when its
+ * completing a v3 request/command.
+ */
+ static int
+ sg_read_v1v2(void __user *buf, int count, struct sg_fd *sfp,
+ struct sg_request *srp)
+ {
+ int res = 0;
+ u32 rq_result = srp->rq_result;
+ struct sg_header *h2p;
+ struct sg_slice_hdr3 *sh3p;
+ struct sg_header a_v2hdr;
+
+ h2p = &a_v2hdr;
+ memset(h2p, 0, SZ_SG_HEADER);
+ sh3p = &srp->s_hdr3;
+ h2p->reply_len = (int)sh3p->timeout;
+ h2p->pack_len = h2p->reply_len; /* old, strange behaviour */
+ h2p->pack_id = sh3p->pack_id;
+ h2p->twelve_byte = (srp->cmd_opcode >= 0xc0 && sh3p->cmd_len == 12);
+ h2p->target_status = status_byte(rq_result);
+ h2p->host_status = host_byte(rq_result);
+ h2p->driver_status = driver_byte(rq_result);
+ if ((CHECK_CONDITION & status_byte(rq_result)) ||
+ (DRIVER_SENSE & driver_byte(rq_result))) {
+ if (srp->sense_bp) {
+ u8 *sbp = srp->sense_bp;
+
+ srp->sense_bp = NULL;
+ memcpy(h2p->sense_buffer, sbp,
+ sizeof(h2p->sense_buffer));
+ mempool_free(sbp, sg_sense_pool);
+ }
+ }
+ switch (host_byte(rq_result)) {
+ /*
+ * This following setting of 'result' is for backward compatibility
+ * and is best ignored by the user who should use target, host and
+ * driver status.
+ */
case DID_OK:
case DID_PASSTHROUGH:
case DID_SOFT_ERROR:
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* linux-next: manual merge of the scsi-mkp tree with the block tree
@ 2019-02-11 4:23 Stephen Rothwell
0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2019-02-11 4:23 UTC (permalink / raw)
To: Martin K. Petersen, Jens Axboe
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Christoph Hellwig, James Bottomley
[-- Attachment #1: Type: text/plain, Size: 4794 bytes --]
Hi all,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
include/linux/blkdev.h
between commit:
eca7abf31abb ("block: queue flag cleanup")
from the block tree and commit:
8b3238cabd50 ("scsi: block: remove bidi support")
from the scsi-mkp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/blkdev.h
index 3603270cb82d,21beb456b97a..000000000000
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@@ -572,33 -567,37 +567,32 @@@ struct request_queue
u64 write_hints[BLK_MAX_WRITE_HINTS];
};
-#define QUEUE_FLAG_STOPPED 1 /* queue is stopped */
-#define QUEUE_FLAG_DYING 2 /* queue being torn down */
-#define QUEUE_FLAG_NOMERGES 5 /* disable merge attempts */
-#define QUEUE_FLAG_SAME_COMP 6 /* complete on same CPU-group */
-#define QUEUE_FLAG_FAIL_IO 7 /* fake timeout */
-#define QUEUE_FLAG_NONROT 9 /* non-rotational device (SSD) */
-#define QUEUE_FLAG_VIRT QUEUE_FLAG_NONROT /* paravirt device */
-#define QUEUE_FLAG_IO_STAT 10 /* do disk/partitions IO accounting */
-#define QUEUE_FLAG_DISCARD 11 /* supports DISCARD */
-#define QUEUE_FLAG_NOXMERGES 12 /* No extended merges */
-#define QUEUE_FLAG_ADD_RANDOM 13 /* Contributes to random pool */
-#define QUEUE_FLAG_SECERASE 14 /* supports secure erase */
-#define QUEUE_FLAG_SAME_FORCE 15 /* force complete on same CPU */
-#define QUEUE_FLAG_DEAD 16 /* queue tear-down finished */
-#define QUEUE_FLAG_INIT_DONE 17 /* queue is initialized */
-#define QUEUE_FLAG_NO_SG_MERGE 18 /* don't attempt to merge SG segments*/
-#define QUEUE_FLAG_POLL 19 /* IO polling enabled if set */
-#define QUEUE_FLAG_WC 20 /* Write back caching */
-#define QUEUE_FLAG_FUA 21 /* device supports FUA writes */
-#define QUEUE_FLAG_FLUSH_NQ 22 /* flush not queueuable */
-#define QUEUE_FLAG_DAX 23 /* device supports DAX */
-#define QUEUE_FLAG_STATS 24 /* track IO start and completion times */
-#define QUEUE_FLAG_POLL_STATS 25 /* collecting stats for hybrid polling */
-#define QUEUE_FLAG_REGISTERED 26 /* queue has been registered to a disk */
-#define QUEUE_FLAG_SCSI_PASSTHROUGH 27 /* queue supports SCSI commands */
-#define QUEUE_FLAG_QUIESCED 28 /* queue has been quiesced */
-#define QUEUE_FLAG_PCI_P2PDMA 29 /* device supports PCI p2p requests */
-
-#define QUEUE_FLAG_DEFAULT ((1 << QUEUE_FLAG_IO_STAT) | \
- (1 << QUEUE_FLAG_SAME_COMP) | \
- (1 << QUEUE_FLAG_ADD_RANDOM))
+#define QUEUE_FLAG_STOPPED 0 /* queue is stopped */
+#define QUEUE_FLAG_DYING 1 /* queue being torn down */
- #define QUEUE_FLAG_BIDI 2 /* queue supports bidi requests */
+#define QUEUE_FLAG_NOMERGES 3 /* disable merge attempts */
+#define QUEUE_FLAG_SAME_COMP 4 /* complete on same CPU-group */
+#define QUEUE_FLAG_FAIL_IO 5 /* fake timeout */
+#define QUEUE_FLAG_NONROT 6 /* non-rotational device (SSD) */
+#define QUEUE_FLAG_VIRT QUEUE_FLAG_NONROT /* paravirt device */
+#define QUEUE_FLAG_IO_STAT 7 /* do disk/partitions IO accounting */
+#define QUEUE_FLAG_DISCARD 8 /* supports DISCARD */
+#define QUEUE_FLAG_NOXMERGES 9 /* No extended merges */
+#define QUEUE_FLAG_ADD_RANDOM 10 /* Contributes to random pool */
+#define QUEUE_FLAG_SECERASE 11 /* supports secure erase */
+#define QUEUE_FLAG_SAME_FORCE 12 /* force complete on same CPU */
+#define QUEUE_FLAG_DEAD 13 /* queue tear-down finished */
+#define QUEUE_FLAG_INIT_DONE 14 /* queue is initialized */
+#define QUEUE_FLAG_NO_SG_MERGE 15 /* don't attempt to merge SG segments*/
+#define QUEUE_FLAG_POLL 16 /* IO polling enabled if set */
+#define QUEUE_FLAG_WC 17 /* Write back caching */
+#define QUEUE_FLAG_FUA 18 /* device supports FUA writes */
+#define QUEUE_FLAG_DAX 19 /* device supports DAX */
+#define QUEUE_FLAG_STATS 20 /* track IO start and completion times */
+#define QUEUE_FLAG_POLL_STATS 21 /* collecting stats for hybrid polling */
+#define QUEUE_FLAG_REGISTERED 22 /* queue has been registered to a disk */
+#define QUEUE_FLAG_SCSI_PASSTHROUGH 23 /* queue supports SCSI commands */
+#define QUEUE_FLAG_QUIESCED 24 /* queue has been quiesced */
+#define QUEUE_FLAG_PCI_P2PDMA 25 /* device supports PCI p2p requests */
#define QUEUE_FLAG_MQ_DEFAULT ((1 << QUEUE_FLAG_IO_STAT) | \
(1 << QUEUE_FLAG_SAME_COMP))
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* linux-next: manual merge of the scsi-mkp tree with the block tree
@ 2017-04-26 5:47 Stephen Rothwell
0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2017-04-26 5:47 UTC (permalink / raw)
To: Martin K. Petersen, Jens Axboe
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Damien Le Moal, Christoph Hellwig
Hi all,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
drivers/scsi/sd.c
between commit:
81d926e8b552 ("sd: split sd_setup_discard_cmnd")
from the block tree and commit:
7529fbb0080d ("scsi: sd: Fix function descriptions")
from the scsi-mkp tree.
I fixed it up (I just used the former version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2024-04-26 6:01 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-09 2:54 linux-next: manual merge of the scsi-mkp tree with the block tree Stephen Rothwell
2016-11-11 19:55 ` Martin K. Petersen
2016-11-17 2:44 ` Stephen Rothwell
2017-04-26 5:47 Stephen Rothwell
2019-02-11 4:23 Stephen Rothwell
2021-01-27 6:58 Stephen Rothwell
2022-02-21 21:59 broonie
2022-02-22 5:57 ` Jinpu Wang
2022-03-01 7:31 ` Stephen Rothwell
2022-02-21 22:06 broonie
2022-03-01 7:29 ` Stephen Rothwell
2024-04-18 4:55 Stephen Rothwell
2024-04-18 5:57 ` Christoph Hellwig
2024-04-26 6:01 ` Stephen Rothwell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).