There are three places in the sym2 driver which print out an interrupt
number; all need to be changed to unsigned
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.c
b/drivers/scsi/sym53c8xx_2/sym_glue.c
index 74300dd..0f214c0 100644
--- a/drivers/
On Tue, Oct 09, 2007 at 04:43:14PM -0400, Dave Jones wrote:
> Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
These have already been taken care of; see
http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=shortlog;h=gdth
--
Intel are signing my paycheques ... these opinions are stil
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index 55e4d2d..bfba877 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -392,12 +392,7 @@
#include
#include
#include
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,6)
#include
-
On Tue, Oct 09, 2007 at 11:42:43AM +0200, Boaz Harrosh wrote:
> Please don't do this patch for now. This is because of the
> soon to come scsi_data_buffer patch that rearages most of the members above
> and puts them in a substructure. Maybe after the scsi_data_buffer patch you
> can
> try to do
If we don't need precise timeout, we can have one single timer running
at regular intervals, say every second. We also record the exact number
of requests that are supposed to be done in a particular interval. This
is done by computing the 'interval index' of a request, incrementing it
when we send
On Tue, Oct 09, 2007 at 09:41:47AM -0700, Andrew Vasquez wrote:
> On Tue, 09 Oct 2007, James Smart wrote:
>
> > Why do you prefer request_firmware() vs something over sysfs ?
> >
> > Does environments like the kdump kernel also have access to data needed
> > by request_firmware() ?
Assuming t
On Tue, 09 Oct 2007, James Smart wrote:
> Why do you prefer request_firmware() vs something over sysfs ?
>
> Does environments like the kdump kernel also have access to data needed
> by request_firmware() ?
There's already much in the way of automation and infrastructure
present in supporting
On Tue, 2007-10-09 at 14:15 +0200, Jens Axboe wrote:
> On Tue, Oct 09 2007, Matthew Wilcox wrote:
> > On Mon, Oct 08, 2007 at 10:36:10PM -0700, [EMAIL PROTECTED] wrote:
> > > Thank you Randy, Jens for your suggestions. I folded the second patch as
> > > it is just a clean up. Here is the fixed one
Matthew Wilcox wrote:
On Tue, Oct 09, 2007 at 11:35:14AM -0400, Jeff Garzik wrote:
Not true. The original code used 'int irq', and the printf format was
correct as a result.
You changed the code to use 'unsigned int irq' as found in struct
pci_dev, without changing IRQ_FMT as needed.
If yo
On Tue, Oct 09, 2007 at 11:35:14AM -0400, Jeff Garzik wrote:
> Not true. The original code used 'int irq', and the printf format was
> correct as a result.
>
> You changed the code to use 'unsigned int irq' as found in struct
> pci_dev, without changing IRQ_FMT as needed.
>
> If you wanted to
Matthew Wilcox wrote:
On Fri, Oct 05, 2007 at 04:59:47PM -0400, Jeff Garzik wrote:
NAK
The proper format string is '%u' because irq is unsigned
I'll change it to %u in the next revision. However, I respectfully
decline your NAK as this was not a regression.
Not true. The original code use
On Fri, Oct 05, 2007 at 04:56:41PM -0400, Jeff Garzik wrote:
> Matthew Wilcox wrote:
> >With sysfs making these options tunable at runtime, there's no
> >justification for keeping this horrendously complex specification
> >string around.
> >
> >Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
> >-
Why do you prefer request_firmware() vs something over sysfs ?
Does environments like the kdump kernel also have access to data needed
by request_firmware() ?
-- james s
Andrew Vasquez wrote:
On Mon, 08 Oct 2007, Darrick J. Wong wrote:
On Mon, Oct 08, 2007 at 03:48:32PM -0700, Andrew Vasque
On Fri, Oct 05, 2007 at 04:59:47PM -0400, Jeff Garzik wrote:
> NAK
>
> The proper format string is '%u' because irq is unsigned
I'll change it to %u in the next revision. However, I respectfully
decline your NAK as this was not a regression.
--
Intel are signing my paycheques ... these opinion
On Fri, Oct 05, 2007 at 05:07:39PM -0400, Jeff Garzik wrote:
> Obviously this is a judgement call on your part... but did you at least
> consider passing sym_hcb for all cases instead?
I did. There's a lot of crap stored in the sym_hcb that needs to move
to the sym_data, so Scsi_host is going to
Here is another attempt! Thank you.
diff -r 1b51503899a0 block/ll_rw_blk.c
--- a/block/ll_rw_blk.c Thu Sep 27 00:25:15 2007 -0700
+++ b/block/ll_rw_blk.c Tue Oct 09 07:00:51 2007 -0700
@@ -181,6 +181,18 @@ void blk_queue_softirq_done(struct reque
EXPORT_SYMBOL(blk_queue_softirq_done);
+void
On Mon, Oct 08, 2007 at 12:07:47PM +0200, Boaz Harrosh wrote:
> I see that these patches are before the conversion to scsi data accessors
> and !use_sg cleanup that was posted by TOMO:
> http://www.spinics.net/lists/linux-scsi/msg19055.html
>
> Could you please also post that patch rebased to lat
On Tue, Oct 09 2007, Matthew Wilcox wrote:
> On Mon, Oct 08, 2007 at 10:36:10PM -0700, [EMAIL PROTECTED] wrote:
> > Thank you Randy, Jens for your suggestions. I folded the second patch as
> > it is just a clean up. Here is the fixed one patch version.
>
> I was thinking about this (in the context
On Tue, Oct 09, 2007 at 11:42:43AM +0200, Boaz Harrosh wrote:
> Please don't do this patch for now. This is because of the
> soon to come scsi_data_buffer patch that rearages most of the members above
> and puts them in a substructure. Maybe after the scsi_data_buffer patch you
> can
> try to do
On Mon, Oct 08, 2007 at 10:36:10PM -0700, [EMAIL PROTECTED] wrote:
> Thank you Randy, Jens for your suggestions. I folded the second patch as
> it is just a clean up. Here is the fixed one patch version.
I was thinking about this (in the context of shrinking scsi_cmnd --
obviously, things are not
On Tue, Oct 09 2007 at 1:50 +0200, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> Thanks to acme's pahole utility, I found some places where we can save
> a lot of bytes in scsi_cmnd, just by rearranging struct elements and
> reducing the size of some elements. We go from 272 to 260 bytes on x86
> an
On Mon, Oct 08 2007, [EMAIL PROTECTED] wrote:
> Thank you Randy, Jens for your suggestions. I folded the second patch as
> it is just a clean up. Here is the fixed one patch version.
>
> Signed-off-by: Mike Christie <[EMAIL PROTECTED]>
> Signed-off-by: Malahal Naineni <[EMAIL PROTECTED]>
>
> Than
22 matches
Mail list logo
