From: Stephen M. Cameron
Ages ago, drivers could return values greater than zero from
their probe function and this would be regarded as success.
Commit f3ec4f87d607f40497 "PCI: change device runtime PM
settings for probe and remove" slightly altered this in 2010,
Just resending the patch with a better change log message (as requested
by Andrew Morton) and cc'ing sta...@vger.kernel.org, (as I originally
had intended.)
---
Stephen M. Cameron (1):
cciss: return 0 from driver probe function on success, not 1
drivers/block/cciss.c |2 +-
1 files
From: Stephen M. Cameron
A return value of 1 is interpreted as an error. See pci_driver.
in local_pci_probe(). If you're wondering how this ever could
have worked, it's because it used to be the case that only return
values less than zero were interpreted as failure. But even in
the current
From: Stephen M. Cameron scame...@beardog.cce.hp.com
A return value of 1 is interpreted as an error. See pci_driver.
in local_pci_probe(). If you're wondering how this ever could
have worked, it's because it used to be the case that only return
values less than zero were interpreted as failure
Just resending the patch with a better change log message (as requested
by Andrew Morton) and cc'ing sta...@vger.kernel.org, (as I originally
had intended.)
---
Stephen M. Cameron (1):
cciss: return 0 from driver probe function on success, not 1
drivers/block/cciss.c |2 +-
1 files
From: Stephen M. Cameron scame...@beardog.cce.hp.com
Ages ago, drivers could return values greater than zero from
their probe function and this would be regarded as success.
Commit f3ec4f87d607f40497 PCI: change device runtime PM
settings for probe and remove slightly altered this in 2010
From: Stephen M. Cameron
A return value of 1 is interpreted as an error
Signed-off-by: Stephen M. Cameron
---
drivers/block/cciss.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index edfa251..0c004ac 100644
From: Stephen M. Cameron scame...@beardog.cce.hp.com
A return value of 1 is interpreted as an error
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/block/cciss.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/block/cciss.c b/drivers
From: Stephen M. Cameron
If a new logical drive is added and the CCISS_REGNEWD ioctl is invoked
(as is normal with the Array Configuration Utility) the process
will hang as below. It attempts to acquire the same mutex twice, once
in do_ioctl() and once in cciss_unlocked_open(). The BKL
From: Stephen M. Cameron scame...@beardog.cce.hp.com
If a new logical drive is added and the CCISS_REGNEWD ioctl is invoked
(as is normal with the Array Configuration Utility) the process
will hang as below. It attempts to acquire the same mutex twice, once
in do_ioctl() and once
From: Stephen M. Cameron
Currently, when adding a new block device driver, if grub support is needed,
then grub needs to be modified to know about this new driver.
See this thread:
https://lists.gnu.org/archive/html/grub-devel/2013-03/msg00049.html
If block drivers could (optionally) share
From: Stephen M. Cameron scame...@beardog.cce.hp.com
Currently, when adding a new block device driver, if grub support is needed,
then grub needs to be modified to know about this new driver.
See this thread:
https://lists.gnu.org/archive/html/grub-devel/2013-03/msg00049.html
If block drivers
From: Stephen M. Cameron
Currently, when adding a new block device driver, if grub support is needed,
then grub needs to be modified to know about this new driver.
See this thread:
https://lists.gnu.org/archive/html/grub-devel/2013-03/msg00049.html
If block drivers could (optionally) share
From: Stephen M. Cameron scame...@beardog.cce.hp.com
Currently, when adding a new block device driver, if grub support is needed,
then grub needs to be modified to know about this new driver.
See this thread:
https://lists.gnu.org/archive/html/grub-devel/2013-03/msg00049.html
If block drivers
From: Stephen M. Cameron
This is really the merest sketch of an idea, I'm not asking that
this patch be taken in its current form, just asking for feedback
on the idea, and if someone else better acquainted with the block
layer wants to take this idea and implement it in a better, proper
way
From: Stephen M. Cameron scame...@beardog.cce.hp.com
This is really the merest sketch of an idea, I'm not asking that
this patch be taken in its current form, just asking for feedback
on the idea, and if someone else better acquainted with the block
layer wants to take this idea and implement
From: Stephen M. Cameron
Signed-off-by: Stephen M. Cameron
---
drivers/scsi/hpsa.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 4217e49..469ba9b 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -54,7
From: Stephen M. Cameron
In the scsi part of the driver (for tape drives and medium changers)
the device reset error handler attempts to use a target reset rather
than a lun reset. If there is some shared tape drive library, this
could be potentially disruptive to other hosts trying to use
From: Stephen M. Cameron scame...@beardog.cce.hp.com
In the scsi part of the driver (for tape drives and medium changers)
the device reset error handler attempts to use a target reset rather
than a lun reset. If there is some shared tape drive library, this
could be potentially disruptive
From: Stephen M. Cameron scame...@beardog.cce.hp.com
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 4217e49..469ba9b 100644
From: Stephen M. Cameron
If a command completes with a status of CMD_PROTOCOL_ERR, this
information should be conveyed to the SCSI mid layer, not dropped
on the floor. Unlike a similar bug in the hpsa driver, this bug
only affects tape drives and CD and DVD ROM drives in the cciss
driver
From: Stephen M. Cameron
If a command status of CMD_PROTOCOL_ERR is received, this
information should be conveyed to the SCSI mid layer, not
dropped on the floor. CMD_PROTOCOL_ERR may be received
from the Smart Array for any commands destined for an external
RAID controller such as a P2000
From: Stephen M. Cameron scame...@beardog.cce.hp.com
If a command status of CMD_PROTOCOL_ERR is received, this
information should be conveyed to the SCSI mid layer, not
dropped on the floor. CMD_PROTOCOL_ERR may be received
from the Smart Array for any commands destined for an external
RAID
From: Stephen M. Cameron scame...@beardog.cce.hp.com
If a command completes with a status of CMD_PROTOCOL_ERR, this
information should be conveyed to the SCSI mid layer, not dropped
on the floor. Unlike a similar bug in the hpsa driver, this bug
only affects tape drives and CD and DVD ROM drives
From: Stephen M. Cameron
I think ioremap() ends up being equivalent to ioremap_nocache
by default, but we should signal our intent that these mappings
should be non-cacheable.
Signed-off-by: Stephen M. Cameron
---
drivers/scsi/hpsa.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions
been
a stupid thing to do.
The other two patches are very minor.
---
Stephen M. Cameron (3):
hpsa: Use LUN reset instead of target reset
hpsa: fix incorrect abort diagnostic message
hpsa: use ioremap_nocache instead of ioremap
drivers/scsi/hpsa.c |7 ---
1 files
From: Stephen M. Cameron
In the abort handler, when asked to abort a command which
is not known to the driver, SUCCESS is returned, but the
diagnostic message incorrectly indicates the abort failed.
Signed-off-by: Stephen M. Cameron
---
drivers/scsi/hpsa.c |2 +-
1 files changed, 1
From: Stephen M. Cameron
It turns out Smart Array logical drives do not support target
reset and when the target reset fails, the logical drive will
be taken off line. Symptoms look like this:
hpsa :03:00.0: Abort request on C1:B0:T0:L0
hpsa :03:00.0: resetting device 1:0:0:0
hpsa
From: Stephen M. Cameron scame...@beardog.cce.hp.com
It turns out Smart Array logical drives do not support target
reset and when the target reset fails, the logical drive will
be taken off line. Symptoms look like this:
hpsa :03:00.0: Abort request on C1:B0:T0:L0
hpsa :03:00.0
From: Stephen M. Cameron scame...@beardog.cce.hp.com
In the abort handler, when asked to abort a command which
is not known to the driver, SUCCESS is returned, but the
diagnostic message incorrectly indicates the abort failed.
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
been
a stupid thing to do.
The other two patches are very minor.
---
Stephen M. Cameron (3):
hpsa: Use LUN reset instead of target reset
hpsa: fix incorrect abort diagnostic message
hpsa: use ioremap_nocache instead of ioremap
drivers/scsi/hpsa.c |7 ---
1 files
From: Stephen M. Cameron scame...@beardog.cce.hp.com
I think ioremap() ends up being equivalent to ioremap_nocache
by default, but we should signal our intent that these mappings
should be non-cacheable.
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c
32 matches
Mail list logo
