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
James Bottomley wrote:
> This is the latest crop of bug fixes plus one new driver: mvsas. We're
[...]
> Jeff Garzik (1):
> mvsas: Add Marvell 6440 SAS/SATA driver
[...]
> 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
Jeff Garzik wrote:
> 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
On Sat, 23 Feb 2008, Jeff Garzik wrote:
>
> 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
On Sat, 23 Feb 2008 12:31:02 -0800 (PST) Linus Torvalds <[email protected]> wrote:
>
>
> On Sat, 23 Feb 2008, Jeff Garzik wrote:
> >
> > 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.
Especially drivers, because a new driver is a bugfix for people who own
that hardware!
On Sat, 2008-02-23 at 12:31 -0800, Linus Torvalds wrote:
>
> On Sat, 23 Feb 2008, Jeff Garzik wrote:
> >
> > 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.
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
Hi,
On Sat, Feb 23, 2008 at 09:13:33AM -0600, James Bottomley wrote:
> Jeff Garzik (1):
> mvsas: Add Marvell 6440 SAS/SATA driver
[...]
> 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
Olof Johansson wrote:
> Hi,
>
> On Sat, Feb 23, 2008 at 09:13:33AM -0600, James Bottomley wrote:
>
>> Jeff Garzik (1):
>> mvsas: Add Marvell 6440 SAS/SATA driver
> [...]
>> 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
Andrew Morton wrote:
> On Sat, 23 Feb 2008 12:31:02 -0800 (PST) Linus Torvalds <[email protected]> wrote:
>
>>
>> On Sat, 23 Feb 2008, Jeff Garzik wrote:
>>> 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
On Sat, 2008-02-23 at 18:31 -0500, Jeff Garzik wrote:
> Olof Johansson wrote:
> > Hi,
> >
> > On Sat, Feb 23, 2008 at 09:13:33AM -0600, James Bottomley wrote:
> >
> >> Jeff Garzik (1):
> >> mvsas: Add Marvell 6440 SAS/SATA driver
> > [...]
> >> 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:
diff --git a/drivers/scsi/mvsas.c b/drivers/scsi/mvsas.c
old mode 100644
new mode 100755
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
On Mon, Feb 25, 2008 at 10:39 PM, Martin Michlmayr <[email protected]> wrote:
> * Linus Torvalds <[email protected]> [2008-02-23 12:31]:
>
> > 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.
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,
--
Byron Bradley
* Linus Torvalds <[email protected]> [2008-02-23 12:31]:
> 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.
--
Martin Michlmayr
http://www.cyrius.com/
On Mon, 25 Feb 2008 23:39:17 +0100, Martin Michlmayr wrote:
> * Linus Torvalds <[email protected]> [2008-02-23 12:31]:
> > 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.
> It's needed by the QNAP TS-109/TS-209, a NAS device for which support
> has been added in 2.6.25-rc1.
--
Jean Delvare
On Tue, 26 Feb 2008 10:28:35 +0100
Jean Delvare <[email protected]> wrote:
> > * Linus Torvalds <[email protected]> [2008-02-23 12:31]:
> > > 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.
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?
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it