Re: [PATCH 2/6] cxlflash: Fix to avoid virtual LUN failover failure

> Virtual LUNs may be accessed through one or both ports of the adapter. Is it possible that there might ever be adapters with a number of ports other than 2? In particular, is it possible for 3 or 4 port adapters to exist? If so, do you need something with a bit more fidelity? If not, this is

Re: [PATCH 3/6] cxlflash: Updated date of the driver

Hi Uma, It looks like CXLFLASH_DRIVER_DATE is only used once, on init, and it's just printed. Is it necessary? It looks like having it will require sending a patch to update it quite often. Regards, Daniel signature.asc Description: PGP signature

Re: [PATCH v5 17/34] cxlflash: Remove dual port online dependency

> Note that despite its void-like behavior, the function was left with a > return code for right now in case its behavior needs to be altered again > in the near future based on testing. > Thanks for updating that. Reviewed-by: Daniel Axtens <d...@axtens.net> Regards, Daniel

Re: [PATCH v5 18/34] cxlflash: Fix AFU version access/storage and add check

"Matthew R. Ochs" writes: > The AFU version is stored as a non-terminated string of bytes within > a 64-bit little-endian register. Presently the value is read directly > (no MMIO accessor) and is stored in a buffer that is not big enough > to contain a NULL

Re: [PATCH v5 18/34] cxlflash: Fix AFU version access/storage and add check

ge, but it's not worth holding up the series for it. I also tend to use the form (var == ~0ULL) for tests like this but that's an aesthetic thing. Reviewed-by: Daniel Axtens <d...@axtens.net> Regards, Daniel signature.asc Description: PGP signature

Re: [PATCH v4 25/32] cxlflash: Fix to prevent EEH recovery failure

o avoid potential deadlock on EEH". Without this fix, you'd end > up in a similar situation but deadlocked on the context mutex instead > of the ioctl semaphore. That makes _much_ more sense. If you could please revise the commit message to explain that, you can include this in the next version:

Re: [PATCH v4 27/32] cxlflash: Fix to prevent stale AFU RRQ

here, so I'm not sure how the all Fs check > would apply. We're also protected fairly well by the generation bit. I suppose > we could look at adding some type of 'max iterations' count to protect against > a runaway handler but that would be in a future patch. Ah, right you are. I had c

Re: [PATCH v4 17/32] cxlflash: Remove dual port online dependency

(resending to the list this time, apologies!) >> I'm not sure I fully understand the flow of this function, but it looks >> like you set rc=0 regardless of how things actually go: is this ever >> going to print a return value other than zero? > > Correct, this function behaves more like a void

Re: [PATCH v4 32/32] cxlflash: Fix to avoid potential deadlock on EEH

adapter is > still being recovered or returns a failure if the recovery failed. In > the event that the adapter reset failed, the failure is simply returned > as the ioctl would be unable to continue. Yep, looks good. Reviewed-by: Daniel Axtens <d...@axtens.net> > > Reported-b

Re: [PATCH v4 29/32] cxlflash: Fix to double the delay each time

"Matthew R. Ochs" <mro...@linux.vnet.ibm.com> writes: >> On Sep 28, 2015, at 8:40 PM, Daniel Axtens <d...@axtens.net> wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> "Matthew R. Ochs" <mro...@linux.vn

Re: [PATCH v4 30/32] cxlflash: Fix to avoid corrupting adapter fops

vert to a model that > does not require an embedded fops. Yep, this looks good. We have discussed adding a private data field to a cxl context, and will no doubt revisit the question at some point in the future :) Reviewed-by: Daniel Axtens <d...@axtens.net> > > Signed-off-by: Matthew

Re: [PATCH v4 07/32] cxlflash: Fix context encode mask width

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Looks good to me. Reviewed-by: Daniel Axtens <d...@axtens.net> Regards, Daniel "Matthew R. Ochs" <mro...@linux.vnet.ibm.com> writes: > The context encode mask covers more than 32-bits, making it > a long i

Re: [PATCH v4 09/32] cxlflash: Correct naming of limbo state and waitq

well. Reviewed-by: Daniel Axtens <d...@axtens.net> > Limbo is not an accurate representation of this state and is > also not consistent with the terminology that other drivers > use to represent this concept. Rename the state and and its > associated waitq to 'reset'. >

Re: [PATCH v4 06/32] cxlflash: Fix to avoid sizeof(bool)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Looks good to me. Reviewed-by: Daniel Axtens <d...@axtens.net> Regards, Daniel "Matthew R. Ochs" <mro...@linux.vnet.ibm.com> writes: > Using sizeof(bool) is considered poor form for various reasons and > spar

Re: [PATCH v4 08/32] cxlflash: Fix to avoid CXL services during EEH

+ * Before checking the state, put back the context obtained with > + * get_context() as it is no longer needed and sleep for a short > + * period of time (see prolog notes). > + */ > + put_context(ctxi); Is this needed for the

Re: [PATCH v4 17/32] cxlflash: Remove dual port online dependency

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, > static int afu_set_wwpn(struct afu *afu, int port, u64 *fc_regs, u64 wwpn) > { > - int ret = 0; > + int rc = 0; I realise it's nice to have things consistent, but making this change now makes the rest of the patch quite difficult to

Re: [PATCH v4 27/32] cxlflash: Fix to prevent stale AFU RRQ

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 "Matthew R. Ochs" writes: > Following an adapter reset, the AFU RRQ that resides in host memory > holds stale data. This can lead to a condition where the RRQ interrupt > handler tries to process stale entries and/or

Re: [PATCH v4 29/32] cxlflash: Fix to double the delay each time

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 "Matthew R. Ochs" writes: > From: Manoj Kumar > > The operator used to double the delay is incorrect and > does not result in delay doubling. > > To fix, use a left shift instead of the XOR

Re: [PATCH v4 25/32] cxlflash: Fix to prevent EEH recovery failure

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 "Matthew R. Ochs" writes: > The process_sense() routine can perform a read capacity which > can take some time to complete. If an EEH occurs while waiting > on the read capacity, the EEH handler is unable to obtain the

Re: [PATCH v4 1/3] cxlflash: Base error recovery support

Actually, I forgot one thing: config CXLFLASH tristate Support for IBM CAPI Flash - depends on PCI SCSI CXL + depends on PCI SCSI CXL EEH Should you depend on CXL_EEH here, seeing as you use CONFIG_CXL_EEH? +#ifndef CONFIG_CXL_EEH +#define

Re: [PATCH v4 1/3] cxlflash: Base error recovery support

On Tue, 2015-08-11 at 16:21 +1000, Daniel Axtens wrote: Actually, I forgot one thing: config CXLFLASH tristate Support for IBM CAPI Flash - depends on PCI SCSI CXL + depends on PCI SCSI CXL EEH Should you depend on CXL_EEH here, seeing as you use CONFIG_CXL_EEH

Re: [PATCH v4 1/3] cxlflash: Base error recovery support

-by: Daniel Axtens d...@axtens.net -- Regards, Daniel signature.asc Description: This is a digitally signed message part

Re: [PATCH v3 2/4] cxlflash: Base error recovery support

Hi, @@ -1857,9 +1884,18 @@ static int cxlflash_eh_device_reset_handler(struct scsi_cmnd *scp) get_unaligned_be32(((u32 *)scp-cmnd)[2]), get_unaligned_be32(((u32 *)scp-cmnd)[3])); - rcr = send_tmf(afu, scp, TMF_LUN_RESET); - if (unlikely(rcr)) -

Re: [PATCH v3 2/4] cxlflash: Base error recovery support

On Wed, 2015-08-05 at 17:30 -0500, Matthew R. Ochs wrote: Hi Brian, Thanks for reviewing. Comments inline below. -matt On Aug 5, 2015, at 11:04 AM, Brian King brk...@linux.vnet.ibm.com wrote: On 08/02/2015 11:33 PM, Matthew R. Ochs wrote: diff --git