sd_done and WRITE_SAME broken?
drivers/scsi/sd.c
1706 if (sshdr.asc == 0x20 || sshdr.asc == 0x24) {
1707 switch (op) {
1708 case UNMAP:
1709 sd_config_discard(sdkp, SD_LBP_DISABLE);
1710 break;
1711 case WRITE_SAME_16:
1712 case WRITE_SAME:
1713 if (unmap)
1714 sd_config_discard(sdkp,
SD_LBP_DISABLE);
1715 else {
1716 sdkp->device->no_write_same = 1;
1717 sd_config_write_same(sdkp);
1718
1719 good_bytes = 0;
1720 req->__data_len =
blk_rq_bytes(req);
1721 req->cmd_flags |= REQ_QUIET;
1722 }
1723 }
1724 }
line 1720 is assigning the same value to same field in same req.
That's probably not what was intended but I don't know what is needed
here.
cheers,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DMA mapping on SCSI device?
On Jan 29, 2008 11:08 AM, Robert Hancock [EMAIL PROTECTED] wrote: ... The last solution I tried was to set the DMA mask on both ports to 32-bit on slave_configure when an ATAPI device is connected. However, this runs into complications as well. This is run on initialization and when trying to set the other port into 32-bit DMA, it may not be initialized yet. Plus, it forces the port with a hard drive on it into 32-bit DMA needlessly. Have you measured the impact of setting the PCI dma mask to 32-bit? Last time Alex Williamson (HP) measured this on IA64, we deliberately forced pci_map_sg() to use the IOMMU even for devices that were 64-bit capable. We got 3-5% better throughput since the device had fewer entries to retrieve and the devices (at the time) weren't that good at processing SG lists. The ideal solution would be to do mapping against a different struct device for each port, so that we could maintain the proper DMA mask for each of them at all times. However I'm not sure if that's possible. The thought of using the SCSI struct device for DMA mapping was brought up at one point.. any thoughts on that? I'm pretty sure that's not possible (using two PCI dev structs). I'm skeptical it's worth converting DMA services to use SCSI devs since that's an extremely invasive change for a marginal benefit. hth, grant - 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 - 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] Marvell 6440 SAS/SATA driver
On Jan 25, 2008 8:43 AM, Ke Wei [EMAIL PROTECTED] wrote: The attached is Marvell 6440 SAS/SATA driver. I will try to send email by git-send-email. Sorry, just saw some more issues in +static void mvs_hba_interrupt_enable(struct mvs_info *mvi, int enable) Three comments here: 1) This routine is slightly misnamed since it can both enable and disable the interrupt. I _suggest_ to not pass in enable parameter and add a mvs_hba_interrupt_disable() to deal with (2) and (3) below. 2) On interrupt disable, MMIO write posting _could_ be a problem here. ie interrupts could be generated after calling this routine since it doesn't force the MMIO write to the PCI device with an MMIO read. (For more info on this see chapter 4 of http://iou.parisc-linux.org/ols_2002/ ) 3) Even after fixing (2), interrupts can already be in-flight and not yet delivered. Higher level code needs to make sure it can tolerate a late arriving IRQ. One MMIO read should mostly solve this for MSI but not for Line-based IRQ. (MMIO Read-return will flush inflight MSI). hth, grant - 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] Marvell 6440 SAS/SATA driver
On Jan 25, 2008 8:43 AM, Ke Wei [EMAIL PROTECTED] wrote:
The attached is Marvell 6440 SAS/SATA driver. I will try to send email
by git-send-email.
I know this isn't part of this patch:
#define mr32(reg) readl(regs + MVS_##reg)
#define mw32(reg,val) writel((val), regs + MVS_##reg)
But can regs be declared a parameter to the macro?
And the one letter difference in the name is just asking for trouble.
Better to call it mmio_base or something a bit longer that won't
likely collide with other stuff.
+/* offset for D2H FIS in the Received FIS List Structure */
+#define SATA_RECEIVED_D2H_FIS(reg_set) \
+ (mvi-rx_fis + 0x400 + 0x100 * reg_set + 0x40)
Ditto.
+ MODE_AUTO_DET_PORT7 = (1U 15), /* port0 SAS/SATA autodetect */
+ MODE_AUTO_DET_PORT6 = (1U 14),
+ MODE_AUTO_DET_PORT5 = (1U 13),
+ MODE_AUTO_DET_PORT4 = (1U 12),
+ MODE_AUTO_DET_PORT3 = (1U 11),
+ MODE_AUTO_DET_PORT2 = (1U 10),
+ MODE_AUTO_DET_PORT1 = (1U 9),
+ MODE_AUTO_DET_PORT0 = (1U 8),
These really aren't needed.
#define MODE_AUTO_DET_EN (0xff 8)/* enable auto detect on all
8 ports */
Ditto for MODE_SAS_SATA.
+ /* Port n Attached Device Info */
Groups bits defined have a comment preceeding a group of bits (which
is a good thing). If multiple registers are being defined in one enum
declaration, can you please add either the register offset
to the comment or include the constant that defines the
offset (e.g. MVS_P0_CFG_ADDR)?
Have to stop for now...but I'm wonder how this driver ever worked
given the number of HW register bits that were changed (assuming
they were wrong before this patch). And this driver looks _alot_
better than the previous Marvell drivers I've looked at. Please keep
up the good work! :)
hth,
grant
Changelog :
Merged from Jeff's branch to James's branch.
Signed-off-by: Ke Wei [EMAIL PROTECTED]
On Jan 23, 2008 7:41 PM, Jeff Garzik [EMAIL PROTECTED] wrote:
Ke Wei wrote:
Attachment is a patch file for 6440 driver. I will have to spend more
time on setting my mail client. Yesterday I used mutt tool. But Look
like the problem still exists.
I fixed all issues which you mentioned , but
The changes look good, thanks!
In terms of engineering process, I should have been more clear: when
revising your submission, you should make the revisions and then
regenerate your original patch.
To use a silly example, if you needed to fix a 1-character typo in a
1,000-line patch, you would need to make your revision, re-generate the
1,000-line patch, and email that new patch.
So, to move forward, please create one single patch with the latest
mvsas, diff'd against the 'mvsas' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
I will ack that patch (indicate my approval), and unless other
objections surface, James will merge your patch into the 'mvsas' branch.
That will get the driver on the road to be included in 2.6.25.
@@ -666,11 +970,53 @@ static int mvs_nvram_read(struct mvs_info *mvi,
unsigned
int addr,
err_out:
dev_printk(KERN_ERR, mvi-pdev-dev, %s, msg);
return rc;
+#else
+ memcpy(buf, \x50\x05\x04\x30\x11\xab\x00\x00, 8);
+ return 0;
+#endif
what happens if two adapters are used, with the same SAS address? That
causes problems...
Our bios can write SAS Address per port when system boot , so I think
we don't need read or configure address.
It is standard Linux policy to reduce or eliminate BIOS dependencies as
much as possible.
This is because there are several common scenarios where BIOS may not
run, or otherwise not be available:
* suspend/resume
* controller hotplug
* non-x86 PCI platforms such as POWER
Thus, we need the driver to obtain these addresses -- hopefully reading
them from a BIOS data table somewhere, if NVRAM is not available.
This is a highly common scenario -- obtaining unique identifying
information in the absence of BIOS.
Similarly, we cannot rely on BIOS to perform any global reset or errata
workaround duties for us. That must be coded into the driver also.
And I reserved hexdump funciton if you don't care. Only debugging.
It is not an important matter, but it would be nice to clean that up
eventually.
Also, FWIW, we have a standard method of debug output:
struct pci_dev *pdev;
dev_dbg(pdev-dev, KERN_INFO,
this is debug message number %d, 2);
which will only be compiled into the driver when DEBUG is defined.
+static int mvs_abort_task(struct sas_task *task)
+{
+ /*FIXME*/
+ MVS_PRINTK(mvs abort task\n);
+ return TMF_RESP_FUNC_COMPLETE;
+}
should make an attempt to do something sane here
if entering this abort function , I think I must fix the unknown
issues instead of here. But I also will implement next.
Re: [linux-usb-devel] [PATCH] [2.6.23.13] udev hangs USB-storage (HP r707 camera)
On Tue, Jan 22, 2008 at 09:27:09PM -0800, Phil Dibowitz wrote: ... Patch looks fine to me. Let me get my tree in order (sorry, been really swamped lately so I haven't updated in a while), make sure this diff's nicely against the latest rc's, It's not. It's against 2.6.23. But I expect it to apply with fuzz at the worst case. and I'll pass it on up. .24 is already (essentially) done, so I'll get it to Greg in the next day or so and it should make it into .25. thanks! Sorry for the delay, and thanks Alan for pinging me on this. As for Grant - more information on Protocol vs Subclass can be found on my unusual_devs page here: http://www.phildev.net/linux/usb-unusualdevs-notes.html In general, a very helpful document! Thanks! useProtocol - These are listed in protocols.h with explinations. One example: * US_SC_DEVICE - use whatever the device claims * see drivers/usb/storage/protocol.h for a full list and comments Some issues/comments: o I don't see any sort of list in protocol.h. And the comments in protocol.h don't discuss useProtocol or which protocols. Maybe the list moved to include/linux/usb_usual.h? o US_SC_* and US_PR_* constants both seem like good candidates for enum (to make sure the right type get used with the right field.) cheers, grant - 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: udev hangs USB-storage (HP r707 camera)
On Sat, Jan 19, 2008 at 07:28:29PM -0700, Grant Grundler wrote: ... Thanks for reminding me...I had collected strace output of udev and all it's children a few days ago (probably with 2.6.22-14-generic (Ubuntu kernel). I've appended everything for PID 17972 (which is only 12k, full output is 559KB). Key bit is this: 17972 _llseek(3, 31129600, [31129600], SEEK_SET) = 0 17972 read(3, unfinished ... 17972 ... read resumed 0x804dc80, 512) = -1 EIO (Input/output error) given the device reports 60801 512-byte hardware sectors (31 MB) and 31129600/512 == 60800...it's obvious vol_id is trying to read the last sector on the disk (I assume it's to verify the size). ISTR reading the last sector caused problems else where. I'll try to hunt that down. That was too easy. http://www.cs.helsinki.fi/linux/linux-kernel/2001-23/0960.html Is 1K alignment still a problem? Or I have to add the HP r707 to some list per comments from this patch: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/broken-out/git-ieee1394.patch + * - fix capacity + * Tell sd_mod to correct the last sector number reported by read_capacity. + * Avoids access beyond actual disk limits on devices with an off-by-one bug. + * Don't use this with devices which don't have this bug. hunting more... grant - 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: udev hangs USB-storage (HP r707 camera)
On Sat, Jan 19, 2008 at 08:56:31PM -0600, James Bottomley wrote: it's children a few days ago (probably with 2.6.22-14-generic (Ubuntu kernel). I've appended everything for PID 17972 (which is only 12k, full output is 559KB). Key bit is this: 17972 _llseek(3, 31129600, [31129600], SEEK_SET) = 0 17972 read(3, unfinished ... 17972 ... read resumed 0x804dc80, 512) = -1 EIO (Input/output error) given the device reports 60801 512-byte hardware sectors (31 MB) and 31129600/512 == 60800...it's obvious vol_id is trying to read the last sector on the disk (I assume it's to verify the size). ISTR reading the last sector caused problems else where. I'll try to hunt that down. If this is the problem, it ought to be reproducible without vol_id by doing dd bs=512b if=/dev/dev of=/dev/null seek=60800 count=1 [EMAIL PROTECTED]:~ # dd bs=512b if=/dev/sda of=/dev/null seek=60800 count=1 1+0 records in 1+0 records out 262144 bytes (262 kB) copied, 0.433933 seconds, 604 kB/s but since 512B is the default (I thought), I tried: [EMAIL PROTECTED]:~ # dd if=/dev/sda of=/dev/null seek=60800 count=1 1+0 records in 1+0 records out 512 bytes (512 B) copied, 0.0239289 seconds, 21.4 kB/s and got different outputwth? Oh...and you mean skip, not seek...no wonder that worked. [EMAIL PROTECTED]:~ # strace -o strace-dd-HPr707.out dd if=/dev/sda of=/dev/null skip=60800 count=1 dd: reading `/dev/sda': Input/output error 0+0 records in 0+0 records out 0 bytes (0 B) copied, 55.7303 seconds, 0.0 kB/s dmesg output: Jan 19 19:08:12 localhost kernel: usb 1-1.1.4: reset full speed USB device using uhci_hcd and address 8 Jan 19 19:08:37 localhost last message repeated 3 times Jan 19 19:08:37 localhost kernel: sd 3:0:0:0: scsi: Device offlined - not ready after error recovery Jan 19 19:08:37 localhost kernel: sd 3:0:0:0: [sda] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK,SUGGEST_OK Jan 19 19:08:37 localhost kernel: end_request: I/O error, dev sda, sector 60800 There is a READ_CAPACITY bug where incompetent usb vendors misread the SCSI standard and actually report one sector more than the actual capacity (and crash when this is accessed), but let's verify first. This seems to be exactly the case. What's the work around? thanks, grant - 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: udev hangs USB-storage (HP r707 camera)
On Sat, Jan 19, 2008 at 08:10:08PM -0700, Grant Grundler wrote:
[EMAIL PROTECTED]:~ # strace -o strace-dd-HPr707.out dd if=/dev/sda
of=/dev/null skip=60800 count=1
dd: reading `/dev/sda': Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 55.7303 seconds, 0.0 kB/s
BTW, here's the relevant bit of the strace output:
open(/dev/sda, O_RDONLY|O_LARGEFILE) = 0
_llseek(0, 0, [0], SEEK_CUR)= 0
close(1)= 0
open(/dev/null, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1
rt_sigaction(SIGUSR1, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGUSR1, {0x80493a0, [INT USR1], 0}, NULL, 8) = 0
rt_sigaction(SIGINT, {0x8049390, [INT USR1], SA_NOMASK|SA_ONESHOT}, NULL, 8) = 0
clock_gettime(CLOCK_MONOTONIC, {70667, 216812381}) = 0
ioctl(0, MGSL_IOCSTXIDLE or MTIOCGET or SNDCTL_MIDI_MPUCMD, 0xbf8e31d0) = -1 EIN
VAL (Invalid argument)
_llseek(0, 31129600, [31129600], SEEK_CUR) = 0
read(0, 0x8059000, 512) = -1 EIO (Input/output error)
thanks,
grant
-
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] [2.6.23.13] udev hangs USB-storage (HP r707 camera)
On Sat, Jan 19, 2008 at 10:11:05PM -0600, James Bottomley wrote: ... Add the device to drivers/usb/storage/unusual_devs.h with US_FL_FIX_CAPACITY. You'll need to know it's USB ids as well for this file. James, Thanks! Patch below (for Alan) works for me. Jan 19 20:50:17 localhost kernel: USB Mass Storage support registered. Jan 19 20:50:22 localhost kernel: scsi scan: INQUIRY result too short (5), using 36 Jan 19 20:50:22 localhost kernel: scsi 0:0:0:0: Direct-Access HP PhotoSmart R707 A001 PQ: 0 ANSI: 0 Jan 19 20:50:22 localhost kernel: sd 0:0:0:0: [sda] 60800 512-byte hardware sectors (31 MB) Jan 19 20:50:22 localhost kernel: sd 0:0:0:0: [sda] Write Protect is off Jan 19 20:50:22 localhost kernel: sd 0:0:0:0: [sda] 60800 512-byte hardware sectors (31 MB) Jan 19 20:50:22 localhost kernel: sd 0:0:0:0: [sda] Write Protect is off Jan 19 20:50:22 localhost kernel: sda: sda1 Jan 19 20:50:22 localhost kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk FTR, previous sd output was showing 60801 sectors. [EMAIL PROTECTED]:~ # lsusb Bus 001 Device 007: ID 03f0:4002 Hewlett-Packard PhotoSmart 720 / PhotoSmart 935 (storage) Bus 001 Device 004: ID 046d:c030 Logitech, Inc. iFeel Mouse Bus 001 Device 003: ID 0451:1446 Texas Instruments, Inc. TUSB2040/2070 Hub Bus 001 Device 002: ID 7fff:bfff Bus 001 Device 001: ID : Thanks! grant Commit Log entry: Add FIX_CAPACITY entry for HP Photosmart r707 Camera in Disk mode. Camera will wedge when /lib/udev/vol_id attempts to access the last sector, EIO gets reported to dmesg, and block device is marked offline (it is). Reproduced vol_id behavior with: dd if=/dev/sda of=/dev/null skip=60800 count=1 With patch, linux now reports 60800 sectors and udev is happy. email thread reference: http://marc.info/?t=12007648332r=1w=2 Signed-off-by: Grant Grundler [EMAIL PROTECTED] --- linux-2.6.23.13/drivers/usb/storage/unusual_devs.h 2008-01-19 19:59:15.0 -0800 +++ linux-2.6.23-GGG/drivers/usb/storage/unusual_devs.h 2008-01-19 20:40:40.0 -0800 @@ -86,6 +86,14 @@ US_SC_8070, US_PR_USBAT, init_usbat_cd, 0), #endif +/* Reported by Grant Grundler [EMAIL PROTECTED] + * HP r707 camera in Disk mode with 2.00.23 or 2.00.24 firmware. + */ +UNUSUAL_DEV( 0x03f0, 0x4002, 0x0001, 0x0001, + HP, + PhotoSmart R707, + US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_FIX_CAPACITY), + /* Reported by Sebastian Kapfer [EMAIL PROTECTED] * and Olaf Hering [EMAIL PROTECTED] (different bcd's, same vendor/product) * for USB floppies that need the SINGLE_LUN enforcement. - 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: MPT Fusion initialization in 2.6.23.12
On Jan 15, 2008 8:37 AM, Karen Shaeffer [EMAIL PROTECTED] wrote: Hi Eric and Grant, These messages, all 15 of them only appear during the boot sequence. I never see them at any other time. The messages are in dmesg and syslog. This is a Sun X4200 M2 Netra server. The LSI SAS1064 RAID enabled Ultra320 SCSI controller supports RAID0, RAID1, and RAID1E modes. The implementation uses RAID1, so this chip is RAID-enabled. http://www.sun.com/servers/netra/x4200/specs.xml says you only have SAS and NOT u320 SCSI (unless an add-on u320 SCSI card is installed). LSI u320 SCSI cards can support RAID0/1 but HP-UX didn't ship with RAID enabled because of Firmware bugs (which may have been fixed in the mean time). If you post lspci -vt and/or lspci output, it would be clear what's in the box. I will look into this more today and report back any useful information I learn. Thanks very much for your help in understanding this. excellent - thanks, grant Thanks, Karen On Mon, Jan 14, 2008 at 06:19:30PM -0700, Moore, Eric wrote: On Monday, January 14, 2008 5:42 PM, Grant Grundler wrote: mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=0001h My interpretation of this (and Eric should know this alot better) is the host is attempting to read (action=01h) this page (type 08h == MPI_CONFIG_PAGETYPE_RAID_VOLUME) and couldn't. ie maybe HW RAID isn't configured on the card? Grant - Your right that this is MPI_CONFIG_PAGETYPE_RAID_VOLUME(=0x8). I responded too soon earlier, my thinking it was scanning the sas topology, in which its expected to get Invalid pages. In previous email, the form being passed (1 thru 0xF) means someone is scaning the target ids, from 1 thru 15. I just checked my code, and there is no place where I scan volumes. The only place I ask for the volume pages, is in mpt_inactive_raid_volume, and I only ask for this page when I already know the target_id. Thus I think this must be application driven thru mptctl interface. Eric ---end quoted text--- -- Karen Shaeffer Neuralscape, Palo Alto, Ca. 94306 [EMAIL PROTECTED] http://www.neuralscape.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: MPT Fusion initialization in 2.6.23.12
On Jan 11, 2008 6:01 AM, Karen Shaeffer [EMAIL PROTECTED] wrote: Hi, I have this server with an LSI Logic SAS1064 RAID enabled Ultra320 SCSI controller on the system board. Karen, The above doesn't make sense to me. How is SAS 1064 RAID related to Ultra320 SCSI? This card has both traditional 68-pin VHDLC connector and SAS/SATA connector? Is the word and missing from the above? I am running a vanilla 2.6.23.12 kernel. Everything runs well, except during the boot I see these logs in dmesg and the syslogs. mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=0001h My interpretation of this (and Eric should know this alot better) is the host is attempting to read (action=01h) this page (type 08h == MPI_CONFIG_PAGETYPE_RAID_VOLUME) and couldn't. ie maybe HW RAID isn't configured on the card? Similarly, if this is being reported for a normal LSI u320 scsi controller which doesn't support RAID, then perhaps the mpt driver should learn it doesn't need to query this page. I've traced through the mptbase.c code and can see these invalid config pages are read from the controller during initialization. My guess is it's reported as an error because the bhost attempted to read them but couldn't. hth, grant This doesn't appear to cause any ill effects, but I am wondering how to resolve this? Maybe a MPT BIOS or MPT firmware upgrade will fix this? Thanks, Karen -- Karen Shaeffer Neuralscape, Palo Alto, Ca. 94306 [EMAIL PROTECTED] http://www.neuralscape.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 - 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 1/3] mpt fusion: IO resource allocation using pci_request_selected_regions API [Resent]
On Jan 11, 2008 1:07 AM, Prakash, Sathya [EMAIL PROTECTED] wrote:
This patch modifies the IO resource allocation behavior of FUSION driver.
By using the pci_select_bars and pci_request_selected_regions API
The IORESOURCE_IO will be requested only when the driver needs the IO
resource.
The plan on linux-pci is to remove and replace pci_select_bars()
and pci_enable_bars() with pci_enable_device_mmio() and pci_enable_device_io().
This is because PCI only has two bits in the config space command
register of each device to enable or disable decoding of either address space
no control over individual BARs.
See the Dec 2007 linux-pci achives. e.g.:
http://marc.info/?l=linux-pcim=119793439127148w=2
and
http://marc.info/?l=linux-kernelm=119848021005444w=2
cheers,
grant
signed-off-by: Sathya Prakash [EMAIL PROTECTED]
---
diff --git a/drivers/message/fusion/mptbase.c
b/drivers/message/fusion/mptbase.c
index 52fb216..9476ad2 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -1470,9 +1470,6 @@ mpt_attach(struct pci_dev *pdev, const struct
pci_device_id *id)
if (mpt_debug_level)
printk(KERN_INFO MYNAM : mpt_debug_level=%xh\n,
mpt_debug_level);
- if (pci_enable_device(pdev))
- return r;
-
ioc = kzalloc(sizeof(MPT_ADAPTER), GFP_ATOMIC);
if (ioc == NULL) {
printk(KERN_ERR MYNAM : ERROR - Insufficient memory to add
adapter!\n);
@@ -1482,6 +1479,20 @@ mpt_attach(struct pci_dev *pdev, const struct
pci_device_id *id)
ioc-id = mpt_ids++;
sprintf(ioc-name, ioc%d, ioc-id);
+ ioc-bars = pci_select_bars(pdev, IORESOURCE_MEM);
+ if (pci_enable_device_bars(pdev, ioc-bars)) {
+ kfree(ioc);
+ printk(MYIOC_s_ERR_FMT pci_enable_device_bars() with MEM
+ failed\n,ioc-name);
+ return r;
+ }
+ if (pci_request_selected_regions(pdev, ioc-bars, mpt)) {
+ kfree(ioc);
+ printk(MYIOC_s_ERR_FMT pci_request_selected_regions() with
+ MEM failed\n,ioc-name);
+ return r;
+ }
+
dinitprintk(ioc, printk(MYIOC_s_INFO_FMT : mpt_adapter_install\n,
ioc-name));
if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
@@ -1791,6 +1802,7 @@ mpt_suspend(struct pci_dev *pdev, pm_message_t state)
CHIPREG_WRITE32(ioc-chip-IntStatus, 0);
pci_disable_device(pdev);
+ pci_release_selected_regions(pdev, ioc-bars);
pci_set_power_state(pdev, device_state);
return 0;
@@ -1807,7 +1819,6 @@ mpt_resume(struct pci_dev *pdev)
MPT_ADAPTER *ioc = pci_get_drvdata(pdev);
u32 device_state = pdev-current_state;
int recovery_state;
- int err;
printk(MYIOC_s_INFO_FMT
pci-resume: pdev=0x%p, slot=%s, Previous operating state [D%d]\n,
@@ -1815,9 +1826,15 @@ mpt_resume(struct pci_dev *pdev)
pci_set_power_state(pdev, 0);
pci_restore_state(pdev);
- err = pci_enable_device(pdev);
- if (err)
- return err;
+ if (ioc-facts.Flags MPI_IOCFACTS_FLAGS_FW_DOWNLOAD_BOOT)
+ ioc-bars = pci_select_bars(ioc-pcidev, IORESOURCE_MEM |
+ IORESOURCE_IO);
+ else
+ ioc-bars = pci_select_bars(pdev, IORESOURCE_MEM);
+ if (pci_enable_device_bars(pdev, ioc-bars))
+ return 0;
+ if (pci_request_selected_regions(pdev, ioc-bars, mpt))
+ return 0;
/* enable interrupts */
CHIPREG_WRITE32(ioc-chip-IntMask, MPI_HIM_DIM);
@@ -1878,6 +1895,7 @@ mpt_signal_reset(u8 index, MPT_ADAPTER *ioc, int
reset_phase)
* -2 if READY but IOCFacts Failed
* -3 if READY but PrimeIOCFifos Failed
* -4 if READY but IOCInit Failed
+ * -5 if failed to enable_device_bars and/or
request_selected_regions
*/
static int
mpt_do_ioc_recovery(MPT_ADAPTER *ioc, u32 reason, int sleepFlag)
@@ -1976,6 +1994,18 @@ mpt_do_ioc_recovery(MPT_ADAPTER *ioc, u32 reason, int
sleepFlag)
}
}
+ if ((ret == 0) (reason == MPT_HOSTEVENT_IOC_BRINGUP)
+ (ioc-facts.Flags MPI_IOCFACTS_FLAGS_FW_DOWNLOAD_BOOT)) {
+ pci_release_selected_regions(ioc-pcidev, ioc-bars);
+ ioc-bars = pci_select_bars(ioc-pcidev, IORESOURCE_MEM |
+ IORESOURCE_IO);
+ if (pci_enable_device_bars(ioc-pcidev, ioc-bars))
+ return -5;
+ if (pci_request_selected_regions(ioc-pcidev, ioc-bars,
+ mpt))
+ return -5;
+ }
+
/*
* Device is reset now. It must have de-asserted the interrupt line
* (if it was asserted) and it should be safe to register for the
@@ -2385,6 +2415,9 @@ mpt_adapter_dispose(MPT_ADAPTER
Re: [PATCH 1/3]: IO resource allocation using pci_request_selected_regions API
On Jan 11, 2008 1:28 AM, Christoph Hellwig [EMAIL PROTECTED] wrote: On Fri, Jan 11, 2008 at 02:33:30PM +0530, Prakash, Sathya wrote: This patch modifies the IO resource allocation behavior of FUSION driver. By using the pci_select_bars and pci_request_selected_regions API The IORESOURCE_IO will be requested only when the driver needs the IO resource. Didn't benh or someone else just replace pci_request_selected_regions with a less braindead API? yes - I just posted links to that: http://marc.info/?l=linux-pcim=119793439127148w=2 grant - 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 - 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 1/1] aacraid: big endian issues
On Jan 8, 2008 12:48 PM, Salyzyn, Mark [EMAIL PROTECTED] wrote:
Big endian systems issues discovered in the aacraid driver.
...
--- a/drivers/scsi/aacraid/comminit.c 2008-01-08 15:32:28.329810853 -0500
+++ b/drivers/scsi/aacraid/comminit.c 2008-01-08 15:37:35.633163607 -0500
@@ -301,10 +301,10 @@
if ((!aac_adapter_sync_cmd(dev, GET_ADAPTER_PROPERTIES,
0, 0, 0, 0, 0, 0, status+0, status+1, status+2, NULL, NULL))
(status[0] == 0x0001)) {
- if (status[1] AAC_OPT_NEW_COMM_64)
+ if (status[1] le32_to_cpu(AAC_OPT_NEW_COMM_64))
...
Why apply le32_to_cpu() to the constant instead of the variable?
On systems were le32_to_cpu() is doing something, can gcc or
preprocessor optimize the constant?
I've always assumed it could not but that might be wrong.
thanks,
grant
-
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 1/1] aacraid: big endian issues
On Jan 8, 2008 1:37 PM, Salyzyn, Mark [EMAIL PROTECTED] wrote:
I've always assumed that byte swapping of constants would be optimized where
a variable would not :-)
definitely...I understood that. It just seemed odd usage.
I have confirmed in assembler output of the compiler that constant
merely become byte reversed constants optimized or no in at least
one architectural case.
Thanks!
And apologies, I didn't mean to cause you additional work since I
was just curious.
I have *not* confirmed that a variable byte reversal requires processing
overhead, as one could possibly expect the compiler to instead optimize by
byte reversing the constant when comparing. However, I will guarantee you
that if optimization is turned off in the compiler that such an optimization
will not take place...
:)
I do not think this turns into a readability issue in either case
and view this as a simple cosmetic coding precaution much
like likely()/unlikely() offers hints to the compiler on code intent...
Agreed - it's not a readability issue.
thanks,
grant
Sincerely -- Mark Salyzyn
-Original Message-
From: Grant Grundler [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 08, 2008 4:17 PM
To: Salyzyn, Mark
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH 1/1] aacraid: big endian issues
On Jan 8, 2008 12:48 PM, Salyzyn, Mark
[EMAIL PROTECTED] wrote:
Big endian systems issues discovered in the aacraid driver.
...
--- a/drivers/scsi/aacraid/comminit.c 2008-01-08
15:32:28.329810853 -0500
+++ b/drivers/scsi/aacraid/comminit.c 2008-01-08
15:37:35.633163607 -0500
@@ -301,10 +301,10 @@
if ((!aac_adapter_sync_cmd(dev, GET_ADAPTER_PROPERTIES,
0, 0, 0, 0, 0, 0, status+0, status+1,
status+2, NULL, NULL))
(status[0] == 0x0001)) {
- if (status[1] AAC_OPT_NEW_COMM_64)
+ if (status[1] le32_to_cpu(AAC_OPT_NEW_COMM_64))
...
Why apply le32_to_cpu() to the constant instead of the variable?
On systems were le32_to_cpu() is doing something, can gcc or
preprocessor optimize the constant?
I've always assumed it could not but that might be wrong.
thanks,
grant
-
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] add help to WAIT_SCAN option
Thibaut Varene's parisc box didn't find the root disk. Problem is he had ASYNC_SCAN enabled and the required SYM2 driver builtin but the root disk wasn't discovered before the kernel wanted to mount root. Oh, and he (like many folks who build their own kernels) didn't use an initrd or initramfs. So no chance to load scsi_wait_scan module. This patch enables one to select y for WAIT_SCAN option and adds help text on how/when to use m vs y. Signed-off-by: Grant Grundler [EMAIL PROTECTED] diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index d28c14e..a2eefb2 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -235,17 +235,31 @@ config SCSI_SCAN_ASYNC be a problem as the devices may not have been found by the time your system expects them to have been. You can load the scsi_wait_scan module to ensure that all scans have completed. + (Requires SCSI_WAIT_SCAN config option be enabled). If you build your SCSI drivers into the kernel, then everything - will work fine if you say Y here. + will work fine if you say Y here and Y to SCSI_WAIT_SCAN option. You can override this choice by specifying scsi_mod.scan=sync or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate Wait until all async SCSI bus scans have completed? default m depends on SCSI depends on MODULES + help + This module will not allow the boot to proceed until all + the async SCSI bus scans are complete. This is needed + if the root disk is not discovered before the kernel + init sequence attempts to mount root. + + To use WITH an initrd/initramfs, say m (default) and set up + the init scripts to modprobe scsi_wait_scan after all the + SCSI HBA drivers have been loaded. + + To use WITHOUT an initrd/initramfs, say y and make sure + all SCSI HBA drivers needed to auto-mount all file systems + (including the root disk) are also y. menu SCSI Transports depends on SCSI - 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] add help to WAIT_SCAN option
On Sat, May 26, 2007 at 02:50:14PM -0500, James Bottomley wrote: This solution is still as wrong as it was the last three times it was submitted to linux-scsi: http://marc.info/?t=11790698961 http://marc.info/?t=117926627700012 http://marc.info/?t=11792306204 ugh...sorry. I should have looked first. A better, but still not quite right fix is here: http://marc.info/?l=linux-scsim=117995785931981 Yes, I like this a lot better too. But I'm failing to understanding why late_initcall isn't ok. I was expecting all drivers to have registered with scsi subsystem in their module_init() calls and have the scans get kicked off at that point. Further, I assumed late_initcall gets called after init list is processed. What am I missing? thanks, grant - 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] add help to WAIT_SCAN option
On Sat, May 26, 2007 at 06:33:10PM -0600, Matthew Wilcox wrote: On Sat, May 26, 2007 at 07:29:30PM -0500, James Bottomley wrote: Er .. I think you misunderstood the email. Grant asked why Hugh's (not Grant's) patch was wrong and I said that on reflection it wasn't. Oh, right. Since Hugh's patch is the same as the one I sent in the other fork of this thread, except for the contents of the comment, by all means put in Hugh's version instead of mine. Include my signed-off if you like. And you can add an Acked-by: Grant Grundler [EMAIL PROTECTED] since I prodded you to reconsider the patch. :) thanks, grant - 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/5] fixing errors handling during pci_driver resume stage [ata]
On Tue, Jan 09, 2007 at 12:01:28PM +0300, Dmitriy Monakhov wrote:
ata pci drivers have to return correct error code during resume stage in
case of errors.
...
@@ -6246,8 +6253,10 @@ int ata_pci_device_suspend(struct pci_de
int ata_pci_device_resume(struct pci_dev *pdev)
{
struct ata_host *host = dev_get_drvdata(pdev-dev);
+ int err;
- ata_pci_device_do_resume(pdev);
+ if ((err = ata_pci_device_do_resume(pdev)))
+ return err;
nit: in every other case I looked at you did:
err = foo()
if (err) ...
Can you make that consistent here too?
thanks,
grant
-
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 1/5] Update Documentation/pci.txt
On Tue, Dec 05, 2006 at 11:26:51PM -0800, Greg KH wrote:
If this looks good, I'll post a diff for gregkh.
This looks very good, thanks for doing this work.
welcome - feels like the most significant contribution I've made
to kernel in a long time.
I do have a few minor comments:
I'll fix up the comments and post a diff in a few days.
Try to answer your questions below.
...
save_state Save a device's state before it is suspended.
There is no such callback. We have suspend, suspend_late,
resume_early, and resume. You might want to update this.
I'll review all the callbacks and verify we aren't missing any too.
Definitely want to update this. I'll add them but ask someone
else whose used those entry points rewrite my crap with a
seperate patch. I don't want to rathole on this patch.
...
driver_data Data private to the driver.
Most drivers don't need to use driver_data field.
Best practice is to use driver_data as an index
into a static list of equivalent device types,
instead of using it as a pointer.
Perhaps mention the PCI_DEVICE() and PCI_DEVICE_CLASS() macros to set
these fields properly?
Yes. Will add that.
Have a table entry {PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID}
PCI_DEVICE(PCI_ANY_ID, PCI_ANY_ID) is a bit smaller :)
ditto.
All fields are passed in as hexadecimal values (no leading 0x).
Users need pass only as many fields as necessary:
ovendor, device, subvendor, and subdevice fields default
to PCI_ANY_ID (),
oclass and classmask fields default to 0
odriver_data defaults to 0UL.
What's with the os here?
Those are supposed to be bullets.
Cute Story: I lost the first blank space on _every_ line when I messed up
my attempt to remove trailing whitespace in vi with :1,$ s/ *//.
I left out the $. :(
I didn't realize the mistake until a few minutes later and had to
hand edit every line to fix it up again. *ouch*
Lesson is to be more careful and save state before making global changes.
Once added, the driver probe routine will be invoked for any unclaimed
PCI devices listed in its (newly updated) pci_ids list.
Device drivers must initialize use_driver_data in the dynids struct
in their pci_driver struct prior to calling pci_register_driver in order
for the driver_data field to get passed to the driver. Otherwise, only a
0 (zero) is passed in that field.
Note that _no one_ uses this field, so it might go away soon...
When it's removed, the patch can remove that paragraph.
This is a seperate issue.
...
o If the driver is not a hotplug driver then use only
__init/__exit and __initdata/__exitdata.
No, don't say this, pci drivers are not hotplug drivers, and since
CONFIG_HOTPLUG is really hard to turn off these days, don't confuse
people with the devinit stuff. Everyone gets it wrong...
Yeah. I'll drop the is not a hotplug driver bullet item.
o Pointers to functions marked as __devexit must be created using
__devexit_p(function_name). That will generate the function
name or NULL if the __devexit function will be discarded.
I really recommend just not using any of these for almost all PCI
drivers, as the space savings just really isn't there...
Ok. fgrep found 321 instances of __devexit_p and thus I think we should
document it's use at a minimum. I'll just add Most PCI drivers don't need
to use __devexit.
thanks for the comments!
Expect the next rev this weekend sometime.
grant
-
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: Symbios PCI error recovery [Was: Re: [PATCH/RFC] ppc64: EEH + SCSI recovery (IPR only)]
On Mon, Mar 21, 2005 at 05:10:28PM -0600, Linas Vepstas wrote: My current hardware will halt all i/o to/from the symbios controller upon detection of a PCI error. The recovery proceedure that I am currently using is to call system firmware (aka 'bios') to raise and then lower the #RST pci signal line for 1/4 second, then wait 2 seconds for the PCI bus to settle, then restore the PCI config space registers (BARs, interrupt line, etc) to what they used to be. Then, I call sym_start_up() in an attempt to get the symbios card working again. And that's where I get stuck ... Does this process cause a SCSI bus reset? SCSI devices will continue *forever* to send status back to the host on IO's that have completed. At least that's what I remember from working on this 8 years ago. Issuing a SCSI Bus Reset or Bus Device Reset (BDR) will quiesce the devices. I'm asking because it's possible sym2 driver isn't expecting anything from any device at that point. BTW, when did sym2 get a chance to cleanup pending requests? You want everything moved back to the queued state or failed (flush pending IO so upper layers can retry if they want). My assumption is that after the #RST, that the symbios card will sit there, dumb and stupid, with no scripts running. But sometimes I find that the card has done something to make the PCI error hardware trip again. Typically, this means that the card attempted to DMA to some address that its not allowed to touch, or raised #SERR or possibly #PERR (I can't tell which). PCI Reset typically only affects PCI facing parts of a chip. e.g. some LAN Phy's don't get reset and need to be manually reset. I'm skeptical sym2 will (or should) issue a SCSI Bus reset when PCI Reset is asserted. Think multi-initiator. Sometimes, I get the PCI error while the card is sitting there idly after the #RST, but more often, I get the error in sym_chip_reset(), immediately after the OUTB (nc_istat, SRST); Oh? Is this the driver trying to issue SCSI Reset? Any clue what this is about? Am I missing something? I'm rather perplexed at this point, any clues/hints/suggestions are welcome. Sorry - I'm no expert on 53c8xx chips. Hope the above helps. grant - 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.11-rc4 rename IOMAPPED config option
On Sun, Feb 20, 2005 at 09:09:36PM -0500, Jeff Garzik wrote: Irrelevant. It matters to automated patch snarfers, lkml.org users, etc. Jeff, I just cut the patch using standard cvs diff. I know SubmittingPatches wants -p0 but I also knew that willy doesn't mind -p1 and he's the maintainer. Incorrect. linux/config.h is not a standard include; you need to include linux/config.h in each file that uses a CONFIG_xxx define. ok - I prefer files directly include the headers they depend on. I'll add that and resubmit next week. Then willy can reject that if he wants. :^) thanks, grant - 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 2.6.11-rc4 rename IOMAPPED config option
Willy,
I'm always confused by what CONFIG_SCSI_SYM53C8XX_IOMAPPED
is supposed to mean. When enabled, the driver uses IO Port space.
But IOMAPPED is just too close to Memory Mapped IO (MMIO).
Following patch renames this to SCSI_SYM53C8XX_USE_MMIO.
I don't need to read the config help to understand what this means.
Signed-off-by: Grant Grundler [EMAIL PROTECTED]
thanks,
grant
Index: drivers/scsi/Kconfig
===
RCS file: /var/cvs/linux-2.6/drivers/scsi/Kconfig,v
retrieving revision 1.32
diff -u -p -r1.32 Kconfig
--- drivers/scsi/Kconfig3 Feb 2005 11:44:46 - 1.32
+++ drivers/scsi/Kconfig21 Feb 2005 00:46:18 -
@@ -1016,13 +1016,15 @@ config SCSI_SYM53C8XX_MAX_TAGS
possible. The driver supports up to 256 queued commands per device.
This value is used as a compiled-in hard limit.
-config SCSI_SYM53C8XX_IOMAPPED
- bool use port IO
+config SCSI_SYM53C8XX_USE_MMIO
+ bool use MMIO space
depends on SCSI_SYM53C8XX_2
+ default y
help
- If you say Y here, the driver will use port IO to access
- the card. This is significantly slower then using memory
- mapped IO. Most people should answer N.
+ If you say Y here, the driver will use MMIO address space
+ to access the card. IO Port space access is significantly
+ slower than MMIO space access.
+ Most people should answer Y.
config SCSI_IPR
tristate IBM Power Linux RAID adapter support
Index: drivers/scsi/sym53c8xx_2/sym53c8xx.h
===
RCS file: /var/cvs/linux-2.6/drivers/scsi/sym53c8xx_2/sym53c8xx.h,v
retrieving revision 1.14
diff -u -p -r1.14 sym53c8xx.h
--- drivers/scsi/sym53c8xx_2/sym53c8xx.h8 Jan 2005 22:11:08 -
1.14
+++ drivers/scsi/sym53c8xx_2/sym53c8xx.h21 Feb 2005 00:46:18 -
@@ -42,10 +42,6 @@
#include linux/config.h
-#ifdef CONFIG_SCSI_SYM53C8XX_IOMAPPED
-#defineSYM_CONF_IOMAPPED
-#endif
-
/*
* DMA addressing mode.
*
Index: drivers/scsi/sym53c8xx_2/sym_glue.c
===
RCS file: /var/cvs/linux-2.6/drivers/scsi/sym53c8xx_2/sym_glue.c,v
retrieving revision 1.84
diff -u -p -r1.84 sym_glue.c
--- drivers/scsi/sym53c8xx_2/sym_glue.c 20 Feb 2005 23:49:27 - 1.84
+++ drivers/scsi/sym53c8xx_2/sym_glue.c 21 Feb 2005 00:46:18 -
@@ -1915,7 +1915,7 @@ sym_init_device(struct pci_dev *pdev, st
i = pci_get_base_address(pdev, 1, device-s.base);
pci_get_base_address(pdev, i, device-s.base_2);
-#ifdef CONFIG_SCSI_SYM53C8XX_IOMAPPED
+#ifndef CONFIG_SCSI_SYM53C8XX_USE_MMIO
device-s.ioaddr = pci_iomap(pdev, 0, pci_resource_len(pdev, 0));
#else
device-s.ioaddr = pci_iomap(pdev, 1, pci_resource_len(pdev, 1));
Index: drivers/scsi/sym53c8xx_2/sym_hipd.c
===
RCS file: /var/cvs/linux-2.6/drivers/scsi/sym53c8xx_2/sym_hipd.c,v
retrieving revision 1.48
diff -u -p -r1.48 sym_hipd.c
--- drivers/scsi/sym53c8xx_2/sym_hipd.c 16 Feb 2005 20:54:02 - 1.48
+++ drivers/scsi/sym53c8xx_2/sym_hipd.c 21 Feb 2005 00:46:18 -
@@ -1044,7 +1044,7 @@ static int sym_prepare_setting(struct sy
*
* Has to be called with interrupts disabled.
*/
-#ifndef SYM_CONF_IOMAPPED
+#ifdef CONFIG_SCSI_SYM53C8XX_USE_MMIO
static int sym_regtest (struct sym_hcb *np)
{
register volatile u32 data;
@@ -1073,7 +1073,7 @@ static int sym_snooptest (struct sym_hcb
{
u32 sym_rd, sym_wr, sym_bk, host_rd, host_wr, pc, dstat;
int i, err=0;
-#ifndef SYM_CONF_IOMAPPED
+#ifdef CONFIG_SCSI_SYM53C8XX_USE_MMIO
err |= sym_regtest (np);
if (err) return (err);
#endif
-
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
