Replacing kmalloc/memset combination with kzalloc.
Signed-off-by: vignesh babu [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/ch.c b/drivers/scsi/ch.c
index 2a2cc6c..2311019 100644
--- a/drivers/scsi/ch.c
+++ b/drivers/scsi/ch.c
@@ -319,10 +319,9 @@ ch_readconfig(scsi_changer *ch)
int
Replacing kmalloc/memset combination with kzalloc.
Signed-off-by: vignesh babu [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
index cd36e81..2184fcb 100644
--- a/drivers/scsi/dpt_i2o.c
+++ b/drivers/scsi/dpt_i2o.c
@@ -1311,13 +1311,12 @@ static s32
Sparc64 systems which have an on-board qla2xxx chip (such as
SunBlade-1000 and SunBlade-2000, there are probably some other systems
like this too) do not have any NVRAM information present, in fact the
NVRAM is basically all 0's from what I can tell.
This always worked just fine since the code
Thanks Vignesh. Looks fine to me except I would prefer to drop the first
fragment and update it another day, another cleanup. The 64 bit updates
may need to be pushed now that the i2o_block driver appears to have no
maintainer (Markus pulled, I have not checked with him why).
The Adaptec version
Inspired somewhat by Vignesh Babu [EMAIL PROTECTED] patch to
dpt_i2o.c to replace kmalloc/memset sequences with kzalloc, doing the
same for the aacraid driver.
ObligatoryDisclaimer: Please accept my condolences regarding Outlook's
handling of patches.
This attached patch is against current
On Mon, 16 Apr 2007, David Miller wrote:
Sparc64 systems which have an on-board qla2xxx chip (such as
SunBlade-1000 and SunBlade-2000, there are probably some other systems
like this too) do not have any NVRAM information present, in fact the
NVRAM is basically all 0's from what I can tell.
Boaz Harrosh wrote:
Following are 4 (large) patches for support of bidirectional
block I/O in kernel. (not including SCSI-ml or iSCSI)
The submitted work is against linux-2.6-block tree as of
2007/04/15, and will only cleanly apply in succession.
The patches are based on the RFC I sent 3
From: David Miller [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 12:37:43 -0700 (PDT)
Now I'm happy to code up the sparc OFW property bits but your attitude
and perspective on this absolutely has to change and the old fallback
code still has to go back in there, possible FC ID collisions or not.
On Mon, 16 Apr 2007, Andrew Vasquez wrote:
On Mon, 16 Apr 2007, David Miller wrote:
They DON'T
CARE, they want their systems to work and if you don't give them that
you're not being a good driver maintainer.
Let's push aside attitudes and unrealistic statistics, could we
perhaps
From: Andrew Vasquez [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 14:10:49 -0700
Ok, how about the following patch based on the one you posted which
adds the codes to retrieve the WWPN/WWNN from firmware on SPARC, and
also adds the module-parameter override I mentioned above.
Perhaps the
On Mon, 16 Apr 2007, David Miller wrote:
From: Andrew Vasquez [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 14:10:49 -0700
Ok, how about the following patch based on the one you posted which
adds the codes to retrieve the WWPN/WWNN from firmware on SPARC, and
also adds the module-parameter
From: Andrew Vasquez [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 15:25:17 -0700
Fine, I'll agree that wacking-users (and
I'll wager the outliers) with a 2x4 was a bit extreme,
And that, right there, is basically the end of the conversation.
You don't do this to users, ever.
Put a big loud
On Mon, 16 Apr 2007, David Miller wrote:
From: Andrew Vasquez [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 15:25:17 -0700
Fine, I'll agree that wacking-users (and
I'll wager the outliers) with a 2x4 was a bit extreme,
And that, right there, is basically the end of the conversation.
You
From: Andrew Vasquez [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 16:28:51 -0700
Sorry, but let's be realistic, this type of warning would have
*NEVER* been addressed if we kept the status quo
Wrong. I watch the logs all the time and would have sent you a fix to
use the Sparc firmware info as
On Mon, 16 Apr 2007, David Miller wrote:
From: Andrew Vasquez [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 16:28:51 -0700
Sorry, but let's be realistic, this type of warning would have
*NEVER* been addressed if we kept the status quo
Wrong. I watch the logs all the time and would have
From: Andrew Vasquez [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 16:47:05 -0700
Dave, according to your earlier emails, the qla2xxx driver worked
'fine' in driver versions before commit
7aef45ac92f49e76d990b51b7ecd714b9a608be1. If that were the case, then
you would have seen the warning
On Mon, 16 Apr 2007, David Miller wrote:
From: Andrew Vasquez [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 16:47:05 -0700
Dave, according to your earlier emails, the qla2xxx driver worked
'fine' in driver versions before commit
7aef45ac92f49e76d990b51b7ecd714b9a608be1. If that were the
From: Andrew Vasquez [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 19:41:07 -0700
That verbiage sounds fine -- so would you consider the previous patch
I submitted (with module parameter) along with the wording above?
Yes, that sounds fine.
I'm in transit for a redeye to NY so I won't be able to
18 matches
Mail list logo
