On Mon, Nov 7, 2016 at 8:48 PM, John Garry wrote:
> From: Xiang Chen
>
> Replace WARN_ON() with dev_warn() print when internal abort fails.
>
> Signed-off-by: Xiang Chen
> Signed-off-by: John Garry
Reviewed-by: Zhangfei Gao
Sorry, miss this one.
--
To unsubscribe from this list: send the line
On 16/11/2016 01:47, Zhangfei Gao wrote:
On Mon, Nov 7, 2016 at 8:48 PM, John Garry wrote:
From: Xiang Chen
For ECC 1bit error, logic can recover it, so we only print
a warning.
For ECC multi-bit and AXI bus fatal error, we panic.
Is it possible to recover via resetting phy and device etc i
On Wed, Nov 23, 2016 at 4:59 PM, John Garry wrote:
> On 16/11/2016 01:47, Zhangfei Gao wrote:
>>
>> On Mon, Nov 7, 2016 at 8:48 PM, John Garry wrote:
>>>
>>> From: Xiang Chen
Reviewed-by: Zhangfei Gao
>>>
>>> For ECC 1bit error, logic can recover it, so we only print
>>> a warning.
>>> For EC
The BUG_ON() recently introduced in lpfc_sli_ringtxcmpl_put()
is hit in the lpfc_els_abort() > lpfc_sli_issue_abort_iotag()
> lpfc_sli_abort_iotag_issue() function path [similar names],
due to 'piocb->vport == NULL':
BUG_ON(!piocb || !piocb->vport);
This happens because lpfc_sli_abort_io
Due credit; an oversight.
On 11/23/2016 10:33 AM, Mauricio Faria de Oliveira wrote:
Reported-by: Harsha Thyagaraja
Cc: sta...@vger.kernel.org # v4.8
Fixes: 22466da5b4b7 ("lpfc: Fix possible NULL pointer dereference")
Signed-off-by: Mauricio Faria de Oliveira
--
Mauricio Faria de Oliveira
On a 32 bit kernel sizeof(void *) is not 64 bits as hv_mpb_array
requires. Also the buffer needs to be cleared or the upper bytes
will contain junk.
Suggested-by: Vitaly Kuznetsov
Signed-off-by: Cathy Avery
ChangeLog:
v1) Initial submission
v2) Remove memset and replace kmalloc with kzalloc.
-
On Wed, Nov 23, 2016 at 10:33:19AM -0200, Mauricio Faria de Oliveira wrote:
> The BUG_ON() recently introduced in lpfc_sli_ringtxcmpl_put()
> is hit in the lpfc_els_abort() > lpfc_sli_issue_abort_iotag()
> > lpfc_sli_abort_iotag_issue() function path [similar names],
> due to 'piocb->vport == NULL
On 11/23/2016 12:12 PM, Johannes Thumshirn wrote:
Looks good and sorry for the bug,
Reviewed-by: Johannes Thumshirn
Thanks for the quick review. Not a problem!
This problem turned out to be a good learning exercise. :)
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
--
To unsubscr
G. Steve Batija
Operations / regionalni direktor
Santander Bank Plc,
47-48 Piccadilly
PICCADILLY
W1J0DT
London, Združeno Kraljestvo
Good Day Spoštovani,
Kako se vi in ??vaša družina? Upam, da danes moje pismo ste se sestaja na svoje
najboljše razpoloženje. Sem Dr. Steve Batija, od Harlesden Nor
- Original Message -
> From: "Eyal Ben David"
> To: "Ewan D. Milne"
> Cc: "Johannes Thumshirn" , dgilb...@interlog.com,
> "Laurence Oberman" ,
> linux-scsi@vger.kernel.org
> Sent: Tuesday, November 22, 2016 3:55:44 PM
> Subject: Re: SG does not ignore dxferp (direct io + mmap)
>
> On
On Wed, 2016-11-23 at 13:55 -0500, Laurence Oberman wrote:
>
> - Original Message -
> > From: "Eyal Ben David"
> > To: "Ewan D. Milne"
> > Cc: "Johannes Thumshirn" , dgilb...@interlog.com,
> > "Laurence Oberman" ,
> > linux-scsi@vger.kernel.org
> > Sent: Tuesday, November 22, 2016 3:55:
qlogicpti uses '__u32' for dma handle while invoking kernel DMA APIs,
instead of using dma_addr_t. This hasn't caused any 'incompatible
pointer type' warning on SPARC because until now dma_addr_t is of
type u32. However, recent changes in SPARC ATU (iommu) enabled 64bit
DMA and therefore dma_addr_t
On Wed, 2016-11-23 at 13:29 -0800, Tushar Dave wrote:
> qlogicpti uses '__u32' for dma handle while invoking kernel DMA APIs,
> instead of using dma_addr_t. This hasn't caused any 'incompatible
> pointer type' warning on SPARC because until now dma_addr_t is of
> type u32. However, recent changes i
LSIs must be ack'ed with an MMIO otherwise they remain asserted
forever. This is controlled by the "clear_isr" flag.
While we set that flag properly when deciding initially whether
to use LSIs or MSIs, we fail to set it if we first chose MSIs,
the test fails, then fallback to LSIs.
Signed-off-by:
From: Yaniv Gardi
According to JESD220B - UFS v2.0, the maximum size of device descriptor
has changed from 0x1F to 0x40. This patch updates the maximum size of
this descriptor.
Signed-off-by: Yaniv Gardi
Signed-off-by: Subhash Jadavani
---
drivers/scsi/ufs/ufs.h | 2 +-
1 file changed, 1 inse
From: Dolev Raviv
The PHY_ADAPTER_ERROR status register indicates PHY lane errors
reported by the M-PHY layer. In some occasions the controller
can recover from such errors. When the error is not recoverable,
a stuck DB error will occur. Since the stuck DB error is spotted
separately, no action o
Some UFS devices require host PA_TACTIVATE to be higher than
device PA_TACTIVATE otherwise it may get stuck during hibern8 sequence.
This change allows this by using quirk.
Reviewed-by: Venkat Gopalakrishnan
Signed-off-by: Subhash Jadavani
---
drivers/scsi/ufs/ufs_quirks.h | 9 ++
drivers/
From: Yaniv Gardi
The condition in which error message is printed out was incorrect and
resulted error message only if retries exhausted.
But retries happens only if DME command is a peer command, and thus
DME commands which are not peer commands and fail are not printed out.
This change fixes th
If we issue the link startup to the device while its UniPro state is
LinkDown (and device state is sleep/power-down) then link startup
will not move the device state to Active. Device will only move to
active state if the link starup is issued when its UniPro state is
LinkUp. So in this case, we wo
From: Yaniv Gardi
When sending query to the device, the index of the failure
is additional useful information that should be printed out as it
might specify the logical unit (LU) where the error occurred.
Signed-off-by: Yaniv Gardi
Signed-off-by: Subhash Jadavani
---
drivers/scsi/ufs/ufshcd.
It is found thats UFS device may take longer than 30ms to respond to
query requests and in this case we might run into following scenario:
1. UFS host SW sends a query request to UFS device to read an attribute
value. SW uses tag #31 for this purpose.
2. UFS host SW waits for 30ms to get the qu
While reading variable size descriptors (like string descriptor), some UFS
devices may report the "LENGTH" (field in "Transaction Specific fields" of
Query Response UPIU) same as what was requested in Query Request UPIU
instead of reporting the actual size of the variable size descriptor.
Although
Consider following sequence of events:
1. UFS is runtime suspended, link_state = Hibern8, device_state = sleep
2. System goes into system suspend, ufshcd_system_suspend() brings both
link and device to active state and then puts the device in Power_Down
state and link in OFF state.
3. System
We would by default like to run in FAST/SLOW mode instead
of FASTAUTO/SLOWAUTO mode for performance reasons. This
change sets the default speed mode to FAST/SLOW mode.
Reviewed-by: Venkat Gopalakrishnan
Signed-off-by: Subhash Jadavani
---
drivers/scsi/ufs/ufshcd.c | 8
1 file changed,
From: Dolev Raviv
Some of the queries might fail during init. To avoid
system failure, we add retry mechanism to issue queries
several times.
Signed-off-by: Dolev Raviv
Signed-off-by: Subhash Jadavani
---
drivers/scsi/ufs/ufshcd.c | 54 +++
1 file c
On 11/23/2016 02:57 PM, James Bottomley wrote:
On Wed, 2016-11-23 at 13:29 -0800, Tushar Dave wrote:
qlogicpti uses '__u32' for dma handle while invoking kernel DMA APIs,
instead of using dma_addr_t. This hasn't caused any 'incompatible
pointer type' warning on SPARC because until now dma_addr
From: James Bottomley
Date: Wed, 23 Nov 2016 14:57:39 -0800
> What's the guarantee, since the device descriptors only cope with 32
> bits of physical address, that this driver never gets any dma address
> beyond its addressable range? Is it that the sbus can never be
> attached to this ATU type
From: tndave
Date: Wed, 23 Nov 2016 17:08:23 -0800
> As per my understanding, I think, all DMA map/unmap go through
> ATU (iommu) in sun4v sparc. To guarantee that driver doesn't get DMA
> address beyond its addressable range , driver must set dma mask before
> requesting any DMA mapping!
>
> I
On 11/23/2016 05:25 PM, David Miller wrote:
From: tndave
Date: Wed, 23 Nov 2016 17:08:23 -0800
As per my understanding, I think, all DMA map/unmap go through
ATU (iommu) in sun4v sparc. To guarantee that driver doesn't get DMA
address beyond its addressable range , driver must set dma mask b
qlogicpti uses '__u32' for dma handle while invoking kernel DMA APIs,
instead of using dma_addr_t. This hasn't caused any 'incompatible
pointer type' warning on SPARC because until now dma_addr_t is of
type u32. However, recent changes in SPARC ATU (iommu) enabled 64bit
DMA and therefore dma_addr_t
Hi, Vinayak
Checked 4.9-rc6, and not find UFS_MASK macro definition.
Have find this patch from google,
http://www.spinics.net/lists/linux-scsi/msg58634.html
[PATCH 2/2] [SCSI] ufs: Add missing UFS_MASK macro definition
Is this patch has been merged?
There will be build error if some definition
On 2016-11-23 19:23, Zhangfei Gao wrote:
Hi, Vinayak
Checked 4.9-rc6, and not find UFS_MASK macro definition.
Have find this patch from google,
http://www.spinics.net/lists/linux-scsi/msg58634.html
[PATCH 2/2] [SCSI] ufs: Add missing UFS_MASK macro definition
Is this patch has been merged?
G
On Thu, Nov 24, 2016 at 12:21 PM, Subhash Jadavani
wrote:
> On 2016-11-23 19:23, Zhangfei Gao wrote:
>>
>> Hi, Vinayak
>>
>> Checked 4.9-rc6, and not find UFS_MASK macro definition.
>> Have find this patch from google,
>>
>> http://www.spinics.net/lists/linux-scsi/msg58634.html
>> [PATCH 2/2] [SCS
From: Santosh Y
Reported-by: Venkatraman S
Reviewed-by: Vinayak Holikatti
Signed-off-by: Santosh Y
Signed-off-by: Zhangfei Gao
---
Find the original patch from
http://www.spinics.net/lists/linux-scsi/msg58634.html
drivers/scsi/ufs/ufshci.h | 2 ++
1 file changed, 2 insertions(+)
diff --gi
34 matches
Mail list logo
