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 },
+ { PCI_VDEVICE(TTI, 0x4210), (kernel_ulong_t)&hptiop_itl_ops },
+ { PCI_VDEVICE(TTI, 0x4211), (kernel_ulong_t)&hptiop_itl_ops },
+ { PCI_VDEVICE(TTI, 0x4310), (kernel_ulong_t)&hptiop_itl_ops },
+ { PCI_VDEVICE(TTI, 0x4311), (kernel_ulong_t)&hptiop_itl_ops },
{ PCI_VDEVICE(TTI, 0x3120), (kernel_ulong_t)&hptiop_mv_ops },
{ PCI_VDEVICE(TTI, 0x3122), (kernel_ulong_t)&hptiop_mv_ops },
{ PCI_VDEVICE(TTI, 0x3020), (kernel_ulong_t)&hptiop_mv_ops },
diff --git a/drivers/scsi/scsi_transport_spi.c b/drivers/scsi/scsi_transport_spi.c
index 75a64a6..b29360e 100644
--- a/drivers/scsi/scsi_transport_spi.c
+++ b/drivers/scsi/scsi_transport_spi.c
@@ -366,12 +366,14 @@ spi_transport_rd_attr(rti, "%d\n");
spi_transport_rd_attr(pcomp_en, "%d\n");
spi_transport_rd_attr(hold_mcs, "%d\n");
-/* we only care about the first child device so we return 1 */
+/* we only care about the first child device that's a real SCSI device
+ * so we return 1 to terminate the iteration when we find it */
static int child_iter(struct device *dev, void *data)
{
- struct scsi_device *sdev = to_scsi_device(dev);
+ if (!scsi_is_sdev_device(dev))
+ return 0;
- spi_dv_device(sdev);
+ spi_dv_device(to_scsi_device(dev));
return 1;
}
diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
index 0fe031f..1bcf3c3 100644
--- a/drivers/scsi/ses.c
+++ b/drivers/scsi/ses.c
@@ -345,14 +345,14 @@ static int ses_enclosure_find_by_addr(struct enclosure_device *edev,
return 0;
}
-#define VPD_INQUIRY_SIZE 512
+#define VPD_INQUIRY_SIZE 36
static void ses_match_to_enclosure(struct enclosure_device *edev,
struct scsi_device *sdev)
{
unsigned char *buf = kmalloc(VPD_INQUIRY_SIZE, GFP_KERNEL);
unsigned char *desc;
- int len;
+ u16 vpd_len;
struct efd efd = {
.addr = 0,
};
@@ -372,9 +372,19 @@ static void ses_match_to_enclosure(struct enclosure_device *edev,
VPD_INQUIRY_SIZE, NULL, SES_TIMEOUT, SES_RETRIES))
goto free;
- len = (buf[2] << 8) + buf[3];
+ vpd_len = (buf[2] << 8) + buf[3];
+ kfree(buf);
+ buf = kmalloc(vpd_len, GFP_KERNEL);
+ if (!buf)
+ return;
+ cmd[3] = vpd_len >> 8;
+ cmd[4] = vpd_len & 0xff;
+ if (scsi_execute_req(sdev, cmd, DMA_FROM_DEVICE, buf,
+ vpd_len, NULL, SES_TIMEOUT, SES_RETRIES))
+ goto free;
+
desc = buf + 4;
- while (desc < buf + len) {
+ while (desc < buf + vpd_len) {
enum scsi_protocol proto = desc[0] >> 4;
u8 code_set = desc[0] & 0x0f;
u8 piv = desc[1] & 0x80;
On Sun, Aug 03, 2008 at 05:03:05PM -0500, James Bottomley wrote:
> 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):
I thought group (or non-person) submissions where explicitly
prohibitted in the signoff section in Documentation/SubmittingPatches
--
Ben ([email protected], http://www.fluff.org/)
'a smiley only costs 4 bytes'
> I thought group (or non-person) submissions where explicitly
> prohibitted in the signoff section in Documentation/SubmittingPatches
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
On Mon, 2008-08-04 at 15:29 +0100, Ben Dooks wrote:
> On Sun, Aug 03, 2008 at 05:03:05PM -0500, James Bottomley wrote:
> > 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):
>
> I thought group (or non-person) submissions where explicitly
> prohibitted in the signoff section in Documentation/SubmittingPatches
Not as I read it. It says:
then you just add a line saying
Signed-off-by: Random J Developer
<[email protected]>
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
Alan Cox wrote:
>> I thought group (or non-person) submissions where explicitly
>> prohibitted in the signoff section in Documentation/SubmittingPatches
>
> 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.
(NOTE!! speaking for myself, not for other Red Hatters)
The solution I've settled upon is [email protected] 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