[GIT PATCH] scsi fixes for 2.6.25-rc2

[GIT PATCH] scsi fixes for 2.6.25-rc2

[James Bottomley]

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

Re: [GIT PATCH] scsi fixes for 2.6.25-rc2

[Jeff Garzik]

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

Re: [GIT PATCH] scsi fixes for 2.6.25-rc2

[Jeff Garzik]

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

Re: [GIT PATCH] scsi fixes for 2.6.25-rc2

[Linus Torvalds]

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

Re: [GIT PATCH] scsi fixes for 2.6.25-rc2

[Andrew Morton]

On Sat, 23 Feb 2008 12:31:02 -0800 (PST) Linus Torvalds <torvalds@linux-foundation.org> 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!

Re: [GIT PATCH] scsi fixes for 2.6.25-rc2

[James Bottomley]

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

Re: [GIT PATCH] scsi fixes for 2.6.25-rc2

[Olof Johansson]

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

Re: [GIT PATCH] scsi fixes for 2.6.25-rc2

[Jeff Garzik]

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

Re: [GIT PATCH] scsi fixes for 2.6.25-rc2

[Jeff Garzik]

Andrew Morton wrote:
> On Sat, 23 Feb 2008 12:31:02 -0800 (PST) Linus Torvalds <torvalds@linux-foundation.org> 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

Re: [GIT PATCH] scsi fixes for 2.6.25-rc2

[James Bottomley]

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

Re: [GIT PATCH] scsi fixes for 2.6.25-rc2

[Martin Michlmayr]

* Linus Torvalds <torvalds@linux-foundation.org> [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/

Re: [GIT PATCH] scsi fixes for 2.6.25-rc2

[Byron Bradley]

On Mon, Feb 25, 2008 at 10:39 PM, Martin Michlmayr <tbm@cyrius.com> wrote:
> * Linus Torvalds <torvalds@linux-foundation.org> [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

Re: [GIT PATCH] scsi fixes for 2.6.25-rc2

[Jean Delvare]

On Mon, 25 Feb 2008 23:39:17 +0100, Martin Michlmayr wrote:
> * Linus Torvalds <torvalds@linux-foundation.org> [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

Re: [GIT PATCH] scsi fixes for 2.6.25-rc2

[Alessandro Zummo]

On Tue, 26 Feb 2008 10:28:35 +0100
Jean Delvare <khali@linux-fr.org> wrote:


> > * Linus Torvalds <torvalds@linux-foundation.org> [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