Re: [PATCH] jazz_esp converted to use esp_core
On Tue, May 22, 2007 at 12:00:41AM +0100, Christoph Hellwig wrote: On Mon, May 21, 2007 at 11:02:24PM +0200, Thomas Bogendoerfer wrote: after chasing and fixing two jazz platform bugs and one MIPS dma mapping bug, I finally succeeded in using the Dave's new esp_core (great work, thank you Dave). Below is the patch. Very nice driver. The only thing that confused me a little are the various helper functions split out of esp_jazz_probe that make the code a bit odd to read. Are these intentional or a carry over from the previous driver? the sparc frontend used them, because most of these helper are checking for prom properties, which the jazz doesn't have. I've changed that and folded those little helpers into the probe function. I'll send a new patch a couple of minutes. --- a/drivers/scsi/Makefile +++ b/drivers/scsi/Makefile @@ -121,7 +121,7 @@ obj-$(CONFIG_BLK_DEV_3W__RAID) += 3w-.o obj-$(CONFIG_SCSI_3W_9XXX) += 3w-9xxx.o obj-$(CONFIG_SCSI_PPA) += ppa.o obj-$(CONFIG_SCSI_IMM) += imm.o -obj-$(CONFIG_JAZZ_ESP) += NCR53C9x.o jazz_esp.o +obj-$(CONFIG_JAZZ_ESP) += jazz_esp.o Note to Dave: it probably would be nice to just build esp_scsi.o from the makefile like the old NCR53C9x drivers did instead of the Kconfig hackery, what do you think? after seeing no objection to using esp_scsi.o like NCR53C9x.o, I also changed that. 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] jazz_esp converted to use esp_core
Here is an updated patch for converting jazz_esp to use esp_scsi.
Thomas.
Use new esp_scsi for JAZZ SCSI host adapter driver
Signed-off-by: Thomas Bogendoerfer [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 51e884f..fc05d90 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -121,7 +121,7 @@ obj-$(CONFIG_BLK_DEV_3W__RAID) += 3w-.o
obj-$(CONFIG_SCSI_3W_9XXX) += 3w-9xxx.o
obj-$(CONFIG_SCSI_PPA) += ppa.o
obj-$(CONFIG_SCSI_IMM) += imm.o
-obj-$(CONFIG_JAZZ_ESP) += NCR53C9x.o jazz_esp.o
+obj-$(CONFIG_JAZZ_ESP) += esp_scsi.o jazz_esp.o
obj-$(CONFIG_SUN3X_ESP)+= NCR53C9x.o sun3x_esp.o
obj-$(CONFIG_SCSI_FCAL)+= fcal.o
obj-$(CONFIG_SCSI_LASI700) += 53c700.o lasi700.o
diff --git a/drivers/scsi/jazz_esp.c b/drivers/scsi/jazz_esp.c
index 19dd4b9..10ceda1 100644
--- a/drivers/scsi/jazz_esp.c
+++ b/drivers/scsi/jazz_esp.c
@@ -1,307 +1,244 @@
-/*
- * jazz_esp.c: Driver for SCSI chip on Mips Magnum Boards (JAZZ architecture)
+/* jazz_esp.c: ESP front-end for MIPS JAZZ systems.
*
- * Copyright (C) 1997 Thomas Bogendoerfer ([EMAIL PROTECTED])
- *
- * jazz_esp is based on David S. Miller's ESP driver and cyber_esp
+ * Copyright (C) 2007 Thomas Bogendörfer ([EMAIL PROTECTED])
*/
-#include linux/init.h
#include linux/kernel.h
-#include linux/delay.h
#include linux/types.h
-#include linux/string.h
-#include linux/slab.h
-#include linux/blkdev.h
-#include linux/proc_fs.h
-#include linux/stat.h
-
-#include scsi.h
-#include scsi/scsi_host.h
-#include NCR53C9x.h
+#include linux/module.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/dma-mapping.h
#include asm/irq.h
-#include asm/jazz.h
-#include asm/jazzdma.h
+#include asm/io.h
#include asm/dma.h
-#include asm/pgtable.h
-
-static int dma_bytes_sent(struct NCR_ESP *esp, int fifo_count);
-static int dma_can_transfer(struct NCR_ESP *esp, struct scsi_cmnd *sp);
-static void dma_dump_state(struct NCR_ESP *esp);
-static void dma_init_read(struct NCR_ESP *esp, __u32 vaddress, int length);
-static void dma_init_write(struct NCR_ESP *esp, __u32 vaddress, int length);
-static void dma_ints_off(struct NCR_ESP *esp);
-static void dma_ints_on(struct NCR_ESP *esp);
-static int dma_irq_p(struct NCR_ESP *esp);
-static int dma_ports_p(struct NCR_ESP *esp);
-static void dma_setup(struct NCR_ESP *esp, __u32 addr, int count, int write);
-static void dma_mmu_get_scsi_one (struct NCR_ESP *esp, struct scsi_cmnd *sp);
-static void dma_mmu_get_scsi_sgl (struct NCR_ESP *esp, struct scsi_cmnd *sp);
-static void dma_mmu_release_scsi_one (struct NCR_ESP *esp, struct scsi_cmnd
*sp);
-static void dma_mmu_release_scsi_sgl (struct NCR_ESP *esp, struct scsi_cmnd
*sp);
-static void dma_advance_sg (struct scsi_cmnd *sp);
-static void dma_led_off(struct NCR_ESP *);
-static void dma_led_on(struct NCR_ESP *);
-
-
-static volatile unsigned char cmd_buffer[16];
- /* This is where all commands are put
-* before they are trasfered to the ESP chip
-* via PIO.
-*/
-
-static int jazz_esp_release(struct Scsi_Host *shost)
-{
- if (shost-irq)
- free_irq(shost-irq, NULL);
- if (shost-dma_channel != 0xff)
- free_dma(shost-dma_channel);
- if (shost-io_port shost-n_io_port)
- release_region(shost-io_port, shost-n_io_port);
- scsi_unregister(shost);
- return 0;
-}
-
-/* Detection */
-static int jazz_esp_detect(struct scsi_host_template *tpnt)
-{
-struct NCR_ESP *esp;
-struct ConfigDev *esp_dev;
-
-/*
- * first assumption it is there:-)
- */
-if (1) {
- esp_dev = NULL;
- esp = esp_allocate(tpnt, esp_dev, 0);
-
- /* Do command transfer with programmed I/O */
- esp-do_pio_cmds = 1;
-
- /* Required functions */
- esp-dma_bytes_sent = dma_bytes_sent;
- esp-dma_can_transfer = dma_can_transfer;
- esp-dma_dump_state = dma_dump_state;
- esp-dma_init_read = dma_init_read;
- esp-dma_init_write = dma_init_write;
- esp-dma_ints_off = dma_ints_off;
- esp-dma_ints_on = dma_ints_on;
- esp-dma_irq_p = dma_irq_p;
- esp-dma_ports_p = dma_ports_p;
- esp-dma_setup = dma_setup;
-
- /* Optional functions */
- esp-dma_barrier = NULL;
- esp-dma_drain = NULL;
- esp-dma_invalidate = NULL;
- esp-dma_irq_entry = NULL;
- esp-dma_irq_exit = NULL;
- esp-dma_poll = NULL;
- esp-dma_reset = NULL;
- esp-dma_led_off = dma_led_off;
- esp-dma_led_on = dma_led_on;
-
- /* virtual DMA functions */
- esp-dma_mmu_get_scsi_one = dma_mmu_get_scsi_one;
- esp-dma_mmu_get_scsi_sgl =
Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4,
[added cc:linux-ide] Hans A Eide writes: Evan Harris wrote: I have a card that mirrors this one from your list: Retail name: SATA300 TX4 Chip label: PDC40718-GP SATAII300 Vendor-Device number: 105a:3d17 (rev 02) Through testing, I've found linux 2.6.16 and 2.6.17 find the ports in this order (the list is ordered by linux detection): 1. silkscreen port 3 2. silkscreen port 2 3. silkscreen port 4 4. silkscreen port 1 NOTE: the patch I have submitted ( http://marc.theaimsgroup.com/?l=linux- idem=114082978311290w=2 ) is a solution that doesn't know about the older Promise SATA controllers, which are not affected with the new wiring problem, so the older controllers will appear screwed if you use it. Hopefully we will collect enough info about all the SATA Promise controllers to distinguish the new and the old wiring controllers, then produce a new patch that will be a correct solution to the new wiring problem. Mikael Pettersson has been doing some excellent work recently on sata_promise. If enough data has been collected on this sata_promise port enumeration problem, maybe the data could be collated and proposed via Mikael as a patch? Jeff Sorry, any updates on this? You should have posted this to linux-ide not linux-scsi. The Promise SATAII TX4 port enumeration issue is fixed in current 2.6.22-rc kernels. A patch for 2.6.21 can be found in http://marc.info/?l=linux-idem=117728096711046w=2. /Mikael - 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] FC Transport support for vports based on NPIV
On Mon, May 21, 2007 at 11:45:13AM -0400, James Smart wrote: True - so this means that who-ever is setting the subchannel device permanent_port_name value needs to take into account this conversation, when T11.3 actually makes a choice on what it should be. I will keep this in mind. Probably this would involve the FCP adapter and the reporting in zfcp. Anyway, my main goal was to understand the changes in the FC transport class and the possible impact to zfcp. Thanks for the clarification of my questions. Christof - 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] aacraid: apply commit config for reset_devices flag
Under some conditions associated with the unclean transition to kdump, the aacraid adapters will view the array as foreign and not export it to prevent access and data manipulation. The solution is to submit a commit configuration to export the devices since this is a expected behavior when transitioning to a kdump kernel. This patch adds the aacraid.reset_devices flag and when either this or the global reset_devices flag is set, ensures that a commit config is issued and extends the startup_timeout if it is set less than 5 minutes. This attached patch is against current scsi-misc-2.6 and was unit tested on RHEL5 and 2.6.22. This is a bugfix, so this patch needs to propagate quickly. ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments. Signed-off-by: Mark Salyzyn [EMAIL PROTECTED] Sincerely -- Mark Salyzyn -Original Message- From: Salyzyn, Mark Sent: Wednesday, May 16, 2007 10:41 AM To: '[EMAIL PROTECTED]' Subject: RE: System does not boot if booted with reset_devices Vivek, could you please try the enclosed patch. This patch adds the aacraid.reset_devices flag and when either this or the global reset_devices flag is set, ensures that a commit config is issued and extends the startup_timeout if it is set less than 5 minutes. IF you are satisfied with this, I will submit it to the scsi list. Sincerely -- Mark Salyzyn -Original Message- From: Vivek Goyal [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 16, 2007 1:31 AM To: Salyzyn, Mark Subject: Re: System does not boot if booted with reset_devices On Tue, May 15, 2007 at 12:51:06PM -0400, Salyzyn, Mark wrote: Been tossing it around here, and it appears I am the only person that considers this a risk to do a forced commit config in this scenario. I will send you a patch later that does this (basically export commit from aachba.c, and set it to a value of one if we had to reset the adapter during the initialization, but I will have to make sure I resolve all symbol name overlaps etc, so not a simple task; and few minutes left in my day to work on this). Thanks Mark. I am waiting for your patch. :-) Thanks Vivek aacraid_commit_reset.patch Description: aacraid_commit_reset.patch
Re: [PATCH] aic7xxx/aicasm build failure w/gcc-3.4.6
On Tue, 2007-05-22 at 06:51 -0500, Bob Tracy wrote: Second try: originally reported this back on April 17th. 2.6.X kernel builds started failing after I upgraded my compiler from gcc-3.3.X to gcc-3.4.6: make -C drivers/scsi/aic7xxx/aicasm (...) gcc -I/usr/include -I. aicasm.c aicasm_symbol.c aicasm_gram.c aicasm_macro_gram.c aicasm_scan.c aicasm_macro_scan.c -o aicasm -ldb aicasm_gram.y:1948: error: conflicting types for 'yyerror' aicasm_gram.tab.c:3004: error: previous implicit declaration of 'yyerror' was here aicasm_macro_gram.y:162: error: conflicting types for 'mmerror' aicasm_macro_gram.tab.c:1196: error: previous implicit declaration of 'mmerror' was here As a workaround, commenting out or deleting the void declarations for yyerror() and mmerror() in the respective .y files fixes the problem. We really don't want gcc making assumptions about prototypes ... even if it's getting them right in all likelihood (doubtless unprototyped assumed functions will become a warning and then an error in later gcc versions ...), so this is a better fix James diff --git a/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y b/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y index c328596..6066998 100644 --- a/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y +++ b/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y @@ -106,6 +106,7 @@ static void make_expression(expression_t *immed, int value); static void add_conditional(symbol_t *symbol); static void add_version(const char *verstring); static int is_download_const(expression_t *immed); +void yyerror(const char *string); #define SRAM_SYMNAME SRAM_BASE #define SCB_SYMNAME SCB_BASE diff --git a/drivers/scsi/aic7xxx/aicasm/aicasm_macro_gram.y b/drivers/scsi/aic7xxx/aicasm/aicasm_macro_gram.y index 439f760..ff46aa6 100644 --- a/drivers/scsi/aic7xxx/aicasm/aicasm_macro_gram.y +++ b/drivers/scsi/aic7xxx/aicasm/aicasm_macro_gram.y @@ -65,6 +65,7 @@ static symbol_t *macro_symbol; static void add_macro_arg(const char *argtext, int position); +void mmerror(const char *string); %} - 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: Dell CERC ATA100/4ch support
James Bottomley wrote: On Wed, 2007-05-16 at 14:36 +0100, Leigh Blackwell wrote: I have been looking at the issue with theses cerc devices, has this bug 374792 been closed based on people reverting the firmware to 6.61. Unfortunately Dell doesn't support a Firmware version that old on our Server, is it possible to re-open this bug? I have been unable to get the current etch install to recognize my driver controller with any of the megaraid drivers. Umm, but this is a bug in Dell Support isn't it? I don't think there's a kernel fix for that. LSIs position is that in current kernels they only support this device with the new megaraid driver and only for firmware version = 6.61. Surely you just need to get Dell and LSI on the same page? Provided they have an interest in doing so. Dell for one is _not_ interested in supplying an updated firmware. So we're stuck. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage [EMAIL PROTECTED] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) - 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] aic7xxx/aicasm build failure w/gcc-3.4.6
James Bottomley wrote: We really don't want gcc making assumptions about prototypes ... even if it's getting them right in all likelihood (doubtless unprototyped assumed functions will become a warning and then an error in later gcc versions ...), so this is a better fix ACK. The fix works here. If you would be so kind, please push it upstream at your convenience. gcc-4.X violates the principle of least astonishment over even more nitnoid matters, but that's another flame for another day. -- --- Bob Tracy | Eagles may soar, but weasels don't get [EMAIL PROTECTED]| sucked into jet engines. --Anon --- - 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] fc_transport: fix sysfs deadlock on vport delete
On Fri, 2007-04-27 at 12:52 -0400, James Smart wrote: When the vport attribute delete is used to delete the vport, sysfs deadlocks waiting for the write to complete, which is waiting for the sysfs teardown to complete. Moved this effort to a work_q element. Took the opportunity to make some other cosmetic changes: - removed tabs in Doc file - replaced with expanded spaces - minor copyright text and author text updates - removed a bunch of trailing whitespace This one rejects against scsi-misc, could you reroll (I suspect because the prior vport patch had spacing errors which git makes me fix before I commit). 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] bug fix: SCSI async scan sysfs -EEXIST problem
On Mon, 2007-05-07 at 14:57 -0400, James Smart wrote: + mutex_lock(shost-scan_mutex); scsi_sysfs_add_devices(shost); + atomic_set(shost-async_scan, 0); + mutex_unlock(shost-scan_mutex); It really seems that the only safety here is expanding the scan mutex to cover more of the code. I don't really see any value to using the atomic types ... it's not a simultaneous variable update problem, it's a scan race which the mutex can be used to mediate. 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 18/28] scsi/lpfc/lpfc_init.c: remove unused variable
On Thu, 2007-05-10 at 23:01 -0700, [EMAIL PROTECTED] wrote: From: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Actually, not against vanilla linus: drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_pci_probe_one': drivers/scsi/lpfc/lpfc_init.c:1581: error: 'retval' undeclared (first use in this function) drivers/scsi/lpfc/lpfc_init.c:1581: error: (Each undeclared identifier is reported only once drivers/scsi/lpfc/lpfc_init.c:1581: error: for each function it appears in.) There's probably some global change in -mm that makes pci_set_mwi() return void ... in which case, this needs to be swept up into it. 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 18/28] scsi/lpfc/lpfc_init.c: remove unused variable
On Tue, 22 May 2007 14:04:02 -0500 James Bottomley [EMAIL PROTECTED] wrote: On Thu, 2007-05-10 at 23:01 -0700, [EMAIL PROTECTED] wrote: From: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Actually, not against vanilla linus: drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_pci_probe_one': drivers/scsi/lpfc/lpfc_init.c:1581: error: 'retval' undeclared (first use in this function) drivers/scsi/lpfc/lpfc_init.c:1581: error: (Each undeclared identifier is reported only once drivers/scsi/lpfc/lpfc_init.c:1581: error: for each function it appears in.) There's probably some global change in -mm that makes pci_set_mwi() return void ... in which case, this needs to be swept up into it. yep, sorry. I rebadged this patch as being after Greg merges add-pci_try_set_mwi.patch - 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 10/28] Fix |/|| confusion in fusion driver
On Monday, May 21, 2007 7:00 PM, Dave Jones wrote: Andrew, the last time this was posted, Eric picked up on some other flaws in the same area. James asked him to followup with a patch, but unless I'm mistaken, that never arrived. This diff should replace the one in your tree until Eric has an equivalent or better. Signed-off-by: Dave Jones [EMAIL PROTECTED] ACK Thanks Dave, this patch will work. - 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] fix for BZ 8426 - massive slowdown on SCSI CD/DVD drive connected to mptspi driver
Eric, Sorry to bother you on this again, I realize you are very busy. From our off-list email and from your comments to Chip Coldwell in redhat BZ 225177 it sounded like you were prepared to ACK this. Any chance you could send your official ACK so this can be committed? much appreciated, - Doug On Mon, 2007-05-07 at 15:59 -0400, Doug Chapman wrote: Patch for: http://bugzilla.kernel.org/show_bug.cgi?id=8426 A recent code cleanup that moved code from mptscsih to mptspi inadvertently change the order some code was called. This caused a massive slowdown (of 150x to 300x) on the CD/DVD drive on the high-end HP Integrity servers. Signed-off-by: Doug Chapman [EMAIL PROTECTED] diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c index 85f21b5..2eb5741 100644 --- a/drivers/message/fusion/mptspi.c +++ b/drivers/message/fusion/mptspi.c @@ -726,13 +726,15 @@ static int mptspi_slave_configure(struct scsi_device *sdev) struct _MPT_SCSI_HOST *hd = (struct _MPT_SCSI_HOST *)sdev-host-hostdata; VirtTarget *vtarget = scsi_target(sdev)-hostdata; - int ret = mptscsih_slave_configure(sdev); + int ret; + + mptspi_initTarget(hd, vtarget, sdev); + + ret = mptscsih_slave_configure(sdev); if (ret) return ret; - mptspi_initTarget(hd, vtarget, sdev); - ddvprintk((MYIOC_s_INFO_FMT id=%d min_period=0x%02x max_offset=0x%02x max_width=%d\n, hd-ioc-name, sdev-id, spi_min_period(scsi_target(sdev)), - 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: Sg_ses question
Haefliger, Juerg wrote: Hi, Not sure if this is the right list for my question but I couldn't find a more suitable place to ask it. I'm trying to set the locator light of a disk in a SAS enclosure using sg_ses but I'm not getting anywhere. I'm dumping the enclosure status diagnostic page using 'sg_ses --page=2 --raw /dev/sgXX page' and then set the SELECT and RQST IDENT bits of the array device element in question and write it back doing 'sg_ses --control --page=2 --data=- /dev/sgXX tmp'. The command completes without error but unfortunately, nothing happens. When I read the page back, the IDENT bit is still cleared and the light on the enclosure remains turned off. Am I doing something wrong or am I missing something? Can't I use sg_ses to achieve this? The procedure looks correct. I haven't had any (other) reports of sg_ses not working lately. The only suggestion I can make is to ask if you have selected the element control rather than the overall control. Doug Gilbert - 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] [scsi] Remove __GFP_DMA
On Mon, 21 May 2007, Bernhard Walle wrote: [PATCH] [scsi] Remove __GFP_DMA After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate a DMA buffer any more in sd.c. Signed-off-by: Bernhard Walle [EMAIL PROTECTED] Great that avoids a DMA kmalloc slab. Any other GFP_DMAs left in the scsi layer? Acked-by: Christoph Lameter [EMAIL PROTECTED] - 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 0/19] clean ups on the drivers
From: FUJITA Tomonori [EMAIL PROTECTED] Subject: Re: [PATCH 0/19] clean ups on the drivers Date: Mon, 14 May 2007 23:40:03 +0900 From: Christoph Hellwig [EMAIL PROTECTED] Subject: Re: [PATCH 0/19] clean ups on the drivers Date: Sat, 12 May 2007 16:30:23 +0100 On Sat, May 12, 2007 at 07:05:42PM +0900, FUJITA Tomonori wrote: There are two patches for each driver, removing the non-use-sg code and converting to use the accessors. One patch would probably be fine aswell. I merged the two. And I finished cleaning up 35 drivers in total. git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git cleanups I rebased the cleanup patchset against the latest scsi-misc (352e921f0dd42f79652cdb50dd91122d068d7209). It includes the cleanups for more than 40 drivers. - 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] [scsi] Remove __GFP_DMA
On 5/23/07, Christoph Lameter [EMAIL PROTECTED] wrote:
On Mon, 21 May 2007, Bernhard Walle wrote:
[PATCH] [scsi] Remove __GFP_DMA
After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate
a
DMA buffer any more in sd.c.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
Great that avoids a DMA kmalloc slab. Any other GFP_DMAs left in the scsi
layer?
Acked-by: Christoph Lameter [EMAIL PROTECTED]
Yes, here is another patch
Signed-off-by: Aubrey.Li [EMAIL PROTECTED]
---
drivers/scsi/aacraid/commctrl.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/aacraid/commctrl.c b/drivers/scsi/aacraid/commctrl.c
index 72b0393..405722d 100644
--- a/drivers/scsi/aacraid/commctrl.c
+++ b/drivers/scsi/aacraid/commctrl.c
@@ -580,8 +580,8 @@ static int aac_send_raw_srb(struct aac_dev* dev,
void __user * arg)
for (i = 0; i upsg-count; i++) {
u64 addr;
void* p;
- /* Does this really need to be GFP_DMA? */
- p =
kmalloc(upsg-sg[i].count,GFP_KERNEL|__GFP_DMA);
+
+ p = kmalloc(upsg-sg[i].count,GFP_KERNEL);
if(p == 0) {
dprintk((KERN_DEBUGaacraid: Could not
allocate SG buffer - size
= %d buffer number %d of %d\n,
upsg-sg[i].count,i,upsg-count));
@@ -624,8 +624,8 @@ static int aac_send_raw_srb(struct aac_dev* dev,
void __user * arg)
for (i = 0; i usg-count; i++) {
u64 addr;
void* p;
- /* Does this really need to be GFP_DMA? */
- p =
kmalloc(usg-sg[i].count,GFP_KERNEL|__GFP_DMA);
+
+ p = kmalloc(usg-sg[i].count,GFP_KERNEL);
if(p == 0) {
kfree (usg);
dprintk((KERN_DEBUGaacraid: Could not
allocate SG buffer - size
= %d buffer number %d of %d\n,
@@ -666,8 +666,8 @@ static int aac_send_raw_srb(struct aac_dev* dev,
void __user * arg)
for (i = 0; i upsg-count; i++) {
u64 addr;
void* p;
- /* Does this really need to be GFP_DMA? */
- p =
kmalloc(usg-sg[i].count,GFP_KERNEL|__GFP_DMA);
+
+ p = kmalloc(usg-sg[i].count,GFP_KERNEL);
if(p == 0) {
dprintk((KERN_DEBUGaacraid: Could not
allocate SG buffer - size
= %d buffer number %d of %d\n,
usg-sg[i].count,i,usg-count));
--
1.5.1.1
-
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
