Acked-by: James Smart
-- james s
On 2/2/2013 8:20 PM, Tejun Heo wrote:
Convert to the much saner new idr interface.
Only compile tested.
Signed-off-by: Tejun Heo
Cc: James Smart
Cc: linux-s...@vger.kernel.org
---
This patch depends on an earlier idr changes and I think it would be
best
Acked-by: James Smart
-- james s
On 2/6/2013 2:40 PM, Tejun Heo wrote:
Convert to the much saner new idr interface.
Only compile tested.
Signed-off-by: Tejun Heo
Cc: James Smart
Cc: linux-s...@vger.kernel.org
---
drivers/scsi/lpfc/lpfc_init.c | 12
1 file changed, 4
different argument. We should answer/solve the
resurrection
problem, then see where things lead us.
-- james s
This is fixed as a side effect of the patch.
Comments welcome.
Thanx,
Tomar
--- James Smart <[EMAIL PROTECTED]> wrote:
This sounds like a return to the old behavior,
The keep-it-in-user-space arguments seem fairly compelling to me.
Especially as we've pushed whole i/o subsystems out to user space
(iscsi, stgt, talked about fcoe, a lot of dm control, etc).
The functionality seems to align with Doug's sg/lsscsi utility chain
as well. Granted, the new utility w
James Bottomley wrote:
I don't disagree with that, but the fact is that there isn't such a
tool. It's also a fact that the enterprise is reasonably unhappy with
the lack of an enclosure management infrastructure, since it's something
they got on all the other unix systems.
I don't disagree.
James Bottomley wrote:
... I wouldn't have bothered except that I could see ad-hoc
in-kernel sysfs solutions beginning to appear.
If this is true, and if no one quickly volunteers to do the utility, then
I agree with what you are doing.
-- james s
--
To unsubscribe from this list: send the l
Adrian Bunk wrote:
This patch makes theneedlessly global lpfc_disable_node() static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
ACK
-- james s
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo in
Thanks Jeff.
-- james s
Acked-By: James Smart
On 10/30/2012 4:14 PM, Jeff Moyer wrote:
Signed-off-by: Jeff Moyer
---
drivers/scsi/lpfc/lpfc_init.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc
Ren,
Based on the discussion recently held at LSF 2013, we are reworking the
error recovery path to address all the issues you are mentioning. That
work contradicts these patches. So for now, these should be held off.
-- james s
On 5/20/2013 3:14 AM, Ren Mingxin wrote:
When there is a s
5/22/2013 3:12 AM, Ren Mingxin wrote:
Hi, James,
On 05/20/2013 11:53 PM, James Smart wrote:
Based on the discussion recently held at LSF 2013, we are
reworking the error recovery path to address all the issues
you are mentioning. That work contradicts these patches.
So for now, these should be
Folks,
FYI:
In testing with 2.6.12-rc1 and -rc2, we've been encountering an issue on SMP
machines with the loading of scsi_mod and sd_mod modules. The sd_mod load fails
with unresolved symbols. It appears to be a race condition based on how quickly
the modules load. This works fine on uni syst
Can anyone give some history on why the workqueue name length is
limited to 10 characters ? Can it be raised ? and if so to what limit ?
-- James S
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Christoph Hellwig
Sent: Tuesday, August 09, 2005 12:32 PM
To:
+P: James Smart
+M: [EMAIL PROTECTED]
+L: linux-scsi@vger.kernel.org
+W: http://sourceforge.net/projects/lpfc
+S: Supported
+
EPSON 1355 FRAMEBUFFER DRIVER
P: Christopher Hoover
M: [EMAIL PROTECTED], [EMAIL PROTECTED]
-
To unsubscribe from this list: send the
This signature is consistent with having out of date firmware on the adapter.
See http://www.emulex.com/ts/indexemu.html. There are some hints on
downloading firmware at the tail end of
http://sourceforge.net/forum/forum.php?thread_id=1130082&forum_id=355154.
Thanks.
-- James S
> -Ori
Actually, I view this as being a little odd...
What is ":00:04:0" in this case ? The "device" is not a serial
port, which is what the ttyXX back link would lead you to believe.
Thus, it's a serial port multiplexer that supports up to N ports,
right ? and wouldn't the more correct representatio
> On Mon, 2005-08-15 at 20:52 -0400, [EMAIL PROTECTED] wrote:
> > What is ":00:04:0" in this case ? The "device" is not a serial
> > port, which is what the ttyXX back link would lead you to believe.
> > Thus, it's a serial port multiplexer that supports up to N ports,
> > right ? and wouldn't
ent interfaces to the "industry-standard" SNIA HBA API,
> allowing various management applications to work out of the
> box with our
> stack.
>
> To make these new features available to Enterprise users and
> reduce the
> fragmentation in driver and management sp
> They are class devices called ttyS0, ttyS1, ttyS2 so you can say
> they're uniquely named.
>
> The problem is that Matthew wants to add a symlink from the device
> device to the class device to complement the class device to device
> symlink, since we end up with multiple symlinks in the devices
I can live with this. I would have liked the "class:" prefix, but the name
does start to get long, and this is ok.
-- james s
> -Original Message-
> From: Greg KH [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 18, 2005 2:37 AM
> To: James Bottomley
> Cc: Matthew Wilcox; Smart, James;
This has already been fixed. It's in our 8.2.3 patches, which were merged into
James's scsi-misc-2.6 tree at the beginning of November, and targeted for
2.6.25.
-- james s
Adrian Bunk wrote:
Commit 2e0fef85e098f6794956b8b80b79fbb4cbb7 added the folowing code
to drivers/scsi/lpfc/lpfc_attr
This sounds like a return to the old behavior, where sdevs in SDEV_DEL
were ignored. However, it too had lots of bad effects. We'd have to go
back to the threads over the last 2 years that justified resurrecting
the sdev. Start looking at threads like :
http://marc.info/?l=linux-scsi&m=117887
Why do you prefer request_firmware() vs something over sysfs ?
Does environments like the kdump kernel also have access to data needed
by request_firmware() ?
-- james s
Andrew Vasquez wrote:
On Mon, 08 Oct 2007, Darrick J. Wong wrote:
On Mon, Oct 08, 2007 at 03:48:32PM -0700, Andrew Vasque
Darrick J. Wong wrote:
Though I don't see why both can't coexist cleanly -- I take it the use
case you are considering is: software recognizes no valid WWPN
available, query via request_firmware() fails, software halts
initialization (rather than fail), and awaits the admin to poke
'0x123456.. >
The hearburn I have with these patches is that you are changing driver-specific
attributes, not common ones as enforced/requested by a subsystem. As such, you
are breaking a management interface for existing tools/scripts.
There's been a long-standing request to create common device attributes, s
rivers/scsi/lpfc/lpfc_mbox.c |2 +-
drivers/scsi/megaraid/megaraid_mbox.c | 10 +-
drivers/scsi/psi240i.c|2 +-
drivers/scsi/qla2xxx/qla_gs.c |2 +-
For the lpfc bits:
Acked-by: James Smart <[EMAIL PROTECTED]>
--
To unsubscribe from thi
ACK
-- james s
Adrian Bunk wrote:
This patch contains the following possible cleanups:
- make the following needlessly global functions static:
- lpfc_els.c: lpfc_register_new_vport()
- lpfc_els.c: lpfc_issue_els_fdisc()
- lpfc_els.c: lpfc_issue_fabric_iocb()
- lpfc_els.c: lpfc_fabric_a
Adrian,
Thanks.
Syntax-wise, it is incorrect. However there's no risk. The datastructure
its indexing into is a union, and its size is sufficient for the index.
The union supports old and new firmware interfaces. We mistakenly used the
array for the old interface and should have used the (large
ACK
-- james s
Mariusz Kozlowski wrote:
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
drivers/scsi/lpfc/lpfc_init.c | 65932 -> 65881 (-51 bytes)
drivers/scsi/lpfc/lpfc_init.o | 219760 -> 219616 (-144 bytes)
drivers/scsi/lpfc/lpfc_init.c |3 +--
1 file changed, 1 insertion(+), 2
ACK
-- james s
Mariusz Kozlowski wrote:
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
drivers/scsi/lpfc/lpfc_scsi.c | 42769 -> 42721 (-48 bytes)
drivers/scsi/lpfc/lpfc_scsi.o | 191332 -> 191240 (-92 bytes)
drivers/scsi/lpfc/lpfc_scsi.c |3 +--
1 file changed, 1 insertion(+), 2 d
ACK
-- james s
Mariusz Kozlowski wrote:
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
drivers/scsi/lpfc/lpfc_debugfs.c | 13809 -> 13716 (-93 bytes)
drivers/scsi/lpfc/lpfc_debugfs.o | 146124 -> 146124 (0 bytes)
drivers/scsi/lpfc/lpfc_debugfs.c |7 ++-
1 file changed, 2 insert
One more area, introduced by the lpfc 8.2.2 patches, that need the
kmalloc+memset conversion.
This patch to be applied atop the 8.2.2 patches.
-- james s
Signed-off-by: James Smart <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/lpfc/lpfc_debugfs.c b/drivers/scsi/lpfc/lpfc_debugfs.c
In defense of my maintainer, who was working on my behalf! ...
The lpfc mods were the bulk of the +/- counts. We batch our bug fixes
together and then push to James as a large lump. Unfortunately, we had
a change that changed logging from a base object to a subobject. Although
not risky, it did
Jeff Garzik wrote:
The lpfc update was probably the biggest thing, LOC-wise. And even
though that was mostly bug fixes -- and notably NOT 100% fixes -- it is
big enough to warrant integration testing and exposure prior to
mainline. Definitely merge-window-open material AFAICS.
FYI - it is i
ACK
-- james s
Joe Perches wrote:
Found these while looking at printk uses.
Add missing newlines to dev_ uses
Add missing KERN_ prefixes to multiline dev_s
Fixed a wierd->weird spelling typo
Added a newline to a printk
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
arch/ia64/sn/kernel/xpne
ACK
-- james s
Jesper Juhl wrote:
I propose this patch, that simply changes the 'hbqno > LPFC_MAX_HBQS'
into 'hbqno >= LPFC_MAX_HBQS' as a possible fix.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/scsi/lpfc/lpfc_sli.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(
will cause an overflow of the statically allocated array at index 4,
since the valid indices are only 0-3.
I propose this patch, that simply changes the 'hbqno > LPFC_MAX_HBQS'
into 'hbqno >= LPFC_MAX_HBQS' as a possible fix.
Signed-off-by: Jesper Juhl <[EMAIL PR
as
the author.
- Coding-wise, you are right, we still didn't fix the range check.
Since this really is just something to keep the tools happy - I'll recind the
NACK.
I'll worry about simply removing this if-check later...
James/Andrew, accept this patch - ACK.
-- james s
Jesper J
fyi
I've seen these before (and they haven't been specific to the LLDD).
The "-EEXIST" error, was an issue of rescan-while-deleting, and where
refcounts held the old sdevs in place. They were ramant in 2.6.18/2.6.19.
Supposedly, we had patches from Hannes Reinecke. to resolve it, but that
wa
A little more
The -EEXIST matches http://marc.info/?l=linux-scsi&m=117699334422336&w=2
I had a bug fix at http://marc.info/?l=linux-scsi&m=117856436302690&w=2
Mathew's fix below superceeded my patch and supposedly also corrects it.
-- james s
PS: Emulex's testing has been with my fix. We h
asses needs updating, and we don't have to handle the
>> > > rather nasty release and unload races.
>
> I was thinking of a wait_event driven system checking for
> list_empty(cont->containers.k_list)
I hope this is more in line with what you were thinking.
-- ja
ACK
-- james s
Adrian Bunk wrote:
This patch fixes a typo introduced by
commit bbfbbbc1182f8b44c8cc4c99f4a3f3a512149022.
It wasn't a compile error since CONFIG_LPFC_DEBUG_FS is not (yet?)
available as an option.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
74e14a2a4ed066aa8fedd557a67
ACK
-- james
Mariusz Kozlowski wrote:
Hello,
Add kmalloc failure check and fix the loop on error path. Without the
patch pool element at index [0] will not be freed.
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
drivers/scsi/lpfc/lpfc_mem.c |6 +-
1 file changed, 5 in
ACK - the patch is fine for lpfc
-- james s
Linas Vepstas wrote:
James,
Please review and forward upstream. This is a patch I'd previously
submitted, and reworked by [EMAIL PROTECTED] in January.
Not clear if I need to also nag James Smart (who is listed as the
maintainer) for an
I don't believe this is a valid fix. This is yet another case
of the reuse-after-free issues on sdevs. The real issue is the
deleted sdev isn't truly getting deleted due to references, and
we're deadlocked trying to allocate a new one while the old one
is outstanding. This fix just jumps over thin
Matthew Wilcox wrote:
On Wed, Nov 29, 2006 at 11:04:22AM +0100, Adrian Bunk wrote:
+#include "scsi_transport_api.h"
scsi_transport_api.h is a weird little file. It's not included by
anything in the drivers/scsi directory, only
drivers/scsi/libsas/sas_scsi_host.c:#include "../scsi_transport_
I'm agnostic on the change... As long as we get a message somewhere
when the failure is meaningful, I'm fine with this change. I didn't
like setting mwi by the driver anyway - it should have already been
done by the platform.
-- james s
Randy Dunlap wrote:
--- a/drivers/scsi/lpfc/lpfc_init.c
+
Florin,
Thanks for the effort to create this patch. Turns out we have already
fixed this, and have it included in our 8.2.2 patch set, which we will be
posting within the next week.
So James, don't pick this patch up, take the larger patch set instead.
Thanks.
-- james s
Florin Malita wrote:
ACK... Looks good...
-- james s
Linas Vepstas wrote:
Bino, James,
Please review, sign-off and forward upstream.
--linas
If a PCI error is detected that cannot be recovered from, there
will be a double call of lpfc_pci_remove_one(), with the second call
resulting in a null-pointer dereferen
fyi...
For FC, we have several async events, and allow for LLDDs to send their own
data or augment the generic transport event w/ additional LLDD-data. The
infrastructure is implemented generically within the scsi midlayer.
We are using Netlink w/ broadcasts to deliver the events rather than
kob
Jeff Garzik wrote:
Fair enough, though I definitely lean towards some use of sysfs / device
model for AN-style events specifically. The media change events are
generated by the device, not the transport, and we should definitely
have an object in the device model that represents the device (
I doubt it's in the fc transport - it's doing what it always did, which has
nothing to do with coherency of the sdev's.
We're seeing like problems, and it looks like it's related to the scan_mutex
being held when some of the entry points are being called via the recent
async scan code (which also
add u64 number parser
Will be used by the nvme-fabrics FC transport in parsing options
Signed-off-by: James Smart
---
include/linux/parser.h | 1 +
lib/parser.c | 47 +++
2 files changed, 48 insertions(+)
diff --git a/include/linux
On 7/22/2016 6:32 PM, Bart Van Assche wrote:
On 07/22/16 17:23, James Smart wrote:
+buf = kmalloc(len + 1, GFP_KERNEL);
+if (!buf)
+return -ENOMEM;
+memcpy(buf, s->from, len);
+buf[len] = '\0';
Hello James,
Have you considered to combine the above
add u64 number parser
Prior patch revised to use kasprintf.
Modified match_number to use kasprintf as well
Signed-off-by: James Smart
---
include/linux/parser.h | 1 +
lib/parser.c | 51 ++
2 files changed, 48 insertions(+), 4
add u64 number parser
Reverted back to version 2 of the patch. This adds the interface
using existing logic. Comments from the prior reviewers to move to
kasprintf were rejected by Linus.
Signed-off-by: James Smart
---
include/linux/parser.h | 1 +
lib/parser.c | 47
This patch is good. Thanks
-- james
Signed-off-by: James Smart
On 6/15/2016 6:00 AM, Johannes Thumshirn wrote:
Check for the existance of pciob->vport before accessing it.
Signed-off-by: Johannes Thumshirn
---
drivers/scsi/lpfc/lpfc_sli.c | 13 -
1 file changed
Patch is fine.
Signed-off-by: James Smart
-- james
On 5/19/2017 1:04 AM, Arnd Bergmann wrote:
The lpfc_nvmeio_data() tracing helper always takes a format string and
three additional arguments. The latest caller has a format string with
only two integer arguments, causing this harmless
Looks good
Signed-off-by: James Smart
-- james
On 5/23/2017 8:09 AM, Gustavo A. R. Silva wrote:
Null check at line 966: if (ndlp) {, implies that ndlp might be NULL.
Functions lpfc_nlp_set_state() and lpfc_issue_els_prli() dereference
pointer ndlp. Include these function calls inside the
Patch is fine.
Signed-off-by: James Smart
-- james
On 5/18/2017 2:35 AM, Colin King wrote:
From: Colin Ian King
functions lpfc_nvmet_cleanup_io_context and lpfc_nvmet_setup_io_context
can be made static as they do not need to be in global scope.
Cleans up sparse warnings:
"wa
it's good :)
Signed-off-by: James Smart
-- james
On 5/26/2017 3:11 AM, Colin King wrote:
From: Colin Ian King
Trivial fix to spelling mistake in debugfs message
Signed-off-by: Colin Ian King
fs_nvmeio_trc) *
- phba->nvmeio_trc_size));
phba->nvmeio_trc_on = 1;
phba->nvmeio_trc_output_idx = 0;
phba->nvmeio_trc = NULL;
looks good.
Signed-off-by: James Smart
On 8/18/2015 6:27 PM, Sebastian Herbszt wrote:
Johannes Thumshirn wrote:
Sebastian Herbszt writes:
Johannes Thumshirn wrote:
If the bf_get() call in lpfc_mbx_cmpl_rdp_page_a2() does succeeds, execution
continues normally and mp gets kfree()d.
If the subsequent call to lpfc_sli_issue_mbox()
Looks Good - Thank you Sudip.
Reviewed-by: James Smart
-- james s
On 9/23/2015 6:32 AM, Sudip Mukherjee wrote:
kmalloc() can return NULL and without checking we were dereferencing it.
Moreover if kmalloc succeeds but the function fails in other parts then
we were returning the error code
On 7/19/2018 7:10 AM, Johannes Thumshirn wrote:
On Thu, Jul 19, 2018 at 03:42:03PM +0200, Christoph Hellwig wrote:
Without even looking at the code yet: why? The nvme abort isn't
very useful, and due to the lack of ordering between different
queues almost harmful on fabrics. What problem do
On 7/19/2018 7:54 AM, Johannes Thumshirn wrote:
On Thu, Jul 19, 2018 at 04:50:05PM +0200, Christoph Hellwig wrote:
The upper layer is only going to retry after tearing down the transport
connection. And a tear down of the connection MUST clear all pending
commands on the way. If it doesn't we
uests...
RECONNECTING - establish new queues/connections and some other
initializing things.
Introduce RECONNECTING to nvme-pci transport to do the same mark.
Then we get a coherent state definition among nvme pci/rdma/fc
transports.
Suggested-by: James Smart
Signed-off-by: Jianchao
Jianchao,
This looks very coherent to me. Thank You.
-- james
On 1/18/2018 2:10 AM, Jianchao Wang wrote:
Hello
Please consider the following scenario.
nvme_reset_ctrl
-> set state to RESETTING
-> queue reset_work
(scheduling)
nvme_reset_work
-> nvme_dev_disable
-> quiesce
On 1/17/2018 2:37 AM, Sagi Grimberg wrote:
After Sagi's nvme-rdma: fix concurrent reset and reconnect, the rdma
ctrl state is changed to RECONNECTING state
after some clearing and shutdown work, then some initializing
procedure, no matter reset work path or error recovery path.
The fc reset
I'm having a hard time following why this patch is being requested. Help
me catch on.
On 1/16/2018 8:54 PM, Jianchao Wang wrote:
Currently, the ctrl->state will be changed to NVME_CTRL_RESETTING
before queue the reset work. This is not so strict. There could be
a big gap before the reset_wo
Thanks jianchoa. This helped.
On 1/17/2018 7:13 PM, jianchao.wang wrote:
Actually, this patchset is to fix a issue in nvme_timeout.
Please consider the following scenario.
nvme_reset_ctrl
-> set state to RESETTING
-> queue reset_work
(scheduling)
nvm
of function 'lpfc_nvmet_cmd_template'
Signed-off-by: Colin Ian King
---
drivers/scsi/lpfc/lpfc_nvme.c | 8
drivers/scsi/lpfc/lpfc_nvmet.c | 8
2 files changed, 8 insertions(+), 8 deletions(-)
Signed-off-by: James Smart
/core.c b/drivers/nvme/host/core.c
index e541fe268bcf..99dd62c1076c 100644
good for the fc side...
Reviewed-by: James Smart
On 5/31/2018 2:31 AM, Sagi Grimberg wrote:
Question, why isn't tfcp_req embedded in fcpreq? don't they have
the same lifetime?
no they don't. To properly simulate cable-pulls, etc - the host side
and controller side effectively have their own "exchange" structure.
tfcp_req corresponds t
(!rport->targetport)
return -ECONNREFUSED;
- tfcp_req = kzalloc(sizeof(*tfcp_req), GFP_KERNEL);
+ tfcp_req = kzalloc(sizeof(*tfcp_req), GFP_ATOMIC);
if (!tfcp_req)
return -ENOMEM;
Reviewed-by: James Smart
] start_secondary+0x18f/0x1b0
Signed-off-by: Johannes Thumshirn
Cc: James Smart
---
drivers/nvme/target/fcloop.c | 52
1 file changed, 29 insertions(+), 23 deletions(-)
Looks ok. I assume it is as the bio_done call can be in an interrupt
handler.
Reviewed-by: James Smart
Alex,
Myself and several others here at Emulex maintain the code. The
recommendations look fine. Feel free to post something if you beat us
to the work.
-- james s
On 12/3/2014 11:05 AM, Alex Thorlton wrote:
On Tue, Dec 02, 2014 at 10:39:40PM +, Elliott, Robert (Server Storage)
wrot
ould be created with fewer than the total number of entries.
As odd as it sounds, and as far as I can tell, the number of SG entries
mapped does not appear to be used anywhere in the fc driver and therefore
there's no current need to store it.
Signed-off-by: Logan Gunthorpe
Cc: James Smart
On 3/29/2018 9:30 AM, Logan Gunthorpe wrote:
Can you elaborate? The 'data_sg_cnt' member was in 'struct
nvmet_fc_fcp_iod' which is declared in fc.c so it doesn't seem sane for
lower driver to access it... In fact the next patch in the series
removes it completely.
Logan
actually, I do think it
the SGLs for
the request.
To do this, we drop the appearantly redundant data_sg and data_sg_cnt
members as they are identical to the existing req.sg and req.sg_cnt.
Signed-off-by: Logan Gunthorpe
Cc: James Smart
Cc: Christoph Hellwig
Cc: Sagi Grimberg
---
On 3/29/2018 10:02 AM, Logan Gunthorpe wrote:
Per the bug in the previous patch, I don't think that was ever a valid
assumption. It doesn't have anything to do with the sgl_alloc change
either. The dma_map interface is allowed to merge SGLs and that's why it
can return fewer nents than it was pas
On 12/24/2020 3:05 AM, leonid.rav...@dell.com wrote:
From: Leonid Ravich
to remove locking from nvmet_fc_find_target_queue
which called per IO.
Signed-off-by: Leonid Ravich
---
drivers/nvme/target/fc.c | 54
1 file changed, 32 insertions(+),
+++-
1 file changed, 38 insertions(+), 43 deletions(-)
Reviewed-by: James Smart
-- james
smime.p7s
Description: S/MIME Cryptographic Signature
(-)
Reviewed-by: James Smart
-- james
smime.p7s
Description: S/MIME Cryptographic Signature
unction is called with hbalock held.
**/
-void
+static void
lpfc_nvmet_prep_abort_wqe(struct lpfc_iocbq *pwqeq, u16 xritag, u8 opt)
{
union lpfc_wqe128 *wqe = &pwqeq->wqe;
Zou, Thank You . I just submitted the same patch. Either one Martin
wants to take.. :)
-- james
R
= lpfc_cmd->rdata;
+ ndlp = rdata->pnode;
+
if (bf_get(lpfc_wcqe_c_xb, wcqe)) {
/* TOREMOVE - currently this flag is checked during
* the release of lpfc_iocbq. Remove once we move
Looks good.
Reviewed-by: James Smart
-- james
smime
* we respond
*/
Looks good.
Reviewed-by: James Smart
-- james
smime.p7s
Description: S/MIME Cryptographic Signature
goto rjt;
+ goto rjt_free;
}
return 0;
+
+rjt_free:
+ kfree(lcb_context);
rjt:
memset(&stat, 0, sizeof(stat));
stat.un.b.lsRjtRsnCode = rjt_err;
Looks good.
Reviewed-by: James Smart
-- james
smime.p7s
Description: S/MIME Cryptographic Signature
pfc driver supports the Emulex LightPulse
Family of Fibre Channel PCI host adapters.
Reviewed-by: James Smart
-- james
Acked-by: James Smart
-- james s
On 2/20/2014 8:10 PM, Daeseok Youn wrote:
>From 9e7478f6e953fac5b2bef0f5abe76fe8dc9e59d1 Mon Sep 17 00:00:00 2001
From: Daeseok Youn
Date: Fri, 21 Feb 2014 09:03:32 +0900
Subject: [PATCH] [SCSI] lpfc 8.3.43: use NULL instead of 0 for pointer
sparse s
Hi Alexander,
The change is fine - but not really necessary. The pci_disable_msix()
call explicitly checks for enablement so it's safe.
It really is a superfluous change - but if James wants to take it:
Acked-by: James Smart
-- james s
On 2/4/2014 6:16 AM, Alexander Gordeev
aces need to be updated to use the
new pci_enable_msi_range() and pci_enable_msix_range()
interfaces.
CC: Alexander Gordeev
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: James Smart
---
lpfc_init.c | 43 ++-
1 f
James,
I'd like to attend to participate in the EH, MQ, and T10 PI RDMA
discussions.
-- james s
On 1/16/2014 11:29 AM, Sagi Grimberg wrote:
On 1/16/2014 1:05 AM, Nicholas A. Bellinger wrote:
Hi all,
I'd like to discuss the current state of scsi-mq prototype code.
And now that blk-mq is
Acked-by: James Smart
-- james s
On 10/15/2013 8:29 PM, Felipe Pena wrote:
In the lpfc_ct_free_iocb function after freeing associated memory to the
ctiocb->context3, the ctiocb->context1 is set to NULL instead of context3.
Signed-off-by: Felipe Pena
---
drivers/scsi/lpfc/lpfc_ct.c
Thanks!
Acked-by: James Smart
-- james s
On 10/18/2013 7:15 PM, Felipe Pena wrote:
On lpfc_debugfs_initialize function the dumpHostSlim member setup happens
when 'phba->sli_rev < LPFC_SLI_REV4' is true, however when it is false NULL
has been assigned to debug_dumpHB
Mike,
Can you confirm - the "nulls" this patch correct are because the
probe_one and error_detect threads are running concurrently, thus battling ?
If so - this fix looks insufficient and we should rework it.
Q: why are they allowed to run concurrently ? I could see this solved
at the platf
s need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Hi James,
Could you please review this patch?
James?
Thanks!
Signed-off-by: Alexander Gordeev
Cc: James Smart
Cc: linux-s...@vger.kernel.org
Cc: linux-...
On 8/14/2015 2:32 AM, Hannes Reinecke wrote:
On 08/13/2015 01:50 PM, Johannes Thumshirn wrote:
Export the RAW SCSI Inquiry to sysfs as binfile. This way the data can be
used by userlang without the need to have and ioctl or use the sg_inq tool.
userland!
Just be careful. There are condition
fyi - this patch was just pushed in our 11.0.0.10 patch set - patch 15/17
-- james s
On 11/17/2015 12:44 AM, SF Markus Elfring wrote:
From: Markus Elfring
Date: Tue, 17 Nov 2015 09:34:27 +0100
The mempool_destroy() function tests whether its argument is NULL
and then returns immediately. Thu
fyi - this patch was just pushed in our 11.0.0.10 patch set - patch 16/17
-- james s
On 10/24/2015 8:25 PM, Matthew R. Ochs wrote:
On Oct 24, 2015, at 2:06 AM, Punit Vara wrote:
This patch is to the lpfc_els.c which resolves following warning
reported by coccicheck:
WARNING: kzalloc should
fyi - this patch was just pushed in our 11.0.0.10 patch set - patch 16/17
Note: Patch 16 contains the exact same patch submitted by Punit Vara. I
posted Punit's change only as it arrived earlier.
-- james s
On 11/18/2015 11:34 PM, Saurabh Sengar wrote:
replacing kmalloc and memset by a sin
1 - 100 of 174 matches
Mail list logo
