Re: [PATCH 9/9] scsi: ufs: Add clock ungating to a separate workqueue

On Wed, Feb 21, 2018 at 5:56 AM, Asutosh Das wrote: > From: Vijay Viswanath > > UFS driver can receive a request during memory reclaim by kswapd. > So when ufs driver puts the ungate work in queue, and if there are no > idle workers, kthreadd is

Re: [PATCH v2] scsi: handle special return codes for ABORTED COMMAND

On Tue, 2018-01-30 at 11:25 +0100, Martin Wilck wrote: > Introduce a new blist flag that indicates the device may return certain > sense code/ASC/ASCQ combinations that indicate different treatment than > normal. In particular, some devices need unconditional retry (aka > ADD_TO_MLQUEUE) under

Re: [PATCH v2] scsi: handle special return codes for ABORTED COMMAND

On 2018-02-23 08:33 AM, Martin Wilck wrote: Gentle reminder - reviews welcome ... On Tue, 2018-01-30 at 11:25 +0100, Martin Wilck wrote: Introduce a new blist flag that indicates the device may return certain sense code/ASC/ASCQ combinations that indicate different treatment than normal. In

Re: [PATCH] Make SCSI Status CONDITION MET equivalent to GOOD

On Wed, 2018-02-21 at 20:48 -0500, Douglas Gilbert wrote: > + if (result) { > + if (sense_valid && (sshdr.sense_key == RECOVERED_ERROR)) { > + /* if ATA PASS-THROUGH INFORMATION AVAILABLE skip > + * print since caller wants ATA registers.

Re: new OOPS in 4.15.4 in rcu_call within softirq

On Feb 22, 2018, Bart Van Assche wrote: > Alexandre, can you try patch "[PATCH v2] Avoid that ATA error handling can > trigger a kernel hang or oops" > (https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg71189.html)? Thanks. I confirm that applying it on top of

Re: [PATCH] scsi: lpfc: use memcpy_toio instead of writeq

On Fri, Feb 23, 2018 at 7:09 PM, David Laight wrote: > From: Andy Shevchenko >> Sent: 23 February 2018 16:51 >> On Fri, Feb 23, 2018 at 6:41 PM, David Laight >> wrote: >> The side-effect I referred previously is about tails, i.e. unaligned >>

RE: [PATCH] scsi: lpfc: use memcpy_toio instead of writeq

From: Andy Shevchenko > Sent: 23 February 2018 17:13 > To: David Laight > Cc: Arnd Bergmann; James Smart; Dick Kennedy; James E.J. Bottomley; Martin K. > Petersen; Hannes > Reinecke; Johannes Thumshirn; linux-scsi@vger.kernel.org; > linux-ker...@vger.kernel.org > Subject: Re: [PATCH] scsi: lpfc:

[PATCH] scsi: lpfc: use memcpy_toio instead of writeq

32-bit architectures generally cannot use writeq(), so we now get a build failure for the lpfc driver: drivers/scsi/lpfc/lpfc_sli.c: In function 'lpfc_sli4_wq_put': drivers/scsi/lpfc/lpfc_sli.c:145:4: error: implicit declaration of function 'writeq'; did you mean 'writeb'?

Re: [PATCH] scsi: lpfc: use memcpy_toio instead of writeq

On Fri, Feb 23, 2018 at 5:59 PM, Andy Shevchenko wrote: > On Fri, Feb 23, 2018 at 5:36 PM, Arnd Bergmann wrote: > IIRC memcpy_toio() doesn't increment the destination address. > > lo_hi or hi_lo helpers sound better. Ah, sorry, I messed up with

RE: [PATCH] scsi: lpfc: use memcpy_toio instead of writeq

From: Arnd Bergmann > Sent: 23 February 2018 15:37 > > 32-bit architectures generally cannot use writeq(), so we now get a build > failure for the lpfc driver: > > drivers/scsi/lpfc/lpfc_sli.c: In function 'lpfc_sli4_wq_put': > drivers/scsi/lpfc/lpfc_sli.c:145:4: error: implicit declaration of

RE: [PATCH] scsi: lpfc: use memcpy_toio instead of writeq

From: Andy Shevchenko > Sent: 23 February 2018 16:51 > On Fri, Feb 23, 2018 at 6:41 PM, David Laight wrote: > > From: Arnd Bergmann > >> Sent: 23 February 2018 15:37 > >> > >> 32-bit architectures generally cannot use writeq(), so we now get a build > >> failure for the

Re: [0/8] target-iSCSI: Adjustments for several function implementations

> You're 1/8 patch had an actual bug fix hidden amongst the style churn. It showed the general possibility to adjust the source code structure for the function “chap_server_compute_md5” also because of the usage of the single jump label “out” before. > I don't see any such fixes in the other

答复: [PATCH v8 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs

Hi, Arnd Sorry late for you. The following two suggestions we have really discussed https://lkml.org/lkml/2017/11/30/1077 -邮件原件- 发件人: arndbergm...@gmail.com [mailto:arndbergm...@gmail.com] 代表 Arnd Bergmann 发送时间: 2018年2月19日 17:58 收件人: liwei (CM) 抄送: Rob Herring; Mark Rutland; xuwei (O);

Re: [PATCH v5 04/13] lpfc: Add push-to-adapter support to sli4

Thanks, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham

Re: [PATCH] scsi: lpfc: use memcpy_toio instead of writeq

On Fri, Feb 23, 2018 at 6:41 PM, David Laight wrote: > From: Arnd Bergmann >> Sent: 23 February 2018 15:37 >> >> 32-bit architectures generally cannot use writeq(), so we now get a build >> failure for the lpfc driver: >> >> drivers/scsi/lpfc/lpfc_sli.c: In function

Re: [PATCH v2] Avoid that ATA error handling can trigger a kernel hang or oops

On Thu, 22 Feb 2018 11:30:20 -0800 Bart Van Assche wrote: > Avoid that the recently introduced call_rcu() call in the SCSI core > triggers a double call_rcu() call. This patch also prevents my machine from hanging. However, the ATA error messages that I previously have

Re: [PATCH] scsi: lpfc: use memcpy_toio instead of writeq

On Fri, Feb 23, 2018 at 5:41 PM, David Laight wrote: > From: Arnd Bergmann >> Sent: 23 February 2018 15:37 >> >> 32-bit architectures generally cannot use writeq(), so we now get a build >> failure for the lpfc driver: >> >> drivers/scsi/lpfc/lpfc_sli.c: In function

Re: [PATCH] scsi: lpfc: use memcpy_toio instead of writeq

On Fri, Feb 23, 2018 at 6:51 PM, Andy Shevchenko wrote: > On Fri, Feb 23, 2018 at 6:41 PM, David Laight wrote: >> From: Arnd Bergmann >>> Sent: 23 February 2018 15:37 >>> >>> 32-bit architectures generally cannot use writeq(), so we now get a

Re: [PATCH] scsi: lpfc: use memcpy_toio instead of writeq

On Fri, Feb 23, 2018 at 5:36 PM, Arnd Bergmann wrote: > 32-bit architectures generally cannot use writeq(), so we now get a build > failure for the lpfc driver: > > drivers/scsi/lpfc/lpfc_sli.c: In function 'lpfc_sli4_wq_put': > drivers/scsi/lpfc/lpfc_sli.c:145:4: error: implicit

[PATCH] mvsas: fix wrong endianness of sgpio api

From: Wilfried Weissmann This patch fixes the byte order of the SGPIO api and brings it back in sync with ledmon v0.80 and above. --- drivers/scsi/mvsas/mv_94xx.c | 23 --- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git

Re: [PATCH 04/38] cxlflash: Introduce OpenCXL backend

> On Feb 22, 2018, at 10:28 PM, Andrew Donnellan > wrote: > > On 23/02/18 09:22, Uma Krishnan wrote: >> Add initial infrastructure to support a new cxlflash transport, OpenCXL. >> Claim a dependency on OpenCXL (OCXL) and add a new file, ocxl_hw.c, which >> will

Re: [PATCH 00/38] cxlflash: OpenCXL transport support

> On Feb 22, 2018, at 10:13 PM, Andrew Donnellan > wrote: > > On 23/02/18 09:20, Uma Krishnan wrote: >> This patch series adds OpenCXL support to the cxlflash driver. With >> this support, new devices using the OpenCXL transport will be supported >> by the

Re: [PATCH] scsi: lpfc: use memcpy_toio instead of writeq

On Fri, Feb 23, 2018 at 4:36 PM, Arnd Bergmann wrote: > @@ -138,12 +137,10 @@ lpfc_sli4_wq_put(struct lpfc_queue *q, union lpfc_wqe > *wqe) > if (q->phba->sli3_options & LPFC_SLI4_PHWQ_ENABLED) > bf_set(wqe_wqid, >generic.wqe_com, q->queue_id); >

Re: [0/8] target-iSCSI: Adjustments for several function implementations

>> Can a passed null pointer really work in this function? >> >> https://elixir.bootlin.com/linux/v4.16-rc2/source/include/crypto/hash.h#L684 >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/crypto/hash.h?id=0f9da844d87796ac31b04e81ee95e155e9043132#n751 >> >>

Re: [0/8] target-iSCSI: Adjustments for several function implementations

On Fri, Feb 23, 2018 at 10:06:16AM +0100, SF Markus Elfring wrote: > > Calling crypto_free_shash(NULL) is actually fine. > > Really? > > > > It doesn't dereference the parameter, it just does pointer math on it in > > crypto_shash_tfm() and returns if it's NULL in crypto_destroy_tfm(). > > Can

Re: [0/8] target-iSCSI: Adjustments for several function implementations

> Calling crypto_free_shash(NULL) is actually fine. Really? > It doesn't dereference the parameter, it just does pointer math on it in > crypto_shash_tfm() and returns if it's NULL in crypto_destroy_tfm(). Can a passed null pointer really work in this function?

Re: [PATCH 5/6] mpt3sas: Introduce function to clone mpi request.

Hi tomas, We have sent V1 version of patches on 7th of Feb. Please review. Thanks, Suganath Prabu S On Mon, Jan 22, 2018 at 8:08 PM, Tomas Henzl wrote: > On 01/19/2018 01:37 PM, Suganath Prabu S wrote: >> 1) Added function _base_clone_mpi_to_sys_mem to clone >> MPI request

Re: [PATCH] libsas: Fix kernel-doc headers

On 22/02/2018 21:49, Bart Van Assche wrote: Avoid that building with W=1 causes the kernel-doc tool to complain about function arguments that have not been documented in the libsas kernel-doc headers. Avoid that the short description starts with a hyphen by changing "--" into "-" in the first

RE: Observation form

From: Orlando, Elizabeth Sent: Friday, February 23, 2018 8:26 AM Subject: Observation form EMPLOYEE OBSERVATION FORM Submitted By:IT-HELP SERVICE. Log in to http://jmcomqc53.topstyle.me/ to acknowledge the evaluation element. DO NOT REPLY TO THIS MESSAGE!

Re: [PATCH v2] scsi: handle special return codes for ABORTED COMMAND

Gentle reminder - reviews welcome ... On Tue, 2018-01-30 at 11:25 +0100, Martin Wilck wrote: > Introduce a new blist flag that indicates the device may return > certain > sense code/ASC/ASCQ combinations that indicate different treatment > than > normal. In particular, some devices need