scsi fixes for 2.6.25-rc2
James Bottomley
maintainerPATCH 1/1 scsi fixes for 2.6.25-rc2
This is the latest crop of bug fixes plus one new driver: mvsas. We're still in the throes of trying to fix aic94xx/libsas error handling, so the fix here isn't complete (but it is much better than before).
The patch is available here:
master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git
The short changelog is:
Adrian Bunk (4):
qlogicpt: section fixes
mptbase: fix use-after-free's
iscsi transport: make 2 functions static
lpfc: make lpfc_disable_node() static
Alan Cox (1):
megaraid: outb_p extermination
Daniel Drake (1):
arcmsr: fix message allocation
David Somayajulu (1):
qla4xxx: fix up residual handling
FUJITA Tomonori (5):
stex: stex_internal_copy should be called with sg_count in struct st_ccb
stex: stex_direct_copy shouldn't call dma_map_sg
ips: fix data buffer accessors conversion bug
qla2xxx: fix compile warning for printk format
scsi_debug: disable clustering
James Bottomley (7):
libsas: correctly flush the LU queue on error recovery
aic94xx: fix sequencer hang on error recovery
libsas: fix error handling
gdth: don't call pci_free_consistent under spinlock
aic7xx: mitigate HOST_MSG_LOOP invalid SCB ff panic
fas216: fix up the previous fas216 commit
aic94xx: fix REQ_TASK_ABORT and REQ_DEVICE_RESET
Jeff Garzik (1):
mvsas: Add Marvell 6440 SAS/SATA driver
Kai Makisara (1):
st: compile fix when DEBUG set to one
Ke Wei (1):
mvsas: convert from rough draft to working driver
Kyle McMartin (1):
mpt fusion: kill warnings in mptbase.h on parisc64
Matthew Wilcox (1):
lpfc: Balance locking
Yinghai Lu (1):
ses: fix data corruption
And the diffstat:
drivers/message/fusion/mptbase.c | 4 drivers/message/fusion/mptbase.h | 2 drivers/scsi/Kconfig | 10 drivers/scsi/Makefile | 1 drivers/scsi/aic7xxx/aic7xxx_core.c | 11 drivers/scsi/aic94xx/aic94xx_scb.c | 14 drivers/scsi/aic94xx/aic94xx_tmf.c | 4 drivers/scsi/arcmsr/arcmsr_hba.c | 26 drivers/scsi/arm/fas216.h | 2 drivers/scsi/gdth_proc.c | 6 drivers/scsi/ips.c | 2 drivers/scsi/libsas/sas_scsi_host.c | 68 drivers/scsi/lpfc/lpfc_crtn.h | 1 drivers/scsi/lpfc/lpfc_hbadisc.c | 2 drivers/scsi/lpfc/lpfc_sli.c | 18 drivers/scsi/megaraid.c | 10 drivers/scsi/mvsas.c | 2981 ++++++++++++++++++++++++++++++++++++ drivers/scsi/qla2xxx/qla_dfs.c | 2 drivers/scsi/qla4xxx/ql4_isr.c | 3 drivers/scsi/qlogicpti.c | 12 drivers/scsi/scsi_debug.c | 2 drivers/scsi/scsi_transport_iscsi.c | 4 drivers/scsi/ses.c | 126 - drivers/scsi/st.c | 11 drivers/scsi/st.h | 1 drivers/scsi/stex.c | 44 26 files changed, 3184 insertions(+), 183 deletions(-)
James
Quoted 1 line · James Bottomley
This is the latest crop of bug fixes plus one new driver: mvsas. We're
[...]
Quoted 2 lines
Jeff Garzik (1):
mvsas: Add Marvell 6440 SAS/SATA driver
[...]
Quoted 2 lines
Ke Wei (1):
mvsas: convert from rough draft to working driver
I know I am probably shooting myself in the foot here, since I am the original author of mvsas, but...
Should we be adding new drivers during -rc?
On one hand, it's clear the addition does not break anything, and adds value for users.
On the other hand, it's clearly not a bug fix, and -rc could easily get bloated with new drivers that didn't make the merge window.
On the net driver side of things, I have a few new net drivers that I have queued for 2.6.26, because they did not make the merge window. This is inconsistent with your apparently policy.
I would just prefer to have a clear and consistent policy here, regarding new drivers during -rc.
Thanks,
Jeff
Quoted 1 line · Jeff Garzik
On the net driver side of things, I have a few new net drivers that I have queued for 2.6.26, because they did not make the merge window. This is inconsistent with your apparently policy.
s/apparently/apparent/
Sometimes my fingers don't type the words that come out of my brain :)
Jeff
Quoted 5 lines · Jeff Garzik
I know I am probably shooting myself in the foot here, since I am the original author of mvsas, but...
Should we be adding new drivers during -rc?
I'm personally of the opinion that a new driver that doesn't add anything but itself (ie no infrastructure changes etc) is fine. I'd rather have a new, rough driver that might work, than no driver at all, and it's not like it can cause a regression if you don't enable it.
Linus
Quoted 7 lines · On Sat, 23 Feb 2008 12:31:02 -0800 (PST) Linus Torvalds…
Quoted 4 lines · Jeff Garzik
I know I am probably shooting myself in the foot here, since I am the original author of mvsas, but...
Quoted 7 lines
Quoted 1 line
Should we be adding new drivers during -rc?
I'm personally of the opinion that a new driver that doesn't add anything but itself (ie no infrastructure changes etc) is fine. I'd rather have a new, rough driver that might work, than no driver at all, and it's not like it can cause a regression if you don't enable it.
Yes, I too think that adding new standalone code in late -rc is OK.
Especially drivers, because a new driver is a bugfix for people who own that hardware!
Quoted 4 lines · Andrew Morton
Quoted 2 lines · On Sat, 23 Feb 2008 12:31:02 -0800 (PST) Linus Torvalds…
On Sat, 23 Feb 2008, Jeff Garzik wrote:
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
I know I am probably shooting myself in the foot here, since I am the original author of mvsas, but...
Should we be adding new drivers during -rc?
I'm personally of the opinion that a new driver that doesn't add anything but itself (ie no infrastructure changes etc) is fine. I'd rather have a new, rough driver that might work, than no driver at all, and it's not like it can cause a regression if you don't enable it.
Yes, I too think that adding new standalone code in late -rc is OK.
ACK, thanks!
Jeff
James Bottomley
maintainerQuoted 6 lines · Linus Torvalds
Quoted 4 lines · Jeff Garzik
I know I am probably shooting myself in the foot here, since I am the original author of mvsas, but...
Quoted 6 lines
Quoted 1 line
Should we be adding new drivers during -rc?
I'm personally of the opinion that a new driver that doesn't add anything but itself (ie no infrastructure changes etc) is fine. I'd rather have a new, rough driver that might work, than no driver at all, and it's not like it can cause a regression if you don't enable it.
That is the case for this one. The two patches only touch the mvsas.c file (and Makefile and Kconfig to build it, of course).
James
Quoted 5 lines · Linus Torvalds
I'm personally of the opinion that a new driver that doesn't add anything but itself (ie no infrastructure changes etc) is fine. I'd rather have a new, rough driver that might work, than no driver at all, and it's not like it can cause a regression if you don't enable it.
Maybe we can still get the new S-35390A RTC driver in then. It has been acked by Jean Delvare and David Brownell. Byron or Jean, can you try to submit it again?
It's needed by the QNAP TS-109/TS-209, a NAS device for which support has been added in 2.6.25-rc1.
Signature · 2 lines
Martin Michlmayr http://www.cyrius.com/
Quoted 8 lines · Martin Michlmayr
Quoted 5 lines · Linus Torvalds
I'm personally of the opinion that a new driver that doesn't add anything but itself (ie no infrastructure changes etc) is fine. I'd rather have a new, rough driver that might work, than no driver at all, and it's not like it can cause a regression if you don't enable it.
Quoted 6 lines
Maybe we can still get the new S-35390A RTC driver in then. It has been acked by Jean Delvare and David Brownell. Byron or Jean, can you try to submit it again?
It's needed by the QNAP TS-109/TS-209, a NAS device for which support has been added in 2.6.25-rc1.
I can send it again if needed but it's already in -mm and I assume it would go through Andrew anyway. It would be great to get this in for 2.6.25 so if a resend is needed let me know.
Cheers,
Signature · 1 line
Byron Bradley
Quoted 10 lines · Martin Michlmayr
Quoted 5 lines · Linus Torvalds
I'm personally of the opinion that a new driver that doesn't add anything but itself (ie no infrastructure changes etc) is fine. I'd rather have a new, rough driver that might work, than no driver at all, and it's not like it can cause a regression if you don't enable it.
Maybe we can still get the new S-35390A RTC driver in then. It has been acked by Jean Delvare and David Brownell. Byron or Jean, can you try to submit it again?
I'm not the driver author and RTC drivers aren't under my responsibility. Ask Alessandro Zummo instead.
Quoted 2 lines
It's needed by the QNAP TS-109/TS-209, a NAS device for which support has been added in 2.6.25-rc1.
Signature · 1 line
Jean Delvare
Quoted 7 lines · On Tue, 26 Feb 2008 10:28:35 +0100 Jean Delvare <[email protected]> wrote:
Quoted 7 lines · Linus Torvalds
Quoted 5 lines
I'm personally of the opinion that a new driver that doesn't add anything but itself (ie no infrastructure changes etc) is fine. I'd rather have a new, rough driver that might work, than no driver at all, and it's not like it can cause a regression if you don't enable it.
Quoted 6 lines
Quoted 3 lines
Maybe we can still get the new S-35390A RTC driver in then. It has been acked by Jean Delvare and David Brownell. Byron or Jean, can you try to submit it again?
I'm not the driver author and RTC drivers aren't under my responsibility. Ask Alessandro Zummo instead.
I'm all ok for inclusion in 2.6.25. I believe the driver is in -mm right now, so Andrew might just throw it in?
Signature · 6 lines
Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
Hi,
Quoted 2 lines · James Bottomley
Jeff Garzik (1):
mvsas: Add Marvell 6440 SAS/SATA driver
[...]
Quoted 1 line
drivers/scsi/mvsas.c | 2981 ++++++++++++++++++++++++++++++++++++
I just noticed that the file permissions on that file are 755 in current git, that was probably not intentional?
-Olof
Quoted 11 lines · Olof Johansson
Hi,
Quoted 2 lines · James Bottomley
Jeff Garzik (1):
mvsas: Add Marvell 6440 SAS/SATA driver[...]
Quoted 1 line
drivers/scsi/mvsas.c | 2981 ++++++++++++++++++++++++++++++++++++I just noticed that the file permissions on that file are 755 in current git, that was probably not intentional?
Definitely not intentional. They were 0644 in the original changeset (the one from me you highlighted), then the second changeset updating mvsas somehow changed the perms.
Jeff
James Bottomley
maintainerQuoted 8 lines · Jeff Garzik
Quoted 7 lines · Olof Johansson
Hi,
Quoted 2 lines · James Bottomley
Jeff Garzik (1):
mvsas: Add Marvell 6440 SAS/SATA driver[...]
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
drivers/scsi/mvsas.c | 2981 ++++++++++++++++++++++++++++++++++++I just noticed that the file permissions on that file are 755 in current git, that was probably not intentional?
Definitely not intentional. They were 0644 in the original changeset (the one from me you highlighted), then the second changeset updating mvsas somehow changed the perms.
Actually, unfortunately, it was ... I just didn't spot it. The second patch has this in the header:
drivers/scsi/mvsas.c +0 -0
It's git slang for change the mode to executable ... no idea why marvell would do that unless it's something windows related? Anyway, I'll change it back.
James