Re: [PATCH v3 0/4] scsi: ufs ums-* esp_scsi: fix module reference counting
On Sun, Jan 11, 2015 at 10:50:02PM +0900, Akinobu Mita wrote: While accessing a scsi_device, the use count of the underlying LLDD module is incremented. The module reference is retrieved through .module field of struct scsi_host_template. This mapping between scsi_device and underlying LLDD module works well except ufs, unusual usb storage drivers, and sub drivers for esp_scsi. These drivers consist with core driver and actual LLDDs, and scsi_host_template is defined in the core driver. So the actual LLDDs can be unloaded even if the scsi_device is being accessed. This patch series first adds ability to adjust module reference for scsi host by LLDDs and then fixes actual LLDDs by adjusting module reference after scsi host allocation. Why don't we move the module into the Scsi_Host only, and use the same macro that passes THIS_MODULE trick you are using in the sub drivers? That seems to be a fairly common scheme in other subsystems as well. -- 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: Allow retry on UNIT_ATTENTION media changed if not CDROM drive
On Thu, Jan 08, 2015 at 05:33:53PM -0500, Al Cooper wrote: Previous commit dfcf7775815504d13a1d273073810058caf84b9d added a workaround for CD-ROM drives that were out of spec. This is causing scsi_check_sense() to return an error instead of NEEDS_RETRY on some USB thumb drives that return UNIT_ATTENTION Media Changed (ASC/ASCQ 28/00) after resuming from S3. This can cause mounted thumb drives to fail on the next access to the filesystem after S3 resume. This is masked on many systems because udev/dbus event handlers open the /dev/sd* device before filesystem access and the open always retries the UNIT_ATTENTION. The fix is to limit the original workaround to CDROM drives. Even better would be quirk for the deice mishandlign the UAs, but I suspect that's too late now.. -- 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 4/4] scsi: esp_scsi: adjust module reference for scsi host
On 01/11/2015 02:50 PM, Akinobu Mita wrote: While accessing a scsi device on host adapter supported by sub driver for the ESP chip (mac_esp, am53c974, sun_esp, jazz_esp, sun3x_esp), the module reference count is not incremented. Because these drivers allocate scsi hosts with scsi_esp_template defined in ESP SCSI driver core module. So these drivers always can be unloaded. This fixes it by passing correct module reference to newly introduced scsi_esp_host_alloc() so that .module field in struct Scsi_Host can be adjusted. Signed-off-by: Akinobu Mita akinobu.m...@gmail.com Cc: David S. Miller da...@davemloft.net Cc: Hannes Reinecke h...@suse.de Cc: Christoph Hellwig h...@lst.de Cc: James E.J. Bottomley jbottom...@parallels.com Cc: linux-scsi@vger.kernel.org --- New patch from v3 Reviewed-by: Hannes Reinecke h...@suse.de Cheers, Hannes -- Dr. Hannes ReineckezSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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 1/4] scsi: add ability to adjust module reference for scsi host
On 01/11/2015 02:50 PM, Akinobu Mita wrote: While accessing a scsi_device, the use count of the underlying LLDD module is incremented. The module reference is retrieved through .module field of struct scsi_host_template. This mapping between scsi_device and underlying LLDD module works well except ufs, unusual usb storage drivers, and sub drivers for esp_scsi. These drivers consist with core driver and actual LLDDs, and scsi_host_template is defined in the core driver. So the actual LLDDs can be unloaded even if the scsi_device is being accessed. This adds .module field in struct Scsi_Host and let the module reference be retrieved though it instead of struct scsi_host_template. This allows the actual LLDDs adjust module reference. Signed-off-by: Akinobu Mita akinobu.m...@gmail.com Cc: Vinayak Holikatti vinholika...@gmail.com Cc: Dolev Raviv dra...@codeaurora.org Cc: Sujit Reddy Thumma sthu...@codeaurora.org Cc: Subhash Jadavani subha...@codeaurora.org Cc: Christoph Hellwig h...@lst.de Cc: James E.J. Bottomley jbottom...@parallels.com Cc: Matthew Dharm mdharm-...@one-eyed-alien.net Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Alan Stern st...@rowland.harvard.edu Cc: linux-...@vger.kernel.org Cc: usb-stor...@lists.one-eyed-alien.net Cc: linux-scsi@vger.kernel.org Reviewed-by: Hannes Reinecke h...@suse.de Cheers, Hannes -- Dr. Hannes ReineckezSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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: [Lsf-pc] [LSF/MM TOPIC] iSCSI MQ adoption via MCS discussion
On 01/11/15 10:40, Sagi Grimberg wrote: I would say there is no need for specific coordination from iSCSI PoV. This is exactly what flow steering is designed for. As I see it, in order to get the TX/RX to match rings, the user can attach 5-tuple rules (using standard ethtool) to steer packets to the right rings. Hello Sagi, Can the 5-tuple rules be chosen such that it is guaranteed that the sockets used to implement per-CPU queues are spread evenly over MSI-X completion vectors ? If not, would it help to add a socket option to the Linux network stack that allows to select the TX ring explicitly, just like ib_create_cq() in the Linux RDMA stack allows to select a completion vector explicitly ? My concerns are as follows: - If the number of queues exceeds the number of MSI-X vectors then I expect that it will be much easier to guarantee even spreading by selecting tx queues explicitly instead of relying on a hashing scheme. - On multi-socket systems it is important to process completion interrupts on the CPU socket from where the I/O was initiated. I'm not sure it is possible to guarantee this when using a hashing algorithm to select the TX ring. Bart. -- 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 9/9] scsi_error: do not display kernel pointer in message logs
On 01/12/2015 02:12 PM, Ewan Milne wrote: On Thu, 2015-01-08 at 07:43 +0100, Hannes Reinecke wrote: It is not good practice to display the kernel pointer in any message logs, and it doesn't display any additional information. And as we know have block-layer assigned tags we can use them to differentiate the messages. So remove any pointer references from the displayed messages. I'd actually be sad to see this go -- I have found it useful in the past when debugging crash dumps from customer sites to be able to look in the kernel messages and see that a particular scsi_cmnd had been aborted just before the crash (and then later completed). But that's precisely why we've prefixed the scmd messages with the tag number; with that you'll be able to extract the same information. And now that hch separated out the block layer tagging from SCSI-2 TCQ we should have the tag number available for any command, not just those from drivers which use TCQ. Let me know if that isn't the case; this patch indeed only makes sense if the tag number is always available. Cheers, Hannes -- Dr. Hannes ReineckezSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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 9/9] scsi_error: do not display kernel pointer in message logs
On Mon, 2015-01-12 at 14:29 +0100, Hannes Reinecke wrote: On 01/12/2015 02:12 PM, Ewan Milne wrote: On Thu, 2015-01-08 at 07:43 +0100, Hannes Reinecke wrote: It is not good practice to display the kernel pointer in any message logs, and it doesn't display any additional information. And as we know have block-layer assigned tags we can use them to differentiate the messages. So remove any pointer references from the displayed messages. I'd actually be sad to see this go -- I have found it useful in the past when debugging crash dumps from customer sites to be able to look in the kernel messages and see that a particular scsi_cmnd had been aborted just before the crash (and then later completed). But that's precisely why we've prefixed the scmd messages with the tag number; with that you'll be able to extract the same information. And now that hch separated out the block layer tagging from SCSI-2 TCQ we should have the tag number available for any command, not just those from drivers which use TCQ. Let me know if that isn't the case; this patch indeed only makes sense if the tag number is always available. Ah, yes, I think you may be right -- I ran into this when debugging some double completion panics, so my concern is whether the tag field remains valid after it completes the first time. I'll check. -Ewan -- 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 9/9] scsi_error: do not display kernel pointer in message logs
On Mon, 2015-01-12 at 09:57 -0500, Ewan Milne wrote: On Mon, 2015-01-12 at 14:29 +0100, Hannes Reinecke wrote: On 01/12/2015 02:12 PM, Ewan Milne wrote: On Thu, 2015-01-08 at 07:43 +0100, Hannes Reinecke wrote: It is not good practice to display the kernel pointer in any message logs, and it doesn't display any additional information. And as we know have block-layer assigned tags we can use them to differentiate the messages. So remove any pointer references from the displayed messages. I'd actually be sad to see this go -- I have found it useful in the past when debugging crash dumps from customer sites to be able to look in the kernel messages and see that a particular scsi_cmnd had been aborted just before the crash (and then later completed). But that's precisely why we've prefixed the scmd messages with the tag number; with that you'll be able to extract the same information. And now that hch separated out the block layer tagging from SCSI-2 TCQ we should have the tag number available for any command, not just those from drivers which use TCQ. Let me know if that isn't the case; this patch indeed only makes sense if the tag number is always available. Ah, yes, I think you may be right -- I ran into this when debugging some double completion panics, so my concern is whether the tag field remains valid after it completes the first time. I'll check. Looks like if the scmd completes twice, the req could be getting reused, so scmd-request-tag might be different. However, for crash analysis, scmd-tag gets a copy of the request tag so that would be good enough to match up with an earlier logged abort message. Reviewed-by: Ewan D. Milne emi...@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 9/9] scsi_error: do not display kernel pointer in message logs
On Thu, 2015-01-08 at 07:43 +0100, Hannes Reinecke wrote: It is not good practice to display the kernel pointer in any message logs, and it doesn't display any additional information. And as we know have block-layer assigned tags we can use them to differentiate the messages. So remove any pointer references from the displayed messages. I'd actually be sad to see this go -- I have found it useful in the past when debugging crash dumps from customer sites to be able to look in the kernel messages and see that a particular scsi_cmnd had been aborted just before the crash (and then later completed). -Ewan -- 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
[PATCH] uas: Add no-report-opcodes quirk for Simpletech devices with id 4971:8017
Like some other uas devices these devices hang when a report-opcodes scsi command is send to them. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1124119 Cc: sta...@vger.kernel.org # 3.16 Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/usb/storage/unusual_uas.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h index 9ec4561..da3d98c 100644 --- a/drivers/usb/storage/unusual_uas.h +++ b/drivers/usb/storage/unusual_uas.h @@ -130,3 +130,10 @@ UNUSUAL_DEV(0x4971, 0x1012, 0x, 0x, External HDD, USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_IGNORE_UAS), + +/* Reported-by: Richard Henderson r...@redhat.com */ +UNUSUAL_DEV(0x4971, 0x8017, 0x, 0x, + SimpleTech, + External HDD, + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_NO_REPORT_OPCODES), -- 2.1.0 -- 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
[PATCH] [SCSI] mpt2sas, mpt3sas: fix sparse warings restricted __le16 degrades to integer
Fixed sparse warings 'restricted __le16 degrades to integer' generated
from below titled patch
[PATCH v2 02/22] [SCSI] mpt2sas, mpt3sas: Added support to log message
when Temperature Threshold exceeds for any Sensor
Signed-off-by: Sreekanth Reddy sreekanth.re...@avagotech.com
---
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 12 ++--
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 12 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
index 5950731..3f26147 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
@@ -3670,12 +3670,12 @@ _scsih_temp_threshold_events(struct MPT2SAS_ADAPTER
*ioc,
{
if (ioc-temp_sensors_count = event_data-SensorNum) {
printk(MPT2SAS_ERR_FMT Temperature Threshold flags %s%s%s%s
-exceeded for Sensor: %d !!!\n, ioc-name,
- ((event_data-Status 0x1) == 1) ? 0 : ,
- ((event_data-Status 0x2) == 2) ? 1 : ,
- ((event_data-Status 0x4) == 4) ? 2 : ,
- ((event_data-Status 0x8) == 8) ? 3 : ,
- event_data-SensorNum);
+ exceeded for Sensor: %d !!!\n, ioc-name,
+ ((le16_to_cpu(event_data-Status) 0x1) == 1) ? 0 : ,
+ ((le16_to_cpu(event_data-Status) 0x2) == 2) ? 1 : ,
+ ((le16_to_cpu(event_data-Status) 0x4) == 4) ? 2 : ,
+ ((le16_to_cpu(event_data-Status) 0x8) == 8) ? 3 : ,
+ event_data-SensorNum);
printk(MPT2SAS_ERR_FMT Current Temp In Celsius: %d\n,
ioc-name, event_data-CurrentTemperature);
}
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index e8e6bd4..5a97e32 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -3364,12 +3364,12 @@ _scsih_temp_threshold_events(struct MPT3SAS_ADAPTER
*ioc,
{
if (ioc-temp_sensors_count = event_data-SensorNum) {
pr_err(MPT3SAS_FMT Temperature Threshold flags %s%s%s%s
-exceeded for Sensor: %d !!!\n, ioc-name,
- ((event_data-Status 0x1) == 1) ? 0 : ,
- ((event_data-Status 0x2) == 2) ? 1 : ,
- ((event_data-Status 0x4) == 4) ? 2 : ,
- ((event_data-Status 0x8) == 8) ? 3 : ,
- event_data-SensorNum);
+ exceeded for Sensor: %d !!!\n, ioc-name,
+ ((le16_to_cpu(event_data-Status) 0x1) == 1) ? 0 : ,
+ ((le16_to_cpu(event_data-Status) 0x2) == 2) ? 1 : ,
+ ((le16_to_cpu(event_data-Status) 0x4) == 4) ? 2 : ,
+ ((le16_to_cpu(event_data-Status) 0x8) == 8) ? 3 : ,
+ event_data-SensorNum);
pr_err(MPT3SAS_FMT Current Temp In Celsius: %d\n,
ioc-name, event_data-CurrentTemperature);
}
--
2.0.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 for v3.19, v2] Avoid that sd_shutdown() triggers a kernel warning
On Thu, 8 Jan 2015, Christoph Hellwig wrote:
On Wed, Jan 07, 2015 at 02:03:22PM +0100, Bart Van Assche wrote:
Since kernel v3.19-rc1 module_refcount() returns 1 instead of 0
when called from inside module_exit(). This breaks the
module_refcount() test in scsi_device_put() and hence causes the
following kernel warning to be reported when unloading the ib_srp
kernel module:
This is getting better, but I still think we need to sort out the root
cause.
The problemt started with commit 39b7f1e25 ([SCSI] sd: Fix refcounting),
which added the calls to scsi_device_get in various struct
device_driver/scsi_driver methods. From the BZ it seems like the
rationale was to protect against races between -rescan and -remove,
but instead of doing that using refcounting we better ensure that
in the SCSI midlayer by taking scan_mutex around calls to -rescan.
The first attached patch does that, which allows us to functionally
revert 39b7f1e25, which then also allows to revert 85b6c720
([SCSI] sd: fix cache flushing on module removal (and individual
device removal)).
See the attached series to do that. Warnings: so far it only got
minimal testing.
This seems like a good idea and the obvious (once it has been pointed
out!) approach.
Perhaps not directly related to the issue at hand is this question: In
scsi_rescan_device() we will now have:
mutex_lock(shost-scan_mutex);
if (dev-driver try_module_get(dev-driver-owner)) {
struct scsi_driver *drv = to_scsi_driver(dev-driver);
if (drv-rescan)
drv-rescan(dev);
module_put(dev-driver-owner);
}
mutex_unlock(shost-scan_mutex);
What prevents the device from being unbound from its driver while the
rescan runs? Evaluating the argument to the module_put() would then
dereference a NULL pointer.
Unbind events that happen through the normal scsi_remove_host()
mechanism are fine, because scsi_remove_host() locks the scan_mutex.
But what about writes to the driver's sysfs unbind attribute?
Alan Stern
--
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: [Lsf-pc] [LSF/MM TOPIC] iSCSI MQ adoption via MCS discussion
On 01/11/2015 03:40 AM, Sagi Grimberg wrote: On 1/9/2015 10:19 PM, Mike Christie wrote: On 01/09/2015 12:28 PM, Hannes Reinecke wrote: On 01/09/2015 07:00 PM, Michael Christie wrote: On Jan 8, 2015, at 11:03 PM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: On Thu, 2015-01-08 at 15:22 -0800, James Bottomley wrote: On Thu, 2015-01-08 at 14:57 -0800, Nicholas A. Bellinger wrote: On Thu, 2015-01-08 at 14:29 -0800, James Bottomley wrote: On Thu, 2015-01-08 at 14:16 -0800, Nicholas A. Bellinger wrote: SNIP The point is that a simple session wide counter for command sequence number assignment is significantly less overhead than all of the overhead associated with running a full multipath stack atop multiple sessions. I don't see how that's relevant to issue speed, which was the measure we were using: The layers above are just a hopper. As long as they're loaded, the MQ lower layer can issue at full speed. So as long as the multipath hopper is efficient enough to keep the queues loaded there's no speed degradation. The problem with a sequence point inside the MQ issue layer is that it can cause a stall that reduces the issue speed. so the counter sequence point causes a degraded issue speed over the multipath hopper approach above even if the multipath approach has a higher CPU overhead. Now, if the system is close to 100% cpu already, *then* the multipath overhead will try to take CPU power we don't have and cause a stall, but it's only in the flat out CPU case. Not to mention that our iSCSI/iSER initiator is already taking a session wide lock when sending outgoing PDUs, so adding a session wide counter isn't adding any additional synchronization overhead vs. what's already in place. I'll leave it up to the iSER people to decide whether they're redoing this as part of the MQ work. Session wide command sequence number synchronization isn't something to be removed as part of the MQ work. It's a iSCSI/iSER protocol requirement. That is, the expected + maximum sequence numbers are returned as part of every response PDU, which the initiator uses to determine when the command sequence number window is open so new non-immediate commands may be sent to the target. So, given some manner of session wide synchronization is required between different contexts for the existing single connection case to update the command sequence number and check when the window opens, it's a fallacy to claim MC/S adds some type of new initiator specific synchronization overhead vs. single connection code. I think you are assuming we are leaving the iscsi code as it is today. For the non-MCS mq session per CPU design, we would be allocating and binding the session and its resources to specific CPUs. They would only be accessed by the threads on that one CPU, so we get our serialization/synchronization from that. That is why we are saying we do not need something like atomic_t/spin_locks for the sequence number handling for this type of implementation. Wouldn't that need to be coordinated with the networking layer? Yes. Doesn't it do the same thing, matching TX/RX queues to CPUs? Yes. Hey Hannes, Mike, I would say there is no need for specific coordination from iSCSI PoV. This is exactly what flow steering is designed for. As I see it, in order to get the TX/RX to match rings, the user can attach 5-tuple rules (using standard ethtool) to steer packets to the right rings. Sagi. If so, wouldn't we decrease bandwidth by restricting things to one CPU? We have a session or connection per CPU though, so we end up hitting the same problem you talked about last year where one hctx (iscsi session or connection's socket or nic hw queue) could get overloaded. This is what I meant in my original mail where iscsi would rely on whatever blk/mq load balancers we end up implementing at that layer to balance requests across hctxs. I'm not sure I understand, The submission flow is CPU bound. In the current single queue model both CPU X and CPU Y will end up using a single socket. In the multi-queue solution, CPU X will go to socket X and CPU Y will go to socket Y. This is equal to what we have today (if only CPU X is active) or better (if more CPUs are active). Am I missing something? I did not take Hannes's comment as comparing what we have today vs the proposal. I thought he was referring to the problem he was talking about at LSF last year and saying there could be cases where we want to spread IO across CPUs/queues and some cases where we would want to execute on the CPU we were originally submitted on. I was just saying the iscsi layer would not control that and would rely on the blk/mq layer to handle this or tell us what to do similar to what we do for the rq_affinity setting. -- 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
Re: [Lsf-pc] [LSF/MM TOPIC] iSCSI MQ adoption via MCS discussion
On 01/11/2015 03:23 AM, Sagi Grimberg wrote: On 1/9/2015 8:00 PM, Michael Christie wrote: SNIP Session wide command sequence number synchronization isn't something to be removed as part of the MQ work. It's a iSCSI/iSER protocol requirement. That is, the expected + maximum sequence numbers are returned as part of every response PDU, which the initiator uses to determine when the command sequence number window is open so new non-immediate commands may be sent to the target. So, given some manner of session wide synchronization is required between different contexts for the existing single connection case to update the command sequence number and check when the window opens, it's a fallacy to claim MC/S adds some type of new initiator specific synchronization overhead vs. single connection code. I think you are assuming we are leaving the iscsi code as it is today. For the non-MCS mq session per CPU design, we would be allocating and binding the session and its resources to specific CPUs. They would only be accessed by the threads on that one CPU, so we get our serialization/synchronization from that. That is why we are saying we do not need something like atomic_t/spin_locks for the sequence number handling for this type of implementation. If we just tried to do this with the old code where the session could be accessed on multiple CPUs then you are right, we need locks/atomics like how we do in the MCS case. I don't think we will want to restrict session per CPU. There is a tradeoff question of system resources. We might want to allow a user to configure multiple HW queues but still not to use too much of the system resources. So the session locks would still be used but definitely less congested... Are you talking about specifically the session per CPU or also MCS and doing a connection per CPU? Based on the srp work, how bad do you think it will be to do a session/connection per CPU? What are you thinking will be more common? Session per 4 CPU? 2 CPUs? 8? There is also multipath to take into account here. We could do a mq/MCS session/connection per CPU (or group of CPS) then also one of those per transport path. We could also do a mq/MCS session/connection per transport path, then bind those to specific CPUs. Or something in between. -- 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 net-next 0/2] All Chelsio drivers : Cleanup CPL messages macros
From: Anish Bhatt an...@chelsio.com Date: Thu, 8 Jan 2015 21:38:14 -0800 This patch series cleans up all register defines/MACROS defined in t4_msg.h and affected files as part of the continuing cleanup effort The patches series is created against 'net-next' tree and includes patches to the cxgb4, cxgb4vf, iw_cxgb4, cxgb4i and csiostor drivers. We have included all the maintainers of respective drivers. Kindly review the change and let us know in case of any review comments. Looks fine, applied to net-next, thanks. -- 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 1/1] be2iscsi: add block valid bit to iBFT flag
From: Minh Duc Tran
Sent: Sunday, November 09, 2014 10:52 PM
To: 'linux-scsi@vger.kernel.org'
Cc: Mike Christie (micha...@cs.wisc.edu); Jayamohan Kallickal
Subject: [PATCH 1/1] be2iscsi: add block valid bit to iBFT flag
From: Minh Tran minhduc.t...@emulex.com
We are starting to see problems with certain open-iscsi
versions out there checking block valid bit. Iscsi boot target login will
not happen without this bit being set.
Signed-off-by: Minh Tran minhduc.t...@emulex.com
---
scsi/be2iscsi/be_main.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/scsi/be2iscsi/be_main.c b/scsi/be2iscsi/be_main.c
index 30d74a0..aacf223 100644
--- a/scsi/be2iscsi/be_main.c
+++ b/scsi/be2iscsi/be_main.c
@@ -429,7 +429,7 @@ static ssize_t beiscsi_show_boot_tgt_info(void *data, int
type, char *buf)
auth_data.chap.intr_secret);
break;
case ISCSI_BOOT_TGT_FLAGS:
- rc = sprintf(str, 2\n);
+ rc = sprintf(str, 3\n);
break;
case ISCSI_BOOT_TGT_NIC_ASSOC:
rc = sprintf(str, 0\n);
@@ -466,7 +466,7 @@ static ssize_t beiscsi_show_boot_eth_info(void *data, int
type, char *buf)
switch (type) {
case ISCSI_BOOT_ETH_FLAGS:
- rc = sprintf(str, 2\n);
+ rc = sprintf(str, 3\n);
break;
case ISCSI_BOOT_ETH_INDEX:
rc = sprintf(str, 0\n);
--
1.7.1
Hi Mike,
I think we have lost track of this patch. I've checked 3.19-rc3 today and it's
not in yet. Can we get this in as soon as possible?
Thanks.
-Minh
(Removed html format, sorry about that)
--
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
[PATCH 2/2] MAINTAINERS: ibmvfc driver maintainer change
Change maintainer of ibmvfc driver to Tyrel Datwyler. Signed-off-by: Tyrel Datwyler tyr...@linux.vnet.ibm.com Cc: Nathan Fontenot nf...@linux.vnet.ibm.com Cc: Brian King brk...@linux.vnet.ibm.com --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index a646b94..f0d7593 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4761,7 +4761,7 @@ F:drivers/scsi/ibmvscsi/ibmvscsi* F: drivers/scsi/ibmvscsi/viosrp.h IBM Power Virtual FC Device Drivers -M: Brian King brk...@linux.vnet.ibm.com +M: Tyrel Datwyler tyr...@linux.vnet.ibm.com L: linux-scsi@vger.kernel.org S: Supported F: drivers/scsi/ibmvscsi/ibmvfc* -- 1.7.12.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
[PATCH 1/2] MAINTAINERS: ibmvscsi driver maintainer change
Change maintainer of ibmvscsi driver to Tyrel Datwyler. Signed-off-by: Tyrel Datwyler tyr...@linux.vnet.ibm.com Cc: Nathan Fontenot nf...@linux.vnet.ibm.com Cc: Brian King brk...@linux.vnet.ibm.com --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 79b2e4b..a646b94 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4754,7 +4754,7 @@ S:Supported F: drivers/net/ethernet/ibm/ibmveth.* IBM Power Virtual SCSI Device Drivers -M: Nathan Fontenot nf...@linux.vnet.ibm.com +M: Tyrel Datwyler tyr...@linux.vnet.ibm.com L: linux-scsi@vger.kernel.org S: Supported F: drivers/scsi/ibmvscsi/ibmvscsi* -- 1.7.12.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
[PATCH] st: implement sysfs based tape statistics v2
Some small changes since the last version - this version removes two files from
sysfs compared to the last version (read and write block counts since they're
derived from the byte counts they can be calculated in user space) but that's
the only change. This version has been rebased to 3.19.0-rc3-next-20150108.
Since posting the last version an email was received by Kai and myself from an
ATT employee who has a need for tape statistics to be implemented (who gave
permission to quote their email), I've included part of the email here:
There are over 20,000 tape devices managed by our operations group zoned to
tens of thousands of servers.
My challenge is that I cannot provide operations a solution that gives them
visibility into the tape drive performance metrics when that platform is linux.
Our legacy platforms (Solaris,HPUX,AIX) provide facilities to use iostat and
sar to determine the write speed of the tape drives. We took for granted that
this would be available in linux and its absence has been very troublesome.
Because operations cannot measure tape drive performance in this way they
cannot easily determine when there is a tape drive performance problem and
whether the change improved or worsened the performance problem.
...
I have followed the debate https://lkml.org/lkml/2013/3/20/696 and from a
service provide perspective we would expect the same maturity and functionality
that we have from the traditional unix platform in regards to iostat/sar. This
issue is important and urgent because tape drive performance issues are common
and I am unable to provide standards and processes to identify and remediate
these issues.
Another HP customer has also requested the same functionality (but hasn't given
permission to be named), they own tape drives numbering in the 1000s and also
need the ability to investigate performance issues.
Signed-off-by: shane.seym...@hp.com
Tested-by: shane.seym...@hp.com
---
diff -uprN a/drivers/scsi/st.c b/drivers/scsi/st.c
--- a/drivers/scsi/st.c 2015-01-11 14:46:00.243814755 -0600
+++ b/drivers/scsi/st.c 2015-01-12 13:54:52.549117333 -0600
@@ -20,6 +20,7 @@
static const char *verstr = 20101219;
#include linux/module.h
+#include linux/kobject.h
#include linux/fs.h
#include linux/kernel.h
@@ -226,6 +227,20 @@ static DEFINE_SPINLOCK(st_index_lock);
static DEFINE_SPINLOCK(st_use_lock);
static DEFINE_IDR(st_index_idr);
+static inline void st_stats_remove_files(struct scsi_tape *);
+static inline void st_stats_create_files(struct scsi_tape *);
+static ssize_t st_tape_attr_show(struct kobject *, struct attribute *, char *);
+static ssize_t st_tape_attr_store(struct kobject *, struct attribute *,
+ const char *, size_t);
+static void st_release_stats_kobj(struct kobject *);
+static const struct sysfs_ops st_stats_sysfs_ops = {
+ .show = st_tape_attr_show,
+ .store = st_tape_attr_store,
+};
+static struct kobj_type st_stats_ktype = {
+ .release = st_release_stats_kobj,
+ .sysfs_ops = st_stats_sysfs_ops,
+};
#include osst_detect.h
@@ -476,10 +491,22 @@ static void st_scsi_execute_end(struct r
struct st_request *SRpnt = req-end_io_data;
struct scsi_tape *STp = SRpnt-stp;
struct bio *tmp;
+ u64 ticks;
STp-buffer-cmdstat.midlevel_result = SRpnt-result = req-errors;
STp-buffer-cmdstat.residual = req-resid_len;
+ if (STp-stats != NULL) {
+ ticks = get_jiffies_64();
+ STp-stats-in_flight--;
+ ticks -= STp-stats-stamp;
+ STp-stats-io_ticks += ticks;
+ if (req-cmd[0] == WRITE_6)
+ STp-stats-write_ticks += ticks;
+ else if (req-cmd[0] == READ_6)
+ STp-stats-read_ticks += ticks;
+ }
+
tmp = SRpnt-bio;
if (SRpnt-waiting)
complete(SRpnt-waiting);
@@ -496,6 +523,7 @@ static int st_scsi_execute(struct st_req
struct rq_map_data *mdata = SRpnt-stp-buffer-map_data;
int err = 0;
int write = (data_direction == DMA_TO_DEVICE);
+ struct scsi_tape *STp = SRpnt-stp;
req = blk_get_request(SRpnt-stp-device-request_queue, write,
GFP_KERNEL);
@@ -516,6 +544,20 @@ static int st_scsi_execute(struct st_req
}
}
+ if (STp-stats != NULL) {
+ if (cmd[0] == WRITE_6) {
+ STp-stats-write_cnt++;
+ STp-stats-write_byte_cnt += bufflen;
+ } else if (cmd[0] == READ_6) {
+ STp-stats-read_cnt++;
+ STp-stats-read_byte_cnt += bufflen;
+ } else {
+ STp-stats-other_cnt++;
+ }
+ STp-stats-stamp = get_jiffies_64();
+ STp-stats-in_flight++;
+ }
+
SRpnt-bio = req-bio;
req-cmd_len = COMMAND_SIZE(cmd[0]);
memset(req-cmd, 0,
RE: [PATCH 02/10] megaraid_sas: add missing __iomem annotations
-Original Message-
From: Christoph Hellwig [mailto:h...@lst.de]
Sent: Saturday, January 10, 2015 10:41 PM
To: sumit.sax...@avagotech.com; kashyap.de...@avagotech.com
Cc: martin.peter...@oracle.com; linux-scsi@vger.kernel.org
Subject: [PATCH 02/10] megaraid_sas: add missing __iomem annotations
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/megaraid/megaraid_sas.h | 2 +-
drivers/scsi/megaraid/megaraid_sas_base.c | 9 +
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
index 14e5c7c..ecc4321 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1681,7 +1681,7 @@ struct megasas_instance {
spinlock_t crashdump_lock;
struct megasas_register_set __iomem *reg_set;
- u32 *reply_post_host_index_addr[MR_MAX_MSIX_REG_ARRAY];
+ u32 __iomem
*reply_post_host_index_addr[MR_MAX_MSIX_REG_ARRAY];
struct megasas_pd_list pd_list[MEGASAS_MAX_PD];
struct megasas_pd_list local_pd_list[MEGASAS_MAX_PD];
u8 ld_ids[MEGASAS_MAX_LD_IDS];
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 2eb5233..875db92 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -814,8 +814,8 @@ megasas_adp_reset_gen2(struct megasas_instance
*instance, {
u32 retry = 0 ;
u32 HostDiag;
- u32 *seq_offset = reg_set-seq_offset;
- u32 *hostdiag_offset = reg_set-host_diag;
+ u32 __iomem *seq_offset = reg_set-seq_offset;
+ u32 __iomem *hostdiag_offset = reg_set-host_diag;
if (instance-instancet == megasas_instance_template_skinny) {
seq_offset = reg_set-fusion_seq_offset; @@ -4499,7
+4499,7 @@ static int megasas_init_fw(struct megasas_instance *instance)
* It is used for all MPT based Adapters.
*/
instance-reply_post_host_index_addr[0] =
- (u32 *)((u8 *)instance-reg_set +
+ (u32 __iomem *)((u8 __iomem *)instance-reg_set +
MPI2_REPLY_POST_HOST_INDEX_OFFSET);
/* Check if MSI-X is supported while in ready state */ @@ -4531,7
+4531,8 @@ static int megasas_init_fw(struct megasas_instance *instance)
*/
for (loop = 1; loop MR_MAX_MSIX_REG_ARRAY;
loop++) {
instance-reply_post_host_index_addr[loop]
=
- (u32 *)((u8 *)instance-reg_set +
+ (u32 __iomem *)
+ ((u8 __iomem*)instance-reg_set +
MPI2_SUP_REPLY_POST_HOST_INDEX_OFFSET
+ (loop * 0x10));
}
Acked-by: Sumit Saxena sumit.sax...@avagotech.com
--
1.9.1
--
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 03/10] megaraid_sas: add endianess annotations
-Original Message-
From: Christoph Hellwig [mailto:h...@lst.de]
Sent: Saturday, January 10, 2015 10:41 PM
To: sumit.sax...@avagotech.com; kashyap.de...@avagotech.com
Cc: martin.peter...@oracle.com; linux-scsi@vger.kernel.org
Subject: [PATCH 03/10] megaraid_sas: add endianess annotations
This adds endianess annotations to all data structures, and a few
variables
directly referencing them.
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/megaraid/megaraid_sas.h| 296
++-
-
drivers/scsi/megaraid/megaraid_sas_base.c | 2 +-
drivers/scsi/megaraid/megaraid_sas_fp.c | 10 +-
drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +-
drivers/scsi/megaraid/megaraid_sas_fusion.h | 276
+--
---
5 files changed, 293 insertions(+), 293 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
index ecc4321..81484f1 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -408,7 +408,7 @@ enum MR_PD_STATE {
* defines the physical drive address structure
*/
struct MR_PD_ADDRESS {
- u16 deviceId;
+ __le16 deviceId;
u16 enclDeviceId;
union {
@@ -433,8 +433,8 @@ struct MR_PD_ADDRESS {
* defines the physical drive list structure
*/
struct MR_PD_LIST {
- u32 size;
- u32 count;
+ __le32 size;
+ __le32 count;
struct MR_PD_ADDRESS addr[1];
} __packed;
@@ -451,28 +451,28 @@ union MR_LD_REF {
struct {
u8 targetId;
u8 reserved;
- u16 seqNum;
+ __le16 seqNum;
};
- u32 ref;
+ __le32 ref;
} __packed;
/*
* defines the logical drive list structure
*/
struct MR_LD_LIST {
- u32 ldCount;
- u32 reserved;
+ __le32 ldCount;
+ __le32 reserved;
struct {
union MR_LD_REF ref;
u8 state;
u8 reserved[3];
- u64 size;
+ __le64 size;
} ldList[MAX_LOGICAL_DRIVES_EXT];
} __packed;
struct MR_LD_TARGETID_LIST {
- u32 size;
- u32 count;
+ __le32 size;
+ __le32 count;
u8 pad[3];
u8 targetId[MAX_LOGICAL_DRIVES_EXT];
};
@@ -553,7 +553,7 @@ struct megasas_ctrl_prop {
} OnOffProperties;
u8 autoSnapVDSpace;
u8 viewSpace;
- u16 spinDownTime;
+ __le16 spinDownTime;
u8 reserved[24];
} __packed;
@@ -567,10 +567,10 @@ struct megasas_ctrl_info {
*/
struct {
- u16 vendor_id;
- u16 device_id;
- u16 sub_vendor_id;
- u16 sub_device_id;
+ __le16 vendor_id;
+ __le16 device_id;
+ __le16 sub_vendor_id;
+ __le16 sub_device_id;
u8 reserved[24];
} __attribute__ ((packed)) pci;
@@ -611,8 +611,8 @@ struct megasas_ctrl_info {
/*
* List of components residing in flash. All str are null
terminated
*/
- u32 image_check_word;
- u32 image_component_count;
+ __le32 image_check_word;
+ __le32 image_component_count;
struct {
@@ -629,7 +629,7 @@ struct megasas_ctrl_info {
* empty if a flash operation has not occurred. All stings are
null
* terminated
*/
- u32 pending_image_component_count;
+ __le32 pending_image_component_count;
struct {
@@ -662,39 +662,39 @@ struct megasas_ctrl_info {
} __attribute__ ((packed)) hw_present;
- u32 current_fw_time;
+ __le32 current_fw_time;
/*
* Maximum data transfer sizes
*/
- u16 max_concurrent_cmds;
- u16 max_sge_count;
- u32 max_request_size;
+ __le16 max_concurrent_cmds;
+ __le16 max_sge_count;
+ __le32 max_request_size;
/*
* Logical and physical device counts
*/
- u16 ld_present_count;
- u16 ld_degraded_count;
- u16 ld_offline_count;
+ __le16 ld_present_count;
+ __le16 ld_degraded_count;
+ __le16 ld_offline_count;
- u16 pd_present_count;
- u16 pd_disk_present_count;
- u16 pd_disk_pred_failure_count;
- u16 pd_disk_failed_count;
+ __le16 pd_present_count;
+ __le16 pd_disk_present_count;
+ __le16 pd_disk_pred_failure_count;
+ __le16 pd_disk_failed_count;
/*
* Memory size information
*/
- u16 nvram_size;
- u16 memory_size;
- u16 flash_size;
+ __le16 nvram_size;
+ __le16 memory_size;
+ __le16 flash_size;
/*
* Error counters
*/
- u16 mem_correctable_error_count;
- u16 mem_uncorrectable_error_count;
+ __le16 mem_correctable_error_count;
+ __le16 mem_uncorrectable_error_count;
/*
* Cluster information
@@ -705,7
RE: [PATCH 01/10] megaraid_sas: megasas_complete_outstanding_ioctls() can be static
-Original Message-
From: Christoph Hellwig [mailto:h...@lst.de]
Sent: Saturday, January 10, 2015 10:41 PM
To: sumit.sax...@avagotech.com; kashyap.de...@avagotech.com
Cc: martin.peter...@oracle.com; linux-scsi@vger.kernel.org; kbuild test
robot
Subject: [PATCH 01/10] megaraid_sas:
megasas_complete_outstanding_ioctls() can be static
From: kbuild test robot fengguang...@intel.com
drivers/scsi/megaraid/megaraid_sas_base.c:1701:6: sparse: symbol
'megasas_complete_outstanding_ioctls' was not declared. Should it be
static?
Signed-off-by: Fengguang Wu fengguang...@intel.com
---
drivers/scsi/megaraid/megaraid_sas_base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 890637f..2eb5233 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1698,7 +1698,7 @@ static int megasas_slave_alloc(struct scsi_device
*sdev)
* @instance: Adapter soft state
*
*/
-void megasas_complete_outstanding_ioctls(struct megasas_instance
*instance)
+static void megasas_complete_outstanding_ioctls(struct megasas_instance
*instance)
{
int i;
struct megasas_cmd *cmd_mfi;
Acked-by: Sumit Saxena sumit.sax...@avagotech.com
--
1.9.1
--
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 05/10] megaraid_sas: move endianess conversion into caller of megasas_get_seq_num
-Original Message- From: Christoph Hellwig [mailto:h...@lst.de] Sent: Saturday, January 10, 2015 10:41 PM To: sumit.sax...@avagotech.com; kashyap.de...@avagotech.com Cc: martin.peter...@oracle.com; linux-scsi@vger.kernel.org Subject: [PATCH 05/10] megaraid_sas: move endianess conversion into caller of megasas_get_seq_num Converting structure fields in place is always a bad idea, and in this case by moving it into the only caller we also only have to do a single byte swap as most fields of this structure are never used. Signed-off-by: Christoph Hellwig h...@lst.de --- drivers/scsi/megaraid/megaraid_sas_base.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index a6556ea..548d033 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -4823,11 +4823,11 @@ megasas_get_seq_num(struct megasas_instance *instance, /* * Copy the data back into callers buffer */ - eli-newest_seq_num = le32_to_cpu(el_info- newest_seq_num); - eli-oldest_seq_num = le32_to_cpu(el_info- oldest_seq_num); - eli-clear_seq_num = le32_to_cpu(el_info-clear_seq_num); - eli-shutdown_seq_num = le32_to_cpu(el_info- shutdown_seq_num); - eli-boot_seq_num = le32_to_cpu(el_info-boot_seq_num); + eli-newest_seq_num = el_info-newest_seq_num; + eli-oldest_seq_num = el_info-oldest_seq_num; + eli-clear_seq_num = el_info-clear_seq_num; + eli-shutdown_seq_num = el_info-shutdown_seq_num; + eli-boot_seq_num = el_info-boot_seq_num; } pci_free_consistent(instance-pdev, sizeof(struct megasas_evt_log_info), @@ -4991,7 +4991,7 @@ static int megasas_start_aen(struct megasas_instance *instance) class_locale.members.class = MR_EVT_CLASS_DEBUG; return megasas_register_aen(instance, - eli.newest_seq_num + 1, + le32_to_cpu(eli.newest_seq_num) + 1, class_locale.word); } Acked-by: Sumit Saxena sumit.sax...@avagotech.com -- 1.9.1 -- 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 04/10] megaraid_sas: add endianess conversions for all ones
-Original Message-
From: Christoph Hellwig [mailto:h...@lst.de]
Sent: Saturday, January 10, 2015 10:41 PM
To: sumit.sax...@avagotech.com; kashyap.de...@avagotech.com
Cc: martin.peter...@oracle.com; linux-scsi@vger.kernel.org
Subject: [PATCH 04/10] megaraid_sas: add endianess conversions for all
ones
Add noop conversions for all ones to make sparse happy.
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/megaraid/megaraid_sas_base.c | 2 +-
drivers/scsi/megaraid/megaraid_sas_fp.c | 7 ---
drivers/scsi/megaraid/megaraid_sas_fusion.c | 9 +
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index cb7d0c4..a6556ea 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1232,7 +1232,7 @@ megasas_build_dcdb(struct megasas_instance
*instance, struct scsi_cmnd *scp,
*/
if (scp-device-type == TYPE_TAPE) {
if ((scp-request-timeout / HZ) 0x)
- pthru-timeout = 0x;
+ pthru-timeout = cpu_to_le16(0x);
else
pthru-timeout = cpu_to_le16(scp-request-
timeout / HZ);
}
diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c
b/drivers/scsi/megaraid/megaraid_sas_fp.c
index e9138a2..2001ffb 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fp.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fp.c
@@ -769,7 +769,7 @@ static u8 mr_spanset_get_phy_params(struct
megasas_instance *instance, u32 ld,
if (pd != MR_PD_INVALID)
*pDevHandle = MR_PdDevHandleGet(pd, map);
else {
- *pDevHandle = MR_PD_INVALID;
+ *pDevHandle = cpu_to_le16(MR_PD_INVALID);
if ((raid-level = 5)
(!do_invader || (do_invader
(raid-regTypeReqOnRead !=
REGION_TYPE_UNUSED @@ -864,7 +864,8 @@ u8
MR_GetPhyParams(struct megasas_instance *instance, u32 ld, u64 stripRow,
/* Get dev handle from Pd. */
*pDevHandle = MR_PdDevHandleGet(pd, map);
else {
- *pDevHandle = MR_PD_INVALID; /* set dev handle as invalid.
*/
+ /* set dev handle as invalid. */
+ *pDevHandle = cpu_to_le16(MR_PD_INVALID);
if ((raid-level = 5)
(!do_invader || (do_invader
(raid-regTypeReqOnRead !=
REGION_TYPE_UNUSED @@ -1109,7 +1110,7 @@
MR_BuildRaidContext(struct megasas_instance *instance,
ref_in_start_stripe, io_info,
pRAID_Context, map);
/* If IO on an invalid Pd, then FP is not possible.*/
- if (io_info-devHandle == MR_PD_INVALID)
+ if (io_info-devHandle == cpu_to_le16(MR_PD_INVALID))
io_info-fpOkForIo = FALSE;
return retval;
} else if (isRead) {
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 983635f..82439f9 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -464,7 +464,7 @@ megasas_alloc_cmds_fusion(struct megasas_instance
*instance)
reply_desc = fusion-reply_frames_desc;
for (i = 0; i fusion-reply_q_depth * count; i++, reply_desc++)
- reply_desc-Words = ULLONG_MAX;
+ reply_desc-Words = cpu_to_le64(ULLONG_MAX);
io_frames_sz = fusion-io_frames_alloc_sz;
@@ -1995,7 +1995,8 @@ complete_cmd_fusion(struct megasas_instance
*instance, u32 MSIxIndex)
num_completed = 0;
- while ((d_val.u.low != UINT_MAX) (d_val.u.high != UINT_MAX)) {
+ while (d_val.u.low != cpu_to_le32(UINT_MAX)
+ d_val.u.high != cpu_to_le32(UINT_MAX)) {
smid = le16_to_cpu(reply_desc-SMID);
cmd_fusion = fusion-cmd_list[smid - 1]; @@ -2063,7
+2064,7
@@ complete_cmd_fusion(struct megasas_instance *instance, u32
MSIxIndex)
fusion-reply_q_depth)
fusion-last_reply_idx[MSIxIndex] = 0;
- desc-Words = ULLONG_MAX;
+ desc-Words = cpu_to_le64(ULLONG_MAX);
num_completed++;
threshold_reply_count++;
@@ -2505,7 +2506,7 @@ void megasas_reset_reply_desc(struct
megasas_instance *instance)
fusion-last_reply_idx[i] = 0;
reply_desc = fusion-reply_frames_desc;
for (i = 0 ; i fusion-reply_q_depth * count; i++, reply_desc++)
- reply_desc-Words = ULLONG_MAX;
+ reply_desc-Words = cpu_to_le64(ULLONG_MAX);
}
/* Check for a second path that is currently UP */
Acked-by: Sumit Saxena sumit.sax...@avagotech.com
--
1.9.1
--
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
