Re: [PATCH 20/30] scsi: In the Advansys driver, do not cast allocation function return values
On Fri, Aug 24, 2007 at 02:16:12AM +0200, Jesper Juhl wrote: > There's no reason to cast void pointers returned by the generic > memory allocation functions. I think I fixed all these already; please check scsi-misc. -- "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/30] scsi: In the Advansys driver, do not cast allocation function return values
There's no reason to cast void pointers returned by the generic
memory allocation functions.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/scsi/advansys.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index 79c0b6e..b28729c 100644
--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -18513,7 +18513,7 @@ advansys_board_found(int iop, struct device *dev, int
bus_type)
* Allocate buffer carrier structures. The total size
* is about 4 KB, so allocate all at once.
*/
- carrp = (ADV_CARR_T *) kmalloc(ADV_CARRIER_BUFSIZE, GFP_ATOMIC);
+ carrp = kmalloc(ADV_CARRIER_BUFSIZE, GFP_ATOMIC);
ASC_DBG1(1, "advansys_board_found: carrp 0x%lx\n",
(ulong)carrp);
if (carrp == NULL) {
@@ -18529,8 +18529,7 @@ advansys_board_found(int iop, struct device *dev, int
bus_type)
for (req_cnt = adv_dvc_varp->max_host_qng;
req_cnt > 0; req_cnt--) {
- reqp = (adv_req_t *)
- kmalloc(sizeof(adv_req_t) * req_cnt, GFP_ATOMIC);
+ reqp = kmalloc(sizeof(adv_req_t) * req_cnt, GFP_ATOMIC);
ASC_DBG3(1,
"advansys_board_found: reqp 0x%lx, req_cnt %d,
bytes %lu\n",
@@ -18552,9 +18551,7 @@ advansys_board_found(int iop, struct device *dev, int
bus_type)
boardp->adv_sgblkp = NULL;
for (sg_cnt = 0; sg_cnt < ADV_TOT_SG_BLOCK; sg_cnt++) {
- sgp = (adv_sgblk_t *)
- kmalloc(sizeof(adv_sgblk_t), GFP_ATOMIC);
-
+ sgp = kmalloc(sizeof(adv_sgblk_t), GFP_ATOMIC);
if (sgp == NULL) {
break;
}
--
1.5.2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/30] scsi: Remove explicit casts of [kv]alloc return values in osst driver
[kv]alloc() return void *. No need to cast the return value.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/scsi/osst.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/osst.c b/drivers/scsi/osst.c
index 08060fb..3ad9d49 100644
--- a/drivers/scsi/osst.c
+++ b/drivers/scsi/osst.c
@@ -1404,7 +1404,7 @@ static int osst_read_back_buffer_and_rewrite(struct
osst_tape * STp, struct osst
int dbg = debugging;
#endif
- if ((buffer = (unsigned char *)vmalloc((nframes + 1) * OS_DATA_SIZE))
== NULL)
+ if ((buffer = vmalloc((nframes + 1) * OS_DATA_SIZE)) == NULL)
return (-EIO);
printk(KERN_INFO "%s:I: Reading back %d frames from drive buffer%s\n",
@@ -2216,7 +2216,7 @@ static int osst_write_header(struct osst_tape * STp,
struct osst_request ** aSRp
if (STp->raw) return 0;
if (STp->header_cache == NULL) {
- if ((STp->header_cache = (os_header_t
*)vmalloc(sizeof(os_header_t))) == NULL) {
+ if ((STp->header_cache = vmalloc(sizeof(os_header_t))) == NULL)
{
printk(KERN_ERR "%s:E: Failed to allocate header
cache\n", name);
return (-ENOMEM);
}
@@ -2404,7 +2404,7 @@ static int __osst_analyze_headers(struct osst_tape * STp,
struct osst_request **
name, ppos, update_frame_cntr);
#endif
if (STp->header_cache == NULL) {
- if ((STp->header_cache = (os_header_t
*)vmalloc(sizeof(os_header_t))) == NULL) {
+ if ((STp->header_cache = vmalloc(sizeof(os_header_t)))
== NULL) {
printk(KERN_ERR "%s:E: Failed to allocate
header cache\n", name);
return 0;
}
@@ -5756,7 +5756,7 @@ static int osst_probe(struct device *dev)
write_lock(&os_scsi_tapes_lock);
if (os_scsi_tapes == NULL) {
os_scsi_tapes =
- (struct osst_tape **)kmalloc(osst_max_dev *
sizeof(struct osst_tape *),
+ kmalloc(osst_max_dev * sizeof(struct osst_tape *),
GFP_ATOMIC);
if (os_scsi_tapes == NULL) {
write_unlock(&os_scsi_tapes_lock);
--
1.5.2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Perc5i / MegaRaid / Linux SCSI subsystem issue
Hi, I've recently acquired some Dell PowerEdge 2950 servers with integrated Perc 5i controllers (which use the MegaRaid driver). I loaded Fedora Core 6 on them fine, did a yum update and much to my surprise the box kernel panics on boot. I haven't loaded anything else on the box other than a stock OS. I did some investigation and determined the issue only occurs with the latest (2.6.22.1-32) kernel in FC6. It did not occur with 2.6.20 or 2.6.18. It seems that the driver for the Perc 5i controller (megaraid_sas) is seeing through the BIOS of the controller and showing all 6 disks rather than one logical volume in the startup messages (I'm seeing SD 0-5). Since the volume is actually RAID 10, it cannot mount the root filesystem. This problem seem very similar to one detailed in an older kernel on the Ubuntu bug tracker: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/55138 I also noticed that the bug has a patch applied in Ubuntu: https://launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/57265 I have done some further diagnosis: - I loaded the kernel.org sources for 2.6.22.1, with no luck, same issue. - I downloaded the megaraid drivers from Dell and tried installing them for 2.6.22.1. It prompted me that the drivers were older than the ones in 2.6.22, I forced it to install, rebuilt the initrd, and the same issue continues. This leads me to believe that the issue might not be with the megaraid driver, but with something else in the kernel scsi subsystem, but I'm no kernel hacker. What steps need to be taken to get this resolved? I tried involving Dell, and have an open case with them, but since 2.6.22 isn't in RHEL yet, they say they have no escalation path and can't help. Any suggestions from the list? Thanks, -- Daniel Jabbour Network / Sytems Engineer Intronis Technologies Direct: (800) 569-0155 x242 Email: [EMAIL PROTECTED] www.intronis.com - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] define global BIT macro
On Sat, Aug 18, 2007 at 11:44:12AM +0200, Jiri Slaby wrote: > define global BIT macro > > move all local BIT defines to the new globally define macro. > > Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> Acked-by: Ralf Baechle <[EMAIL PROTECTED]> for the MACE ethernet and MIPS bits. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
