This is just a small selection of four fixes, one expanding driver
bindings and the other three fixing actual bugs (all of which need
backporting to 2.6.26 I'm afraid).

The patch is available here:

master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git

The short changelog is:

HighPoint Linux Team (1):
      hptiop: add more PCI device IDs

James Bottomley (2):
      scsi_transport_spi: fix oops in revalidate
      ses: fix VPD inquiry overrun

Tim Wright (1):
      block: Fix miscalculation of sg_io timeout in CDROM_SEND_PACKET handler.


The diffstat:

 block/scsi_ioctl.c                |    2 +-
 drivers/scsi/hptiop.c             |    7 +++++++
 drivers/scsi/scsi_transport_spi.c |    8 +++++---
 drivers/scsi/ses.c                |   18 ++++++++++++++----
 4 files changed, 27 insertions(+), 8 deletions(-)

With the full diff attached below.

James

---


diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index c5b9bcf..12a5182 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -518,7 +518,7 @@ int scsi_cmd_ioctl(struct file *file, struct request_queue *q,
 			hdr.sbp = cgc.sense;
 			if (hdr.sbp)
 				hdr.mx_sb_len = sizeof(struct request_sense);
-			hdr.timeout = cgc.timeout;
+			hdr.timeout = jiffies_to_msecs(cgc.timeout);
 			hdr.cmdp = ((struct cdrom_generic_command __user*) arg)->cmd;
 			hdr.cmd_len = sizeof(cgc.cmd);
 
diff --git a/drivers/scsi/hptiop.c b/drivers/scsi/hptiop.c
index da876d3..74d12b5 100644
--- a/drivers/scsi/hptiop.c
+++ b/drivers/scsi/hptiop.c
@@ -1249,6 +1249,13 @@ static struct pci_device_id hptiop_id_table[] = {
 	{ PCI_VDEVICE(TTI, 0x3522), (kernel_ulong_t)&hptiop_itl_ops },
 	{ PCI_VDEVICE(TTI, 0x3410), (kernel_ulong_t)&hptiop_itl_ops },
 	{ PCI_VDEVICE(TTI, 0x3540), (kernel_ulong_t)&hptiop_itl_ops },
+	{ PCI_VDEVICE(TTI, 0x3530), (kernel_ulong_t)&hptiop_itl_ops },
+	{ PCI_VDEVICE(TTI, 0x3560), (kernel_ulong_t)&hptiop_itl_ops },
+	{ PCI_VDEVICE(TTI, 0x4322), (kernel_ulong_t)&hptiop_itl_ops ...
[ message continues ]

I thought group (or non-person) submissions where explicitly
prohibitted in the signoff section in Documentation/SubmittingPatches

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'
--

[ message continues ]

Highpoint is a legal entity so highpoint can enter into agreements. Thats
a bit different from say "Dave the anonymous ferret" or "three people
down the pub"

In many ways companies that sign the patches themselves are being nicer
to their employees than those who encourage the current practise.

Alan
--

[ message continues ]

(NOTE!! speaking for myself, not for other Red Hatters)

The solution I've settled upon is jgarzik@redhat.com for sign-offs, and 
my usual addresses (jeff@garzik, jgarzik@pobox) for all email 
communication and patch posting.

That makes it clear who is really signing off on the patches, while 
still ensuring that if I get fired or leave Red Hat, the flow of 
communication can be largely uninterrupted.

For those who don't know, to prevent sensitive information leaks, it is 
standard corporate policy for many companies these days to immediately 
yank an email address the minute an employee's status changes.

	Jeff


--

[ message continues ]

Not as I read it.  It says:

        then you just add a line saying
        
                Signed-off-by: Random J Developer
        <random@developer.example.org>
        
        using your real name (sorry, no pseudonyms or anonymous
        contributions.)
        
Which doesn't preclude company signoffs (as long as it's a real
company).  Of course, most companies worry about the legal liability
from the GPL and the DCO, which is why we get so few of them.

James


--

[ message continues ]