[PATCH] aic79xx: fix warnings with CONFIG_PM disabled
CC [M] drivers/scsi/aic7xxx/aic79xx_osm_pci.o
drivers/scsi/aic7xxx/aic79xx_osm_pci.c:101: warning:
'ahd_linux_pci_dev_suspend' defined but not used
drivers/scsi/aic7xxx/aic79xx_osm_pci.c:121: warning: 'ahd_linux_pci_dev_resume'
defined but not used
This moves aic79xx_pci_driver struct, removes some forward
declarations, and adds some ifdef CONFIG_PM.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/aic7xxx/aic79xx.h |5 +++-
drivers/scsi/aic7xxx/aic79xx_core.c|2 +
drivers/scsi/aic7xxx/aic79xx_osm_pci.c | 33 +++
drivers/scsi/aic7xxx/aic79xx_pci.c |2 +
4 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/drivers/scsi/aic7xxx/aic79xx.h b/drivers/scsi/aic7xxx/aic79xx.h
index ce638aa..2f00467 100644
--- a/drivers/scsi/aic7xxx/aic79xx.h
+++ b/drivers/scsi/aic7xxx/aic79xx.h
@@ -1340,8 +1340,10 @@ struct ahd_pci_identity
*ahd_find_pci_device(ahd_dev_softc_t);
int ahd_pci_config(struct ahd_softc *,
struct ahd_pci_identity *);
intahd_pci_test_register_access(struct ahd_softc *);
+#ifdef CONFIG_PM
void ahd_pci_suspend(struct ahd_softc *);
void ahd_pci_resume(struct ahd_softc *);
+#endif
/** SCB and SCB queue management
**/
void ahd_qinfifo_requeue_tail(struct ahd_softc *ahd,
@@ -1352,8 +1354,10 @@ struct ahd_softc *ahd_alloc(void *platform_arg, char
*name);
int ahd_softc_init(struct ahd_softc *);
voidahd_controller_info(struct ahd_softc *ahd, char *buf);
int ahd_init(struct ahd_softc *ahd);
+#ifdef CONFIG_PM
int ahd_suspend(struct ahd_softc *ahd);
voidahd_resume(struct ahd_softc *ahd);
+#endif
int ahd_default_config(struct ahd_softc *ahd);
int ahd_parse_vpddata(struct ahd_softc *ahd,
struct vpd_config *vpd);
@@ -1361,7 +1365,6 @@ intahd_parse_cfgdata(struct
ahd_softc *ahd,
struct seeprom_config *sc);
voidahd_intr_enable(struct ahd_softc *ahd, int enable);
voidahd_pause_and_flushwork(struct ahd_softc *ahd);
-int ahd_suspend(struct ahd_softc *ahd);
voidahd_set_unit(struct ahd_softc *, int);
voidahd_set_name(struct ahd_softc *, char *);
struct scb *ahd_get_scb(struct ahd_softc *ahd, u_int col_idx);
diff --git a/drivers/scsi/aic7xxx/aic79xx_core.c
b/drivers/scsi/aic7xxx/aic79xx_core.c
index a7dd8cd..ade0fb8 100644
--- a/drivers/scsi/aic7xxx/aic79xx_core.c
+++ b/drivers/scsi/aic7xxx/aic79xx_core.c
@@ -7175,6 +7175,7 @@ ahd_pause_and_flushwork(struct ahd_softc *ahd)
ahd-flags = ~AHD_ALL_INTERRUPTS;
}
+#ifdef CONFIG_PM
int
ahd_suspend(struct ahd_softc *ahd)
{
@@ -7197,6 +7198,7 @@ ahd_resume(struct ahd_softc *ahd)
ahd_intr_enable(ahd, TRUE);
ahd_restart(ahd);
}
+#endif
/** Busy Target Table
*/
/*
diff --git a/drivers/scsi/aic7xxx/aic79xx_osm_pci.c
b/drivers/scsi/aic7xxx/aic79xx_osm_pci.c
index 66f0259..4150c8a 100644
--- a/drivers/scsi/aic7xxx/aic79xx_osm_pci.c
+++ b/drivers/scsi/aic7xxx/aic79xx_osm_pci.c
@@ -43,17 +43,6 @@
#include aic79xx_inline.h
#include aic79xx_pci.h
-static int ahd_linux_pci_dev_probe(struct pci_dev *pdev,
- const struct pci_device_id *ent);
-static int ahd_linux_pci_reserve_io_regions(struct ahd_softc *ahd,
-u_long *base, u_long *base2);
-static int ahd_linux_pci_reserve_mem_region(struct ahd_softc *ahd,
-u_long *bus_addr,
-uint8_t __iomem **maddr);
-static int ahd_linux_pci_dev_suspend(struct pci_dev *pdev, pm_message_t
mesg);
-static int ahd_linux_pci_dev_resume(struct pci_dev *pdev);
-static voidahd_linux_pci_dev_remove(struct pci_dev *pdev);
-
/* Define the macro locally since it's different for different class of chips.
*/
#define ID(x)\
@@ -85,17 +74,7 @@ static struct pci_device_id ahd_linux_pci_id_table[] = {
MODULE_DEVICE_TABLE(pci, ahd_linux_pci_id_table);
-static struct pci_driver aic79xx_pci_driver = {
- .name = aic79xx,
- .probe = ahd_linux_pci_dev_probe,
#ifdef CONFIG_PM
- .suspend= ahd_linux_pci_dev_suspend,
- .resume = ahd_linux_pci_dev_resume,
-#endif
- .remove = ahd_linux_pci_dev_remove,
- .id_table = ahd_linux_pci_id_table
-};
-
static int
ahd_linux_pci_dev_suspend(struct pci_dev *pdev, pm_message_t mesg)
{
@@ -139,6 +118,7 @@ ahd_linux_pci_dev_resume(struct pci_dev *pdev)
[PATCH] aic7xxx: fix warnings with CONFIG_PM disabled
CC [M] drivers/scsi/aic7xxx/aic7xxx_osm_pci.o
drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:148: warning:
'ahc_linux_pci_dev_suspend' defined but not used
drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:166: warning: 'ahc_linux_pci_dev_resume'
defined but not used
This moves aic7xxx_pci_driver struct, removes some forward declarations,
and adds some ifdef CONFIG_PM.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/aic7xxx/aic7xxx.h |4 +++
drivers/scsi/aic7xxx/aic7xxx_core.c|3 +-
drivers/scsi/aic7xxx/aic7xxx_osm_pci.c | 33 +++
drivers/scsi/aic7xxx/aic7xxx_pci.c |2 +
4 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/drivers/scsi/aic7xxx/aic7xxx.h b/drivers/scsi/aic7xxx/aic7xxx.h
index 3d4e42d..c0344e6 100644
--- a/drivers/scsi/aic7xxx/aic7xxx.h
+++ b/drivers/scsi/aic7xxx/aic7xxx.h
@@ -1143,7 +1143,9 @@ struct ahc_pci_identity
*ahc_find_pci_device(ahc_dev_softc_t);
int ahc_pci_config(struct ahc_softc *,
struct ahc_pci_identity *);
int ahc_pci_test_register_access(struct ahc_softc *);
+#ifdef CONFIG_PM
voidahc_pci_resume(struct ahc_softc *ahc);
+#endif
/*** EISA/VL Front End
/
struct aic7770_identity *aic7770_find_device(uint32_t);
@@ -1170,8 +1172,10 @@ int ahc_chip_init(struct ahc_softc
*ahc);
int ahc_init(struct ahc_softc *ahc);
voidahc_intr_enable(struct ahc_softc *ahc, int enable);
voidahc_pause_and_flushwork(struct ahc_softc *ahc);
+#ifdef CONFIG_PM
int ahc_suspend(struct ahc_softc *ahc);
int ahc_resume(struct ahc_softc *ahc);
+#endif
voidahc_set_unit(struct ahc_softc *, int);
voidahc_set_name(struct ahc_softc *, char *);
voidahc_alloc_scbs(struct ahc_softc *ahc);
diff --git a/drivers/scsi/aic7xxx/aic7xxx_core.c
b/drivers/scsi/aic7xxx/aic7xxx_core.c
index f350b5e..6d2ae64 100644
--- a/drivers/scsi/aic7xxx/aic7xxx_core.c
+++ b/drivers/scsi/aic7xxx/aic7xxx_core.c
@@ -5078,6 +5078,7 @@ ahc_pause_and_flushwork(struct ahc_softc *ahc)
ahc-flags = ~AHC_ALL_INTERRUPTS;
}
+#ifdef CONFIG_PM
int
ahc_suspend(struct ahc_softc *ahc)
{
@@ -5113,7 +5114,7 @@ ahc_resume(struct ahc_softc *ahc)
ahc_restart(ahc);
return (0);
}
-
+#endif
/** Busy Target Table
*/
/*
* Return the untagged transaction id for a given target/channel lun.
diff --git a/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
b/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
index 4488946..dd6e21d 100644
--- a/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
+++ b/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
@@ -42,17 +42,6 @@
#include aic7xxx_osm.h
#include aic7xxx_pci.h
-static int ahc_linux_pci_dev_probe(struct pci_dev *pdev,
- const struct pci_device_id *ent);
-static int ahc_linux_pci_reserve_io_region(struct ahc_softc *ahc,
- u_long *base);
-static int ahc_linux_pci_reserve_mem_region(struct ahc_softc *ahc,
-u_long *bus_addr,
-uint8_t __iomem **maddr);
-static int ahc_linux_pci_dev_suspend(struct pci_dev *pdev, pm_message_t
mesg);
-static int ahc_linux_pci_dev_resume(struct pci_dev *pdev);
-static voidahc_linux_pci_dev_remove(struct pci_dev *pdev);
-
/* Define the macro locally since it's different for different class of chips.
*/
#define ID(x) ID_C(x, PCI_CLASS_STORAGE_SCSI)
@@ -132,17 +121,7 @@ static struct pci_device_id ahc_linux_pci_id_table[] = {
MODULE_DEVICE_TABLE(pci, ahc_linux_pci_id_table);
-static struct pci_driver aic7xxx_pci_driver = {
- .name = aic7xxx,
- .probe = ahc_linux_pci_dev_probe,
#ifdef CONFIG_PM
- .suspend= ahc_linux_pci_dev_suspend,
- .resume = ahc_linux_pci_dev_resume,
-#endif
- .remove = ahc_linux_pci_dev_remove,
- .id_table = ahc_linux_pci_id_table
-};
-
static int
ahc_linux_pci_dev_suspend(struct pci_dev *pdev, pm_message_t mesg)
{
@@ -182,6 +161,7 @@ ahc_linux_pci_dev_resume(struct pci_dev *pdev)
return (ahc_resume(ahc));
}
+#endif
static void
ahc_linux_pci_dev_remove(struct pci_dev *pdev)
@@ -289,6 +269,17 @@ ahc_linux_pci_dev_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
return (0);
}
+static struct pci_driver aic7xxx_pci_driver = {
+ .name = aic7xxx,
+ .probe = ahc_linux_pci_dev_probe,
+#ifdef CONFIG_PM
+ .suspend= ahc_linux_pci_dev_suspend,
+ .resume = ahc_linux_pci_dev_resume,
+#endif
+ .remove =
[PATCH 2.6.24] sym53c8xx_2 modpost section mismatch fix
Building 2.6.24 with
# CONFIG_HOTPLUG is not set
CONFIG_SCSI_SYM53C8XX_2=y
results in the following during modpost:
WARNING: vmlinux.o(.text+0x14b36c): Section mismatch: reference to
.exit.text:sym2_remove (between 'sym2_io_error_detected' and
'sym_set_cam_result_error')
because sym2_io_error_detected() calls sym2_remove(), which is marked __devexit.
Fixed by removing the __devexit from sym2_remove().
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
---
Resend. Previously reported against 2.6.24-rc6 on 2007-12-15.
--- linux-2.6.24-rc5/drivers/scsi/sym53c8xx_2/sym_glue.c.~1~2007-12-15
15:37:04.0 +0100
+++ linux-2.6.24-rc5/drivers/scsi/sym53c8xx_2/sym_glue.c2007-12-15
16:22:08.0 +0100
@@ -1744,7 +1744,7 @@ static int __devinit sym2_probe(struct p
return -ENODEV;
}
-static void __devexit sym2_remove(struct pci_dev *pdev)
+static void sym2_remove(struct pci_dev *pdev)
{
struct Scsi_Host *shost = pci_get_drvdata(pdev);
@@ -2056,7 +2056,7 @@ static struct pci_driver sym2_driver = {
.name = NAME53C8XX,
.id_table = sym2_id_table,
.probe = sym2_probe,
- .remove = __devexit_p(sym2_remove),
+ .remove = sym2_remove,
.err_handler= sym2_err_handler,
};
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
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 2.6.24] sym53c8xx_2 modpost section mismatch fix
On Sat, Jan 26, 2008 at 07:03:15PM +0100, Mikael Pettersson wrote: Building 2.6.24 with # CONFIG_HOTPLUG is not set CONFIG_SCSI_SYM53C8XX_2=y results in the following during modpost: WARNING: vmlinux.o(.text+0x14b36c): Section mismatch: reference to .exit.text:sym2_remove (between 'sym2_io_error_detected' and 'sym_set_cam_result_error') because sym2_io_error_detected() calls sym2_remove(), which is marked __devexit. Fixed by removing the __devexit from sym2_remove(). Signed-off-by: Mikael Pettersson [EMAIL PROTECTED] --- Resend. Previously reported against 2.6.24-rc6 on 2007-12-15. Fixed in upstream kernel by commit: 864473cbe99e95a57ad496894768cd77a567 Sam - 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
on patch [SCSI] relax scsi dma alignment
On commit 465ff3185e0cb76d46137335a4d21d0d9d3ac8a2: This patch relaxes the default SCSI DMA alignment from 512 bytes to 4 bytes. I remember from previous discussions that usb and firewire have sector size alignment requirements, so I upped their alignments in the respective slave allocs. [...] drivers/ata/libata-scsi.c |5 - drivers/firewire/fw-sbp2.c |6 ++ drivers/ieee1394/sbp2.c|6 ++ drivers/scsi/scsi_lib.c|8 drivers/usb/storage/scsiglue.c | 20 ++-- 5 files changed, 34 insertions(+), 11 deletions(-) No, FireWire only requires 4 bytes alignment. I will channel a reversion of the firewire and ieee1394 hunks through linux1394-2.6.git for 2.6.26. -- Stefan Richter -=-==--- ---= ==-=- http://arcgraph.de/sr/ - 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: on patch [SCSI] relax scsi dma alignment
On Sat, 2008-01-26 at 19:49 +0100, Stefan Richter wrote: On commit 465ff3185e0cb76d46137335a4d21d0d9d3ac8a2: This patch relaxes the default SCSI DMA alignment from 512 bytes to 4 bytes. I remember from previous discussions that usb and firewire have sector size alignment requirements, so I upped their alignments in the respective slave allocs. [...] drivers/ata/libata-scsi.c |5 - drivers/firewire/fw-sbp2.c |6 ++ drivers/ieee1394/sbp2.c|6 ++ drivers/scsi/scsi_lib.c|8 drivers/usb/storage/scsiglue.c | 20 ++-- 5 files changed, 34 insertions(+), 11 deletions(-) No, FireWire only requires 4 bytes alignment. I will channel a reversion of the firewire and ieee1394 hunks through linux1394-2.6.git for 2.6.26. Don't revert, just put the numbers down to 4 (just in case someone decides to lower the default SCSI alignment down from four ...). James - 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 2.6.24] sym53c8xx_2 modpost section mismatch fix
Sam Ravnborg writes: On Sat, Jan 26, 2008 at 07:03:15PM +0100, Mikael Pettersson wrote: Building 2.6.24 with # CONFIG_HOTPLUG is not set CONFIG_SCSI_SYM53C8XX_2=y results in the following during modpost: WARNING: vmlinux.o(.text+0x14b36c): Section mismatch: reference to .exit.text:sym2_remove (between 'sym2_io_error_detected' and 'sym_set_cam_result_error') because sym2_io_error_detected() calls sym2_remove(), which is marked __devexit. Fixed by removing the __devexit from sym2_remove(). Signed-off-by: Mikael Pettersson [EMAIL PROTECTED] --- Resend. Previously reported against 2.6.24-rc6 on 2007-12-15. Fixed in upstream kernel by commit: 864473cbe99e95a57ad496894768cd77a567 Great, thanks. - 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] sym53c8xx: fix bad memset argument in sym_set_cam_result_error
On a big powerpc box I got the following oops with 2.6.24-git2: sym0: 1010-66 rev 0x1 at pci :d0:01.0 irq 215 sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking sym0: SCSI BUS has been reset. scsi0 : sym-2.2.3 target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31) scsi 0:0:8:0: Direct-Access IBM ST318305LC C509 PQ: 0 ANSI: 3 target0:0:8: tagged command queuing enabled, command queue depth 16. target0:0:8: Beginning Domain Validation target0:0:8: asynchronous target0:0:8: wide asynchronous target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31) target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31) Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc0038460 cpu 0x25: Vector: 300 (Data Access) at [cf567840] pc: c0038460: .memcpy+0x60/0x280 lr: d0050280: .sym_set_cam_result_error+0xfc/0x1e0 [sym53c8xx] sp: cf567ac0 msr: 80009032 dar: 0 dsisr: 4200 current = 0xc06d1e0af0a0 paca= 0xc04afc00 pid = 0, comm = swapper enter ? for help [link register ] d0050280 .sym_set_cam_result_error+0xfc/0x1e0 [sym53c8xx] [cf567ac0] cf567b80 (unreliable) [cf567b80] d00552b8 .sym_complete_error+0x12c/0x1bc [sym53c8xx] [cf567c20] d00561a4 .sym_int_sir+0xaa4/0x1718 [sym53c8xx] [cf567d00] d0057e8c .sym_interrupt+0x4e4/0x6ec [sym53c8xx] [cf567dc0] d004fdf4 .sym53c8xx_intr+0x6c/0xdc [sym53c8xx] [cf567e50] c00a83e0 .handle_IRQ_event+0x7c/0xec [cf567ef0] c00aa344 .handle_fasteoi_irq+0x130/0x1f0 [cf567f90] c002a538 .call_handle_irq+0x1c/0x2c [c04d5e0b3a90] c000c320 .do_IRQ+0x108/0x1d0 [c04d5e0b3b20] c0004790 hardware_interrupt_entry+0x18/0x1c The memset() in sym_set_cam_result_error() would appear to be trashing the scsi_cmnd struct instead of clearing sense_buffer. Signed-off-by: Nathan Lynch [EMAIL PROTECTED] --- drivers/scsi/sym53c8xx_2/sym_glue.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.c b/drivers/scsi/sym53c8xx_2/sym_glue.c index 21e926d..e939f38 100644 --- a/drivers/scsi/sym53c8xx_2/sym_glue.c +++ b/drivers/scsi/sym53c8xx_2/sym_glue.c @@ -207,7 +207,7 @@ void sym_set_cam_result_error(struct sym_hcb *np, struct sym_ccb *cp, int resid) /* * Bounce back the sense data to user. */ - memset(cmd-sense_buffer, 0, SCSI_SENSE_BUFFERSIZE); + memset(cmd-sense_buffer, 0, SCSI_SENSE_BUFFERSIZE); memcpy(cmd-sense_buffer, cp-sns_bbuf, min(SCSI_SENSE_BUFFERSIZE, SYM_SNS_BBUF_LEN)); #if 0 -- 1.5.3.7.1112.g9758e - 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: [UPDATED PATCH] SGIWD93: use cached memory access to make driver work on IP28
On Fri, Jan 25, 2008 at 10:44:40AM -0600, James Bottomley wrote: + void *cpu; + void *dev; This should be struct device *dev; shouldn't it (that seems to be how it's always used)? of course, no need for the void *. And that should be dma_free_noncoherent(pdev-dev, ...) shouldn't it? yes it should. I'm sending an updated patch in a couple of seconds. Thanks for the review. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea.[ RFC1925, 2.3 ] - 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
[UPDATED PATCH] SGIWD93: use cached memory access to make driver work on IP28
SGI IP28 machines would need special treatment (enable adding addtional
wait states) when accessing memory uncached. To avoid this pain I
changed the driver to use only cached access to memory.
Signed-off-by: Thomas Bogendoerfer [EMAIL PROTECTED]
---
Changes to last version:
- struct device * instead of void * in hostdata struct
- get rid of not used dev argument in init_hpc_chain
- fix device argument in dma_free_noncoherent call
drivers/scsi/Kconfig |2 +-
drivers/scsi/sgiwd93.c | 64 +--
2 files changed, 40 insertions(+), 26 deletions(-)
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index a6676be..2a071b0 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -345,7 +345,7 @@ config ISCSI_TCP
config SGIWD93_SCSI
tristate SGI WD93C93 SCSI Driver
- depends on SGI_IP22 SCSI
+ depends on SGI_HAS_WD93 SCSI
help
If you have a Western Digital WD93 SCSI controller on
an SGI MIPS system, say Y. Otherwise, say N.
diff --git a/drivers/scsi/sgiwd93.c b/drivers/scsi/sgiwd93.c
index eef8275..2c43047 100644
--- a/drivers/scsi/sgiwd93.c
+++ b/drivers/scsi/sgiwd93.c
@@ -33,10 +33,9 @@
struct ip22_hostdata {
struct WD33C93_hostdata wh;
- struct hpc_data {
- dma_addr_t dma;
- void*cpu;
- } hd;
+ dma_addr_t dma;
+ void *cpu;
+ struct device *dev;
};
#define host_to_hostdata(host) ((struct ip22_hostdata *)((host)-hostdata))
@@ -46,6 +45,11 @@ struct hpc_chunk {
u32 _padding; /* align to quadword boundary */
};
+/* space for hpc dma descriptors */
+#define HPC_DMA_SIZE PAGE_SIZE
+
+#define DMA_DIR(d) ((d == DATA_OUT_DIR) ? DMA_TO_DEVICE : DMA_FROM_DEVICE)
+
static irqreturn_t sgiwd93_intr(int irq, void *dev_id)
{
struct Scsi_Host * host = dev_id;
@@ -59,15 +63,17 @@ static irqreturn_t sgiwd93_intr(int irq, void *dev_id)
}
static inline
-void fill_hpc_entries(struct hpc_chunk *hcp, struct scsi_cmnd *cmd, int
datainp)
+void fill_hpc_entries(struct ip22_hostdata *hd, struct scsi_cmnd *cmd, int din)
{
unsigned long len = cmd-SCp.this_residual;
void *addr = cmd-SCp.ptr;
dma_addr_t physaddr;
unsigned long count;
+ struct hpc_chunk *hcp;
- physaddr = dma_map_single(NULL, addr, len, cmd-sc_data_direction);
+ physaddr = dma_map_single(hd-dev, addr, len, DMA_DIR(din));
cmd-SCp.dma_handle = physaddr;
+ hcp = hd-cpu;
while (len) {
/*
@@ -89,6 +95,9 @@ void fill_hpc_entries(struct hpc_chunk *hcp, struct scsi_cmnd
*cmd, int datainp)
*/
hcp-desc.pbuf = 0;
hcp-desc.cntinfo = HPCDMA_EOX;
+ dma_cache_sync(hd-dev, hd-cpu,
+ (unsigned long)(hcp + 1) - (unsigned long)hd-cpu,
+ DMA_TO_DEVICE);
}
static int dma_setup(struct scsi_cmnd *cmd, int datainp)
@@ -96,9 +105,8 @@ static int dma_setup(struct scsi_cmnd *cmd, int datainp)
struct ip22_hostdata *hdata = host_to_hostdata(cmd-device-host);
struct hpc3_scsiregs *hregs =
(struct hpc3_scsiregs *) cmd-device-host-base;
- struct hpc_chunk *hcp = (struct hpc_chunk *) hdata-hd.cpu;
- pr_debug(dma_setup: datainp%d hcp%p , datainp, hcp);
+ pr_debug(dma_setup: datainp%d hcp%p , datainp, hdata-cpu);
hdata-wh.dma_dir = datainp;
@@ -111,12 +119,12 @@ static int dma_setup(struct scsi_cmnd *cmd, int datainp)
if (cmd-SCp.ptr == NULL || cmd-SCp.this_residual == 0)
return 1;
- fill_hpc_entries(hcp, cmd, datainp);
+ fill_hpc_entries(hdata, cmd, datainp);
pr_debug( HPCGO\n);
/* Start up the HPC. */
- hregs-ndptr = hdata-hd.dma;
+ hregs-ndptr = hdata-dma;
if (datainp)
hregs-ctrl = HPC3_SCTRL_ACTIVE;
else
@@ -134,6 +142,9 @@ static void dma_stop(struct Scsi_Host *instance, struct
scsi_cmnd *SCpnt,
if (!SCpnt)
return;
+ if (SCpnt-SCp.ptr == NULL || SCpnt-SCp.this_residual == 0)
+ return;
+
hregs = (struct hpc3_scsiregs *) SCpnt-device-host-base;
pr_debug(dma_stop: status%d , status);
@@ -145,8 +156,9 @@ static void dma_stop(struct Scsi_Host *instance, struct
scsi_cmnd *SCpnt,
barrier();
}
hregs-ctrl = 0;
- dma_unmap_single(NULL, SCpnt-SCp.dma_handle, SCpnt-SCp.this_residual,
-SCpnt-sc_data_direction);
+ dma_unmap_single(hdata-dev, SCpnt-SCp.dma_handle,
+SCpnt-SCp.this_residual,
+DMA_DIR(hdata-wh.dma_dir));
pr_debug(\n);
}
@@ -160,22 +172,23 @@ void sgiwd93_reset(unsigned long base)
hregs-ctrl = 0;
}
-static inline void init_hpc_chain(struct hpc_data *hd)
+static inline void init_hpc_chain(struct ip22_hostdata *hdata)
{
-
Re: [PATCH] sym53c8xx: fix bad memset argument in sym_set_cam_result_error
Hello, On a big powerpc box I got the following oops with 2.6.24-git2: sym0: 1010-66 rev 0x1 at pci :d0:01.0 irq 215 sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking sym0: SCSI BUS has been reset. scsi0 : sym-2.2.3 target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31) scsi 0:0:8:0: Direct-Access IBM ST318305LC C509 PQ: 0 ANSI: 3 target0:0:8: tagged command queuing enabled, command queue depth 16. target0:0:8: Beginning Domain Validation target0:0:8: asynchronous target0:0:8: wide asynchronous target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31) target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31) Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc0038460 cpu 0x25: Vector: 300 (Data Access) at [cf567840] pc: c0038460: .memcpy+0x60/0x280 lr: d0050280: .sym_set_cam_result_error+0xfc/0x1e0 [sym53c8xx] sp: cf567ac0 msr: 80009032 dar: 0 dsisr: 4200 current = 0xc06d1e0af0a0 paca= 0xc04afc00 pid = 0, comm = swapper enter ? for help [link register ] d0050280 .sym_set_cam_result_error+0xfc/0x1e0 [sym53c8xx] [cf567ac0] cf567b80 (unreliable) [cf567b80] d00552b8 .sym_complete_error+0x12c/0x1bc [sym53c8xx] [cf567c20] d00561a4 .sym_int_sir+0xaa4/0x1718 [sym53c8xx] [cf567d00] d0057e8c .sym_interrupt+0x4e4/0x6ec [sym53c8xx] [cf567dc0] d004fdf4 .sym53c8xx_intr+0x6c/0xdc [sym53c8xx] [cf567e50] c00a83e0 .handle_IRQ_event+0x7c/0xec [cf567ef0] c00aa344 .handle_fasteoi_irq+0x130/0x1f0 [cf567f90] c002a538 .call_handle_irq+0x1c/0x2c [c04d5e0b3a90] c000c320 .do_IRQ+0x108/0x1d0 [c04d5e0b3b20] c0004790 hardware_interrupt_entry+0x18/0x1c The memset() in sym_set_cam_result_error() would appear to be trashing the scsi_cmnd struct instead of clearing sense_buffer. Signed-off-by: Nathan Lynch [EMAIL PROTECTED] --- drivers/scsi/sym53c8xx_2/sym_glue.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.c b/drivers/scsi/sym53c8xx_2/sym_glue.c index 21e926d..e939f38 100644 --- a/drivers/scsi/sym53c8xx_2/sym_glue.c +++ b/drivers/scsi/sym53c8xx_2/sym_glue.c @@ -207,7 +207,7 @@ void sym_set_cam_result_error(struct sym_hcb *np, struct sym_ccb *cp, int resid) /* * Bounce back the sense data to user. */ - memset(cmd-sense_buffer, 0, SCSI_SENSE_BUFFERSIZE); + memset(cmd-sense_buffer, 0, SCSI_SENSE_BUFFERSIZE); memcpy(cmd-sense_buffer, cp-sns_bbuf, min(SCSI_SENSE_BUFFERSIZE, SYM_SNS_BBUF_LEN)); #if 0 I was looking into it and found something interesting. What you see was just exposed by: commit b80ca4f7ee36c26d300c5a8f429e73372d153379 Author: FUJITA Tomonori [EMAIL PROTECTED] Date: Sun Jan 13 15:46:13 2008 +0900 [SCSI] replace sizeof sense_buffer with This replaces sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE in several LLDs. It's a preparation for the future changes to remove sense_buffer array in scsi_cmnd structure. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] Signed-off-by: James Bottomley [EMAIL PROTECTED] But this is not a simple replace sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE It has a side effect. Take a look a this portion of the commit: --- a/drivers/scsi/sym53c8xx_2/sym_glue.c +++ b/drivers/scsi/sym53c8xx_2/sym_glue.c @@ -207,10 +207,9 @@ void sym_set_cam_result_error(struct sym_hcb *np, struct sym_ccb *cp, int resid) /* * Bounce back the sense data to user. */ - memset(cmd-sense_buffer, 0, sizeof(cmd-sense_buffer)); + memset(cmd-sense_buffer, 0, SCSI_SENSE_BUFFERSIZE); memcpy(cmd-sense_buffer, cp-sns_bbuf, - min(sizeof(cmd-sense_buffer), - (size_t)SYM_SNS_BBUF_LEN)); + min(SCSI_SENSE_BUFFERSIZE, SYM_SNS_BBUF_LEN)); Before the patch: 1) memset sets cmd-sense_buffer pointer value to zero (only 4 bytes which is wrong) 2) memcpy copies min(sizeof(cmd-sense_buffer), (size_t)SYM_SNS_BBUF_LEN)) which is equal to min(4, 32) so after this only first four bytes were copied from 32 bytes long cp-sns_bbuf into the sense_buffer After the patch: 1) memset zeroes 96 bytes of cmd structure starting at offset where sense_buffer in cmd is and results in an oops which you fixed 2) memcpy copies min(SCSI_SENSE_BUFFERSIZE, SYM_SNS_BBUF_LEN)) is equal to min(96, 32). cp-sns_bbuf is 32 bytes so I guess
Re: [PATCH] sym53c8xx: fix bad memset argument in sym_set_cam_result_error
On Sun, 2008-01-27 at 01:18 +0100, Mariusz Kozlowski wrote: Hello, On a big powerpc box I got the following oops with 2.6.24-git2: sym0: 1010-66 rev 0x1 at pci :d0:01.0 irq 215 sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking sym0: SCSI BUS has been reset. scsi0 : sym-2.2.3 target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31) scsi 0:0:8:0: Direct-Access IBM ST318305LC C509 PQ: 0 ANSI: 3 target0:0:8: tagged command queuing enabled, command queue depth 16. target0:0:8: Beginning Domain Validation target0:0:8: asynchronous target0:0:8: wide asynchronous target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31) target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31) Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc0038460 cpu 0x25: Vector: 300 (Data Access) at [cf567840] pc: c0038460: .memcpy+0x60/0x280 lr: d0050280: .sym_set_cam_result_error+0xfc/0x1e0 [sym53c8xx] sp: cf567ac0 msr: 80009032 dar: 0 dsisr: 4200 current = 0xc06d1e0af0a0 paca= 0xc04afc00 pid = 0, comm = swapper enter ? for help [link register ] d0050280 .sym_set_cam_result_error+0xfc/0x1e0 [sym53c8xx] [cf567ac0] cf567b80 (unreliable) [cf567b80] d00552b8 .sym_complete_error+0x12c/0x1bc [sym53c8xx] [cf567c20] d00561a4 .sym_int_sir+0xaa4/0x1718 [sym53c8xx] [cf567d00] d0057e8c .sym_interrupt+0x4e4/0x6ec [sym53c8xx] [cf567dc0] d004fdf4 .sym53c8xx_intr+0x6c/0xdc [sym53c8xx] [cf567e50] c00a83e0 .handle_IRQ_event+0x7c/0xec [cf567ef0] c00aa344 .handle_fasteoi_irq+0x130/0x1f0 [cf567f90] c002a538 .call_handle_irq+0x1c/0x2c [c04d5e0b3a90] c000c320 .do_IRQ+0x108/0x1d0 [c04d5e0b3b20] c0004790 hardware_interrupt_entry+0x18/0x1c The memset() in sym_set_cam_result_error() would appear to be trashing the scsi_cmnd struct instead of clearing sense_buffer. Signed-off-by: Nathan Lynch [EMAIL PROTECTED] --- drivers/scsi/sym53c8xx_2/sym_glue.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.c b/drivers/scsi/sym53c8xx_2/sym_glue.c index 21e926d..e939f38 100644 --- a/drivers/scsi/sym53c8xx_2/sym_glue.c +++ b/drivers/scsi/sym53c8xx_2/sym_glue.c @@ -207,7 +207,7 @@ void sym_set_cam_result_error(struct sym_hcb *np, struct sym_ccb *cp, int resid) /* * Bounce back the sense data to user. */ - memset(cmd-sense_buffer, 0, SCSI_SENSE_BUFFERSIZE); + memset(cmd-sense_buffer, 0, SCSI_SENSE_BUFFERSIZE); memcpy(cmd-sense_buffer, cp-sns_bbuf, min(SCSI_SENSE_BUFFERSIZE, SYM_SNS_BBUF_LEN)); #if 0 I was looking into it and found something interesting. What you see was just exposed by: commit b80ca4f7ee36c26d300c5a8f429e73372d153379 Author: FUJITA Tomonori [EMAIL PROTECTED] Date: Sun Jan 13 15:46:13 2008 +0900 [SCSI] replace sizeof sense_buffer with This replaces sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE in several LLDs. It's a preparation for the future changes to remove sense_buffer array in scsi_cmnd structure. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] Signed-off-by: James Bottomley [EMAIL PROTECTED] But this is not a simple replace sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE It has a side effect. Take a look a this portion of the commit: --- a/drivers/scsi/sym53c8xx_2/sym_glue.c +++ b/drivers/scsi/sym53c8xx_2/sym_glue.c @@ -207,10 +207,9 @@ void sym_set_cam_result_error(struct sym_hcb *np, struct sym_ccb *cp, int resid) /* * Bounce back the sense data to user. */ - memset(cmd-sense_buffer, 0, sizeof(cmd-sense_buffer)); + memset(cmd-sense_buffer, 0, SCSI_SENSE_BUFFERSIZE); memcpy(cmd-sense_buffer, cp-sns_bbuf, - min(sizeof(cmd-sense_buffer), - (size_t)SYM_SNS_BBUF_LEN)); + min(SCSI_SENSE_BUFFERSIZE, SYM_SNS_BBUF_LEN)); Before the patch: 1) memset sets cmd-sense_buffer pointer value to zero (only 4 bytes which is wrong) 2) memcpy copies min(sizeof(cmd-sense_buffer), (size_t)SYM_SNS_BBUF_LEN)) which is equal to min(4, 32) so after this only first four bytes were copied from 32 bytes long cp-sns_bbuf into the sense_buffer This logic is wrong. There was a commit (de25deb18016f66dcdede165d07654559bb332bc) that changed scsi_cmnd.sense_buffer
Re: [PATCH] sym53c8xx: fix bad memset argument in sym_set_cam_result_error
Hello, On a big powerpc box I got the following oops with 2.6.24-git2: sym0: 1010-66 rev 0x1 at pci :d0:01.0 irq 215 sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking sym0: SCSI BUS has been reset. scsi0 : sym-2.2.3 target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31) scsi 0:0:8:0: Direct-Access IBM ST318305LC C509 PQ: 0 ANSI: 3 target0:0:8: tagged command queuing enabled, command queue depth 16. target0:0:8: Beginning Domain Validation target0:0:8: asynchronous target0:0:8: wide asynchronous target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31) target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31) Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc0038460 cpu 0x25: Vector: 300 (Data Access) at [cf567840] pc: c0038460: .memcpy+0x60/0x280 lr: d0050280: .sym_set_cam_result_error+0xfc/0x1e0 [sym53c8xx] sp: cf567ac0 msr: 80009032 dar: 0 dsisr: 4200 current = 0xc06d1e0af0a0 paca= 0xc04afc00 pid = 0, comm = swapper enter ? for help [link register ] d0050280 .sym_set_cam_result_error+0xfc/0x1e0 [sym53c8xx] [cf567ac0] cf567b80 (unreliable) [cf567b80] d00552b8 .sym_complete_error+0x12c/0x1bc [sym53c8xx] [cf567c20] d00561a4 .sym_int_sir+0xaa4/0x1718 [sym53c8xx] [cf567d00] d0057e8c .sym_interrupt+0x4e4/0x6ec [sym53c8xx] [cf567dc0] d004fdf4 .sym53c8xx_intr+0x6c/0xdc [sym53c8xx] [cf567e50] c00a83e0 .handle_IRQ_event+0x7c/0xec [cf567ef0] c00aa344 .handle_fasteoi_irq+0x130/0x1f0 [cf567f90] c002a538 .call_handle_irq+0x1c/0x2c [c04d5e0b3a90] c000c320 .do_IRQ+0x108/0x1d0 [c04d5e0b3b20] c0004790 hardware_interrupt_entry+0x18/0x1c The memset() in sym_set_cam_result_error() would appear to be trashing the scsi_cmnd struct instead of clearing sense_buffer. Signed-off-by: Nathan Lynch [EMAIL PROTECTED] --- drivers/scsi/sym53c8xx_2/sym_glue.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.c b/drivers/scsi/sym53c8xx_2/sym_glue.c index 21e926d..e939f38 100644 --- a/drivers/scsi/sym53c8xx_2/sym_glue.c +++ b/drivers/scsi/sym53c8xx_2/sym_glue.c @@ -207,7 +207,7 @@ void sym_set_cam_result_error(struct sym_hcb *np, struct sym_ccb *cp, int resid) /* * Bounce back the sense data to user. */ - memset(cmd-sense_buffer, 0, SCSI_SENSE_BUFFERSIZE); + memset(cmd-sense_buffer, 0, SCSI_SENSE_BUFFERSIZE); memcpy(cmd-sense_buffer, cp-sns_bbuf, min(SCSI_SENSE_BUFFERSIZE, SYM_SNS_BBUF_LEN)); #if 0 I was looking into it and found something interesting. What you see was just exposed by: commit b80ca4f7ee36c26d300c5a8f429e73372d153379 Author: FUJITA Tomonori [EMAIL PROTECTED] Date: Sun Jan 13 15:46:13 2008 +0900 [SCSI] replace sizeof sense_buffer with This replaces sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE in several LLDs. It's a preparation for the future changes to remove sense_buffer array in scsi_cmnd structure. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] Signed-off-by: James Bottomley [EMAIL PROTECTED] But this is not a simple replace sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE It has a side effect. Take a look a this portion of the commit: --- a/drivers/scsi/sym53c8xx_2/sym_glue.c +++ b/drivers/scsi/sym53c8xx_2/sym_glue.c @@ -207,10 +207,9 @@ void sym_set_cam_result_error(struct sym_hcb *np, struct sym_ccb *cp, int resid) /* * Bounce back the sense data to user. */ - memset(cmd-sense_buffer, 0, sizeof(cmd-sense_buffer)); + memset(cmd-sense_buffer, 0, SCSI_SENSE_BUFFERSIZE); memcpy(cmd-sense_buffer, cp-sns_bbuf, - min(sizeof(cmd-sense_buffer), - (size_t)SYM_SNS_BBUF_LEN)); + min(SCSI_SENSE_BUFFERSIZE, SYM_SNS_BBUF_LEN)); Before the patch: 1) memset sets cmd-sense_buffer pointer value to zero (only 4 bytes which is wrong) 2) memcpy copies min(sizeof(cmd-sense_buffer), (size_t)SYM_SNS_BBUF_LEN)) which is equal to min(4, 32) so after this only first four bytes were copied from 32 bytes long cp-sns_bbuf into the sense_buffer This logic is wrong. There was a commit
[PATCH] hptiop: fix sense_buffer
Sorry, there was another place that I overlooked in the sense buffer conversion. = From: FUJITA Tomonori [EMAIL PROTECTED] Subject: [PATCH] hptiop: fix sense_buffer access bug Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- drivers/scsi/hptiop.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/hptiop.c b/drivers/scsi/hptiop.c index e7b2f35..890f44f 100644 --- a/drivers/scsi/hptiop.c +++ b/drivers/scsi/hptiop.c @@ -573,7 +573,7 @@ static void hptiop_finish_scsi_req(struct hptiop_hba *hba, u32 tag, scsi_set_resid(scp, scsi_bufflen(scp) - le32_to_cpu(req-dataxfer_length)); scp-result = SAM_STAT_CHECK_CONDITION; - memcpy(scp-sense_buffer, req-sg_list, + memcpy(scp-sense_buffer, req-sg_list, min_t(size_t, SCSI_SENSE_BUFFERSIZE, le32_to_cpu(req-dataxfer_length))); break; -- 1.5.3.4 - 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
aic79xx: fix sense_buffer access bug
Ah, I overlooked more LLDs... = From: FUJITA Tomonori [EMAIL PROTECTED] Subject: [PATCH] aic79xx: fix sense_buffer access bug The commit de25deb18016f66dcdede165d07654559bb332bc changed scsi_cmnd.sense_buffer from a static array to a dynamically allocated buffer. We can't access to sense_buffer in 'cmd-sense_buffer' way. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- drivers/scsi/aic7xxx/aic79xx_osm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/aic7xxx/aic79xx_osm.c b/drivers/scsi/aic7xxx/aic79xx_osm.c index 0e4708f..3c4efa4 100644 --- a/drivers/scsi/aic7xxx/aic79xx_osm.c +++ b/drivers/scsi/aic7xxx/aic79xx_osm.c @@ -1922,7 +1922,7 @@ ahd_linux_queue_cmd_complete(struct ahd_softc *ahd, struct scsi_cmnd *cmd) struct scsi_sense_data *sense; sense = (struct scsi_sense_data *) - cmd-sense_buffer; + cmd-sense_buffer; if (sense-extra_len = 5 (sense-add_sense_code == 0x47 || sense-add_sense_code == 0x48)) -- 1.5.3.4 - 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] zfcp: fix sense_buffer access bug
The commit de25deb18016f66dcdede165d07654559bb332bc changed scsi_cmnd.sense_buffer from a static array to a dynamically allocated buffer. We can't access to sense_buffer in 'cmd-sense_buffer' way. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- drivers/s390/scsi/zfcp_fsf.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/s390/scsi/zfcp_fsf.c b/drivers/s390/scsi/zfcp_fsf.c index fe57941..a9a147d 100644 --- a/drivers/s390/scsi/zfcp_fsf.c +++ b/drivers/s390/scsi/zfcp_fsf.c @@ -4224,10 +4224,10 @@ zfcp_fsf_send_fcp_command_task_handler(struct zfcp_fsf_req *fsf_req) ZFCP_LOG_TRACE(%i bytes sense data provided by FCP\n, fcp_rsp_iu-fcp_sns_len); - memcpy(scpnt-sense_buffer, + memcpy(scpnt-sense_buffer, zfcp_get_fcp_sns_info_ptr(fcp_rsp_iu), sns_len); ZFCP_HEX_DUMP(ZFCP_LOG_LEVEL_TRACE, - (void *) scpnt-sense_buffer, sns_len); + (void *)scpnt-sense_buffer, sns_len); } /* check for overrun */ -- 1.5.3.4 - 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] ncr53c8xx: fix sense_buffer access bug
The commit de25deb18016f66dcdede165d07654559bb332bc changed
scsi_cmnd.sense_buffer from a static array to a dynamically allocated
buffer. We can't access to sense_buffer in 'cmd-sense_buffer' way.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/ncr53c8xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/ncr53c8xx.c b/drivers/scsi/ncr53c8xx.c
index c02771a..c5ebf01 100644
--- a/drivers/scsi/ncr53c8xx.c
+++ b/drivers/scsi/ncr53c8xx.c
@@ -4967,7 +4967,7 @@ void ncr_complete (struct ncb *np, struct ccb *cp)
sizeof(cp-sense_buf)));
if (DEBUG_FLAGS (DEBUG_RESULT|DEBUG_TINY)) {
- u_char * p = (u_char*) cmd-sense_buffer;
+ u_char *p = cmd-sense_buffer;
int i;
PRINT_ADDR(cmd, sense data:);
for (i=0; i14; i++) printk ( %x, *p++);
--
1.5.3.4
-
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
