ree the request. However, LLD may allocate
> > private data for this request, so this way will cause memory leak.
>
> I am confused about this. Probably because I am not up-to-date with
> all of blk-mq. But if you free the LLD private data before the request
> is finished, what
Hey Ming Lei,
On Sat, Jul 20, 2019 at 11:06:35AM +0800, Ming Lei wrote:
> Hi,
>
> When one request is dispatched to LLD via dm-rq, if the result is
> BLK_STS_*RESOURCE, dm-rq will free the request. However, LLD may allocate
> private data for this request, so this way will cause
Hi,
When one request is dispatched to LLD via dm-rq, if the result is
BLK_STS_*RESOURCE, dm-rq will free the request. However, LLD may allocate
private data for this request, so this way will cause memory leak.
Add .cleanup_rq() callback and implement it in SCSI for fixing the issue,
since SCSI
Hi,
When one request is dispatched to LLD via dm-rq, if the result is
BLK_STS_*RESOURCE, dm-rq will free the request. However, LLD may allocate
private stuff for this request, so this way will cause memory leak.
Add .cleanup_rq() callback and implement it in SCSI for fixing the issue.
And SCSI
From: Hannes Reinecke
Use private commands to allocate internal commands.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/aacraid/aacraid.h | 6 --
drivers/scsi/aacraid/commsup.c | 47 +++---
drivers/scsi/aacraid/linit.c | 3 +++
3 files changed, 24
Move global variables into SCSI host private data in order to support
multiple cards.
Signed-off-by: Ondrej Zary
---
drivers/scsi/fdomain.c | 593 +
1 file changed, 307 insertions(+), 286 deletions(-)
diff --git a/drivers/scsi/fdomain.c b/drivers
I have a business Proposal that will be of benefit to the both of us.Kindly
contact me on mrmichealwu...@yahoo.com.hk should this be of interest to you.
I have a business Proposal that will be of benefit to the both of us.Kindly
contact me on mrmichealwu...@yahoo.com.hk should this be of interest to you.
On 1/28/19 5:40 PM, Christoph Hellwig wrote:
On Mon, Jan 28, 2019 at 03:33:46PM +0100, Hannes Reinecke wrote:
Well ... not always.
Some drivers (eg aacraid or hpsa) use internal commands to query hardware,
handle events and the like.
These commands use the same infrastructure than normal SCSI co
On Mon, Jan 28, 2019 at 03:33:46PM +0100, Hannes Reinecke wrote:
> Well ... not always.
> Some drivers (eg aacraid or hpsa) use internal commands to query hardware,
> handle events and the like.
> These commands use the same infrastructure than normal SCSI commands,
> and hence need to use the same
y of those allocations.
For most users of private tags/commands we need to be the queue working
_prior_ to setting up the 'normal' request queues, as the commands are used
to fetch information from the hardware required to setup the queues.
And typically the 'private' comman
will
> expose a 'struct request', (and by implication a struct scsi_cmnd).
The same interface as we do in other block drivers:
blk_mq_alloc_request with BLK_MQ_REQ_RESERVED. And yes, this gets us
a struct scsi_cmnd, which is exactly what we need.
> For most users of private tags/comma
On 1/28/19 3:03 PM, Christoph Hellwig wrote:
On Thu, Jan 24, 2019 at 08:52:20AM +0100, Hannes Reinecke wrote:
Hi all,
blk-mq has the concept of 'private' tags to handle driver-internal commands.
Also quite some SCSI HBAs use internal commands for configuration, event
handling etc.
Bu
On Thu, Jan 24, 2019 at 08:52:20AM +0100, Hannes Reinecke wrote:
> Hi all,
>
> blk-mq has the concept of 'private' tags to handle driver-internal commands.
> Also quite some SCSI HBAs use internal commands for configuration, event
> handling etc.
> But sadly no interfa
[Resending with proper header, thx jthumshirn]
Hi all,
blk-mq has the concept of 'private' tags to handle driver-internal commands.
Also quite some SCSI HBAs use internal commands for configuration, event
handling etc.
But sadly no interface to use the 'private' tags
Hi all,
blk-mq has the concept of 'private' tags to handle driver-internal commands.
Also quite some SCSI HBAs use internal commands for configuration, event
handling etc.
But sadly no interface to use the 'private' tags from the block layer
exists, so quite some drive
ecial filtering is desired.
This is a revert of commit 018e044 ("block: get rid of queue-private
command filter", 2009-06-26), though with many changes.
Cc: linux-scsi@vger.kernel.org
Cc: Hannes Reinecke
Cc: Martin K. Petersen
Cc: James Bottomley
Signed-off-by: Paolo Bonzini
---
bl
Add the SCB onto the scsi command allocation and use dma streaming
mappings for it only when in use. This avoid possibly calling
dma_alloc_coherent under a lock or even in irq context, while also
making the code simpler.
Thanks to Ondrej Zary for testing and various bug fixes.
Signed-off-by: Chr
Add the SCB onto the scsi command allocation and use dma streaming
mappings for it only when in use. This avoid possibly calling
dma_alloc_coherent under a lock or even in irq context, while also
making the code simpler.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/wd719x.c | 95 ++
@@ get_children_pid(struct inode *inode, struct pid
*pid_prev, loff_t pos)
static int children_seq_show(struct seq_file *seq, void *v)
{
- seq_printf(seq, "%d ", pid_nr_ns(v, proc_pid_ns(seq->private)));
+ struct inode *inode = file_inode(seq->file);
+
+ seq_printf(seq, &q
(struct inode *inode, struct pid *pid_prev,
loff_t pos)
static int children_seq_show(struct seq_file *seq, void *v)
{
- struct inode *inode = seq->private;
+ struct inode *inode = file_inode(seq->file);
pid_t pid;
pid = pid_nr_ns(v, inode->i_sb-&
(struct inode *inode, struct pid *pid_prev,
loff_t pos)
static int children_seq_show(struct seq_file *seq, void *v)
{
- struct inode *inode = seq->private;
+ struct inode *inode = file_inode(seq->file);
pid_t pid;
pid = pid_nr_ns(v, inode->i_sb-&
> Il giorno 17 apr 2018, alle ore 23:42, Kees Cook ha
> scritto:
>
> Some elevators may not correctly check rq->rq_flags & RQF_ELVPRIV, and
> may attempt to read rq->elv fields. When requests got reused, this
> caused BFQ to think it already had a bfqq (rq->elv.priv[1]) allocated.
Hi Kees,
wh
On 4/17/18 4:57 PM, Kees Cook wrote:
> On Tue, Apr 17, 2018 at 2:45 PM, Jens Axboe wrote:
>> On 4/17/18 3:42 PM, Kees Cook wrote:
>>> Some elevators may not correctly check rq->rq_flags & RQF_ELVPRIV, and
>>> may attempt to read rq->elv fields. When requests got reused, this
>>> caused BFQ to thin
On Tue, Apr 17, 2018 at 2:45 PM, Jens Axboe wrote:
> On 4/17/18 3:42 PM, Kees Cook wrote:
>> Some elevators may not correctly check rq->rq_flags & RQF_ELVPRIV, and
>> may attempt to read rq->elv fields. When requests got reused, this
>> caused BFQ to think it already had a bfqq (rq->elv.priv[1]) a
On 4/17/18 3:42 PM, Kees Cook wrote:
> Some elevators may not correctly check rq->rq_flags & RQF_ELVPRIV, and
> may attempt to read rq->elv fields. When requests got reused, this
> caused BFQ to think it already had a bfqq (rq->elv.priv[1]) allocated.
> This could lead to odd behaviors like having
Some elevators may not correctly check rq->rq_flags & RQF_ELVPRIV, and
may attempt to read rq->elv fields. When requests got reused, this
caused BFQ to think it already had a bfqq (rq->elv.priv[1]) allocated.
This could lead to odd behaviors like having the sense buffer address
slowly start increme
Andy,
> The function sas_parse_addr() could be easily substituted by hex2bin()
> which is in kernel library code.
Applied to 4.16/scsi-queue. Thank you!
--
Martin K. Petersen Oracle Linux Engineering
在 2017/12/20 1:37, Andy Shevchenko 写道:
The function sas_parse_addr() could be easily substituted by hex2bin() which is
in kernel library code.
Cc: Christoph Hellwig
Signed-off-by: Andy Shevchenko
Tested-by: Xiang Chen
---
drivers/scsi/libsas/sas_scsi_host.c | 20
1
The function sas_parse_addr() could be easily substituted by hex2bin() which is
in kernel library code.
Cc: Christoph Hellwig
Signed-off-by: Andy Shevchenko
---
drivers/scsi/libsas/sas_scsi_host.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/
When the HBA is connected to a private loop, the driver
reports FLOGI loop-open failure as functional error. This is
an expected condition.
Mark loop-open failure as a warning instead of error.
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
Reviewed-by: Hannes Reinecke
---
drivers
On 11/10/2017 02:08 AM, James Smart wrote:
> When the HBA is connected to a private loop, the driver
> reports FLOGI loop-open failure as functional error. This is
> an expected condition.
>
> Mark loop-open failure as a warning instead of error.
>
> Signed-off-by: Dick Ken
When the HBA is connected to a private loop, the driver
reports FLOGI loop-open failure as functional error. This is
an expected condition.
Mark loop-open failure as a warning instead of error.
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
---
v2:
Reworked printf. v1 printed 2
On 11/8/2017 1:05 AM, Hannes Reinecke wrote:
Isn't that a bit excessive?
Printing the same message _two_ times, and not providing additional info?
Please do only duplicate message if there is new information printed;
otherwise we might as well skip the second message.
Cheers,
Hannes
yep. will
On 11/03/2017 11:56 PM, James Smart wrote:
> When the HBA is connected to a private loop, the driver
> reports FLOGI loop-open failure as functional error. This is
> an expected condition.
>
> Mark loop-open failure as a warning instead of error.
>
> Signed-off-by: Dick Ken
When the HBA is connected to a private loop, the driver
reports FLOGI loop-open failure as functional error. This is
an expected condition.
Mark loop-open failure as a warning instead of error.
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
---
drivers/scsi/lpfc/lpfc_els.c | 35
There's no need to keep the private data for a device in a separate
list; better to store it in ->hostdata and do away with the additional
list.
Signed-off-by: Hannes Reinecke
Reviewed-by: David Kershner
---
drivers/staging/unisys/visorhba/visorhba_main.c | 123 ++--
On 07/19/2017 07:45 PM, Kershner, David A wrote:
>
>
>> -Original Message-
>> From: Hannes Reinecke [mailto:h...@suse.de]
>> Sent: Wednesday, June 28, 2017 4:25 AM
>> To: Christoph Hellwig
>> Subject: [PATCH 26/28] visorhba: sanitze private device d
> Subject: [PATCH 26/28] visorhba: sanitze private device data allocation
>
> There's no need to keep the private data for a device in a separate
> list; better to store it in ->hostdata and do away with the additional
> list.
>
> Signed-off-by: Hannes Reinecke
>
There's no need to keep the private data for a device in a separate
list; better to store it in ->hostdata and do away with the additional
list.
Signed-off-by: Hannes Reinecke
Cc: David Kershner
---
drivers/staging/unisys/visorhba/visorhba_main.c | 123 ++--
1 file
On Fri, Jun 23, 2017 at 03:02:26PM +0200, Hannes Reinecke wrote:
> There's no need to keep the private data for a device in a separate
> list; better to store it in ->hostdata and do away with the additional
> list.
Nice improvement, although that driver is a complete mess.. And
There's no need to keep the private data for a device in a separate
list; better to store it in ->hostdata and do away with the additional
list.
Signed-off-by: Hannes Reinecke
---
drivers/staging/unisys/visorhba/visorhba_main.c | 123 ++--
1 file changed, 53 in
From: "Matthew R. Ochs"
The SCSI core now zeroes the per-command private data area prior to
calling into the LLD. Replace the clearing operation that takes place
when the private command data reference is obtained with a routine that
performs common initializations. The zeroing that t
Since the SCSI core zeroes driver-private command data, remove
that code from the xen-scsifront driver.
Signed-off-by: Bart Van Assche
Reviewed-by: Hannes Reinecke
Reviewed-by: Juergen Gross
Reviewed-by: Christoph Hellwig
Cc: xen-de...@lists.xenproject.org
Cc: Johannes Thumshirn
---
drivers
Since the SCSI core zeroes driver-private command data, remove
that code from the snic driver.
Signed-off-by: Bart Van Assche
Reviewed-by: Hannes Reinecke
Reviewed-by: Narsimhulu Musini
Reviewed-by: Christoph Hellwig
Cc: Sesidhar Baddela
Cc: Johannes Thumshirn
---
drivers/scsi/snic
Since the SCSI core zeroes driver-private command data, remove
that code from the virtio driver.
Signed-off-by: Bart Van Assche
Reviewed-by: Hannes Reinecke
Reviewed-by: Christoph Hellwig
Cc: Michael S. Tsirkin
Cc: Johannes Thumshirn
---
drivers/scsi/virtio_scsi.c | 1 -
1 file changed, 1
On Fri, 2017-06-02 at 09:23 +0200, Christoph Hellwig wrote:
> Nit: the driver name is virtio_scsi, not just virtio.
Hello Christoph,
I will update the patch title.
Bart.
Looks fine,
Reviewed-by: Christoph Hellwig
Nit: the driver name is virtio_scsi, not just virtio.
Otherwise this looks fine:
Reviewed-by: Christoph Hellwig
Looks fine,
Reviewed-by: Christoph Hellwig
Since the SCSI core zeroes driver-private command data, remove
that code from the virtio driver.
Signed-off-by: Bart Van Assche
Reviewed-by: Hannes Reinecke
Cc: Michael S. Tsirkin
Cc: Christoph Hellwig
Cc: Johannes Thumshirn
---
drivers/scsi/virtio_scsi.c | 1 -
1 file changed, 1 deletion
Since the SCSI core zeroes driver-private command data, remove
that code from the xen-scsifront driver.
Signed-off-by: Bart Van Assche
Reviewed-by: Hannes Reinecke
Reviewed-by: Juergen Gross
Cc: xen-de...@lists.xenproject.org
Cc: Johannes Thumshirn
---
drivers/scsi/xen-scsifront.c | 1 -
1
Since the SCSI core zeroes driver-private command data, remove
that code from the snic driver.
Signed-off-by: Bart Van Assche
Reviewed-by: Hannes Reinecke
Cc: Narsimhulu Musini
Cc: Sesidhar Baddela
Cc: Christoph Hellwig
Cc: Johannes Thumshirn
---
drivers/scsi/snic/snic_scsi.c | 2 --
1
On 24/05/17 02:34, Bart Van Assche wrote:
> Since the SCSI core zeroes driver-private command data, remove
> that code from the xen-scsifront driver.
>
> Signed-off-by: Bart Van Assche
> Cc: Juergen Gross
> Cc: xen-de...@lists.xenproject.org
Reviewed-by: Juergen Gross
Thanks,
Juergen
On 05/24/2017 02:34 AM, Bart Van Assche wrote:
> Since the SCSI core zeroes driver-private command data, remove
> that code from the xen-scsifront driver.
>
> Signed-off-by: Bart Van Assche
> Cc: Juergen Gross
> Cc: xen-de...@lists.xenproject.org
> ---
> drivers/scsi/xe
On 05/24/2017 02:34 AM, Bart Van Assche wrote:
> Since the SCSI core zeroes driver-private command data, remove
> that code from the virtio driver.
>
> Signed-off-by: Bart Van Assche
> Cc: Michael S. Tsirkin
> Cc: Christoph Hellwig
> Cc: Hannes Reinecke
> ---
> dri
On 05/24/2017 02:34 AM, Bart Van Assche wrote:
> Since the SCSI core zeroes driver-private command data, remove
> that code from the snic driver.
>
> Signed-off-by: Bart Van Assche
> Cc: Narsimhulu Musini
> Cc: Sesidhar Baddela
> Cc: Christoph Hellwig
> Cc: Hannes Re
On 05/24/2017 02:34 AM, Bart Van Assche wrote:
> This patch does not change any functionality but avoids duplication
> of the code for clearing driver-private command data.
>
> Signed-off-by: Bart Van Assche
> Cc: Christoph Hellwig
> Cc: Hannes Reinecke
> ---
> dri
On 05/24/2017 02:34 AM, Bart Van Assche wrote:
> Since the cdrom driver only supports request queues for which
> struct scsi_request is the first member of their private request
> data, refuse to register block layer queues for which this is
> not the case.
>
> References: c
On 05/24/2017 02:34 AM, Bart Van Assche wrote:
> Since using scsi_req() is only allowed against request queues for
> which struct scsi_request is the first member of their private
> request data, refuse to submit SCSI commands against a queue for
> which this is not the case.
>
Since the SCSI core zeroes driver-private command data, remove
that code from the virtio driver.
Signed-off-by: Bart Van Assche
Cc: Michael S. Tsirkin
Cc: Christoph Hellwig
Cc: Hannes Reinecke
---
drivers/scsi/virtio_scsi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi
Since using scsi_req() is only allowed against request queues for
which struct scsi_request is the first member of their private
request data, refuse to submit SCSI commands against a queue for
which this is not the case.
References: commit 82ed4db499b8 ("block: split scsi_request out of s
This patch does not change any functionality but avoids duplication
of the code for clearing driver-private command data.
Signed-off-by: Bart Van Assche
Cc: Christoph Hellwig
Cc: Hannes Reinecke
---
drivers/scsi/scsi_lib.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
Since the SCSI core zeroes driver-private command data, remove
that code from the snic driver.
Signed-off-by: Bart Van Assche
Cc: Narsimhulu Musini
Cc: Sesidhar Baddela
Cc: Christoph Hellwig
Cc: Hannes Reinecke
---
drivers/scsi/snic/snic_scsi.c | 2 --
1 file changed, 2 deletions(-)
diff
Since the SCSI core zeroes driver-private command data, remove
that code from the xen-scsifront driver.
Signed-off-by: Bart Van Assche
Cc: Juergen Gross
Cc: xen-de...@lists.xenproject.org
---
drivers/scsi/xen-scsifront.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/xen
Since the cdrom driver only supports request queues for which
struct scsi_request is the first member of their private request
data, refuse to register block layer queues for which this is
not the case.
References: commit 82ed4db499b8 ("block: split scsi_request out of struct
request&quo
On Sun, 2017-05-21 at 08:51 +0200, Christoph Hellwig wrote:
> On Fri, May 19, 2017 at 11:30:13AM -0700, Bart Van Assche wrote:
> > The storvsc driver is the only SCSI LLD that uses driver-private
> > command data and that does not zero-initialize that data before
> > reading
On Sun, May 21, 2017 at 02:33:05PM +, Bart Van Assche wrote:
> Thanks for the review comments. The cover letter should have made it to at
> least the linux-scsi mailing list since it shows up in at least one archive of
> that mailing list: https://www.spinics.net/lists/linux-scsi/msg108940.html
On Sun, 2017-05-21 at 08:32 +0200, Christoph Hellwig wrote:
> And btw, I didn't get your cover letter [0/18], did that get lost
> somewhere?
Hello Christoph,
Thanks for the review comments. The cover letter should have made it to at
least the linux-scsi mailing list since it shows up in at least
On Fri, May 19, 2017 at 11:30:13AM -0700, Bart Van Assche wrote:
> The storvsc driver is the only SCSI LLD that uses driver-private
> command data and that does not zero-initialize that data before
> reading it. Make this driver consistent with the other SCSI LLDs
> that use driver-pri
Hi Bart,
I think this is the wrong kind of check - while we do care about the
size of the queue, we only do it as a side effect of the queue
being able to handle REQ_OP_SCSI_IN/REQ_OP_SCSI_OUT commands.
I think we'll need a flag for those in the queue instead.
And btw, I didn't get your cover le
ACK as far as I'm concerned.--b.
On Fri, May 19, 2017 at 11:30:03AM -0700, Bart Van Assche wrote:
> Since using scsi_req() is only allowed against request queues for which
> struct scsi_request is the first member of their private request
> data, refuse to register block layer qu
Since the pktcdvd driver only supports request queues for which
struct scsi_request is the first member of their private request
data, refuse to register block layer queues for which the private
data is smaller than struct scsi_request.
References: commit 82ed4db499b8 ("block: split scsi_re
Since the cdrom driver only supports request queues for which
struct scsi_request is the first member of their private request
data, refuse to register block layer queues for which the private
data is smaller than struct scsi_request.
References: commit 82ed4db499b8 ("block: split scsi_re
The storvsc driver is the only SCSI LLD that uses driver-private
command data and that does not zero-initialize that data before
reading it. Make this driver consistent with the other SCSI LLDs
that use driver-private command data.
Signed-off-by: Bart Van Assche
Cc: Christoph Hellwig
Cc: Hannes
Since using scsi_req() is only allowed against request queues for which
struct scsi_request is the first member of their private request
data, refuse to register block layer queues for which the private
data is smaller than struct scsi_request.
References: commit 82ed4db499b8 ("block:
Since BSG only supports request queues for which struct scsi_request
is the first member of their private request data, refuse to register
block layer queues for which the private data is smaller than struct
scsi_request.
References: commit bd1599d931ca ("scsi_transport_sas: fix BSG ioctl m
Long,
> In lower layer driver's (LLD) scsi_host_template, the driver may
> optionally ask SCSI to allocate its private driver memory for each
> command, by specifying cmd_size. This memory is allocated at the end
> of scsi_cmnd by SCSI. Later when SCSI queues a command,
From: Long Li
In lower layer driver's (LLD) scsi_host_template, the driver may optionally
ask SCSI to allocate its private driver memory for each command, by
specifying cmd_size. This memory is allocated at the end of scsi_cmnd by SCSI.
Later when SCSI queues a command, the LLD ca
Currently it's used by the lighnvm passthrough ioctl, but we'd like to make
it private in preparation of block layer specific error code. Lighnvm already
returns the real NVMe status anyway, so I think we can just limit it to
returning -EIO for any status set.
This will need a careful
Currently it's used by the lighnvm passthrough ioctl, but we'd like to make
it private in preparation of block layer specific error code. Lighnvm already
returns the real NVMe status anyway, so I think we can just limit it to
returning -EIO for any status set.
This will need a careful
From: Christoph Hellwig
Currently it's used by the lighnvm passthrough ioctl, but we'd like to make
it private in preparation of block layer specific error code. Lighnvm already
returns the real NVMe status anyway, so I think we can just limit it to
returning -EIO for any status set.
Currently it's used by the lighnvm passthrough ioctl, but we'd like to make
it private in preparation of block layer specific error code. Lighnvm already
returns the real NVMe status anyway, so I think we can just limit it to
returning -EIO for any status set.
This will need a careful
From: "Matthew R. Ochs"
Clean up and remove the remaining private command pool infrastructure
that is no longer required.
Signed-off-by: Matthew R. Ochs
Acked-by: Uma Krishnan
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of
This looks good !
From: "Matthew R. Ochs"
Instead of using a private pool of AFU commands, use cmd_size to prime
the private pool of SCSI commands such that they are allocated with a
size large enough to contain an aligned AFU command. Use scsi_cmd_priv()
to derive the aligned/zero
From: "Matthew R. Ochs"
Instead of using a private pool of AFU commands, use cmd_size to prime
the private pool of SCSI commands such that they are allocated with a
size large enough to contain an aligned AFU command. Use scsi_cmd_priv()
to derive the aligned/zeroed private
From: "Matthew R. Ochs"
Clean up and remove the remaining private command pool infrastructure
that is no longer required.
Signed-off-by: Matthew R. Ochs
---
drivers/scsi/cxlflash/common.h | 7 -
drivers/scsi/cxlflash/main.c | 68 -
From: "Matthew R. Ochs"
Instead of using a private pool of AFU commands, use cmd_size to prime
the private pool of SCSI commands such that they are allocated with a
size large enough to contain an aligned AFU command. Use scsi_cmd_priv()
to derive the aligned/zeroed private
From: "Matthew R. Ochs"
Clean up and remove the remaining private command pool infrastructure
that is no longer required.
Signed-off-by: Matthew R. Ochs
---
drivers/scsi/cxlflash/common.h | 7 -
drivers/scsi/cxlflash/main.c | 68 -
On Mon, Oct 10, 2016 at 12:46:53AM -0400, Finn Thain wrote:
> The various 5380 drivers inconsistently store register pointers
> either in the Scsi_Host struct "legacy crap" area or in special,
> board-specific members of the NCR5380_hostdata struct. Uniform
> use of the latter struct makes for simp
The various 5380 drivers inconsistently store register pointers
either in the Scsi_Host struct "legacy crap" area or in special,
board-specific members of the NCR5380_hostdata struct. Uniform
use of the latter struct makes for simpler and faster code (see
the following patches) and helps to reduce
The various 5380 drivers inconsistently store register pointers
either in the Scsi_Host struct "legacy crap" area or in special,
board-specific members of the NCR5380_hostdata struct. Uniform
use of the latter struct makes for simpler and faster code (see
the following patches) and helps to reduce
The various 5380 drivers inconsistently store register pointers
either in the Scsi_Host struct "legacy crap" area or in special,
board-specific members of the NCR5380_hostdata struct. Uniform
use of the latter struct makes for simpler and faster code (see
the following patches) and helps to reduce
The function sas_parse_addr() could be easily substituted by hex2bin() which is
in kernel library code.
Cc: Christoph Hellwig
Signed-off-by: Andy Shevchenko
---
drivers/scsi/libsas/sas_scsi_host.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/driver
Hi Johannes,
On 1/28/16, 12:59 AM, "Johannes Thumshirn" wrote:
>On Wed, Jan 27, 2016 at 12:03:33PM -0500, Himanshu Madhani wrote:
>> From: Harish Zunjarrao
>>
>> Signed-off-by: Harish Zunjarrao
>> Signed-off-by: Himanshu Madhani
>> ---
>> drivers/scsi/qla2xxx/qla_attr.c |6 ++-
>> dr
On Wed, Jan 27, 2016 at 12:03:33PM -0500, Himanshu Madhani wrote:
> From: Harish Zunjarrao
>
> Signed-off-by: Harish Zunjarrao
> Signed-off-by: Himanshu Madhani
> ---
> drivers/scsi/qla2xxx/qla_attr.c |6 ++-
> drivers/scsi/qla2xxx/qla_bsg.c | 61
> +
From: Harish Zunjarrao
Signed-off-by: Harish Zunjarrao
Signed-off-by: Himanshu Madhani
---
drivers/scsi/qla2xxx/qla_attr.c |6 ++-
drivers/scsi/qla2xxx/qla_bsg.c | 61 +++
drivers/scsi/qla2xxx/qla_bsg.h |1 +
drivers/scsi/qla2xxx/qla_dbg.c |
On 01/26/2016 06:10 PM, Himanshu Madhani wrote:
> From: Harish Zunjarrao
>
> Signed-off-by: Harish Zunjarrao
> Signed-off-by: Himanshu Madhani
> ---
> drivers/scsi/qla2xxx/qla_attr.c |6 ++-
> drivers/scsi/qla2xxx/qla_bsg.c | 61
> +++
> drivers/scsi
From: Harish Zunjarrao
Signed-off-by: Harish Zunjarrao
Signed-off-by: Himanshu Madhani
---
drivers/scsi/qla2xxx/qla_attr.c |6 ++-
drivers/scsi/qla2xxx/qla_bsg.c | 61 +++
drivers/scsi/qla2xxx/qla_bsg.h |1 +
drivers/scsi/qla2xxx/qla_dbg.c |
Signed-off-by: Christoph Hellwig
Reviewed-by: Hannes Reinecke
---
drivers/scsi/device_handler/scsi_dh_alua.c | 25 +
drivers/scsi/device_handler/scsi_dh_emc.c | 24 ++--
drivers/scsi/device_handler/scsi_dh_hp_sw.c | 23 +--
drive
1 - 100 of 129 matches
Mail list logo
