Re: [PATCH 3/3] PCI, scsi, ahci: Unify usages of 0x1b4b vendor ID to use PCI_VENDOR_ID_MARVELL_EXT
On 04/04/2013 02:23 PM, Bjorn Helgaas wrote: On Wed, Mar 20, 2013 at 10:35 PM, Myron Stowe myron.st...@redhat.com wrote: With the 0x1b4b vendor ID #define in place, convert hard-coded ID values. Also, unify the previous SCSI specific use of this vendor ID to the new macro. Signed-off-by: Myron Stowe myron.st...@redhat.com --- drivers/ata/ahci.c | 10 +- drivers/scsi/mvsas/mv_init.c |6 +++--- drivers/scsi/mvumi.c |4 ++-- drivers/scsi/mvumi.h |1 - 4 files changed, 10 insertions(+), 11 deletions(-) Jeff James, if you don't object to these, I can push them through my PCI tree along with the corresponding pci_ids.h addition. ACK -- 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: [PATCH v14 1/3] scsi: sr: support runtime pm
On 01/23/2013 02:09 AM, Aaron Lu wrote: This patch adds runtime pm support for sr. It did this by increasing the runtime usage_count of the device when its block device is accessed. And decreasing the runtime usage_count of the device when the access is done. If there is media inside, runtime suspend is not allowed as we don't always know if the ODD is being used or not. The idea is discussed here: http://thread.gmane.org/gmane.linux.acpi.devel/55243/focus=52703 and the restriction to check media inside is discussed here: http://thread.gmane.org/gmane.linux.ide/53665/focus=58836 Signed-off-by: Aaron Lu aaron...@intel.com Acked-by: Alan Stern st...@rowland.harvard.edu Acked-by: James Bottomley james.bottom...@hansenpartnership.com --- drivers/scsi/sr.c | 42 +++--- 1 file changed, 39 insertions(+), 3 deletions(-) applied 1-3 -- 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: [PATCH v13 2/9] libata: identify and init ZPODD devices
On 01/15/2013 04:20 AM, Aaron Lu wrote: The ODD can be enabled for ZPODD if the following three conditions are satisfied: 1 The ODD supports device attention; 2 The platform can runtime power off the ODD through ACPI; 3 The ODD is either slot type or drawer type. For such ODDs, zpodd_init is called and a new structure is allocated for it to store ZPODD related stuffs. And the zpodd_dev_enabled function is used to test if ZPODD is currently enabled for this ODD. A new config CONFIG_SATA_ZPODD is added to selectively build ZPODD code. Signed-off-by: Aaron Lu aaron...@intel.com Acked-by: Tejun Heo t...@kernel.org How possible is it to apply patches 2-6 right now? It appears possible according to my read, but I've not tested this guess. Jeff -- 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: [PATCH v13 8/9] libata: do not suspend port if normal ODD is attached
On 01/15/2013 04:21 AM, Aaron Lu wrote: For ODDs, the upper layer will poll for media change every few seconds, which will make it enter and leave suspend state very often. And as each suspend will also cause a hard/soft reset, the gain of runtime suspend is very little while the ODD may malfunction after constantly being reset. So the idle callback here will not proceed to suspend if a non-ZPODD capable ODD is attached to the port. Signed-off-by: Aaron Lu aaron...@intel.com Acked-by: Tejun Heo t...@kernel.org --- drivers/ata/libata-core.c | 19 +++ 1 file changed, 19 insertions(+) applied patches #2-6 and #8 -- 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: [PATCH v12 7/9] libata: scsi: no poll when ODD is powered off
On 01/11/2013 01:44 PM, Tejun Heo wrote:
Hello,
On Fri, Jan 11, 2013 at 11:16:26AM +0800, Aaron Lu wrote:
OK, will make it atomic in next version, thanks for the advice.
Perhaps I can add two scsi helper functions in scsi_lib.c like:
void sdev_disable_disk_events(struct scsi_device *sdev)
{
atomic_inc(sdev-disk_events_disable_depth);
}
void sdev_enable_disk_events(struct scsi_device *sdev)
{
if (WARN_ON_ONCE(atomic_read(sdev-disk_events_disable_depth) = 0))
return;
atomic_dec(sdev-disk_events_disable_depth);
}
And call them in ATA layer. Do you like this?
Sounds good to me. James, how does the series look to you?
Indeed. Want James' Acked-by for patch #1.
I think it's ready. It can go into libata-dev.git #upstream, and be
reverted prior to Linus push if James NAKs.
Jeff
--
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: [PATCH v9 06/10] ata: zpodd: check zero power ready status
On 12/03/2012 11:23 AM, Tejun Heo wrote:
Hello, James.
On Mon, Dec 03, 2012 at 08:25:43AM +, James Bottomley wrote:
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index e65c62e..1756151 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -160,6 +160,7 @@ struct scsi_device {
unsigned can_power_off:1; /* Device supports runtime power off */
unsigned wce_default_on:1; /* Cache is ON by default */
unsigned no_dif:1; /* T10 PI (DIF) should be disabled */
+ unsigned event_driven:1; /* No need to poll the device */
DECLARE_BITMAP(supported_events, SDEV_EVT_MAXBITS); /* supported events
*/
struct list_head event_list;/* asserted events */
Yes, but if we can get away with doing that, it should be in genhd
because it's completely generic.
I was imagining we'd have to fake the reply to the test unit ready or
some other commands, which is why it would need to be in sr.c
The check events code is Tejun's baby, if he's OK with it then just do
it in genhd.c
The problem here is there's no easy to reach genhd from libata (or the
other way around) without going through sr. I think we're gonna have
to have something in sr one way or the other.
...which is precisely as I said when v1 of this ZPODD patchset appeared.
sr modifications cannot be avoided.
Jeff
--
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: [patch,v3 06/10] ata: use scsi_host_alloc_node
On 11/09/2012 02:18 PM, Jeff Moyer wrote: Signed-off-by: Jeff Moyer jmo...@redhat.com --- drivers/ata/libata-scsi.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) Acked-by: Jeff Garzik jgar...@redhat.com -- 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: [PATCH v7 2/6] scsi: sr: support runtime pm
On 09/29/2012 06:31 PM, Rafael J. Wysocki wrote: On Saturday, September 29, 2012, Alan Stern wrote: Can arbitrary SCSI devices be ZP, or does this notion apply only to ATAPI-based drives? That's the key question, and the answer determines where the ZP support belongs. I agree. That said for now I'm not aware of any other ZP devices. It also is unclear whether or not their requirements would be the same for the ZPODD devices. Not quite. The key question is whether or not this operates at the SCSI command set level. ATAPI is simply SCSI MMC command set tunnelling. The ATA-specific bits that belong in libata include everything below the SCSI command set: bus details, delivering the command to the device, returning the command response, etc. sr handles the SCSI command set details. SATA optical devices are aligned with the SCSI MMC command set, which periodically synchronizes with USB and ATAPI industry efforts. There are ugly hacks around the edges, where sometimes ATA or USB subsystems may tweak the request or response in passing, but that is the general model: it belongs in libata UNLESS the operation is occurring wholly at the SCSI command set level. Because USB and ATA chose to use the SCSI command set, it is sadly inevitable that there might be a few details -- hopefully glossed over with layer-hopping hooks and flags -- within 'sr' that are bus-specific. The simple fact of only ZPODD devices out there are ATA is not the decision-maker for where the code should live. It is more a question where ZPODD belongs in the device/command set model currently employed. Jeff -- 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: [PATCH v7 2/6] scsi: sr: support runtime pm
On 09/29/2012 06:44 PM, Rafael J. Wysocki wrote: On Saturday, September 29, 2012, Aaron Lu wrote: On 09/29/2012 10:29 PM, Alan Stern wrote: On Sat, 29 Sep 2012, Aaron Lu wrote: I don't think this is a good idea, quite frankly. sr seems to be a too generic place for that. Does this mean sr can only have code that is useful to all devices it manages? i.e. If a piece of code enables a feature for a special kind of ODD(like the sata based ZPODD), it shouldn't be done in sr? Drivers are allowed to have special features and quirks that apply only to some devices. I think SATA based zero power capable ODDs are the some devices. There is nothing in theory stopping us from doing this in ata layer. For the loading mechanism, we can always send an ATAPI command to figure it out. So gentlemen, I need your opinions on where this ZPODD code should live before I can continue this work, thanks. Can arbitrary SCSI devices be ZP, or does this notion apply only to ATAPI-based drives? That's the key question, and the answer determines where the ZP support belongs. I don't know if arbitrary SCSI devices can be ZP or not, the SPC spec doesn't seem to define such a power state. ZPODD is defined for sata based ATAPI ODD which supports device attention, but doesn't specify how the ODD is powered off and how the device attention pin notifies OS. On x86 systems, these are implemented by ACPI. Though SCSI devices may not have a general notion of ZP, the fact that ZPODD are managed by sr driver is enough to make the decision that ZPODD code can live in sr? Well, only a part of it is handled by sr, the high-level part so to speak. The low-level handling is done by the ATA layer. Now, since sr is the high-level part and is supposed to be generic, I don't think it's appropriate to make it care about some low-level things specific to ATA (because there is another layer of code supposed to handle those). On the other hand, the sr driver certainly deserves to have some form of runtime PM support, even for devices that aren't ZP. Agree. And the following codes need to find a home: - Code used to handle ACPI wake notification(currently done in ATA, but causes the annoying need_eject flag in scsi_device); And quite frankly I'd more and more convinced that this flag isn't really necessary. What you really want to achieve is to eject the tray of a tray-type ODD if the eject is signaled through a GPE. I don't see anything for sr to do in that. Moreover, you probably would like to do that even if the drive is not powered down, right? I wonder if this mechanism can be used for user space notification without polling regardless of whether or not the zero-power feature is used? Fair questions, and I think this is finally getting to the heart of the matter/solution. - Code to check if the ODD is ready to be powered off per the ZPODD spec. If that can be done at the ATA level, I'd prefer it too. Does the ready-to-poweroff check involve SCSI/MMC command set commands? If no, it probably belongs in libata. If yes, it probably belongs in sr. Jeff -- 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: [PATCH v7 2/6] scsi: sr: support runtime pm
On 09/30/2012 10:47 AM, Alan Stern wrote: On Sun, 30 Sep 2012, Aaron Lu wrote: Makes sense to me, but there is a problem if I want to block events checking for the disk, as I do not have a pointer to the gendisk in ATA layer. You may discover the gendisk by going the ATA - SCSI - block route. The tray will be ejected by the ODD itself when it has power, I do not need to do that. Moreover, I don't think I need enable the GPE bit when it has power. It sounds like you need to add only two things to the sr layer: An interface to enable/disable event checking and an interface to request an eject. (And perhaps ejects can be carried out entirely within the ATAPI layer, with no need to involve sr.) Sounds reasonable. Jeff -- 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: [PATCH v7 2/6] scsi: sr: support runtime pm
On 09/30/2012 03:43 PM, Alan Stern wrote: On Sun, 30 Sep 2012, Jeff Garzik wrote: The simple fact of only ZPODD devices out there are ATA is not the decision-maker for where the code should live. It is more a question where ZPODD belongs in the device/command set model currently employed. I don't really accept this argument. It's a little like saying: The tty layer uses ioctl commands to control RS232 line settings; therefore RS232 settings should be handled in the VFS layer as part of the ioctl core. Hardly -- sr is an optical device driver, much more aligned. And libata is probably at least 50% of the entire sr userbase, if not much much more. Jeff -- 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: [SCSI PATCH] sd: max-retries becomes configurable
On 09/25/2012 06:38 AM, James Bottomley wrote: On Tue, 2012-09-25 at 01:21 -0400, Jeff Garzik wrote: Can you be more specific about sysfs location? A runtime-writable (via sysfs!) module parameter for a module-wide default seemed appropriate. Well, if it's really important, the same thing should happen with retries as happened with timeout (it became a request_queue property), but it could be hacked as a struct scsi_disk one with a corresponding entry in sd_dis_attrs. Well, it is already a request property... but assigned at initialization from sd-specific code. sd also passes this through scmd-allowed to rq-retries. It could become a request_queue property, but that seems like a hack as it is simply passed right back into SCSI EH, for SCSI-specific disposition. Jeff -- 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
[SCSI PATCH] sd: max-retries becomes configurable
drivers/scsi/sd.c |4 drivers/scsi/sd.h |2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 4df73e5..d15074b 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -92,6 +92,10 @@ MODULE_ALIAS_SCSI_DEVICE(TYPE_DISK); MODULE_ALIAS_SCSI_DEVICE(TYPE_MOD); MODULE_ALIAS_SCSI_DEVICE(TYPE_RBC); +static int sd_max_retries = 5; +module_param_named(max_retries, sd_max_retries, int, 0644); +MODULE_PARM_DESC(max_retries, Maximum number of retries, before failing command (default 5)); + #if !defined(CONFIG_DEBUG_BLOCK_EXT_DEVT) #define SD_MINORS 16 #else diff --git a/drivers/scsi/sd.h b/drivers/scsi/sd.h index f703f48..f8488fa 100644 --- a/drivers/scsi/sd.h +++ b/drivers/scsi/sd.h @@ -18,7 +18,7 @@ /* * Number of allowed retries */ -#define SD_MAX_RETRIES 5 +#define SD_MAX_RETRIES sd_max_retries #define SD_PASSTHROUGH_RETRIES 1 #define SD_MAX_MEDIUM_TIMEOUTS 2 -- 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: [PATCH v7 3/6] scsi: sr: support zero power ODD(ZPODD)
On 09/12/2012 04:29 AM, Aaron Lu wrote:
When ODD is runtime suspended, we will check if it is OK to remove
its power:
1 For tray type, no medium inside and tray closed;
2 For slot type, no medium inside.
And if yes, we will set the ready_to_power_off flag as an indication to
ATA layer that it is safe to place this device into ACPI D3 cold power
state.
And when it is powered off, we will set the powered_off flag so that the
periodically running check_events will not bother this device by simply
return.
Signed-off-by: Aaron Lu aaron...@intel.com
---
drivers/ata/libata-acpi.c | 27 +++
drivers/scsi/sr.c | 53 ++
drivers/scsi/sr.h | 1 +
drivers/scsi/sr_ioctl.c| 7 +-
include/scsi/scsi_device.h | 3 +++
5 files changed, 81 insertions(+), 10 deletions(-)
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 902b5a4..9aca057 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -854,7 +854,7 @@ void ata_acpi_set_state(struct ata_port *ap, pm_message_t
state)
{
struct ata_device *dev;
acpi_handle handle;
- int acpi_state;
+ int acpi_state, ret;
/* channel first and then drives for power on and vica versa
for power off */
@@ -869,17 +869,24 @@ void ata_acpi_set_state(struct ata_port *ap, pm_message_t
state)
if (state.event != PM_EVENT_ON) {
acpi_state = acpi_pm_device_sleep_state(
- dev-sdev-sdev_gendev, NULL, ACPI_STATE_D3);
- if (acpi_state 0)
- acpi_bus_set_power(handle, acpi_state);
- /* TBD: need to check if it's runtime pm request */
- acpi_pm_device_run_wake(
- dev-sdev-sdev_gendev, true);
+ dev-sdev-sdev_gendev, NULL,
+ dev-sdev-ready_to_power_off ?
+ ACPI_STATE_D3 : ACPI_STATE_D3_HOT);
+ if (acpi_state 0) {
+ ret = acpi_bus_set_power(handle, acpi_state);
+ if (!ret acpi_state == ACPI_STATE_D3)
+ dev-sdev-powered_off = 1;
+
+ /* TODO: check if it's runtime pm request */
+ acpi_pm_device_run_wake(
+ dev-sdev-sdev_gendev, true);
+ }
} else {
/* Ditto */
acpi_pm_device_run_wake(
dev-sdev-sdev_gendev, false);
acpi_bus_set_power(handle, ACPI_STATE_D0);
+ dev-sdev-powered_off = 0;
}
}
@@ -985,8 +992,10 @@ static void ata_acpi_wake_dev(acpi_handle handle, u32
event, void *context)
struct ata_device *ata_dev = context;
if (event == ACPI_NOTIFY_DEVICE_WAKE ata_dev
- pm_runtime_suspended(ata_dev-sdev-sdev_gendev))
- scsi_autopm_get_device(ata_dev-sdev);
+ ata_dev-sdev-powered_off) {
+ ata_dev-sdev-need_eject = 1;
+ pm_runtime_resume(ata_dev-sdev-sdev_gendev);
+ }
}
these bits are Acked-by: Jeff Garzik jgar...@redhat.com
but obviously that is contingent upon acceptance of the upper level SCSI
and ACPI changes.
--
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: [PATCH v7 6/6] libata: acpi: respect may_power_off flag
On 09/12/2012 04:29 AM, Aaron Lu wrote:
If user does not want the device to be powered off when runtime
suspended by setting may_power_off flag to 0, we will not choose
D3 cold for it.
Signed-off-by: Aaron Lu aaron...@intel.com
---
drivers/ata/libata-acpi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 9aca057..24347e0 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -855,6 +855,7 @@ void ata_acpi_set_state(struct ata_port *ap, pm_message_t
state)
struct ata_device *dev;
acpi_handle handle;
int acpi_state, ret;
+ bool power_off_allowed;
/* channel first and then drives for power on and vica versa
for power off */
@@ -868,9 +869,11 @@ void ata_acpi_set_state(struct ata_port *ap, pm_message_t
state)
continue;
if (state.event != PM_EVENT_ON) {
+ power_off_allowed = dev-sdev-ready_to_power_off
+ dev-sdev-may_power_off;
acpi_state = acpi_pm_device_sleep_state(
dev-sdev-sdev_gendev, NULL,
- dev-sdev-ready_to_power_off ?
+ power_off_allowed ?
ACPI_STATE_D3 : ACPI_STATE_D3_HOT);
Acked-by: Jeff Garzik jgar...@redhat.com
with the same caveat as with the rest of this patchset: contingent upon
acceptance of the other API changes.
--
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: [PATCH v2 1/4] scsi: introduce sync_before_stop flag
On 09/18/2012 04:31 AM, Aaron Lu wrote: I agree that it is better handled in libata's SALT, I tried to do this but didn't find a good way so I introduced this flag. The SALT is 1-1 mapping, I'm not sure how to handle this 1-2 mapping. That is the crux of the matter: it is rather difficult within the current code, if there is not a 1:1 correspondence between SCSI command and ATA command. The solution that works within libata-scsi.c involves creating two ata_queued_cmd's, and managing the issuance and completion yourself. But really -- the most practical route seems to be simply to set WCE, to trigger the desired behavior. Jeff -- 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: [PATCH] ahci: add a boot option to enable promise ahci
On 09/23/2012 10:34 PM, Tony Hung - PTT 洪瑞嶸 wrote: linux-3.2.0/drivers/ata/ahci.c: In function 'hptiop_host_request_callback': Use min_t(size_t, ...) to fix. Signed-off-by: Tony Hung tony.h...@tw.promise.com --- diff --git a/linux-3.2.0/drivers/ata/ahci.c b/linux-3.2.0/drivers/ata/ahci.c --- a/linux-3.2.0/drivers/ata/ahci.c 2012-08-29 13:40:26.046851693 +0800 +++ b/linux-3.2.0/drivers/ata/ahci.c 2012-08-30 17:23:10.207838960 +0800 @@ -430,6 +430,9 @@ static int marvell_enable = 1; module_param(marvell_enable, int, 0644); MODULE_PARM_DESC(marvell_enable, Marvell SATA via AHCI (1 = enabled)); +static int promise_enable; +module_param(promise_enable, int, 0644); +MODULE_PARM_DESC(promise_enable, Promise SATA via AHCI (1 = enabled)); static void ahci_pci_save_initial_config(struct pci_dev *pdev, struct ahci_host_priv *hpriv) @@ -1049,6 +1052,16 @@ static int ahci_init_one(struct pci_dev if (pdev-vendor == PCI_VENDOR_ID_MARVELL !marvell_enable) return -ENODEV; +/* + * In RAID mode, Promise software RAID need to replace + * original AHCI module, but if AHCI driver build-in kernel, + * Promise AHCI module need a boot option to disable it + */ +if (promise_enable +((pdev-class 8) == PCI_CLASS_STORAGE_RAID) + (pdev-vendor == PCI_VENDOR_ID_ATI || + pdev-vendor == PCI_VENDOR_ID_AMD)) +return -ENODEV; We need the patch for the Promise Software RAID driver, to accept this... Jeff -- 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: [SCSI PATCH] sd: max-retries becomes configurable
On 09/25/2012 12:06 AM, James Bottomley wrote: On Mon, 2012-09-24 at 17:00 -0400, Jeff Garzik wrote: drivers/scsi/sd.c |4 drivers/scsi/sd.h |2 +- 2 files changed, 5 insertions(+), 1 deletion(-) I'm not opposed in principle to doing this (except that it should be a sysfs parameter like all our other controls), but what's the reasoning behind needing it changed? vendor hat on Periodically turns up as a useful field sledgehammer for solving problems, until the real problem is found and fixed. Got tired of a very similar patch manually bouncing around the hey, pssst, this worked for me backchannel IT network. /red hat Can you be more specific about sysfs location? A runtime-writable (via sysfs!) module parameter for a module-wide default seemed appropriate. Jeff -- 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: [RFC][PATCH] libata: enable SATA disk fua detection on default
On 09/09/2012 04:34 PM, Arvydas Sidorenko wrote: Meanwhile there already has a number of SATA disks that have supported this feature. So I think maybe we can enable it. Regards, Zheng Blindly enabling FUA by default in my opinion is not a good idea at all. I believe the focus should be on detecting FUA support on the device instead, which the kernel at this point cannot reliably do (is it possible?). Premature assumptions. It is entirely possible that FUA is detected accurately, but the software is missing a flush somewhere that FUA requires, if disks are to be used in FUA mode. The filesystem and the block layer must properly generate and order their I/Os based on the FUA enablement bits that appear in the block layer after libata discovers the SATA FUA feature. Jeff -- 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: [PATCH v6 4/7] libata: acpi: set can_power_off for both ODD and HD
On 09/04/2012 10:24 AM, Aaron Lu wrote: From: Aaron Lu aaron...@intel.com Hard disk may also be runtime powered off, so set can_power_off flag for it too if condition satisfies. Signed-off-by: Aaron Lu aaron...@intel.com Acked-by: Jeff Garzik jgar...@redhat.com -- 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: [PATCH v6 7/7] libata: acpi: respect may_power_off flag
On 09/04/2012 10:24 AM, Aaron Lu wrote:
From: Aaron Lu aaron...@intel.com
If user does not want the device being powered off when runtime
suspended by setting may_power_off flag to 0, we will not choose D3 cold
ACPI D-State for it.
Signed-off-by: Aaron Lu aaron...@intel.com
---
drivers/ata/libata-acpi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 6c8f89c..774180d 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -869,7 +869,9 @@ void ata_acpi_set_state(struct ata_port *ap, pm_message_t
state)
if (state.event != PM_EVENT_ON) {
acpi_state = acpi_pm_device_sleep_state(
- dev-sdev-sdev_gendev, NULL, ACPI_STATE_D3);
+ dev-sdev-sdev_gendev, NULL,
+ dev-sdev-may_power_off ?
+ ACPI_STATE_D3_COLD : ACPI_STATE_D3_HOT);
if (acpi_state 0)
acpi_bus_set_power(handle, acpi_state);
Acked-by: Jeff Garzik jgar...@redhat.com
--
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
Enabling FUA for SATA drives (was Re: [RFC][PATCH] libata: enable SATA disk fua detection on default)
On 05/07/2012 11:24 PM, Zheng Liu wrote: From: Zheng Liu wenqing...@taobao.com Currently, SATA disk fua detection is disabled on default because most of devices don't support this feature at that time. With the development of technology, more and more SATA disks support this feature. So now we can enable this detection on default. Although fua detection is defined as a kernel module parameter, it is too hard to set its value because it must be loaded and set before system starts up. That needs to modify initrd file. So it is inconvenient for administrator who needs to manage a huge number of servers. CC: Jeff Garzik j...@garzik.org Signed-off-by: Zheng Liu wenqing...@taobao.com --- drivers/ata/libata-core.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 23763a1..3627251 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -133,9 +133,9 @@ int atapi_passthru16 = 1; module_param(atapi_passthru16, int, 0444); MODULE_PARM_DESC(atapi_passthru16, Enable ATA_16 passthru for ATAPI devices (0=off, 1=on [default])); -int libata_fua = 0; +int libata_fua = 1; module_param_named(fua, libata_fua, int, 0444); -MODULE_PARM_DESC(fua, FUA support (0=off [default], 1=on)); +MODULE_PARM_DESC(fua, FUA support (0=off, 1=on [default])); Applied. Let's see how far down the rabbit hole we go ;-) The FUA decision, as previously indicated, was based on early SATA drives, and perhaps better ones are available now. Only testing will tell, at this point. The larger questions, raised by Christoph and others remain unaddressed (though perhaps we can start addressing them now, with this patch): * what is smart flushing policy for ATA devices with FUA? * ATA NCQ's flush is not queued * ATA NCQ always had the FUA bit... * ...but mixing ATA NCQ FUA and !FUA in a queue is not fully supported by the existing code and probably a few other details I forgot :) Jeff -- 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: [patch] [SCSI] mvsas: fix a vs bug
On 08/16/2012 07:04 AM, Dan Carpenter wrote: The 1 (slot_idx % 32) condition is always true. The intent was to test a bit field here using bitwise AND. We do the test correctly a few lines later in the do while loop. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com Acked-by: Jeff Garzik jgar...@redhat.com -- 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: [PATCH v4 4/7] scsi: sr: block events when runtime suspended
On 08/03/2012 05:50 AM, Aaron Lu wrote: Hello, Not sure if I should use EXPORT_SYMBOL or EXPORT_SYMBOL_GPL, any comments? Typically you follow the pattern of similar exports in the file (or in the API, if no others are in the file). Jeff -- 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: [PATCH v3 0/7] ZPODD patches for scsi tree
On 07/26/2012 06:05 AM, Aaron Lu wrote: v3: Rebase on top of scsi-misc tree; Add the sr related patches previously in Jeff's libata tree; Re-organize the sr patches. A problem for now: for patch scsi: sr: support zero power ODD(ZPODD) I can't set a flag in libata-acpi.c since a related function is missing in scsi-misc tree. Will fix this when 3.6-rc1 released. What does this mean? Would you be more specific? Jeff -- 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: [PATCH v3 0/7] ZPODD patches for scsi tree
On 07/26/2012 10:41 AM, Aaron Lu wrote: On Thu, Jul 26, 2012 at 09:43:37AM -0400, Jeff Garzik wrote: On 07/26/2012 06:05 AM, Aaron Lu wrote: I can't set a flag in libata-acpi.c since a related function is missing in scsi-misc tree. Will fix this when 3.6-rc1 released. What does this mean? Would you be more specific? The patch libata-acpi: add ata port runtime D3Cold support by Lin Ming introduced a function ata_acpi_wake_dev in libata-acpi.c, and only lives in libata-next tree but not scsi-misc tree. [...] Another minor issue is, I need to use the can_power_off and wakeup_by_user flag of the scsi_device structure in sr patches, but they are all introduced in patches in libata-next tree, so I have to re-define them in this patch set. Will cause conflict if James send these sr patches to Linus. Any way to avoid this? Linus said he just merged the libata patches, so they should appear in the torvalds/linux.git as soon as he pushes out (in the next 12 hours, I'm guessing). Up to James how he wants to coordinate after that... he might pull in Linus's tree into scsi-misc or another solution. Jeff -- 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: [resend PATCH 5/5] libsas, ipr: cleanup ata_host flags initialization via ata_host_init
On 07/10/2012 12:06 AM, Dan Williams wrote: libsas and ipr pass flags to ata_host_init that are meant for the port. ata_host flags: ATA_HOST_SIMPLEX= (1 0), /* Host is simplex, one DMA channel per host only */ ATA_HOST_STARTED= (1 1), /* Host started */ ATA_HOST_PARALLEL_SCAN = (1 2), /* Ports on this host can be scanned in parallel */ ATA_HOST_IGNORE_ATA = (1 3), /* Ignore ATA devices on this host. */ flags passed by libsas: ATA_FLAG_SATA = (1 1), ATA_FLAG_PIO_DMA= (1 7), /* PIO cmds via DMA */ ATA_FLAG_NCQ= (1 10), /* host supports NCQ */ The only one that aliases is ATA_HOST_STARTED which is a 'don't care' in the libsas and ipr cases since ata_hosts from these sources are not registered with libata. Cc: Brian King brk...@us.ibm.com Reported-by: Hannes Reinecke h...@suse.com Signed-off-by: Dan Williams dan.j.willi...@intel.com --- drivers/ata/libata-core.c | 10 ++ drivers/scsi/ipr.c|3 +-- drivers/scsi/libsas/sas_ata.c |5 + include/linux/libata.h|3 +-- Acked-by: Jeff Garzik jgar...@redhat.com -- 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: [git patches] libata updates
On Wed, Jul 25, 2012 at 04:35:51PM -0400, Jeff Garzik wrote: Please pull 641589bff714f39b33ef1d7f02eaa009f2993b64 from git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git tags/upstream Oh, I forgot to point out the merge commit, making my HEAD more recent than might be expected. There was a merge conflict and an API change that needed to be dealt with, in order for your pull to be correct. Jeff -- 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: [git patches] libata updates
On 07/25/2012 04:35 PM, Jeff Garzik wrote: Please pull 641589bff714f39b33ef1d7f02eaa009f2993b64 from git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git tags/upstream (text copied from the upstream-linus tag) Notable changes: * Updating libata to directly bind with ACPI / runtime power mgmt. This is a pre-req for SATA ZPODD (CD-ROM power management). Touches ACPI (exports++) and SCSI in minor ways. Has been in linux-next for weeks. The rest of [ZPODD] will probably come via SCSI tree, as it involves a lot of updates to the 'sr' driver etc. BTW Lin and Aaron, note that this did not include these changes: sr: check support for device busy class events sr: support zero power ODD sr: make sure ODD is in resumed state in block ioctl as in the end I wanted to put the brakes on SCSI-touching patches. These should be able to go into James' scsi-misc tree with the other SCSI-area ZPODD changes. For those three 'sr' changes listed above, you may add Acked-by: Jeff Garzik jgar...@redhat.com when moving them over. Jeff -- 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: [git patches] libata updates
On 07/25/2012 06:06 PM, Linus Torvalds wrote: On Wed, Jul 25, 2012 at 1:43 PM, Jeff Garzik j...@garzik.org wrote: On Wed, Jul 25, 2012 at 04:35:51PM -0400, Jeff Garzik wrote: Please pull 641589bff714f39b33ef1d7f02eaa009f2993b64 from git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git tags/upstream Oh, I forgot to point out the merge commit, making my HEAD more recent than might be expected. There was a merge conflict and an API change that needed to be dealt with, in order for your pull to be correct. So I'd *much* rather see an explanation of what the conflict is when you ask me to pull, and let me handle it, rather than you pre-merging things for me. I *want* to see conflicts between subsystems. Seriously. Tried to add some explanation to the merge commit itself, giving plenty of detail. Even so, separately, it still needed that post-merge compile fix. Jeff -- 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: [git patches] libata updates
On 07/25/2012 06:31 PM, Linus Torvalds wrote: On Wed, Jul 25, 2012 at 3:26 PM, Jeff Garzik jgar...@pobox.com wrote: Even so, separately, it still needed that post-merge compile fix. And that's yet another example of how *NOT* to do things. If the merge has errors like that, then they should be fixed up in the merge. Please. Don't do this. Let me merge stuff, and you explain in the pull request why it gets merge problems. Not this mess. That merge itself was *trivial*. I do those kinds of fixups in my sleep and you don't even need to explain those. The non-trivial part you did as a separate commit. But neither of those should have been I'll pre-merge for Linus so that he doesn't see these problems. What is the right course in when a post-merge change is needed? Jeff -- 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: [git patches] libata updates
On 07/25/2012 07:30 PM, Linus Torvalds wrote: On Wed, Jul 25, 2012 at 3:58 PM, Jeff Garzik jgar...@pobox.com wrote: What is the right course in when a post-merge change is needed? Just describe the issue and the required change. Than I can just do it as part of the merge, and now the whole series is bisectable, including the merge itself. Here's a (fairly bad) example: http://www.spinics.net/lists/netdev/msg192349.html and the reason I call that a bad example is not because that's a bad pull request, but simply that those are all real data conflicts, not the more subtle kind of it merges fine, but because new code introduced uses an interface that changed, you need to do xyz. Thanks, so noted. I guess if the merge gets more complex than something easily described in an email, that implies that maintainers should do more cross-coordination and maybe a merge tree. What's the best way for libata to move forward, now that this hideous merge has been pushed out to the Well Known libata branches? The pre-jgarzik-merge commit you would have pulled is dc7f71f486f4f5fa96f6dcf86833da020cde8a11 had my pull request been proper. I can lop off the top 3 commits and force-update the libata-dev.git branches, then send a new pull request -- but you have grumbled at that sort of behavior in maintainer trees before too... Jeff -- 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: [resend PATCH 1/5] libata: reset once
On 07/10/2012 12:05 AM, Dan Williams wrote: Hotplug testing with libsas currently encounters a 55 second wait for link recovery to give up. In the case where the user trusts the response time of their devices permit the recovery attempts to be limited to one. Signed-off-by: Dan Williams dan.j.willi...@intel.com Acked-by: Jeff Garzik jgar...@redhat.com -- 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: [resend PATCH 2/5] libata: export ata_port suspend/resume infrastructure for sas
On 07/10/2012 12:05 AM, Dan Williams wrote:
Reuse ata_port_{suspend|resume}_common for sas. This path is chosen
over adding coordination between ata-tranport and sas-transport because
libsas wants to revalidate the domain at resume-time at the host level.
It can not validate links have resumed properly until libata has had a
chance to perform its revalidation, and any sane placing of an ata_port
in the sas-transport model would delay it's resumption until after the
host.
Export the common portion of port suspend/resume (bypass pm_runtime),
and allow sas to perform these operations asynchronously (similar to the
libsas async-ata probe implmentation). Async operation is determined by
having an external, rather than stack based, location for storing the
result of the operation.
Reviewed-by: Jacek Danecki jacek.dane...@intel.com
Signed-off-by: Dan Williams dan.j.willi...@intel.com
Acked-by: Jeff Garzik jgar...@redhat.com
--
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: Need help with libata error handling in libsas
James Bottomley wrote: On Mon, 2008-02-25 at 10:34 -0600, Brian King wrote: The new libata-eh is used for more than just EH. It is used for device probing, device revalidation, and power management. It is also woken for all command failures and is where the request sense for ATAPI devices is issued. Device revalidation following reset is also critical for ATA and ATAPI devices. One example of this is some SATA/PATA converter chips lose their DMA xfer settings following a reset and default to PIO mode only. Any DMA transfer that is attempted simply hangs. Strongly seconded. Doing your own ATA EH would be foolish, as that would imply duplicating all that carefully-time-tested logic handling devices which follow the ATA specs... about 98% of the time :) Just the set-transfer-mode logic took years to get right for the majority of ATA devices. OK ... I'm grepping around in the source trying to figure out all of this. Is it documented anywhere? That would really help me out at the moment. Unfortunately, not really. The simplistic version is... freeze, set some flags, call a function to schedule EH as needed -- most notably when your HBA signals an ATA device error or some other error in the ATA domain. Regardless of all this... libsas IMO will cause some libata-EH growing pains. libsas needs libata-EH for probing, revalidation, initialization, etc. But libsas probably does NOT need libata-EH for certain duties like SATA PHY diagnosis and link handling. libsas needs libata-EH. Unfortunately for libsas, libata-EH was written from the libata controls the world point of view, and probably needs some modifications to play well in the new SATA/SAS shared worldview. Brian's recommendation is quite sane... your -error_handler() probably just needs hard reset (aka COMRESET) capability. Jeff - 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] [3/22] Remove unchecked_isa_dma in advansys.c
Matthew Wilcox wrote: On Mon, Feb 25, 2008 at 11:40:35PM +0100, Andi Kleen wrote: (I must have fixed it somehow because it works on parisc, which is most unforgiving of drivers which do DMA without the DMA API). At least on x86 the DMA API cannot do ISA bouncing. You're saying that if I set a 24-bit DMA mask, and then do a pci_alloc_coherent(), x86 might hand me back something that's not accessible? That would be just broken. Indeed. Jeff - 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] mvsas: convert from rough draft to working driver
Ke Wei wrote: On Sat, Feb 23, 2008 at 11:28:50AM -0500, Jeff Garzik wrote: Ke Wei wrote: Convert rough draft Marvell 6440 driver to a working driver. Added support for SAS and SATA devices, hotplug, wide port, and expanders. This patch is based on: branch 'mvsas' of git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git Yay! Perfect patch: good tech content, applyable to #mvsas, and the most important part, the driver works :) One minor (though important) detail: may we assume this patch has the same Signed-off-by as previous patches? Oah, I have no idea how to diff between the previous 5th commit and current to use git-format-patch command, so I had to use git-diff to create patch. As a result, I format to place my Signed-off-by when sending email. Jeff, Do you have a good suggestion? Thank you for your help. That's just a simple mistake, so I wouldn't worry about it. We all forget such things, every now and then. If I forget to sign-off on a patch, I usually just reply to my own email (publicly), providing the Signed-off-by line requested... which is precisely what you did below :) Signed-off-by: Ke Wei [EMAIL PROTECTED] Thanks! Jeff - 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: [GIT PATCH] scsi fixes for 2.6.25-rc2
James Bottomley wrote: This is the latest crop of bug fixes plus one new driver: mvsas. We're [...] Jeff Garzik (1): mvsas: Add Marvell 6440 SAS/SATA driver [...] Ke Wei (1): mvsas: convert from rough draft to working driver I know I am probably shooting myself in the foot here, since I am the original author of mvsas, but... Should we be adding new drivers during -rc? On one hand, it's clear the addition does not break anything, and adds value for users. On the other hand, it's clearly not a bug fix, and -rc could easily get bloated with new drivers that didn't make the merge window. On the net driver side of things, I have a few new net drivers that I have queued for 2.6.26, because they did not make the merge window. This is inconsistent with your apparently policy. I would just prefer to have a clear and consistent policy here, regarding new drivers during -rc. Thanks, Jeff - 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: [GIT PATCH] scsi fixes for 2.6.25-rc2
Jeff Garzik wrote: On the net driver side of things, I have a few new net drivers that I have queued for 2.6.26, because they did not make the merge window. This is inconsistent with your apparently policy. s/apparently/apparent/ Sometimes my fingers don't type the words that come out of my brain :) Jeff - 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] mvsas: fix build warning, clean prototypes
- Fix build 'make randconfig' build warning spotted by Toralf Foerster: drivers/scsi/mvsas.c: In function 'mvs_hexdump': drivers/scsi/mvsas.c:715: error: implicit declaration of function 'isalnum' - Remove unneeded prototypes (spotted by hch) Signed-off-by: Jeff Garzik [EMAIL PROTECTED] --- NOTE: A proper fix, as noted in initial review (and by hch), would be to convert this driver over to using lib/hexdump.c, to eliminate a hand-rolled hexdump function. drivers/scsi/mvsas.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/scsi/mvsas.c b/drivers/scsi/mvsas.c index 30e20e6..d4a6ac3 100755 --- a/drivers/scsi/mvsas.c +++ b/drivers/scsi/mvsas.c @@ -35,6 +35,7 @@ #include linux/spinlock.h #include linux/delay.h #include linux/dma-mapping.h +#include linux/ctype.h #include scsi/libsas.h #include asm/io.h @@ -632,15 +633,6 @@ static int mvs_phy_control(struct asd_sas_phy *sas_phy, enum phy_func func, void *funcdata); static u32 mvs_read_phy_ctl(struct mvs_info *mvi, u32 port); static void mvs_write_phy_ctl(struct mvs_info *mvi, u32 port, u32 val); -static u32 mvs_read_port(struct mvs_info *mvi, u32 off, u32 off2, u32 port); -static void mvs_write_port(struct mvs_info *mvi, u32 off, u32 off2, - u32 port, u32 val); -static u32 mvs_read_port_cfg_data(struct mvs_info *mvi, u32 port); -static void mvs_write_port_cfg_data(struct mvs_info *mvi, u32 port, u32 val); -static void mvs_write_port_cfg_addr(struct mvs_info *mvi, u32 port, u32 addr); -static u32 mvs_read_port_vsr_data(struct mvs_info *mvi, u32 port); -static void mvs_write_port_vsr_data(struct mvs_info *mvi, u32 port, u32 val); -static void mvs_write_port_vsr_addr(struct mvs_info *mvi, u32 port, u32 addr); static u32 mvs_read_port_irq_stat(struct mvs_info *mvi, u32 port); static void mvs_write_port_irq_stat(struct mvs_info *mvi, u32 port, u32 val); static void mvs_write_port_irq_mask(struct mvs_info *mvi, u32 port, u32 val); @@ -649,9 +641,6 @@ static u32 mvs_read_port_irq_mask(struct mvs_info *mvi, u32 port); static u32 mvs_is_phy_ready(struct mvs_info *mvi, int i); static void mvs_detect_porttype(struct mvs_info *mvi, int i); static void mvs_update_phyinfo(struct mvs_info *mvi, int i, int get_st); -static void mvs_free_reg_set(struct mvs_info *mvi, struct mvs_port *port); -static u8 mvs_assign_reg_set(struct mvs_info *mvi, struct mvs_port *port); -static u32 mvs_is_sig_fis_received(u32 irq_status); static int mvs_scan_finished(struct Scsi_Host *, unsigned long); static void mvs_scan_start(struct Scsi_Host *); - 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: [GIT PATCH] scsi fixes for 2.6.25-rc2
Olof Johansson wrote: Hi, On Sat, Feb 23, 2008 at 09:13:33AM -0600, James Bottomley wrote: Jeff Garzik (1): mvsas: Add Marvell 6440 SAS/SATA driver [...] drivers/scsi/mvsas.c| 2981 I just noticed that the file permissions on that file are 755 in current git, that was probably not intentional? Definitely not intentional. They were 0644 in the original changeset (the one from me you highlighted), then the second changeset updating mvsas somehow changed the perms. Jeff - 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: [GIT PATCH] scsi fixes for 2.6.25-rc2
Andrew Morton wrote: On Sat, 23 Feb 2008 12:31:02 -0800 (PST) Linus Torvalds [EMAIL PROTECTED] wrote: On Sat, 23 Feb 2008, Jeff Garzik wrote: I know I am probably shooting myself in the foot here, since I am the original author of mvsas, but... Should we be adding new drivers during -rc? I'm personally of the opinion that a new driver that doesn't add anything but itself (ie no infrastructure changes etc) is fine. I'd rather have a new, rough driver that might work, than no driver at all, and it's not like it can cause a regression if you don't enable it. Yes, I too think that adding new standalone code in late -rc is OK. ACK, thanks! Jeff - 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 1/1] [SCSI] gdth: misc cleanups, preparation for ISA/EISA hotplug API
Several misc. cleanups:
- remove recently-noop'd 'reverse_scan' module parm
- remove pointless function prototypes
- remove ha-pccb, its value always == ha-cmdext
- move thrice-redundant DMA memory alloc and (in EISA's case, mapping)
into common functions gdth_ha_alloc(), gdth_ha_free()
- delete pointless zero-initializations of ha struct members, as these
are zeroed when ha is allocated (and never assigned any other value,
prior to the explicit zero initializations)
- consolidate thrice-repeated spinlock init
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
---
NOTE: Applies on top of my previous two gdth patches (PCI hotplug prep,
PCI hotplug convert).
drivers/scsi/gdth.c | 299 ++
drivers/scsi/gdth.h |1 -
2 files changed, 108 insertions(+), 192 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index ad9aff2..b17eb15 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -51,8 +51,6 @@
* reserve_list:h,b,t,l,h,b,t,l,... reserve particular drive(s) with
* h- controller no., b- channel no.,
* t- target ID, l- LUN
- * reverse_scan:Y reverse scan order for PCI controllers
- * reverse_scan:N scan PCI controllers like BIOS
* max_ids:xx - target ID count per channel (1..MAXID)
* rescan:Y rescan all channels/IDs
* rescan:N use all devices found until now
@@ -66,7 +64,7 @@
* force_dma32:Yuse only 32 bit DMA mode
* force_dma32:Nuse 64 bit DMA mode, if supported
*
- * The default values are: gdth=disable:N,reserve_mode:1,reverse_scan:N,
+ * The default values are: gdth=disable:N,reserve_mode:1,
* max_ids:127,rescan:N,hdr_channel:0,
* shared_access:Y,probe_eisa_isa:N,force_dma32:N.
* Here is another example: gdth=reserve_list:0,1,2,0,0,1,3,0,rescan:Y.
@@ -77,7 +75,7 @@
* with ' ' and all ':' with '=' and you must use
* '1' in place of 'Y' and '0' in place of 'N'.
*
- * Default: modprobe gdth disable=0 reserve_mode=1 reverse_scan=0
+ * Default: modprobe gdth disable=0 reserve_mode=1
* max_ids=127 rescan=0 hdr_channel=0 shared_access=0
* probe_eisa_isa=0 force_dma32=0
* The other example: modprobe gdth reserve_list=0,1,2,0,0,1,3,0 rescan=1.
@@ -148,29 +146,13 @@ static int gdth_sync_event(gdth_ha_str *ha, int service,
unchar index,
static int gdth_async_event(gdth_ha_str *ha);
static void gdth_log_event(gdth_evt_data *dvr, char *buffer);
-static void gdth_putq(gdth_ha_str *ha, Scsi_Cmnd *scp, unchar priority);
-static void gdth_next(gdth_ha_str *ha);
static int gdth_fill_raw_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp, unchar b);
static int gdth_special_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp);
-static gdth_evt_str *gdth_store_event(gdth_ha_str *ha, ushort source,
- ushort idx, gdth_evt_data *evt);
static int gdth_read_event(gdth_ha_str *ha, int handle, gdth_evt_str *estr);
-static void gdth_readapp_event(gdth_ha_str *ha, unchar application,
- gdth_evt_str *estr);
-static void gdth_clear_events(void);
-static void gdth_copy_internal_data(gdth_ha_str *ha, Scsi_Cmnd *scp,
-char *buffer, ushort count, int to_buffer);
static int gdth_internal_cache_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp);
static int gdth_fill_cache_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp, ushort hdrive);
-static void gdth_enable_int(gdth_ha_str *ha);
-static int gdth_test_busy(gdth_ha_str *ha);
-static int gdth_get_cmd_index(gdth_ha_str *ha);
-static void gdth_release_event(gdth_ha_str *ha);
-static int gdth_wait(gdth_ha_str *ha, int index,ulong32 time);
-static int gdth_internal_cmd(gdth_ha_str *ha, unchar service, ushort opcode,
- ulong32 p1, ulong64 p2,ulong64
p3);
static int gdth_search_drives(gdth_ha_str *ha);
static int gdth_analyse_hdrive(gdth_ha_str *ha, ushort hdrive);
@@ -181,7 +163,6 @@ static int gdth_close(struct inode *inode, struct file
*filep);
static int gdth_ioctl(struct inode *inode, struct file *filep,
unsigned int cmd, unsigned long arg);
-static void gdth_flush(gdth_ha_str *ha);
static int gdth_halt(struct notifier_block *nb, ulong event, void *buf);
static int gdth_queuecommand(Scsi_Cmnd *scp,void (*done)(Scsi_Cmnd *));
static int __gdth_queuecommand(gdth_ha_str *ha, struct scsi_cmnd *scp,
@@ -336,8 +317,6 @@ static int reserve_list[MAX_RES_ARGS] =
{0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff};
-/* scan order for PCI controllers */
-static int reverse_scan = 0;
/* virtual channel for the host drives */
static
Re: [PATCH 1/1] [SCSI] gdth: misc cleanups, preparation for ISA/EISA hotplug API
Christoph Hellwig wrote:
Eventually we shoud just kill the INT_COAL ifdefed code. It has never
been enabled and clutters up the driver quite badly.
Noted (queued)... fine by me, and makes life easier.
+#ifdef CONFIG_EISA
+ if ((ha-type == GDT_EISA) (ha-ccb_phys))
+ pci_unmap_single(ha-pdev, ha-ccb_phys, sizeof(gdth_cmd_str),
+PCI_DMA_BIDIRECTIONAL);
+#endif /* CONFIG_EISA */
I don't think moving this into the common helper makes any sense, as
it's only ever done for the eisa adapter. Just keep it local there.
+#ifdef CONFIG_EISA
+ if (ha-type == GDT_EISA) {
+ ha-ccb_phys = pci_map_single(ha-pdev, ha-cmdext,
+ sizeof(gdth_cmd_str), PCI_DMA_BIDIRECTIONAL);
+ if (!ha-ccb_phys)
+ goto out_free;
+ }
+#endif /* CONFIG_EISA */
Same here.
hm. We'll see how it plays out... on the remove side, the above is
exact what happens in gdth_remove_one() without my patch, thus
consolidating two cases of the same code into one. There is a
less-strong argument for doing the allocation that way, but it may turn
out to be useful anyway once the ISA/EISA API conversion is complete.
Jeff
-
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] [SCSI] gdth: misc cleanups, preparation for ISA/EISA hotplug API
Christoph Hellwig wrote: On Sun, Feb 24, 2008 at 12:18:23AM -0500, Jeff Garzik wrote: hm. We'll see how it plays out... on the remove side, the above is exact what happens in gdth_remove_one() without my patch, thus consolidating two cases of the same code into one. There is a less-strong argument for doing the allocation that way, but it may turn out to be useful anyway once the ISA/EISA API conversion is complete. EISA -remove has a different prototype from PCI -remove from ISA -remove, so gdth_remove_one will be split up eventually. Having the scsi_host_put duplicated in each shouldn't be too much of a problem :) We'll see what the final result is... you might turn out to be right. If people want to avoid merging this patch because of this issue, that's fine. Jeff - 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] aic94xx: plumb in I_T_nexus_reset task management function
James Bottomley wrote: Currently aic94xx has no exported I_T_nexus_reset function. This is a bit of a huge problem, since sas_ata relies on this function to perform an ATA phy reset and also it means that if abort fails, we really have no bigger hammer to hit everything with. Plumb in the I_T_nexus_reset by quiescing the sequencer, sending the correct phy reset (link for ATA and hard for SAS) and then carefully resuming the sequencer again. Signed-off-by: James Bottomley [EMAIL PROTECTED] --- drivers/scsi/aic94xx/aic94xx.h |1 + drivers/scsi/aic94xx/aic94xx_init.c |2 +- drivers/scsi/aic94xx/aic94xx_tmf.c | 58 -- 3 files changed, 56 insertions(+), 5 deletions(-) Tangent: Now that patches for ipr and sata_sx4 exist, libsas is the last holdout using libata's old error handling paths. I think Darrick was either scoping that work, or had preliminary patches? Anyway, that's holding back removal of a lot of libata code, so I wanted to make sure the issue remained in people's minds... Jeff - 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
Ke Wei wrote: Added support for Expander. Based on version 0.1 for mvsas. Signed-off-by: Ke Wei [EMAIL PROTECTED] --- diff --git a/drivers/scsi/mvsas.c b/drivers/scsi/mvsas.c old mode 100644 new mode 100755 index 03638b9..3c7a154 --- a/drivers/scsi/mvsas.c +++ b/drivers/scsi/mvsas.c @@ -2,6 +2,7 @@ mvsas.c - Marvell 88SE6440 SAS/SATA support Copyright 2007 Red Hat, Inc. + Copyright 2008 Marvell. [EMAIL PROTECTED] This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as @@ -25,6 +26,13 @@ structures. this permits elimination of all the le32_to_cpu() and cpu_to_le32() conversions. + Changelog: + 2008-02-22 0.5 Added support for Expander. + 2008-02-05 0.4 Added support for hotplug and wide port. + 2008-01-22 0.3 Added support for SAS HD and SATA Devices. + 2008-01-09 0.2 detect SAS disk. + 2007-09-25 0.1 rough draft, Initial version. + */ #include linux/kernel.h Technical content: looks good, ACK Patch content: looks diff'd against correct version, ACK But we still have one major process problem, and a couple minor problems to fix: 1) [minor] please do not include a changelog in the source code. That's what the git repository history is for. 2) [minor] Your patch description (email body) is incorrect. It should describe all changes since version 0.1, the version you diff'd against: Convert rough draft Marvell 6440 driver to a working driver. Added support for SAS and SATA devices, hotplug, wide port, and expanders. 3) [minor] Your email subject should reflect that you are updating version 0.1, the version you diff'd against: [PATCH] mvsas: convert from rough draft to working driver 4) [major] Your email was encoded in base64, which makes it difficult for automated tools to handle, and difficult for some mail clients to view and reply-to. It will require some email configuration on your part to disable this, and send the email as a text/plain message. I've copied Saeed Bishara @ Marvell on this email. Saeed has been successfully sending patch for the sata_mv driver (5040, 6080, 6042, etc.) Maybe Saeed can advise you on his email setup? In any case, once we fix this last problem -- base64 -- we can finally apply your patch and get things moving. You are very close to having a working Linux kernel development setup, thanks for your patience! Jeff - 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/2] libsas: Provide a transport-level facility to request SAS addrs
Darrick J. Wong wrote: Provide a facility to use the request_firmware() interface to get a SAS address from userspace. This can be used by SAS LLDDs that cannot obtain the address from the host adapter. Resend of 8 Oct. 2007 patch, now based off 2.6.25-rc2 + scsi_misc. Signed-off-by: Darrick J. Wong [EMAIL PROTECTED] --- drivers/scsi/libsas/sas_scsi_host.c | 41 +++ include/scsi/libsas.h |2 ++ 2 files changed, 43 insertions(+), 0 deletions(-) ACK patches 1-2 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 2.6.25-rc1-git2: GDT SCSI: change drivers/scsi/gdth.c into using pci_get device
Boaz Harrosh wrote: On Sat, Feb 16 2008 at 18:37 +0200, Matthew Wilcox [EMAIL PROTECTED] wrote: On Wed, Feb 13, 2008 at 10:57:37AM +0200, Boaz Harrosh wrote: I still don't have a card for testing myself. Again anyone wants to send me a card. Intel people anybody home? Apparently Intel sold this line of cards to Adaptec. The copyright notice in the file backs this up: * Copyright (C) 1995-06 ICP vortex GmbH, Achim Leubner * * Copyright (C) 2002-04 Intel Corporation * * Copyright (C) 2003-06 Adaptec Inc. * * [EMAIL PROTECTED] * OK I never got this guy to ping back. CCing [EMAIL PROTECTED] Who is the right contact person, regarding the HW that is supported by the gdth driver? Form what we see in driver commit logs (above), it was transfered to Adaptec from Intel in 2003. Is that still so? In my experience Achim does respond, but this driver is probably very low priority, so it might take a while... Jeff - 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] gdth: convert to PCI hotplug API
James Bottomley wrote: diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c index c825239..1b53e92 100644 --- a/drivers/scsi/gdth.c +++ b/drivers/scsi/gdth.c @@ -595,85 +595,107 @@ static int __init gdth_search_isa(ulong32 bios_adr) #endif /* CONFIG_ISA */ #ifdef CONFIG_PCI -static void gdth_search_dev(gdth_pci_str *pcistr, ushort *cnt, -ushort vendor, ushort dev); +static gdth_pci_str gdth_pcistr[MAXHA]; +static int gdth_pci_cnt; +static bool gdth_pci_registered; Could we get rid of these static arrays and MAXHA entirely? It should be possible just to bung the parameters in pci_str into gdth_ha_str and dump the arrays. I kept those array for one reason: you need it to preserve the existing in-driver PCI device sort. If we can eliminate the sorting, then the array can easily disappear. I /think/ the sort can be eliminated now because we have pci=reverse, but I have not verified that guess. Jeff - 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 1/2] SCSI/gdth: PCI probe cleanups, prep for PCI hotplug API conversion
- Reduce uses of gdth_pci_str::pdev, preferring a local variable
(or function arg) 'pdev' instead.
- Reduce uses of gdth_pcistr array, preferring local variable
(or function arg) 'pcistr' instead.
- Eliminate lone use of gdth_pci_str::irq, using equivalent
pdev-irq instead
- Eliminate assign-only gdth_pci_str::io_mm
Note: If the indentation seems weird, that's because a line was
converted from spaces to tabs, when it was modified.
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
---
NOTE: this patch series supercedes the previous gdth: convert to PCI
hotplug API patch.
drivers/scsi/gdth.c | 59 --
drivers/scsi/gdth.h |2 -
2 files changed, 28 insertions(+), 33 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index 6d67f5c..56c2b91 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -653,7 +653,6 @@ static void __init gdth_search_dev(gdth_pci_str *pcistr,
ushort *cnt,
/* GDT PCI controller found, resources are already in pdev */
pcistr[*cnt].pdev = pdev;
-pcistr[*cnt].irq = pdev-irq;
base0 = pci_resource_flags(pdev, 0);
base1 = pci_resource_flags(pdev, 1);
base2 = pci_resource_flags(pdev, 2);
@@ -668,7 +667,6 @@ static void __init gdth_search_dev(gdth_pci_str *pcistr,
ushort *cnt,
!(base1 IORESOURCE_IO))
continue;
pcistr[*cnt].dpmem = pci_resource_start(pdev, 2);
-pcistr[*cnt].io_mm = pci_resource_start(pdev, 0);
pcistr[*cnt].io= pci_resource_start(pdev, 1);
}
TRACE2((Controller found at %d/%d, irq %d, dpmem 0x%lx\n,
@@ -913,7 +911,8 @@ static int __init gdth_init_isa(ulong32
bios_adr,gdth_ha_str *ha)
#endif /* CONFIG_ISA */
#ifdef CONFIG_PCI
-static int __init gdth_init_pci(gdth_pci_str *pcistr,gdth_ha_str *ha)
+static int __init gdth_init_pci(struct pci_dev *pdev, gdth_pci_str *pcistr,
+ gdth_ha_str *ha)
{
register gdt6_dpram_str __iomem *dp6_ptr;
register gdt6c_dpram_str __iomem *dp6c_ptr;
@@ -925,14 +924,14 @@ static int __init gdth_init_pci(gdth_pci_str
*pcistr,gdth_ha_str *ha)
TRACE((gdth_init_pci()\n));
-if (pcistr-pdev-vendor == PCI_VENDOR_ID_INTEL)
+if (pdev-vendor == PCI_VENDOR_ID_INTEL)
ha-oem_id = OEM_ID_INTEL;
else
ha-oem_id = OEM_ID_ICP;
-ha-brd_phys = (pcistr-pdev-bus-number 8) | (pcistr-pdev-devfn
0xf8);
-ha-stype = (ulong32)pcistr-pdev-device;
-ha-irq = pcistr-irq;
-ha-pdev = pcistr-pdev;
+ha-brd_phys = (pdev-bus-number 8) | (pdev-devfn 0xf8);
+ha-stype = (ulong32)pdev-device;
+ha-irq = pdev-irq;
+ha-pdev = pdev;
if (ha-pdev-device = PCI_DEVICE_ID_VORTEX_GDT6000B) { /* GDT6000/B */
TRACE2((init_pci() dpmem %lx irq %d\n,pcistr-dpmem,ha-irq));
@@ -960,8 +959,7 @@ static int __init gdth_init_pci(gdth_pci_str
*pcistr,gdth_ha_str *ha)
continue;
}
iounmap(ha-brd);
-pci_write_config_dword(pcistr-pdev,
- PCI_BASE_ADDRESS_0, i);
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0, i);
ha-brd = ioremap(i, sizeof(gdt6_dpram_str));
if (ha-brd == NULL) {
printk(GDT-PCI: Initialization error (DPMEM remap
error)\n);
@@ -1070,8 +1068,7 @@ static int __init gdth_init_pci(gdth_pci_str
*pcistr,gdth_ha_str *ha)
continue;
}
iounmap(ha-brd);
-pci_write_config_dword(pcistr-pdev,
- PCI_BASE_ADDRESS_2, i);
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_2, i);
ha-brd = ioremap(i, sizeof(gdt6c_dpram_str));
if (ha-brd == NULL) {
printk(GDT-PCI: Initialization error (DPMEM remap
error)\n);
@@ -1163,16 +1160,16 @@ static int __init gdth_init_pci(gdth_pci_str
*pcistr,gdth_ha_str *ha)
}
/* manipulate config. space to enable DPMEM, start RP controller */
-pci_read_config_word(pcistr-pdev, PCI_COMMAND, command);
+ pci_read_config_word(pdev, PCI_COMMAND, command);
command |= 6;
-pci_write_config_word(pcistr-pdev, PCI_COMMAND, command);
-if (pci_resource_start(pcistr-pdev, 8) == 1UL)
-pci_resource_start(pcistr-pdev, 8) = 0UL;
+ pci_write_config_word(pdev, PCI_COMMAND, command);
+ if (pci_resource_start(pdev, 8) == 1UL)
+ pci_resource_start(pdev, 8) = 0UL;
i = 0xFEFF0001UL;
-pci_write_config_dword(pcistr-pdev, PCI_ROM_ADDRESS, i);
+ pci_write_config_dword(pdev, PCI_ROM_ADDRESS, i);
gdth_delay(1);
-pci_write_config_dword(pcistr-pdev, PCI_ROM_ADDRESS,
- pci_resource_start(pcistr-pdev, 8));
+ pci_write_config_dword(pdev
Re: [PATCH 1/5] gdth: update deprecated pci_find_device
Boaz Harrosh wrote:
From: Sergio Luis [EMAIL PROTECTED]
Fix compilation warning in gdth.c, which was using the deprecated
pci_find_device.
drivers/scsi/gdth.c:645: warning: 'pci_find_device' is deprecated (declared at
include/linux/pci.h:495)
Changing it to use pci_get_device, instead.
Signed-off-by: Sergio Luis [EMAIL PROTECTED]
Signed-off-by: James Bottomley [EMAIL PROTECTED]
---
drivers/scsi/Kconfig |2 +-
drivers/scsi/gdth.c |7 +--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 184c7ae..46fcb82 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -725,7 +725,7 @@ config SCSI_FD_MCS
config SCSI_GDTH
tristate Intel/ICP (former GDT SCSI Disk Array) RAID Controller
support
- depends on (ISA || EISA || PCI) SCSI ISA_DMA_API PCI_LEGACY
+ depends on (ISA || EISA || PCI) SCSI ISA_DMA_API
---help---
Formerly called GDT SCSI Disk Array Controller Support.
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index b253b8c..5f0e054 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -643,12 +643,15 @@ static void __init gdth_search_dev(gdth_pci_str *pcistr,
ushort *cnt,
*cnt, vendor, device));
pdev = NULL;
-while ((pdev = pci_find_device(vendor, device, pdev))
+while ((pdev = pci_get_device(vendor, device, pdev))
!= NULL) {
if (pci_enable_device(pdev))
continue;
-if (*cnt = MAXHA)
+if (*cnt = MAXHA) {
+pci_dev_put(pdev);
return;
+}
This patch is already upstream... (unfortunately)
Jeff
-
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] gdth: update deprecated pci_find_device
James Bottomley wrote: On Thu, 2008-02-14 at 15:13 -0500, Jeff Garzik wrote: Boaz Harrosh wrote: From: Sergio Luis [EMAIL PROTECTED] Fix compilation warning in gdth.c, which was using the deprecated pci_find_device. [...] This patch is already upstream... (unfortunately) I think, in spite of the cover name (patches for stable), these are for the set of testers who're based on 2.6.24. Oops! My mistake, then. Jeff - 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] gdth: convert to PCI hotplug API
Boaz Harrosh wrote: do you intend this to be pushed into 2.6.25-rcx or this is already for 2.6.26? Should we put this in -mm tree for testing? Not intended for 2.6.25. I just wanted to get this in process somewhere, and keep this issue moving. I would definitely prefer to have this tested before it goes to Linus. Its a long term goal to kill pci_find_device(), and this conversion was a side effect of that. Jeff - 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] gdth: convert to PCI hotplug API
Comments noted for my next round of revisions (its a low priority, so definitely not this week). Good spotting, thanks! Jeff - 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: [SCSI] gdth: update deprecated pci_find_device
Linux Kernel Mailing List wrote:
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99109301d103fbf0de43fc5a580a406c12a501e0
Commit: 99109301d103fbf0de43fc5a580a406c12a501e0
Parent: 61c92814dc324b541391757062ff02fbf3b08086
Author: Sergio Luis [EMAIL PROTECTED]
AuthorDate: Tue Feb 12 20:48:03 2008 -0300
Committer: James Bottomley [EMAIL PROTECTED]
CommitDate: Wed Feb 13 09:33:10 2008 -0600
[SCSI] gdth: update deprecated pci_find_device
Fix compilation warning in gdth.c, which was using the deprecated
pci_find_device.
drivers/scsi/gdth.c:645: warning: 'pci_find_device' is deprecated (declared at include/linux/pci.h:495)
Changing it to use pci_get_device, instead.
Signed-off-by: Sergio Luis [EMAIL PROTECTED]
Signed-off-by: James Bottomley [EMAIL PROTECTED]
---
drivers/scsi/Kconfig |2 +-
drivers/scsi/gdth.c |7 +--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index a5f0aaa..a7a0813 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -722,7 +722,7 @@ config SCSI_FD_MCS
config SCSI_GDTH
tristate Intel/ICP (former GDT SCSI Disk Array) RAID Controller
support
- depends on (ISA || EISA || PCI) SCSI ISA_DMA_API PCI_LEGACY
+ depends on (ISA || EISA || PCI) SCSI ISA_DMA_API
---help---
Formerly called GDT SCSI Disk Array Controller Support.
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index 7079fef..6d67f5c 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -642,12 +642,15 @@ static void __init gdth_search_dev(gdth_pci_str *pcistr,
ushort *cnt,
*cnt, vendor, device));
pdev = NULL;
-while ((pdev = pci_find_device(vendor, device, pdev))
+while ((pdev = pci_get_device(vendor, device, pdev))
!= NULL) {
if (pci_enable_device(pdev))
continue;
-if (*cnt = MAXHA)
+if (*cnt = MAXHA) {
+pci_dev_put(pdev);
return;
+}
+
Why no pci_dev_put() in the module cleanup path?
Jeff
-
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] gdth: convert to PCI hotplug API
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
---
drivers/scsi/gdth.c | 143 +++-
1 file changed, 86 insertions(+), 57 deletions(-)
06196f50915da97bb897495863f9f084d785c1e4
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index c825239..1b53e92 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -595,85 +595,107 @@ static int __init gdth_search_isa(ulong32 bios_adr)
#endif /* CONFIG_ISA */
#ifdef CONFIG_PCI
-static void gdth_search_dev(gdth_pci_str *pcistr, ushort *cnt,
-ushort vendor, ushort dev);
+static gdth_pci_str gdth_pcistr[MAXHA];
+static int gdth_pci_cnt;
+static bool gdth_pci_registered;
-static int __init gdth_search_pci(gdth_pci_str *pcistr)
+static bool __init gdth_search_vortex(ushort device)
{
-ushort device, cnt;
-
-TRACE((gdth_search_pci()\n));
-
-cnt = 0;
-for (device = 0; device = PCI_DEVICE_ID_VORTEX_GDT6555; ++device)
-gdth_search_dev(pcistr, cnt, PCI_VENDOR_ID_VORTEX, device);
-for (device = PCI_DEVICE_ID_VORTEX_GDT6x17RP;
- device = PCI_DEVICE_ID_VORTEX_GDTMAXRP; ++device)
-gdth_search_dev(pcistr, cnt, PCI_VENDOR_ID_VORTEX, device);
-gdth_search_dev(pcistr, cnt, PCI_VENDOR_ID_VORTEX,
-PCI_DEVICE_ID_VORTEX_GDTNEWRX);
-gdth_search_dev(pcistr, cnt, PCI_VENDOR_ID_VORTEX,
-PCI_DEVICE_ID_VORTEX_GDTNEWRX2);
-gdth_search_dev(pcistr, cnt, PCI_VENDOR_ID_INTEL,
-PCI_DEVICE_ID_INTEL_SRC);
-gdth_search_dev(pcistr, cnt, PCI_VENDOR_ID_INTEL,
-PCI_DEVICE_ID_INTEL_SRC_XSCALE);
-return cnt;
+ if (device = PCI_DEVICE_ID_VORTEX_GDT6555)
+ return true;
+ if (device = PCI_DEVICE_ID_VORTEX_GDT6x17RP
+ device = PCI_DEVICE_ID_VORTEX_GDTMAXRP)
+ return true;
+ if (device == PCI_DEVICE_ID_VORTEX_GDTNEWRX ||
+ device == PCI_DEVICE_ID_VORTEX_GDTNEWRX2)
+ return true;
+ return false;
}
+static int gdth_pci_init_one(struct pci_dev *pdev,
+const struct pci_device_id *ent);
+static void gdth_pci_remove_one(struct pci_dev *pdev);
+static void gdth_remove_one(gdth_ha_str *ha);
+
/* Vortex only makes RAID controllers.
* We do not really want to specify all 550 ids here, so wildcard match.
*/
-static struct pci_device_id gdthtable[] __maybe_unused = {
-{PCI_VENDOR_ID_VORTEX,PCI_ANY_ID,PCI_ANY_ID, PCI_ANY_ID},
-{PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_SRC,PCI_ANY_ID,PCI_ANY_ID},
-
{PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_SRC_XSCALE,PCI_ANY_ID,PCI_ANY_ID},
-{0}
+static struct pci_device_id gdthtable[] __devinitdata = {
+ { PCI_VDEVICE(VORTEX, PCI_ANY_ID) },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_SRC) },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_SRC_XSCALE) },
+ { } /* terminate list */
+};
+MODULE_DEVICE_TABLE(pci, gdthtable);
+
+static struct pci_driver gdth_pci_driver = {
+ .name = gdth,
+ .id_table = gdthtable,
+ .probe = gdth_pci_init_one,
+ .remove = gdth_pci_remove_one,
};
-MODULE_DEVICE_TABLE(pci,gdthtable);
-static void __init gdth_search_dev(gdth_pci_str *pcistr, ushort *cnt,
- ushort vendor, ushort device)
+static void gdth_pci_remove_one(struct pci_dev *pdev)
+{
+ gdth_ha_str *ha = pci_get_drvdata(pdev);
+
+ pci_set_drvdata(pdev, NULL);
+
+ list_del(ha-list);
+ gdth_remove_one(ha);
+
+ pci_disable_device(pdev);
+}
+
+static int __devinit gdth_pci_init_one(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
{
-ulong base0, base1, base2;
-struct pci_dev *pdev;
+ ushort vendor = pdev-vendor;
+ ushort device = pdev-device;
+ ulong base0, base1, base2;
+ int rc;
-TRACE((gdth_search_dev() cnt %d vendor %x device %x\n,
- *cnt, vendor, device));
+ TRACE((gdth_search_dev() cnt %d vendor %x device %x\n,
+ gdth_pci_cnt, vendor, device));
+
+ if (vendor == PCI_VENDOR_ID_VORTEX !gdth_search_vortex(device))
+ return -ENODEV;
+
+ rc = pci_enable_device(pdev);
+ if (rc)
+ return rc;
+
+ if (gdth_pci_cnt = MAXHA)
+ return -EBUSY;
-pdev = NULL;
-while ((pdev = pci_find_device(vendor, device, pdev))
- != NULL) {
-if (pci_enable_device(pdev))
-continue;
-if (*cnt = MAXHA)
-return;
/* GDT PCI controller found, resources are already in pdev */
-pcistr[*cnt].pdev = pdev;
-pcistr[*cnt].irq = pdev-irq;
+ gdth_pcistr[gdth_pci_cnt].pdev = pdev;
+ gdth_pcistr[gdth_pci_cnt].irq = pdev-irq;
base0 = pci_resource_flags(pdev, 0);
base1 = pci_resource_flags(pdev, 1);
base2 = pci_resource_flags(pdev, 2
Re: [PATCHSET #upstream] block/libata: update and use block layer padding and draining
Jeff Garzik wrote: Tejun Heo wrote: This patchset updates block layer padding and draining support and make libata use it. It's based on James Bottomley's initial work and, of the five, the last two patches are from James with some modifications. Please read the following thread for more info. http://thread.gmane.org/gmane.linux.scsi/37185 This patchset is on top of upstream (a6af42fc9a12165136d82206ad52f18c5955ce87) + kill-n_iter-and-fix-fsl patch [1] ACK patchset... lets definitely get these fixes upstream. Once Jens is happy, I would prefer the merge the lot upstream, if that is OK with everyone involved? Jens, ping? It's a bug fix, so it would be nice to get this in soonish. As noted, if all looks good, I would prefer to merge via libata-dev... Thanks, Jeff - 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: [PATCHSET #upstream] block/libata: update and use block layer padding and draining
Jens Axboe wrote: On Fri, Feb 08 2008, Jeff Garzik wrote: Jeff Garzik wrote: Tejun Heo wrote: This patchset updates block layer padding and draining support and make libata use it. It's based on James Bottomley's initial work and, of the five, the last two patches are from James with some modifications. Please read the following thread for more info. http://thread.gmane.org/gmane.linux.scsi/37185 This patchset is on top of upstream (a6af42fc9a12165136d82206ad52f18c5955ce87) + kill-n_iter-and-fix-fsl patch [1] ACK patchset... lets definitely get these fixes upstream. Once Jens is happy, I would prefer the merge the lot upstream, if that is OK with everyone involved? Jens, ping? It's a bug fix, so it would be nice to get this in soonish. As noted, if all looks good, I would prefer to merge via libata-dev... I'm ok with it, but lets please merge the block bits through the block repo, since they are not trivial. Wont be until the week after next, though. hmmm, rather than delaying the bug fixes for two weeks, since you're OK with it we can push upstream now, and apply further fixes if problems arise during testing? I would rather get these fixes out into wide testing sooner rather than later. Jeff - 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: Integration of SCST in the mainstream Linux kernel
Bart Van Assche wrote: On Feb 5, 2008 6:50 PM, Jeff Garzik [EMAIL PROTECTED] wrote: For remotely accessing data, iSCSI+fs is quite simply more overhead than a networked fs. With iSCSI you are doing local VFS - local blkdev - network whereas a networked filesystem is local VFS - network There are use cases than can be solved better via iSCSI and a filesystem than via a network filesystem. One such use case is when deploying a virtual machine whose data is stored on a network server: in that case there is only one user of the data (so there are no locking issues) and filesystem and block device each run in another operating system: the filesystem runs inside the virtual machine and iSCSI either runs in the hypervisor or in the native OS. Hence the diskless root fs configuration I referred to in multiple emails... whoopee, you reinvented NFS root with quotas :) Jeff - 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: [PATCHSET #upstream] block/libata: update and use block layer padding and draining
Tejun Heo wrote: This patchset updates block layer padding and draining support and make libata use it. It's based on James Bottomley's initial work and, of the five, the last two patches are from James with some modifications. Please read the following thread for more info. http://thread.gmane.org/gmane.linux.scsi/37185 This patchset is on top of upstream (a6af42fc9a12165136d82206ad52f18c5955ce87) + kill-n_iter-and-fix-fsl patch [1] ACK patchset... lets definitely get these fixes upstream. Once Jens is happy, I would prefer the merge the lot upstream, if that is OK with everyone involved? Jeff - 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
Ke Wei wrote: Added support for hotplug and wide port. Signed-off-by: Ke Wei [EMAIL PROTECTED] --- drivers/scsi/mvsas.c | 445 ++ 1 files changed, 339 insertions(+), 106 deletions(-) Technically speaking, everything is looking great so far. We need to correct one process problem, and we should be able to get your work into the 'mvsas' branch of scsi-misc-2.6.git... and soon thereafter hopefully into the official upstream kernel. The process problem is... when making revisions, we need to get the full patch each time. In this case, each patch should be diff'd against the current version in the 'mvsas' branch: version 0.1. The succession of emails would look like this: Email #1: Subject: [PATCH] mvsas: make it work Convert the skeleton mvsas driver into a real, working driver. Currently, the following works: SAS, SAS expanders, SAS wide ports SATA devices, SATAPI Signed-off-by: Ke Wei [EMAIL PROTECTED] And then James, myself, other reviewers reply. Or, you add some new features like hotplugging. Each time, you must regenerate a full patch against the most git repository revision: If a previous patch of yours, version 0.2, has been applied to git, then you would create your patch against version 0.2. If a previous patch of yours has NOT yet been applied to git, then you would create your patch against version 0.1. Thus, in this case, version 0.1 is in 'mvsas' branch, so your second email would then be Email #2: Subject: [PATCH v2] mvsas: make it work Convert the skeleton mvsas driver into a real, working driver. Currently, the following works: SAS, SAS expanders, SAS wide ports SATA devices, SATAPI Signed-off-by: Ke Wei [EMAIL PROTECTED] --- Changes since last posting (version 0.2): - fix coding problem And then you continue your work, and add another revision while everyone else is sleeping, the third email would look like: Email #3: Subject: [PATCH v3] mvsas: make it work Convert the skeleton mvsas driver into a real, working driver. Currently, the following works: SAS, SAS expanders, SAS wide ports SATA devices, SATAPI Signed-off-by: Ke Wei [EMAIL PROTECTED] --- Changes since last posting (version 0.3): - add hotplug support - add wide port support Changes since last posting (version 0.2): - fix coding problem Thus, you always create a patch against the most recent source code in the git repository. It is common for patches to go through a few revisions on the mailing list, before it is applied to the git repository. So anyway... send a patch against the latest #mvsas (version 0.1), and that patch should go in rapidly. Thanks! And keep up the good work, Jeff - 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 21/24][RFC] scsi_tgt: use of sense accessors
FUJITA Tomonori wrote: On Tue, 5 Feb 2008 11:21:33 -0500 Pete Wyckoff [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote on Mon, 04 Feb 2008 19:53 +0200: FIXME: I need help with this driver (Pete?) I used scsi_sense() in a none const way. But since scsi_tgt is the ULD here, it can just access it's own sense buffer directly. I did not use scsi_eh_cpy_sense() because I did not want the extra copy. Pete will want to use a 260 bytes buffer here. Signed-off-by: Boaz Harrosh [EMAIL PROTECTED] Need-help-from: Pete Wyckoff [EMAIL PROTECTED] FYI, I never use scsi_tgt. Only just pure userspace on the target, and a dumb ethernet NIC that does not know it is speaking any form of SCSI. Seems that many people misunderstand STGT iSCSI (and iSER), FCoE, and SRP (not implemented yet) software target drivers. They don't use the tgt kernel module. They just run in user space like user-space nfs daemon. FWIW, some AHCI and other SATA chips implement ATA target mode. I'm watching this SCSI work with interest, hoping that many of the concepts (and code?) can be applied to SATA as well. If for no other reason than I can build a cheap ATA protocol analyzer, or bridge. Jeff - 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: Integration of SCST in the mainstream Linux kernel
Bart Van Assche wrote: On Feb 4, 2008 11:57 PM, Jeff Garzik [EMAIL PROTECTED] wrote: Networked block devices are attractive because the concepts and implementation are more simple than networked filesystems... but usually you want to run some sort of filesystem on top. At that point you might as well run NFS or [gfs|ocfs|flavor-of-the-week], and ditch your networked block device (and associated complexity). Running a filesystem on top of iSCSI results in better performance than NFS, especially if the NFS client conforms to the NFS standard (=synchronous writes). By searching the web search for the keywords NFS, iSCSI and performance I found the following (6 years old) document: http://www.technomagesinc.com/papers/ip_paper.html. A quote from the conclusion: Our results, generated by running some of industry standard benchmarks, show that iSCSI significantly outperforms NFS for situations when performing streaming, database like accesses and small file transactions. async performs better than sync... this is news? Furthermore, NFSv4 has not only async capability but delegation too (and RDMA if you like such things), so the comparison is not relevant to modern times. But a networked filesystem (note I'm using that term, not NFS, from here on) is simply far more useful to the average user. A networked block device is a building block -- and a useful one. A networked filesystem is an immediately usable solution. For remotely accessing data, iSCSI+fs is quite simply more overhead than a networked fs. With iSCSI you are doing local VFS - local blkdev - network whereas a networked filesystem is local VFS - network iSCSI+fs also adds new manageability issues, because unless the filesystem is single-computer (such as diskless iSCSI root fs), you still need to go across the network _once again_ to handle filesystem locking and coordination issues. There is no _fundamental_ reason why remote shared storage via iSCSI OSD is any faster than a networked filesystem. SCSI-over-IP has its uses. Absolutely. It needed to be standardized. But let's not pretend iSCSI is anything more than what it is. Its a bloated cat5 cabling standard :) Jeff - 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: Integration of SCST in the mainstream Linux kernel
Olivier Galibert wrote: On Mon, Feb 04, 2008 at 05:57:47PM -0500, Jeff Garzik wrote: iSCSI and NBD were passe ideas at birth. :) Networked block devices are attractive because the concepts and implementation are more simple than networked filesystems... but usually you want to run some sort of filesystem on top. At that point you might as well run NFS or [gfs|ocfs|flavor-of-the-week], and ditch your networked block device (and associated complexity). Call me a sysadmin, but I find easier to plug in and keep in place an ethernet cable than these parallel scsi cables from hell. Every server has at least two ethernet ports by default, with rarely any surprises at the kernel level. Adding ethernet cards is inexpensive, and you pretty much never hear of compatibility problems between cards. So ethernet as a connection medium is really nice compared to scsi. Too bad iscsi is demented and ATAoE/NBD inexistant. Maybe external SAS will be nice, but I don't see it getting to the level of universality of ethernet any time soon. And it won't get the same amount of user-level compatibility testing in any case. Indeed, at the end of the day iSCSI is a bloated cabling standard. :) It has its uses, but I don't see it as ever coming close to replacing direct-to-network (perhaps backed with local cachefs) filesystems... which is how all the hype comes across to me. Cheap Lintel boxes everybody is familiar with _are_ the storage appliances. Until mass-produced ATA and SCSI devices start shipping with ethernet connectors, anyway. Jeff - 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: Integration of SCST in the mainstream Linux kernel
Vladislav Bolkhovitin wrote: Jeff Garzik wrote: iSCSI is way, way too complicated. I fully agree. From one side, all that complexity is unavoidable for case of multiple connections per session, but for the regular case of one connection per session it must be a lot simpler. Actually, think about those multiple connections... we already had to implement fast-failover (and load bal) SCSI multi-pathing at a higher level. IMO that portion of the protocol is redundant: You need the same capability elsewhere in the OS _anyway_, if you are to support multi-pathing. Jeff - 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] pci: pci_enable_device_bars() fix
Ingo Molnar wrote: * Jeff Garzik [EMAIL PROTECTED] wrote: Ingo Molnar wrote: so please tell me Jeff. If Greg, who is the super-maintainer of your code area, and who deals with your code every day and changes it every minute and hour, simply did not Cc: the SCSI list - how am i, a largely outside party in this matter, supposed to notice that 3 maintainers and 3 mailing lists in the Cc: were somehow not enough and that i was supposed to grow the already sizable Cc: list even more? Because, regardless of the situation, it's both common courtesy and wise practice to CC relevant driver maintainers, when you touch a driver. And it's just common sense: Greg simply does not know the intimate details of every PCI driver. Nor do I. Nor you. In the case of lpfc here, we have an active driver maintainer, and an up-to-date MAINTAINERS entry. Even if you are too slack to read MAINTAINERS, 'git log' would have given you the same info. Don't pretend there is some benefit here to ignoring the people that best know the driver. I don't buy that; it simply makes no engineering sense whatsoever. what you _STILL_ do not realize is the following: you still attribute the lack of Cc:s to some intention of mine. No, it was not my intention. I was never speaking to intent. I was noting that, having been in the kernel community for years, both of you guys should know that you should always CC a driver author, when touching their driver. Even after this thread, I have not even heard a yes, I agree, I should have CC'd the driver author since they know the most about the driver from either of you, which is quite disappointing. Instead, I get this long thread in response... is just super fragile and does not serve users at all. Even Greg and i got it wrong accidentally. If _we_ get it wrong, who will get it Sure. But... do you agree the CC list should have included the driver author? Do you agree that a mistake was made in this case? Jeff - 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 6/24][RFC] gdth: Use of scsi_eh API and sense accessors
Boaz Harrosh wrote:
Use of new scsi_eh API for setting sense information into
the scsi command.
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
---
drivers/scsi/gdth.c | 47 ++-
drivers/scsi/gdth.h |1 +
2 files changed, 27 insertions(+), 21 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index c825239..9fdd5ef 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -2098,6 +2098,16 @@ static void gdth_putq(gdth_ha_str *ha, Scsi_Cmnd *scp,
unchar priority)
#endif
}
+static void gdth_set_4byte_sense(struct scsi_cmnd *scp, u8 sense_code)
+{
+ u8 sense[4];
+
+ memset(sense, 0, sizeof(sense));
+ sense[0] = 0x70;
+ sense[2] = sense_code;
+ scsi_eh_cpy_sense(scp, sense, sizeof(sense));
+}
IMO, setting 0x70 and 0x72 is highly common, and worthy of some simple
helper functions. See ata_scsi_set_sense() in libata-scsi.c or
stex_set_sense() in stex.c, which is a copy of the former.
Jeff
-
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] pci: pci_enable_device_bars() fix
Andrew Morton wrote: Actually I (and probably others) generally avoid cc'ing mailing lists on patch traffic. I spew out enough script-generated traffic as it is. You pretty much always ensure the driver author gets CC'd, which is exemplary :) Jeff - 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: dmesg spam
James Bottomley wrote: It's here in sr_ioctl.c: Ah, indeed. My grep-fu sucks today. I'm not averse to simply nuking the printk ... it's probably valueless in a modern kernel, since something dbussy is supposed to tell you to put a CD in the drive, not something in the kernel. The reverse... dbussy/HAL is implementing autodetection of media insertion, by polling ad infinitum. Jeff - 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: Integration of SCST in the mainstream Linux kernel
Alan Cox wrote: better. So for example, I personally suspect that ATA-over-ethernet is way better than some crazy SCSI-over-TCP crap, but I'm biased for simple and low-level, and against those crazy SCSI people to begin with. Current ATAoE isn't. It can't support NCQ. A variant that did NCQ and IP would probably trash iSCSI for latency if nothing else. AoE is truly a thing of beauty. It has a two/three page RFC (say no more!). But quite so... AoE is limited to MTU size, which really hurts. Can't really do tagged queueing, etc. iSCSI is way, way too complicated. It's an Internet protocol designed by storage designers, what do you expect? For years I have been hoping that someone will invent a simple protocol (w/ strong auth) that can transit ATA and SCSI commands and responses. Heck, it would be almost trivial if the kernel had a TLS/SSL implementation. Jeff - 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: dmesg spam
Andrew Morton wrote: On Mon, 4 Feb 2008 15:24:55 +0100 Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote: On Sunday 03 February 2008, Andrew Morton wrote: With latest -mm, running fc8 I am getting this in the logs, ^^^ = SCSI/libata cc:ing Jeff once per second. sr0: CDROM not ready. Make sure there is a disc in the drive. sr0: CDROM not ready. Make sure there is a disc in the drive. sr0: CDROM not ready. Make sure there is a disc in the drive. sr0: CDROM not ready. Make sure there is a disc in the drive. sr0: CDROM not ready. Make sure there is a disc in the drive. sr0: CDROM not ready. Make sure there is a disc in the drive. sr0: CDROM not ready. Make sure there is a disc in the drive. sr0: CDROM not ready. Make sure there is a disc in the drive. sr0: CDROM not ready. Make sure there is a disc in the drive. Well.. it's coming out of the kernel. Presumably it's that cdrom polling thing in KDE. James recently made changes to sr_ioctl.c but I've been buried in more terminal regressions than this one. I don't see this in upstream... can you isolate it to a particular git tree? Clearly userland is initiating a once-per-second poll. That is quite normal for 99% of CDROMs, which do not support async notification. But also clearly that message is printk'd way too much in your case. Jeff - 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: Integration of SCST in the mainstream Linux kernel
Linus Torvalds wrote: On Mon, 4 Feb 2008, Jeff Garzik wrote: Well, speaking as a complete nutter who just finished the bare bones of an NFSv4 userland server[1]... it depends on your approach. You definitely are a complete nutter ;) If the userland server is the _only_ one accessing the data[2] -- i.e. the database server model where ls(1) shows a couple multi-gigabyte files or a raw partition -- then it's easy to get all the semantics right, including file handles. You're not racing with local kernel fileserving. It's not really simple in general even then. The problems come with file handles, and two big issues in particular: - handling a reboot (of the server) without impacting the client really does need a look up by file handle operation (which you can do by logging the pathname to filehandle translation, but it certainly gets problematic). - non-Unix-like filesystems don't necessarily have a stable st_ino field (ie it may change over a rename or have no meaning what-so-ever, things like that), and that makes trying to generate a filehandle really interesting for them. Both of these are easily handled if the server is 100% in charge of managing the filesystem _metadata_ and data. That's what I meant by complete control. i.e. it not ext3 or reiserfs or vfat, its a block device or 1000GB file managed by a userland process. Doing it that way gives one a bit more freedom to tune the filesystem format directly. Stable inode numbers and filehandles are just easy as they are with ext3. I'm the filesystem format designer, after all. (run for your lives...) You do wind up having to roll your own dcache in userspace, though. A matter of taste in implementation, but it is not difficult... I've certainly never been accused of having good taste :) I do agree that it's possible - we obviously _did_ have a user-level NFSD for a long while, after all - but it's quite painful if you want to handle things well. Only allowing access through the NFSD certainly helps a lot, but still doesn't make it quite as trivial as you claim ;) Nah, you're thinking about something different: a userland NFSD competing with other userland processes for access to the same files, while the kernel ultimately manages the filesystem metadata. Recipe for races and inequities, and it's good we moved away from that. I'm talking about where a userland process manages the filesystem metadata too. In a filesystem with a million files, ls(1) on the server will only show a single file: [EMAIL PROTECTED] ~]$ ls -l /spare/fileserver-data/ total 70657116 -rw-r--r-- 1 jgarzik jgarzik 1818064825 2007-12-29 06:40 fsimage.1 Of course, I think you can make NFSv4 to use volatile filehandles instead of the traditional long-lived ones, and that really should avoid almost all of the problems with doing a NFSv4 server in user space. However, I'd expect there to be clients that don't do the whole volatile thing, or support the file handle becoming stale only at certain well-defined points (ie after renames, not at random reboot times). Don't get me started on volatile versus persistent filehandles in NFSv4... groan. Jeff - 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: Integration of SCST in the mainstream Linux kernel
Linus Torvalds wrote: On Mon, 4 Feb 2008, Matt Mackall wrote: But ATAoE is boring because it's not IP. Which means no routing, firewalls, tunnels, congestion control, etc. The thing is, that's often an advantage. Not just for performance. NBD and iSCSI (for all its hideous growths) can take advantage of these things. .. and all this could equally well be done by a simple bridging protocol (completely independently of any AoE code). The thing is, iSCSI does things at the wrong level. It *forces* people to use the complex protocols, when it's a known that a lot of people don't want it. Which is why these AoE and FCoE things keep popping up. It's easy to bridge ethernet and add a new layer on top of AoE if you need it. In comparison, it's *impossible* to remove an unnecessary layer from iSCSI. This is why simple and low-level is good. It's always possible to build on top of low-level protocols, while it's generally never possible to simplify overly complex ones. Never discount easy and just works, which is what IP (and TCP) gives you... Sure you can use a bridging protocol and all that jazz, but I wager, to a network admin yet-another-IP-application is easier to evaluate, deploy and manage on existing networks. Jeff - 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 RESEND number 2] libata: eliminate the home grown dma padding in favour of that provided by the block layer
James Bottomley wrote: The aic94xx sequencer has a very finely honed sense of DMA transfers. It's fully automated, and handles both ATA DMA and ATA PIO in the sequencer engine (so all the driver sees is DMA). ditto AHCI, and most other DMA engines It reports both underrun and overrun conditions. For DMA underrun ditto AHCI, and most other DMA engines (device transfers less than expected, it just returns what it has and how much was missing as the residual) for DMA overrun (as in device tried to take more than it was programmed to send on either read or write) for PIO it does seem to zero fill or discard and then simply report task complete with overrun and let libsas sort it out. I suspect for DMA it first tries DMAT before taking other actions, but I'd need a protocol analyser (or the sequencer docs) to be sure. Almost every other DMA engine on the planet besides aic94xx is pretty much the same... you set up an s/g tables, and it reports overrun or underrun via an interrupt + status register bit. It sounds like aic94xx might do more work in the firmware -- that counts as advanced, since some of the DMA engine cleanup clearly occurs in firmware, rather than pushed to kernel software. Nowhere do I see anything about AHCI that is broken. It has standard DMA engine behavior found in storage and non-storage hardware. We handle overruns as error conditions in both SAS and ATA at the moment, but the point is that the ATAPI device is fully happy and quiesced when we do this. That may be the result of aic94xx handling extra FIS's in the firmware, something we cannot depend on for purely silicon-based devices. mvsas, broadsas, ahci, sata_sil24, and others behave similarly... Please don't mistake lack of firmware cleanup as broken hardware. Jeff - 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] pci: pci_enable_device_bars() fix
Ingo Molnar wrote: === --- linux.orig/drivers/scsi/lpfc/lpfc_init.c +++ linux/drivers/scsi/lpfc/lpfc_init.c @@ -1894,7 +1894,7 @@ lpfc_pci_probe_one(struct pci_dev *pdev, uint16_t iotag; int bars = pci_select_bars(pdev, IORESOURCE_MEM); - if (pci_enable_device_bars(pdev, bars)) + if (pci_enable_device_io(pdev)) goto out; Look at the line right above it... AFAICS you want pci_enable_device_mem(), if the mask is selecting IORESOURCE_MEM BARs. Also a CC to linux-scsi and the driver author would be nice, as they are the ones with hardware and can verify. This set of changes seemed like 50% guesswork to me, without consulting the authors :( And unlike many changes, you actually have to know the hardware [or get clues from surrounding code] to make the change. Jeff - 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] pci: pci_enable_device_bars() fix
Ingo Molnar wrote: it would have been totally appropriate for me to just send a mail to lkml with the proper subject line about the breakage. (I might even have decided to stay completely silent about the issue and fix it for my own build, letting you guys figure it out.) Oh come on... You are smart enough to know to at least CC the driver maintainer, the key POC who should be aware of breakage of their driver. That is a standard courtesy. ( And as this was spent from my family's weekend time and i had no time and no interest to dig any further than to figure out the first hop of the change that broke the build, and the parties who initiated that hop. I'm in fact surprised that your and James's answer to my bugreport is hostility. ) I'm sorry you read would be nice as hostility. So i find your suggestion that i should have added more people to the Cc: line unfair on several levels. As I noted, it is an obvious courtesy to CC the driver maintainer, at the very least. _Especially_ when it is a change that requires some knowledge of the hardware, as was this case. This set of changes seemed like 50% guesswork to me, without consulting the authors :( And unlike many changes, you actually have to know the hardware [or get clues from surrounding code] to make the change. you mean the whole set of changes? The whole set of changes, yes, not just yours. but ... i guess next time i'll think twice before sending any bugreports about or related to the SCSI code anywhere, unless they become really annoying. Who needs this hassle? The fact is, each larger subsystem (net, scsi, ata I know) has several vendor contacts and driver maintainers who for various reasons prefer a more focused -- and often less hostile -- mailing list to LKML. I have a hard enough time as it is, trying to convince hardware vendors to work with us, that we are not all assholes. How about respecting the preferences of certain segments of a very large community, even when they differ from your own? We have a community-accepted method of expressing these preferences, the MAINTAINERS file. IMO, standard practice should be: * To or CC: driver maintainer mentioned in MAINTAINERS (if any) * CC: LKML, any list mentioned in MAINTAINERS So, how about CC'ing the targets that have nicely requested to be CC'd? Jeff - 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] pci: pci_enable_device_bars() fix
Ingo Molnar wrote: * Jeff Garzik [EMAIL PROTECTED] wrote: Ingo Molnar wrote: it would have been totally appropriate for me to just send a mail to lkml with the proper subject line about the breakage. (I might even have decided to stay completely silent about the issue and fix it for my own build, letting you guys figure it out.) Oh come on... You are smart enough to know to at least CC the driver maintainer, the key POC who should be aware of breakage of their driver. That is a standard courtesy. is there any particular reason why you cut out the most relevant part of my reply, which happens to answer all your questions AFAICS: Instead i did a search of lkml (based on the function name in the build error) and figured out where the pull request was on lkml: Greg. I replied to that mail, he'll obviously know whom else to Cc from that point on (if anyone). I really didnt want to (nor did i need to) figure out whether this was some general driver level API change that happen kernel-wide, or some SCSI specific change. I simply replied to the pull request whose Cc: line seemed well-populated to me already. I also took a look at the commit itself and did a quick hack in a hurry to keep the tests rolling. It really did not occur to me that i should have added anyone else to the Cc: line, as [EMAIL PROTECTED] was Cc:-ed already so i assumed the interest was from that angle. had you read this portion you'd have realized that i did not search for any owner of the file, i simply searched for the person who introduced the change, and the on-lkml mail where the change was introduced. And therein lies the problem. The original submittor omitted relevant maintainers, you followed that [incorrect] example, and the end result was clear: an obviously wrong change. Thus, the problem is precisely what you stated: you did not bother to search for people who care about that file. and that's all that should be needed, really. Believe me, i hit tons of Hardly. What part of this change requires knowledge of the hardware is difficult to understand? And if you do not have that knowledge, why is it so trying to CC people who actively maintain a driver, and have that knowledge? It's simple common sense to -ask- or at least -notify- in such cases. That the original submittor made the same mistake is no reason to repeat the mistake. bugs all across the kernel, often several bugs a day, and it's hard even for me to figure out who maintains a file and when. (and in Linux there's no ownership of files anyway) So as a general rule i go after changes instead, and that's exactly what i did here too. I do delta/regression QA - i.e. i watch for _changes_ that break the kernel and hence the general 'owner' of a file is often irrelevant - it's the maintainer who introduces a change who matters, and we do lots of cross-maintain merges. Only if i do not manage to identify a change do i try to figure out who maintains a file at that given moment. (But those mails often go into black holes, they get bounced, subscriber-required email lists, etc. etc.) It's also nontrivial to map the files to the MAINTAINERS file, and it's also quite outdated in some portions. So the MAINTAINERS file is the last resort i use. That's a long list of excuses in an attempt to ignore the facts: Fact 1: The driver you modified is actively maintained Fact 2: The driver maintainer has respectfully indicated, through the standard community mechanism, the useful points of contact. Fact 3: The MAINTAINERS entry is correct and up-to-date. Fact 4: Even if you wanted to ignore MAINTAINERS, 'git log' on the relevant file could have told you who are useful parties to CC. It's just common courtesy to CC a driver maintainer, ESPECIALLY when a change requires knowledge of the driver/hardware in question. so i'm still totally befuddled why you think that there was anything particularly wrong or unhelpful about me replying to the specific pull request that introduced a particular breakage into the kernel. Had i mailed to lkml with a terse kernel build broke message with just an URL to a config and the build breakage, you could rightfully have complained that i should have done more to properly direct my bugreport. But this breakage was about a PCI API change, the pull request had a PCI mailing list Cc:-ed, why should i have thought that this needs the attention of any other parties? Because the change required knowledge not only of PCI, but of the hardware in question. As your patch demonstrated. And yes -- the original changes should have been CC'd to interested parties as well. I'm still waiting to hear back from Alan or Bart whether the ATA/IDE changes in that PCI pile actually work... the original changeset even noted that relevant parties had not yet been queried. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message
Re: [patch] pci: pci_enable_device_bars() fix
Ingo Molnar wrote: so please tell me Jeff. If Greg, who is the super-maintainer of your code area, and who deals with your code every day and changes it every minute and hour, simply did not Cc: the SCSI list - how am i, a largely outside party in this matter, supposed to notice that 3 maintainers and 3 mailing lists in the Cc: were somehow not enough and that i was supposed to grow the already sizable Cc: list even more? Because, regardless of the situation, it's both common courtesy and wise practice to CC relevant driver maintainers, when you touch a driver. And it's just common sense: Greg simply does not know the intimate details of every PCI driver. Nor do I. Nor you. In the case of lpfc here, we have an active driver maintainer, and an up-to-date MAINTAINERS entry. Even if you are too slack to read MAINTAINERS, 'git log' would have given you the same info. Don't pretend there is some benefit here to ignoring the people that best know the driver. I don't buy that; it simply makes no engineering sense whatsoever. Jeff - 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 RESEND number 2] libata: eliminate the home grown dma padding in favour of that provided by the block layer
James Bottomley wrote: Could we please get this in ... I thought I mentioned several times that it fixes a fatal oops in both aic94xx and ipr. Tejun has a persistent objection... see other email. Jeff - 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
James Bottomley wrote: The lack of interrupt enable looks potentially fatal... See my comments on this specific issue, in this thread, for the reason why that function isn't used... Jeff - 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
Grant Grundler wrote: 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? This is a common technique in drivers (especially net drivers), eliminating the redundant-across-the-entire-driver argument passed to each register read or write. The result is infinitely more readable and compact. val = mr32(IRQ_STAT); immediately communicates all the necessary information you need. + 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. Like James noted, without public docs, we don't want to be removing any hardware definitions. 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! :) Before this patch, the driver did not work. As I do with all other drivers I write, I write the entire driver from the datasheet before testing anything. Jeff - 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 rc8-mm1] hotfix libata-scsi corruption
James Bottomley wrote:
Actually, I don't think it's a smaller I/O issue. The SMART protocol
specifically mandates that the transfers for SMART READ DATA and SMART
READ LOG shall be 512 bytes). However, the pio transfer routine does
seem to be assuming sector alignment as well, which will be where your
problems are coming from. I think we need to specify sector minimum
alignment for ata (but not atapi, which has its own non sector size pio
routine). How about the attached?
We have to do this for all ATA devices, because they'll likely all
support SMART, and SMART is defined to be a PIO command.
James
---
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 4bb268b..bc5cf6b 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -824,9 +824,6 @@ static void ata_scsi_sdev_config(struct scsi_device *sdev)
* requests.
*/
sdev-max_device_blocked = 1;
-
- /* set the min alignment */
- blk_queue_update_dma_alignment(sdev-request_queue, ATA_DMA_PAD_SZ - 1);
}
static void ata_scsi_dev_config(struct scsi_device *sdev,
@@ -842,7 +839,14 @@ static void ata_scsi_dev_config(struct scsi_device *sdev,
if (dev-class == ATA_DEV_ATAPI) {
struct request_queue *q = sdev-request_queue;
blk_queue_max_hw_segments(q, q-max_hw_segments - 1);
- }
+
+ /* set the min alignment */
+ blk_queue_update_dma_alignment(sdev-request_queue,
+ ATA_DMA_PAD_SZ - 1);
+ } else
+ /* ATA devices must be sector aligned */
+ blk_queue_update_dma_alignment(sdev-request_queue,
+ ATA_SECT_SIZE - 1);
if (dev-flags ATA_DFLAG_AN)
set_bit(SDEV_EVT_MEDIA_CHANGE, sdev-supported_events);
ACK
Unlike ATAPI, ATA is indeed all 512-byte alignment transfers (_not_
sector size, which may or may not be 512 bytes)
Does this apply to libata? libata + jejb dma alignment patch?
What tree...
Jeff
-
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
Comments inline, mostly minor stuff cleaning up the source.
Major problem though: your mailer converted tabs to spaces, so our
automated patch tools won't work on your submission. It usually takes a
few attempts to get your email setup working, such that all the
automated tools used in the Linux community work.
Ke Wei wrote:
+#define MVS_QUEUE_SIZE (30)
to be consistent with the rest of the driver, make this an enum
+#define MVS_PRINTK(_x_, ...) \
+ printk(KERN_NOTICE DRV_NAME : _x_ , ## __VA_ARGS__)
#define mr32(reg) readl(regs + MVS_##reg)
#define mw32(reg,val) writel((val), regs + MVS_##reg)
@@ -47,6 +53,65 @@
readl(regs + MVS_##reg);\
} while (0)
+#define MVS_BIT(x) (1L (x))
+
+#define PORT_TYPE_SATA MVS_BIT(0)
+#define PORT_TYPE_SAS MVS_BIT(1)
to be consistent with the rest of the driver, just open-code 1 n.
This also makes it easier to get the C type correct.
+#define MVS_ID_NOT_MAPPED 0xff
+#define MVS_CHIP_SLOT_SZ (1U mvi-chip-slot_width)
+
+/* 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)
+#define SATA_RECEIVED_PIO_FIS(reg_set) \
+ (mvi-rx_fis + 0x400 + 0x100 * reg_set + 0x20)
+#define UNASSOC_D2H_FIS(id) \
+ (mvi-rx_fis + 0x100 * id)
+
+
+#define READ_PORT_CONFIG_DATA(i) \
+ ((i 3)?mr32(P4_CFG_DATA + (i - 4) * 8):mr32(P0_CFG_DATA + i * 8))
+#define WRITE_PORT_CONFIG_DATA(i,tmp) \
+ {if (i 3)mw32(P4_CFG_DATA + (i - 4) * 8, tmp); \
+ else \
+ mw32(P0_CFG_DATA + i * 8, tmp); }
+#define WRITE_PORT_CONFIG_ADDR(i,tmp) \
+ {if (i 3)mw32(P4_CFG_ADDR + (i - 4) * 8, tmp); \
+ else \
+ mw32(P0_CFG_ADDR + i * 8, tmp); }
+
+#define READ_PORT_PHY_CONTROL(i) \
+ ((i 3)?mr32(P4_SER_CTLSTAT + (i - 4) * 4):mr32(P0_SER_CTLSTAT+i * 4))
+#define WRITE_PORT_PHY_CONTROL(i,tmp) \
+ {if (i 3)mw32(P4_SER_CTLSTAT + (i - 4) * 4, tmp); \
+ else \
+ mw32(P0_SER_CTLSTAT + i * 4, tmp); }
+
+#define READ_PORT_VSR_DATA(i) \
+ ((i 3)?mr32(P4_VSR_DATA + (i - 4) * 8):mr32(P0_VSR_DATA+i*8))
+#define WRITE_PORT_VSR_DATA(i,tmp) \
+ {if (i 3)mw32(P4_VSR_DATA + (i - 4) * 8, tmp); \
+ else \
+ mw32(P0_VSR_DATA + i*8, tmp); }
+#define WRITE_PORT_VSR_ADDR(i,tmp) \
+ {if (i 3)mw32(P4_VSR_ADDR + (i - 4) * 8, tmp); \
+ else \
+ mw32(P0_VSR_ADDR + i * 8, tmp); }
+
+#define READ_PORT_IRQ_STAT(i) \
+ ((i 3)?mr32(P4_INT_STAT + (i - 4) * 8):mr32(P0_INT_STAT + i * 8))
+#define WRITE_PORT_IRQ_STAT(i,tmp) \
+ {if (i 3)mw32(P4_INT_STAT + (i-4) * 8, tmp); \
+ else \
+ mw32(P0_INT_STAT + i * 8, tmp); }
+#define READ_PORT_IRQ_MASK(i) \
+ ((i 3)?mr32(P4_INT_MASK + (i-4) * 8):mr32(P0_INT_MASK+i*8))
+#define WRITE_PORT_IRQ_MASK(i,tmp) \
+ {if (i 3)mw32(P4_INT_MASK + (i-4) * 8, tmp); \
+ else \
+ mw32(P0_INT_MASK + i * 8, tmp); }
make these macros readable, by breaking each C statement into a separate
line
@@ -260,13 +368,33 @@ enum hw_register_bits {
PHYEV_RDY_CH= (1U 0),/* phy ready changed state */
/* MVS_PCS */
+ PCS_EN_SATA_REG = (16), /* Enable SATA Register Set*/
+ PCS_EN_PORT_XMT_START = (12), /* Enable Port Transmit*/
+ PCS_EN_PORT_XMT_START2 = (8), /* For 6480*/
PCS_SATA_RETRY = (1U 8),/* retry ctl FIS on R_ERR */
PCS_RSP_RX_EN = (1U 7),/* raw response rx */
PCS_SELF_CLEAR = (1U 5),/* self-clearing int mode */
PCS_FIS_RX_EN = (1U 4),/* FIS rx enable */
PCS_CMD_STOP_ERR= (1U 3),/* cmd stop-on-err enable */
- PCS_CMD_RST = (1U 2),/* reset cmd issue */
+ PCS_CMD_RST = (1U 1),/* reset cmd issue */
PCS_CMD_EN = (1U 0),/* enable cmd issue */
+
+ /*Port n Attached Device Info*/
+ PORT_DEV_SSP_TRGT = (1U 19),
+ PORT_DEV_SMP_TRGT = (1U 18),
+ PORT_DEV_STP_TRGT = (1U 17),
+ PORT_DEV_SSP_INIT = (1U 11),
+ PORT_DEV_SMP_INIT = (1U 10),
+ PORT_DEV_STP_INIT = (1U 9),
+ PORT_PHY_ID_MASK= (0xFFU 24),
+ PORT_DEV_TRGT_MASK = (0x7U 17),
+ PORT_DEV_INIT_MASK = (0x7U 9),
+ PORT_DEV_TYPE_MASK = (0x7U 0),
+
+ /*Port n PHY Status*/
+ PHY_RDY = (1U 2),
+ PHY_DW_SYNC = (1U 1),
+ PHY_OOB_DTCTD = (1U 0),
to be consistent, add spaces after /* and before */
struct mvs_port {
struct asd_sas_port sas_port;
+ u8 taskfileset;
};
struct mvs_phy {
struct mvs_port *port;
struct asd_sas_phy sas_phy;
+
Re: Actually using the sg table/chain code
James Bottomley wrote:
if (BLK_DEF_MAX_SECTORS max_sectors)
q-max_hw_sectors = q-max_sectors = max_sectors;
else {
q-max_sectors = BLK_DEF_MAX_SECTORS;
q-max_hw_sectors = max_sectors;
}
}
So it imposes a maximum possible setting of BLK_DEF_MAX_SECTORS which is
defined in blkdev.h to 1024, thus also forcing the queue down to
128 scatterlist entries.
Once I raised this limit as well, I was able to transfer over 128
scatterlist elements during benchmark test runs of normal I/O (actually
kernel compiles seem best, they hit 608 scatterlist entries).
So my question, is there any reason not to raise this limit to something
large (like 65536) or even eliminate it altogether?
ISTR a thread long ago, perhaps including Andrea A (as well as Jens),
where 1024 sectors was arrived upon as a reasonable balance between
tying up gobs of VM memory on a single command (multiplied, then, across
N commands), and getting decent per-command throughput.
Jens probably recalls better than I... but I'm pretty sure that the
1024 limit played into being nice with the VM somehow.
Jeff
-
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: sata_nv does not function in kernel 2.6.20.21
Matthew Hall wrote: ACPI: PCI Interrupt Link [LT3D] enabled at IRQ 46 ACPI: PCI Interrupt :80:07.0[A] - Link [LT3D] - GSI 46 (level, low) - IRQ 46 sata_nv :80:07.0: Using ADMA mode PCI: Unable to reserve mem region #6:[EMAIL PROTECTED] for device :80:07.0 ACPI: PCI interrupt for device :80:07.0 disabled sata_nv: probe of :80:07.0 failed with error -16 ACPI: PCI Interrupt Link [LT2E] enabled at IRQ 45 ACPI: PCI Interrupt :80:08.0[A] - Link [LT2E] - GSI 45 (level, low) - IRQ 45 sata_nv :80:08.0: Using ADMA mode PCI: Unable to reserve mem region #6:[EMAIL PROTECTED] for device :80:08.0 ACPI: PCI interrupt for device :80:08.0 disabled sata_nv: probe of :80:08.0 failed with error -16 Error -16 is EBUSY, which causes the driver load to fail due to the Unable to reserve mem region message. This means that the sata_nv driver needed to use PCI BAR 6, but was unable to for some reason. Given that sata_nv uses devres like other libata drivers, IMO the likely cause is outside the ATA subsystem (PCI? ACPI?). One workaround to try is setting sata_nv module option 'adma' to zero (0), in the hopes that it ignores that final region and work anyway. Jeff - 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: AHCI finds disks; no /dev/sd inodes bound?
Matthew Wilcox wrote: On Wed, Jan 09, 2008 at 12:36:26PM -0800, Jon Watte wrote: Stefan Richter wrote: Those systems (servers) typically have enough memory to tolerate a few extra KB of code without problems. In fact most PCs these days have. It would be a stupid solution nevertheless. (We also don't select EXT3.) Not selecting EXT3 is a little more understandable, because there are many options -- cramfs, xfs, reiserfs, etc, depending on target. However, the number of people who DO want SATA support but DO NOT want SD block device support is... uh.. anyone? Solving the problem bigger and better, by factoring SD into a mid-level menu, and maybe calling it something non-SCSI, would probably be even better. And even more work. OK, how about this? config BLK_DEV_ATA_SD tristate ATA disc support select BLK_DEV_SD config BLK_DEV_ATA_SR tristate ATA CDROM support select BLK_DEV_SR Help text left as an exercise for the reader. Speaking as one who strongly objects to CONFIG_ATA unconditionally selecting SD or SR... I think you are on the right track. IMO a more clean and future-proof solution would be config ATA_PROT_ATA select SD config ATA_PROT_ATAPI (or ATAPI_PROT) select SR But that's just an example. Maybe the choices could be ATA_DISK and ATA_EVERYTHING_ELSE. :) The main points are * its not just CDROM support, but floppy/tape/etc. too for ATAPI * do not include sd or sr in the config name, it should be more generic, because SCSI will eventually be an optional module for libata. When libata talks to straight blkdev, we don't want this same problem to resurface! Jeff (very tired, so pardon any incoherence) - 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 (draft)
Ke Wei wrote: The 88SE6440 driver : The driver is based on bare code from Jeff Garzik. And it can work under linux kernel 2.6.23. By far, Can discover and find SAS HDD, but SATA is currently unsupported. Command queue depth can be above 1. Most error handling, and some phy handling code is notably missing. contains the following updates: --- mvsas_orig.c2007-12-06 19:21:32.0 -0500 +++ mvsas.c 2008-01-09 04:53:14.0 -0500 Fantastic! I'm delighted to see this is moving, and thanks much for getting the driver to that critical it works milestone. We should note for the linux-scsi audience and potential testers that the base driver upon which this is based is available on the sas branch of git://git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git I will give some substantive comments tomorrow (just got back from long trip). Two quick suggestions: 1) To make it easier for people to review and test the driver, I would suggest posting a diff against 2.6.24-rc7 (or 2.6.23), ignoring my original code. Thus, it would result in a patch 2) In future patches, include a Signed-off-by: line when you are ready for your patch to be included in the kernel. Thanks! Jeff - 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 (draft)
Jeff Garzik wrote: 1) To make it easier for people to review and test the driver, I would suggest posting a diff against 2.6.24-rc7 (or 2.6.23), ignoring my original code. Thus, it would result in a patch Er, that sentence was incomplete. Continuing... Thus it would result in a patch that adds a new file drivers/scsi/mvsas.c to the 2.6.24-rc7 kernel, and modifies drivers/scsi/Makefile and drivers/scsi/Kconfig to enable this new driver. That is the format that developers and users are most familiar with, when reviewing (and testing) a new driver. But of course this is a draft, so these guidelines are certainly loose... Jeff - 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] libata: eliminate the home grown dma padding in favour of that provided by the block layer
James Bottomley wrote: ATA requires that all DMA transfers begin and end on word boundaries. Because of this, a large amount of machinery grew up in ide to adjust scatterlists on this basis. However, as of 2.5, the block layer has a dma_alignment variable which ensures both the beginning and length of a DMA transfer are aligned on the dma_alignment boundary. Although the block layer does adjust the beginning of the transfer to ensure this happens, it doesn't actually adjust the length, it merely makes sure that space is allocated for transfers beyond the declared length. The upshot of this is that scatterlists may be padded to any size between the actual length and the length adjusted to the dma_alignment safely knowing that memory is allocated in this region. Right at the moment, SCSI takes the default dma_aligment which is on a 512 byte boundary. Note that this aligment only applies to transfers coming in from user space. However, since all kernel allocations are automatically aligned on a minimum of 32 byte boundaries, it is safe to adjust them in this manner as well. Signed-off-by: James Bottomley [EMAIL PROTECTED] --- This also fixes a current panic in libsas with SATAPI devices. I was trying to trace a bad interaction between the libata padding and the new sglist code which was the root cause, and ended up concluding that the whole libata padding thing was redundant. In a future improvement, I think we can relax SCSI dma_alignemnt (it's causing almost every user space command to be copied instead of directly passed through) and allow devices and transports to build up their own requirements instead. Initial read: ACK, with thanks. I'll queue this into libata#upstream, unless you have other suggestions. This is definitely the sort of thing that low-level drivers (and their helper libs, e.g. libata) should not need to do. Jeff - 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] libsas: Don't issue commands to devices that have been hot-removed.
Darrick J. Wong wrote: Hrm... does this patch help? You'll get a bunch of ATA/SAS disk errors printed to the screen if you yank the disk, but at least libsas won't get stuck waiting for the cache-flush commands to time out. --- sd will get hung up issuing commands to flush write cache if a SAS device is unplugged without warning. Change libsas to reject commands to domain devices that have already gone away. Signed-off-by: Darrick J. Wong [EMAIL PROTECTED] --- drivers/scsi/libsas/sas_ata.c |4 drivers/scsi/libsas/sas_expander.c |3 +++ drivers/scsi/libsas/sas_port.c |2 ++ drivers/scsi/libsas/sas_scsi_host.c |7 +++ include/scsi/libsas.h |1 + 5 files changed, 17 insertions(+), 0 deletions(-) Seems sane... diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c index 0829b55..f5e5213 100644 --- a/drivers/scsi/libsas/sas_ata.c +++ b/drivers/scsi/libsas/sas_ata.c @@ -161,6 +161,10 @@ static unsigned int sas_ata_qc_issue(struct ata_queued_cmd *qc) unsigned int num = 0; unsigned int xfer = 0; + /* If the device fell off, no sense in issuing commands */ + if (dev-gone) + return AC_ERR_SYSTEM; + task = sas_alloc_task(GFP_ATOMIC); if (!task) return AC_ERR_SYSTEM; As an aside, issues like this really really imply a need to move libsas away from the old libata EH stuff (like brking did with ipr, in patches). Jeff - 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] libsas: Don't issue commands to devices that have been hot-removed.
Darrick J. Wong wrote: On Tue, Dec 04, 2007 at 05:48:33PM -0500, Jeff Garzik wrote: As an aside, issues like this really really imply a need to move libsas away from the old libata EH stuff (like brking did with ipr, in patches). Hm... does the new libata EH handle the case of device was unplugged, don't bother trying to send any more commands? In general, I agree that sas-ata should adopt the new EH. Unfortunately, I believe the old way of sas-ata configuring ATA ports is somehow not compatible with the new EH stuff and causes a crash during the device probe with my patch to move sas-ata to the new EH. If I apply the patch that migrates sas-ata to use brking's latest ata-sas configuration mechanism (the one that creates real ata_hosts), I see (a) lots and lots of ATA hosts getting created (one per ATA port; possibly undesirable if you've a SAS topology with a lot of SATA disks) and (b) NCQ disks don't seem to work if you unplug the disk and plug it back in (unless NCQ is disabled entirely). Jeff, by any chance have you tried plugging SATA devices into your SAS controllers? aic94xx yes, bcm and mv no. Will take a look though... James Bottomley wondered if it would be easier to have sas-ata call only into the parts of libata that convert SCSI commands to ATA taskfiles, though I'm unsure how many wormy cans that would open. You want more than that. You want to make sure libata is the place for knowledge about weird ATA devices, SATA quirks, ATA device error handling (to be distinguished from ATA /link/ error handling), and other areas. That stuff shouldn't be duplicated, and you /really/ do not want to re-learn all those lessons all over again ;-) Jeff - 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: aic94xx or libsas crash on X7DB3 supermicro with enclosure and sata drives
Darrick J. Wong wrote: On Mon, Dec 03, 2007 at 05:09:54PM +0100, Krzysztof B??aszkowski wrote: I noticed also another failure when i removed a drive. The event was not notified by anything (ie the block device and corresponding sg were registered) so i run dd on this truly virtual drive. dd reached D state (as well as scsi_wq) . i think it shouldn't happen no matter it was AIC failure or LSI expander failure. It's wireless! ;) Seriously, though, it's a good idea to tell the kernel that you're about to unplug a disk before actually doing it: echo 1 /sys/block/sdX/device/delete This way, the kernel can tell the disk to flush its caches long before power actually gets removed. Otherwise, the device removal code can get hung up just like you observed, and whatever's in the write cache may or may not actually get written to the media. What you say is quite true about write cache -- you can clearly lose some data by hot-unplugging a device. And there's nothing we can do about that. But what do you mean by device removal code can get hung up? That sounds like a bug we should fix. Jeff - 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: [RFC 0/3] [SCSI/libata] libata EH conversion for ipr SAS
Brian King wrote: The following three patches convert ipr to use the new libata EH APIs. In the process of doing this, I first looked into implementing this in a similar manner to how libata SAS is done today, which is hooking into target_alloc/target_destroy to allocate/delete sata ports. While I was able to get this working after writing my own eh_strategy_handler, I was doubtful this was the best long term solution. One problem with this implementation I didn't solve was the fact that libata now invokes EH for each and every error received. For some devices, such as optical devices, each not ready response received during a media reload would result in all the attached SAS devices getting quiesced as well. My second approach is the attached patch set. In this series I have created a new libata API which can be used by SAS LLDDs. It introduces an ata_sas_rphy device object which is created/destroyed by the following API: ata_sas_rphy_alloc ata_sas_rphy_add ata_sas_rphy_delete When using this API in ipr, I made ipr's scsi_host the parent device of the SATA rphy. The SATA rphy is then the parent of the allocated scsi_hosts. This means that each SATA rphy in the SAS topology will have its own scsi_host, making SAS *much* more like all the SATA LLDDs in how it uses libata. The only issue I ran into with this implementation is that since each SATA port has its own scsi_host, the adapter cannot rely on scsi core to manage any LLDD or adapter imposed queue depth. To solve this I added some code to ipr. Longer term, block layer queue groups might be another way to do this. I'm still polishing this up, but it is up and running and seems to work with what testing I've done so far. I'm generally happy with this, though I am curious what Tejun thinks as well. Once everybody is happy, I think we should collect libata ACKs and then push this via the SCSI maintainership route. That would libsas work in parallel, with perhaps in situ tweaks and fixes as the implementation is fleshed out. Jeff - 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] SCSI: Fix bugs and canonicalize irq handler usage in NCR5380 drivers
* Always pass the same value to free_irq() that we pass to
request_irq(). This fixes several bugs.
* Always call NCR5380_intr() with 'irq' and 'dev_id' arguments.
Note, scsi_falcon_intr() is the only case now where dev_id is not the
scsi_host.
* Always pass Scsi_Host to request_irq(). For most cases, the drivers
already did so, and I merely neated the source code line. In other
cases, either NULL or a non-sensical value was passed, verified to be
unused, then changed to be Scsi_Host in anticipation of the future.
In addition to the bugs fixes, this change makes the interface usage
consistent, which in turn enables the possibility of directly
referencing Scsi_Host from all NCR5380_intr() invocations.
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
---
Resend #1. Originally sent on Oct 26.
Please send upstream for 2.6.24-rc in some form, this fixes obvious
free_irq() problems that prevent irq release.
drivers/scsi/atari_scsi.c| 10 +-
drivers/scsi/dtc.c |5 +++--
drivers/scsi/g_NCR5380.c |5 +++--
drivers/scsi/mac_scsi.c |4 ++--
drivers/scsi/pas16.c |5 +++--
drivers/scsi/sun3_scsi.c |4 ++--
drivers/scsi/sun3_scsi_vme.c |4 ++--
drivers/scsi/t128.c |5 +++--
8 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/drivers/scsi/atari_scsi.c b/drivers/scsi/atari_scsi.c
index 6f8403b..f5732d8 100644
--- a/drivers/scsi/atari_scsi.c
+++ b/drivers/scsi/atari_scsi.c
@@ -393,7 +393,7 @@ static irqreturn_t scsi_tt_intr(int irq, void *dummy)
#endif /* REAL_DMA */
- NCR5380_intr(0, 0);
+ NCR5380_intr(irq, dummy);
#if 0
/* To be sure the int is not masked */
@@ -458,7 +458,7 @@ static irqreturn_t scsi_falcon_intr(int irq, void *dummy)
#endif /* REAL_DMA */
- NCR5380_intr(0, 0);
+ NCR5380_intr(irq, dummy);
return IRQ_HANDLED;
}
@@ -684,7 +684,7 @@ int atari_scsi_detect(struct scsi_host_template *host)
* interrupt after having cleared the pending flag for the DMA
* interrupt. */
if (request_irq(IRQ_TT_MFP_SCSI, scsi_tt_intr, IRQ_TYPE_SLOW,
-SCSI NCR5380, scsi_tt_intr)) {
+SCSI NCR5380, instance)) {
printk(KERN_ERR atari_scsi_detect: cannot allocate irq
%d, aborting,IRQ_TT_MFP_SCSI);
scsi_unregister(atari_scsi_host);
atari_stram_free(atari_dma_buffer);
@@ -701,7 +701,7 @@ int atari_scsi_detect(struct scsi_host_template *host)
IRQ_TYPE_PRIO, Hades DMA emulator,
hades_dma_emulator)) {
printk(KERN_ERR atari_scsi_detect: cannot
allocate irq %d, aborting (MACH_IS_HADES),IRQ_AUTO_2);
- free_irq(IRQ_TT_MFP_SCSI, scsi_tt_intr);
+ free_irq(IRQ_TT_MFP_SCSI, instance);
scsi_unregister(atari_scsi_host);
atari_stram_free(atari_dma_buffer);
atari_dma_buffer = 0;
@@ -761,7 +761,7 @@ int atari_scsi_detect(struct scsi_host_template *host)
int atari_scsi_release(struct Scsi_Host *sh)
{
if (IS_A_TT())
- free_irq(IRQ_TT_MFP_SCSI, scsi_tt_intr);
+ free_irq(IRQ_TT_MFP_SCSI, sh);
if (atari_dma_buffer)
atari_stram_free(atari_dma_buffer);
return 1;
diff --git a/drivers/scsi/dtc.c b/drivers/scsi/dtc.c
index 2596165..c2677ba 100644
--- a/drivers/scsi/dtc.c
+++ b/drivers/scsi/dtc.c
@@ -277,7 +277,8 @@ found:
/* With interrupts enabled, it will sometimes hang when doing
heavy
* reads. So better not enable them until I finger it out. */
if (instance-irq != SCSI_IRQ_NONE)
- if (request_irq(instance-irq, dtc_intr, IRQF_DISABLED,
dtc, instance)) {
+ if (request_irq(instance-irq, dtc_intr, IRQF_DISABLED,
+ dtc, instance)) {
printk(KERN_ERR scsi%d : IRQ%d not free,
interrupts disabled\n, instance-host_no, instance-irq);
instance-irq = SCSI_IRQ_NONE;
}
@@ -459,7 +460,7 @@ static int dtc_release(struct Scsi_Host *shost)
NCR5380_local_declare();
NCR5380_setup(shost);
if (shost-irq)
- free_irq(shost-irq, NULL);
+ free_irq(shost-irq, shost);
NCR5380_exit(shost);
if (shost-io_port shost-n_io_port)
release_region(shost-io_port, shost-n_io_port);
diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index 607336f..75585a5 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -460,7 +460,8 @@ int __init generic_NCR5380_detect(struct scsi_host_template
Re: [PATCH 1/2] libsas: Convert sas_proto users to sas_protocol
Darrick J. Wong wrote: sparse complains about the mixing of enums in libsas. Since the underlying numeric values of both enums are the same, combine them to get rid of the warning. Signed-off-by: Darrick J. Wong [EMAIL PROTECTED] --- drivers/scsi/aic94xx/aic94xx_dev.c |6 +++--- drivers/scsi/aic94xx/aic94xx_dump.c |4 ++-- drivers/scsi/aic94xx/aic94xx_hwi.c |2 +- drivers/scsi/aic94xx/aic94xx_scb.c |6 +++--- drivers/scsi/aic94xx/aic94xx_task.c | 30 +++--- drivers/scsi/aic94xx/aic94xx_tmf.c | 12 ++-- drivers/scsi/libsas/sas_discover.c |2 +- drivers/scsi/libsas/sas_expander.c |6 +++--- drivers/scsi/libsas/sas_internal.h |2 +- include/scsi/libsas.h | 18 +- include/scsi/sas.h | 13 ++--- include/scsi/scsi_transport_sas.h |8 +--- 12 files changed, 51 insertions(+), 58 deletions(-) ACK patches 1-2 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] Add and use media change notification
Linus Torvalds wrote: On Sun, 4 Nov 2007, Jeff Garzik wrote: The end to CD-ROM polling... newer SATA ATAPI hardware will emit 'asynchronous notification' events when media is changed. This adds support. I *really* didn't want to pull this. Not only is it after the -rc1 period, but I also think you pushed this ina really offensive manner, and I don't like how you and James have made this whole thing personal. You guys need to sort it out, and there is no way you can blame James for all your troubles, since I've heard the same kind of complaints about every single maintainer out there (including you) about some driver or other infrastructure issue. So I'm unhappy about pulling this. That said, I did finally decide to just pull it. Partly because the concept apparently has been in -mm for a while anyway (even if the final patch has not - but the patch itself isn't that large, I'd worry more about thngs like certain hardware simply not doing things right), but mostly because I hate it when others hold up driver features, and I decided that in this case this really is something that is better done earlier rather than later, to get exposure as soon as possible. But I really think you need to lay off James, and help him rather than make every single complaint a big flame-war! Please, Jeff? Fair enough... Jeff - 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
[git patches] Add and use media change notification
The end to CD-ROM polling... newer SATA ATAPI hardware will emit
'asynchronous notification' events when media is changed. This adds
support.
The libata change /using/ the infrastructure is tiny, encompassed
entirely in the first file patched, drivers/ata/libata-scsi.c.
Been working since August (and in -mm), but has gone through various
revisions to try and make SCSI maintainer happy. Every step of the way,
it was upstream-mergeable in my opinion.
Everyone agrees this should go upstream; indeed, the key change from
me [SCSI] add asynchronous event notification API is even found
in jejb/scsi-misc-2.6.git (db0e2c76011f25f22f71e9c0d69ce95d15f21e8a).
There are minor disagreements with regards to userspace API, with a
more complex solve all your problems change currently being discussed,
blocked behind sysfs changes that don't exist yet (and are still being
discussed).
I am ready and waiting to address further feedback -- each feedback
I received so far was addressed in under 24 hours -- but let us not
delay this anymore.
Changes can and should be iterated upstream... that is what the bug fix
process is for... getting final feedback and polish on working, testing
changes that have been waiting in the wings for months.
Please pull from 'an' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git an
to receive the following updates:
drivers/ata/libata-scsi.c |8 ++-
drivers/scsi/scsi_lib.c| 136
drivers/scsi/scsi_scan.c |3 +
drivers/scsi/scsi_sysfs.c | 47 +++
include/scsi/scsi_device.h | 25
5 files changed, 216 insertions(+), 3 deletions(-)
commit f26792d5c63344e14540ced4b19deb29e360bb8d
Author: Jeff Garzik [EMAIL PROTECTED]
Date: Mon Oct 29 17:18:39 2007 -0400
[libata] Utilize new SCSI event infrastructure
An end to CD-ROM polling (if you have a device that supports AN)...
hooray!
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
commit a341cd0f6a0fde1f85fec9aa8f81f824ea4a3f92
Author: Jeff Garzik [EMAIL PROTECTED]
Date: Mon Oct 29 17:15:22 2007 -0400
SCSI: add asynchronous event notification API
Originally based on a patch by Kristen Carlson Accardi @ Intel.
Copious input from James Bottomley.
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 245057d..94144ed 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -841,6 +841,9 @@ static void ata_scsi_dev_config(struct scsi_device *sdev,
blk_queue_max_hw_segments(q, q-max_hw_segments - 1);
}
+ if (dev-flags ATA_DFLAG_AN)
+ set_bit(SDEV_EVT_MEDIA_CHANGE, sdev-supported_events);
+
if (dev-flags ATA_DFLAG_NCQ) {
int depth;
@@ -3296,10 +3299,9 @@ static void ata_scsi_handle_link_detach(struct ata_link
*link)
*/
void ata_scsi_media_change_notify(struct ata_device *dev)
{
-#ifdef OTHER_AN_PATCHES_HAVE_BEEN_APPLIED
if (dev-sdev)
- scsi_device_event_notify(dev-sdev, SDEV_MEDIA_CHANGE);
-#endif
+ sdev_evt_send_simple(dev-sdev, SDEV_EVT_MEDIA_CHANGE,
+GFP_ATOMIC);
}
/**
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 88de771..0e81e4c 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -2115,6 +2115,142 @@ scsi_device_set_state(struct scsi_device *sdev, enum
scsi_device_state state)
EXPORT_SYMBOL(scsi_device_set_state);
/**
+ * sdev_evt_emit - emit a single SCSI device uevent
+ * @sdev: associated SCSI device
+ * @evt: event to emit
+ *
+ * Send a single uevent (scsi_event) to the associated scsi_device.
+ */
+static void scsi_evt_emit(struct scsi_device *sdev, struct scsi_event *evt)
+{
+ int idx = 0;
+ char *envp[3];
+
+ switch (evt-evt_type) {
+ case SDEV_EVT_MEDIA_CHANGE:
+ envp[idx++] = SDEV_MEDIA_CHANGE=1;
+ break;
+
+ default:
+ /* do nothing */
+ break;
+ }
+
+ envp[idx++] = NULL;
+
+ kobject_uevent_env(sdev-sdev_gendev.kobj, KOBJ_CHANGE, envp);
+}
+
+/**
+ * sdev_evt_thread - send a uevent for each scsi event
+ * @work: work struct for scsi_device
+ *
+ * Dispatch queued events to their associated scsi_device kobjects
+ * as uevents.
+ */
+void scsi_evt_thread(struct work_struct *work)
+{
+ struct scsi_device *sdev;
+ LIST_HEAD(event_list);
+
+ sdev = container_of(work, struct scsi_device, event_work);
+
+ while (1) {
+ struct scsi_event *evt;
+ struct list_head *this, *tmp;
+ unsigned long flags;
+
+ spin_lock_irqsave(sdev-list_lock, flags);
+ list_splice_init(sdev-event_list, event_list);
+ spin_unlock_irqrestore(sdev-list_lock, flags
Re: [PATCH] scsi menu: move RAID transport class to Transports menu
Matthew Wilcox wrote: On Sun, Nov 04, 2007 at 10:44:23AM -0800, Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Move RAID_ATTRS into the SCSI Transports sub-menu. Fix some help text whitespace in Transports. Ummm ... RAID isn't really a SCSI property, is it? How about putting it in block/Kconfig? Agreed. IMO would be nice to emphasize that the RAID transport attributes are not necessarily SCSI-specific. Jeff - 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 v2] block: move RAID transport class to BLOCK menu
Randy Dunlap wrote: Jeff Garzik wrote: Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Move RAID class configuration to the BLOCK menu since it is not SCSI-specific. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- block/Kconfig|5 + drivers/scsi/Kconfig |7 --- 2 files changed, 5 insertions(+), 7 deletions(-) ACK Though IMO we should move the code, too. OK, I'll do that and resend. Well, I'm only one voice... might wait to see if others agree first :) Jeff - 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
