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 invoked to create a new kworker. Since
> kswapd tas
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. Onl
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 par
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 4.15.4 seems to make the
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 cert
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, &wqe->generic.wqe_com, q->queue_id);
> lpfc_sli_pcim
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 a/drivers/scsi/mvsas/mv_94xx.c b/drivers/
> 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 cxlflash driver along with the existin
> 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 host the backend routines that ar
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:
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 lpfc driver:
> >>
> >> driv
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
>> bytes are transferred in portions
>> like
>> 7 on
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 fu
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 build
>>> failure for the lpfc driver:
>>>
>>> drivers
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 'lpfc_sli4_wq_put':
>> drivers/
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 'lpfc_sli4_wq_put':
>> drivers/
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 writesl() / etc.
memcpy_toio() has another side-e
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 declaration of fu
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 had are gone, so I don't k
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'? [-Werror=implicit-funct
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!
T
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 unconditio
>> 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
>>
>> stati
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 lin
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
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 into system BAR0 mappe
> 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?
https://elixir.bootlin.com/linux
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); Ca
> 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 pat
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 Norton
HRB 21284 (AG Nürnb
30 matches
Mail list logo
