I wait for your response.

2021-04-17 Thread Agata Arnoldo
Dear Beloved,

How are you doing, hope all is well? Please I am verifying if your
email is still working, I have sent you several messages, but could
not get any reply from you, would you get back to me? I have an
important message for you.

Please write me through my private email for more clarification: (
mrsagataarno...@gmail.com )

Warm Regards,
Agata Arnoldo.


[PATCH 4.14 44/68] net/ncsi: Avoid GFP_KERNEL in response handler

2021-04-15 Thread Greg Kroah-Hartman
From: Samuel Mendoza-Jonas 

commit b0949618826cbb64e9ba764bdd52aa14eaf5073d upstream.

ncsi_rsp_handler_gc() allocates the filter arrays using GFP_KERNEL in
softirq context, causing the below backtrace. This allocation is only a
few dozen bytes during probing so allocate with GFP_ATOMIC instead.

[   42.813372] BUG: sleeping function called from invalid context at 
mm/slab.h:416
[   42.820900] in_atomic(): 1, irqs_disabled(): 0, pid: 213, name: kworker/0:1
[   42.827893] INFO: lockdep is turned off.
[   42.832023] CPU: 0 PID: 213 Comm: kworker/0:1 Tainted: GW   
4.13.16-01441-gad99b38 #65
[   42.841007] Hardware name: Generic DT based system
[   42.845966] Workqueue: events ncsi_dev_work
[   42.850251] [<8010a494>] (unwind_backtrace) from [<80107510>] 
(show_stack+0x20/0x24)
[   42.858046] [<80107510>] (show_stack) from [<80612770>] 
(dump_stack+0x20/0x28)
[   42.865309] [<80612770>] (dump_stack) from [<80148248>] 
(___might_sleep+0x230/0x2b0)
[   42.873241] [<80148248>] (___might_sleep) from [<80148334>] 
(__might_sleep+0x6c/0xac)
[   42.881129] [<80148334>] (__might_sleep) from [<80240d6c>] 
(__kmalloc+0x210/0x2fc)
[   42.888737] [<80240d6c>] (__kmalloc) from [<8060ad54>] 
(ncsi_rsp_handler_gc+0xd0/0x170)
[   42.896770] [<8060ad54>] (ncsi_rsp_handler_gc) from [<8060b454>] 
(ncsi_rcv_rsp+0x16c/0x1d4)
[   42.905314] [<8060b454>] (ncsi_rcv_rsp) from [<804d86c8>] 
(__netif_receive_skb_core+0x3c8/0xb50)
[   42.914158] [<804d86c8>] (__netif_receive_skb_core) from [<804d96cc>] 
(__netif_receive_skb+0x20/0x7c)
[   42.923420] [<804d96cc>] (__netif_receive_skb) from [<804de4b0>] 
(netif_receive_skb_internal+0x78/0x6a4)
[   42.932931] [<804de4b0>] (netif_receive_skb_internal) from [<804df980>] 
(netif_receive_skb+0x78/0x158)
[   42.942292] [<804df980>] (netif_receive_skb) from [<8042f204>] 
(ftgmac100_poll+0x43c/0x4e8)
[   42.950855] [<8042f204>] (ftgmac100_poll) from [<804e094c>] 
(net_rx_action+0x278/0x4c4)
[   42.958918] [<804e094c>] (net_rx_action) from [<801016a8>] 
(__do_softirq+0xe0/0x4c4)
[   42.966716] [<801016a8>] (__do_softirq) from [<8011cd9c>] 
(do_softirq.part.4+0x50/0x78)
[   42.974756] [<8011cd9c>] (do_softirq.part.4) from [<8011cebc>] 
(__local_bh_enable_ip+0xf8/0x11c)
[   42.983579] [<8011cebc>] (__local_bh_enable_ip) from [<804dde08>] 
(__dev_queue_xmit+0x260/0x890)
[   42.992392] [<804dde08>] (__dev_queue_xmit) from [<804df1f0>] 
(dev_queue_xmit+0x1c/0x20)
[   43.000689] [<804df1f0>] (dev_queue_xmit) from [<806099c0>] 
(ncsi_xmit_cmd+0x1c0/0x244)
[   43.008763] [<806099c0>] (ncsi_xmit_cmd) from [<8060dc14>] 
(ncsi_dev_work+0x2e0/0x4c8)
[   43.016725] [<8060dc14>] (ncsi_dev_work) from [<80133dfc>] 
(process_one_work+0x214/0x6f8)
[   43.024940] [<80133dfc>] (process_one_work) from [<80134328>] 
(worker_thread+0x48/0x558)
[   43.033070] [<80134328>] (worker_thread) from [<8013ba80>] 
(kthread+0x130/0x174)
[   43.040506] [<8013ba80>] (kthread) from [<80102950>] 
(ret_from_fork+0x14/0x24)

Fixes: 062b3e1b6d4f ("net/ncsi: Refactor MAC, VLAN filters")
Signed-off-by: Samuel Mendoza-Jonas 
Signed-off-by: David S. Miller 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ncsi/ncsi-rsp.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c
@@ -651,7 +651,7 @@ static int ncsi_rsp_handler_gc(struct nc
  NCSI_CAP_VLAN_MASK;
 
size = (rsp->uc_cnt + rsp->mc_cnt + rsp->mixed_cnt) * ETH_ALEN;
-   nc->mac_filter.addrs = kzalloc(size, GFP_KERNEL);
+   nc->mac_filter.addrs = kzalloc(size, GFP_ATOMIC);
if (!nc->mac_filter.addrs)
return -ENOMEM;
nc->mac_filter.n_uc = rsp->uc_cnt;
@@ -660,7 +660,7 @@ static int ncsi_rsp_handler_gc(struct nc
 
nc->vlan_filter.vids = kcalloc(rsp->vlan_cnt,
   sizeof(*nc->vlan_filter.vids),
-  GFP_KERNEL);
+  GFP_ATOMIC);
if (!nc->vlan_filter.vids)
return -ENOMEM;
/* Set VLAN filters active so they are cleared in the first




[PATCH 4.14 41/68] net/ncsi: Dont return error on normal response

2021-04-15 Thread Greg Kroah-Hartman
From: Samuel Mendoza-Jonas 

commit 04bad8bda9e25afe676a6f4452f3b304c1fdea16 upstream.

Several response handlers return EBUSY if the data corresponding to the
command/response pair is already set. There is no reason to return an
error here; the channel is advertising something as enabled because we
told it to enable it, and it's possible that the feature has been
enabled previously.

Signed-off-by: Samuel Mendoza-Jonas 
Signed-off-by: David S. Miller 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ncsi/ncsi-rsp.c |   31 ++-
 1 file changed, 14 insertions(+), 17 deletions(-)

--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c
@@ -146,7 +146,7 @@ static int ncsi_rsp_handler_ec(struct nc
 
ncm = >modes[NCSI_MODE_ENABLE];
if (ncm->enable)
-   return -EBUSY;
+   return 0;
 
ncm->enable = 1;
return 0;
@@ -173,7 +173,7 @@ static int ncsi_rsp_handler_dc(struct nc
 
ncm = >modes[NCSI_MODE_ENABLE];
if (!ncm->enable)
-   return -EBUSY;
+   return 0;
 
ncm->enable = 0;
return 0;
@@ -217,7 +217,7 @@ static int ncsi_rsp_handler_ecnt(struct
 
ncm = >modes[NCSI_MODE_TX_ENABLE];
if (ncm->enable)
-   return -EBUSY;
+   return 0;
 
ncm->enable = 1;
return 0;
@@ -239,7 +239,7 @@ static int ncsi_rsp_handler_dcnt(struct
 
ncm = >modes[NCSI_MODE_TX_ENABLE];
if (!ncm->enable)
-   return -EBUSY;
+   return 0;
 
ncm->enable = 1;
return 0;
@@ -263,7 +263,7 @@ static int ncsi_rsp_handler_ae(struct nc
/* Check if the AEN has been enabled */
ncm = >modes[NCSI_MODE_AEN];
if (ncm->enable)
-   return -EBUSY;
+   return 0;
 
/* Update to AEN configuration */
cmd = (struct ncsi_cmd_ae_pkt *)skb_network_header(nr->cmd);
@@ -382,7 +382,7 @@ static int ncsi_rsp_handler_ev(struct nc
/* Check if VLAN mode has been enabled */
ncm = >modes[NCSI_MODE_VLAN];
if (ncm->enable)
-   return -EBUSY;
+   return 0;
 
/* Update to VLAN mode */
cmd = (struct ncsi_cmd_ev_pkt *)skb_network_header(nr->cmd);
@@ -409,7 +409,7 @@ static int ncsi_rsp_handler_dv(struct nc
/* Check if VLAN mode has been enabled */
ncm = >modes[NCSI_MODE_VLAN];
if (!ncm->enable)
-   return -EBUSY;
+   return 0;
 
/* Update to VLAN mode */
ncm->enable = 0;
@@ -455,13 +455,10 @@ static int ncsi_rsp_handler_sma(struct n
 
bitmap = >bitmap;
if (cmd->at_e & 0x1) {
-   if (test_and_set_bit(cmd->index, bitmap))
-   return -EBUSY;
+   set_bit(cmd->index, bitmap);
memcpy(ncf->data + 6 * cmd->index, cmd->mac, 6);
} else {
-   if (!test_and_clear_bit(cmd->index, bitmap))
-   return -EBUSY;
-
+   clear_bit(cmd->index, bitmap);
memset(ncf->data + 6 * cmd->index, 0, 6);
}
 
@@ -485,7 +482,7 @@ static int ncsi_rsp_handler_ebf(struct n
/* Check if broadcast filter has been enabled */
ncm = >modes[NCSI_MODE_BC];
if (ncm->enable)
-   return -EBUSY;
+   return 0;
 
/* Update to broadcast filter mode */
cmd = (struct ncsi_cmd_ebf_pkt *)skb_network_header(nr->cmd);
@@ -511,7 +508,7 @@ static int ncsi_rsp_handler_dbf(struct n
/* Check if broadcast filter isn't enabled */
ncm = >modes[NCSI_MODE_BC];
if (!ncm->enable)
-   return -EBUSY;
+   return 0;
 
/* Update to broadcast filter mode */
ncm->enable = 0;
@@ -538,7 +535,7 @@ static int ncsi_rsp_handler_egmf(struct
/* Check if multicast filter has been enabled */
ncm = >modes[NCSI_MODE_MC];
if (ncm->enable)
-   return -EBUSY;
+   return 0;
 
/* Update to multicast filter mode */
cmd = (struct ncsi_cmd_egmf_pkt *)skb_network_header(nr->cmd);
@@ -564,7 +561,7 @@ static int ncsi_rsp_handler_dgmf(struct
/* Check if multicast filter has been enabled */
ncm = >modes[NCSI_MODE_MC];
if (!ncm->enable)
-   return -EBUSY;
+   return 0;
 
/* Update to multicast filter mode */
ncm->enable = 0;
@@ -591,7 +588,7 @@ static int ncsi_rsp_handler_snfc(struct
/* Check if flow control has been enabled */
ncm = >modes[NCSI_MODE_FC];
if (ncm->enable)
-   return -EBUSY;
+   return 0;
 
/* Update to flow control mode */
cmd = (struct ncsi_cmd_snfc_pkt *)skb_network_header(nr->cmd);




URGENT RESPONSE NEEDED.

2021-04-13 Thread ibrahim musa
Dear friend, i am contacting you independently of my investigation in
my bank and no one is informed of this communication. I need your
urgent assistance in transferring the sum of $5.3million dollars to
your private account,that belongs to one of our foreign customer who
died a longtime with his supposed NEXT OF KIN since July 22, 2003. The
money has been here in our Bank lying dormant for years now without
anybody coming for the claim of it.

I want to release the money to you as the relative to our deceased
customer , the Banking laws here does not allow such money to stay
more than 18years, because the money will be recalled to the Bank
treasury account as unclaimed fund. I am ready to share with you 40%
for you and 60% will be kept for me, by indicating your interest i
will send you the full details on how the business will be executed, i
will be waiting for your urgent response.


Urgent Response

2021-04-12 Thread Alexandra Kelly
Dear friend,


I am contacting you independently of my investigation in
my bank and no one is informed of this communication. I need your
urgent assistance in transferring the sum of $5.3 million dollars to
your private account,that belongs to one of our foreign customers who
died a longtime with his supposed NEXT OF KIN since July 22, 2003. The
money has been here in our Bank lying dormant for years now without
anybody coming for the claim of it.

I want to release the money to you as the relative to our deceased
customer , the Banking laws here does not allow such money to stay
more than 18 years, because the money will be recalled to the Bank
treasury account as unclaimed fund. I am ready to share with you 40%
for you and 60% will be kept for me, by indicating your interest i
will send you the full details on how the business will be executed, i
will be waiting for your urgent response.



Re: I appreciate your quick response.

2021-04-11 Thread Mr. Ying Wang
Mr. Ying Wang
Vice President & Branch Manager
Hacienda Heights Branch
17180 Colima Road,
Hacienda Heights, CA 91745, USA

Good day,

My name is Mr. Ying Wang, ICBC Bank, Hacienda Hieghts Branch,
California USA. I discovered a huge sum secretly in a high profile
account. On investigation I discovered it is without any administrator
thus a floating funds.

I want you to partner with me to transfer this funds out into your
account. We shall share the money in terms that we will both agree .
Let me know if you are willing to partner with me.

Please do in your reply email state your full name and phone number
and I will call to give you more information.

I await your response.

Sincerely,

Mr. Ying Wang



[PATCH v13 13/13] vfio/pci: Inject page response upon response region fill

2021-04-11 Thread Eric Auger
When the userspace increments the head of the page response
buffer ring, let's push the response into the iommu layer.
This is done through a workqueue that pops the responses from
the ring buffer and increment the tail.

Signed-off-by: Eric Auger 
---
 drivers/vfio/pci/vfio_pci.c | 40 +
 drivers/vfio/pci/vfio_pci_private.h |  7 +
 drivers/vfio/pci/vfio_pci_rdwr.c|  1 +
 3 files changed, 48 insertions(+)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 560b1a830726..bb4a0e1e39bf 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -552,6 +552,32 @@ static int vfio_pci_dma_fault_init(struct vfio_pci_device 
*vdev)
return ret;
 }
 
+static void dma_response_inject(struct work_struct *work)
+{
+   struct vfio_pci_dma_fault_response_work *rwork =
+   container_of(work, struct vfio_pci_dma_fault_response_work, 
inject);
+   struct vfio_region_dma_fault_response *header = rwork->header;
+   struct vfio_pci_device *vdev = rwork->vdev;
+   struct iommu_page_response *resp;
+   u32 tail, head, size;
+
+   mutex_lock(>fault_response_queue_lock);
+
+   tail = header->tail;
+   head = header->head;
+   size = header->nb_entries;
+
+   while (CIRC_CNT(head, tail, size) >= 1) {
+   resp = (struct iommu_page_response 
*)(vdev->fault_response_pages + header->offset +
+   tail * header->entry_size);
+
+   /* TODO: properly handle the return value */
+   iommu_page_response(>pdev->dev, resp);
+   header->tail = tail = (tail + 1) % size;
+   }
+   mutex_unlock(>fault_response_queue_lock);
+}
+
 #define DMA_FAULT_RESPONSE_RING_LENGTH 512
 
 static int vfio_pci_dma_fault_response_init(struct vfio_pci_device *vdev)
@@ -597,8 +623,22 @@ static int vfio_pci_dma_fault_response_init(struct 
vfio_pci_device *vdev)
header->nb_entries = DMA_FAULT_RESPONSE_RING_LENGTH;
header->offset = PAGE_SIZE;
 
+   vdev->response_work = kzalloc(sizeof(*vdev->response_work), GFP_KERNEL);
+   if (!vdev->response_work)
+   goto out;
+   vdev->response_work->header = header;
+   vdev->response_work->vdev = vdev;
+
+   /* launch the thread that will extract the response */
+   INIT_WORK(>response_work->inject, dma_response_inject);
+   vdev->dma_fault_response_wq =
+   create_singlethread_workqueue("vfio-dma-fault-response");
+   if (!vdev->dma_fault_response_wq)
+   return -ENOMEM;
+
return 0;
 out:
+   kfree(vdev->fault_response_pages);
vdev->fault_response_pages = NULL;
return ret;
 }
diff --git a/drivers/vfio/pci/vfio_pci_private.h 
b/drivers/vfio/pci/vfio_pci_private.h
index f7b1e7fb86e5..835fbb221dea 100644
--- a/drivers/vfio/pci/vfio_pci_private.h
+++ b/drivers/vfio/pci/vfio_pci_private.h
@@ -52,6 +52,12 @@ struct vfio_pci_irq_ctx {
struct irq_bypass_producer  producer;
 };
 
+struct vfio_pci_dma_fault_response_work {
+   struct work_struct inject;
+   struct vfio_region_dma_fault_response *header;
+   struct vfio_pci_device *vdev;
+};
+
 struct vfio_pci_device;
 struct vfio_pci_region;
 
@@ -146,6 +152,7 @@ struct vfio_pci_device {
u8  *fault_pages;
u8  *fault_response_pages;
struct workqueue_struct *dma_fault_response_wq;
+   struct vfio_pci_dma_fault_response_work *response_work;
struct mutexfault_queue_lock;
struct mutexfault_response_queue_lock;
struct list_headdummy_resources_list;
diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
index efde0793360b..78c494fe35cc 100644
--- a/drivers/vfio/pci/vfio_pci_rdwr.c
+++ b/drivers/vfio/pci/vfio_pci_rdwr.c
@@ -430,6 +430,7 @@ size_t vfio_pci_dma_fault_response_rw(struct 
vfio_pci_device *vdev, char __user
mutex_lock(>fault_response_queue_lock);
header->head = new_head;
mutex_unlock(>fault_response_queue_lock);
+   queue_work(vdev->dma_fault_response_wq, 
>response_work->inject);
} else {
if (copy_to_user(buf, base + pos, count))
return -EFAULT;
-- 
2.26.3



[PATCH v13 12/13] vfio/pci: Register a DMA fault response region

2021-04-11 Thread Eric Auger
In preparation for vSVA, let's register a DMA fault response region,
where the userspace will push the page responses and increment the
head of the buffer. The kernel will pop those responses and inject them
on iommu side.

Signed-off-by: Eric Auger 

---

v11 -> v12:
- use DMA_FAULT_RESPONSE cap [Shameer]
- struct vfio_pci_device dma_fault_response_wq field introduced in
  this patch
- return 0 if the domain is NULL
- pass an int pointer to iommu_domain_get_attr
---
 drivers/vfio/pci/vfio_pci.c | 125 ++--
 drivers/vfio/pci/vfio_pci_private.h |   6 ++
 drivers/vfio/pci/vfio_pci_rdwr.c|  39 +
 include/uapi/linux/vfio.h   |  32 +++
 4 files changed, 193 insertions(+), 9 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 72d7c667b64c..560b1a830726 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -316,9 +316,20 @@ static void vfio_pci_dma_fault_release(struct 
vfio_pci_device *vdev,
kfree(vdev->fault_pages);
 }
 
-static int vfio_pci_dma_fault_mmap(struct vfio_pci_device *vdev,
-  struct vfio_pci_region *region,
-  struct vm_area_struct *vma)
+static void
+vfio_pci_dma_fault_response_release(struct vfio_pci_device *vdev,
+   struct vfio_pci_region *region)
+{
+   if (vdev->dma_fault_response_wq)
+   destroy_workqueue(vdev->dma_fault_response_wq);
+   kfree(vdev->fault_response_pages);
+   vdev->fault_response_pages = NULL;
+}
+
+static int __vfio_pci_dma_fault_mmap(struct vfio_pci_device *vdev,
+struct vfio_pci_region *region,
+struct vm_area_struct *vma,
+u8 *pages)
 {
u64 phys_len, req_len, pgoff, req_start;
unsigned long long addr;
@@ -331,14 +342,14 @@ static int vfio_pci_dma_fault_mmap(struct vfio_pci_device 
*vdev,
((1U << (VFIO_PCI_OFFSET_SHIFT - PAGE_SHIFT)) - 1);
req_start = pgoff << PAGE_SHIFT;
 
-   /* only the second page of the producer fault region is mmappable */
+   /* only the second page of the fault region is mmappable */
if (req_start < PAGE_SIZE)
return -EINVAL;
 
if (req_start + req_len > phys_len)
return -EINVAL;
 
-   addr = virt_to_phys(vdev->fault_pages);
+   addr = virt_to_phys(pages);
vma->vm_private_data = vdev;
vma->vm_pgoff = (addr >> PAGE_SHIFT) + pgoff;
 
@@ -347,13 +358,29 @@ static int vfio_pci_dma_fault_mmap(struct vfio_pci_device 
*vdev,
return ret;
 }
 
-static int vfio_pci_dma_fault_add_capability(struct vfio_pci_device *vdev,
-struct vfio_pci_region *region,
-struct vfio_info_cap *caps)
+static int vfio_pci_dma_fault_mmap(struct vfio_pci_device *vdev,
+  struct vfio_pci_region *region,
+  struct vm_area_struct *vma)
+{
+   return __vfio_pci_dma_fault_mmap(vdev, region, vma, vdev->fault_pages);
+}
+
+static int
+vfio_pci_dma_fault_response_mmap(struct vfio_pci_device *vdev,
+   struct vfio_pci_region *region,
+   struct vm_area_struct *vma)
+{
+   return __vfio_pci_dma_fault_mmap(vdev, region, vma, 
vdev->fault_response_pages);
+}
+
+static int __vfio_pci_dma_fault_add_capability(struct vfio_pci_device *vdev,
+  struct vfio_pci_region *region,
+  struct vfio_info_cap *caps,
+  u32 cap_id)
 {
struct vfio_region_info_cap_sparse_mmap *sparse = NULL;
struct vfio_region_info_cap_fault cap = {
-   .header.id = VFIO_REGION_INFO_CAP_DMA_FAULT,
+   .header.id = cap_id,
.header.version = 1,
.version = 1,
};
@@ -381,6 +408,23 @@ static int vfio_pci_dma_fault_add_capability(struct 
vfio_pci_device *vdev,
return ret;
 }
 
+static int vfio_pci_dma_fault_add_capability(struct vfio_pci_device *vdev,
+struct vfio_pci_region *region,
+struct vfio_info_cap *caps)
+{
+   return __vfio_pci_dma_fault_add_capability(vdev, region, caps,
+  
VFIO_REGION_INFO_CAP_DMA_FAULT);
+}
+
+static int
+vfio_pci_dma_fault_response_add_capability(struct vfio_pci_device *vdev,
+  struct vfio_pci_region *region,
+  struct vfio_info_cap *caps)
+{
+   retu

[PATCH v8 07/11] scsi: ufshpb: Add hpb dev reset response

2021-04-11 Thread Avri Altman
The spec does not define what is the host's recommended response when
the device send hpb dev reset response (oper 0x2).

We will update all active hpb regions: mark them and do that on the next
read.

Signed-off-by: Avri Altman 
Reviewed-by: Daejun Park 
---
 drivers/scsi/ufs/ufshpb.c | 32 +++-
 drivers/scsi/ufs/ufshpb.h |  1 +
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index 28aef5acffa2..0352d269c1e9 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -195,7 +195,8 @@ static void ufshpb_iterate_rgn(struct ufshpb_lu *hpb, int 
rgn_idx, int srgn_idx,
}
spin_unlock(>rgn_lock);
 
-   if (activate) {
+   if (activate ||
+   test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {
spin_lock_irqsave(>rsp_list_lock, flags);
ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
spin_unlock_irqrestore(>rsp_list_lock, flags);
@@ -1417,6 +1418,20 @@ static void ufshpb_rsp_req_region_update(struct 
ufshpb_lu *hpb,
queue_work(ufshpb_wq, >map_work);
 }
 
+static void ufshpb_dev_reset_handler(struct ufshpb_lu *hpb)
+{
+   struct victim_select_info *lru_info = >lru_info;
+   struct ufshpb_region *rgn;
+   unsigned long flags;
+
+   spin_lock_irqsave(>rgn_state_lock, flags);
+
+   list_for_each_entry(rgn, _info->lh_lru_rgn, list_lru_rgn)
+   set_bit(RGN_FLAG_UPDATE, >rgn_flags);
+
+   spin_unlock_irqrestore(>rgn_state_lock, flags);
+}
+
 /*
  * This function will parse recommended active subregion information in sense
  * data field of response UPIU with SAM_STAT_GOOD state.
@@ -1491,6 +1506,18 @@ void ufshpb_rsp_upiu(struct ufs_hba *hba, struct 
ufshcd_lrb *lrbp)
case HPB_RSP_DEV_RESET:
dev_warn(>sdev_ufs_lu->sdev_dev,
 "UFS device lost HPB information during PM.\n");
+
+   if (hpb->is_hcm) {
+   struct scsi_device *sdev;
+
+   __shost_for_each_device(sdev, hba->host) {
+   struct ufshpb_lu *h = sdev->hostdata;
+
+   if (h)
+   ufshpb_dev_reset_handler(h);
+   }
+   }
+
break;
default:
dev_notice(>sdev_ufs_lu->sdev_dev,
@@ -1817,6 +1844,8 @@ static int ufshpb_alloc_region_tbl(struct ufs_hba *hba, 
struct ufshpb_lu *hpb)
} else {
rgn->rgn_state = HPB_RGN_INACTIVE;
}
+
+   rgn->rgn_flags = 0;
}
 
return 0;
@@ -2144,6 +2173,7 @@ static void ufshpb_cancel_jobs(struct ufshpb_lu *hpb)
 {
if (hpb->is_hcm)
cancel_work_sync(>ufshpb_normalization_work);
+
cancel_work_sync(>map_work);
 }
 
diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
index 1ea58c17a4de..b863540e28d6 100644
--- a/drivers/scsi/ufs/ufshpb.h
+++ b/drivers/scsi/ufs/ufshpb.h
@@ -127,6 +127,7 @@ struct ufshpb_region {
struct list_head list_lru_rgn;
unsigned long rgn_flags;
 #define RGN_FLAG_DIRTY 0
+#define RGN_FLAG_UPDATE 1
 
/* region reads - for host mode */
spinlock_t rgn_lock;
-- 
2.25.1



Your urgent response is needed

2021-04-06 Thread Dr Bryan Bouchet
Dear Friend,

With due respect, i have decided to contact you on a business
transaction that will be beneficial to both of us. At the bank last
account and auditing evaluation, my staffs came across an old account
which was being maintained by a foreign client who we learn was among
the deceased passengers of motor accident on November.2003, the
deceased was unable to run this account since his death. The account
has remained dormant without the knowledge of his family since it was
put in a safe deposit account in the bank for future investment by the client.

Since his demise, even the members of his family haven't applied for
claims over this fund and it has been in the safe deposit account
until i discovered that it cannot be claimed since our client is a
foreign national and we are sure that he has no next of kin here to
file claims over the money. As the director of the department, this
discovery was brought to my office so as to decide what is to be done;
I decided to seek ways through which to transfer this money out of the
bank and out of the country too.

The total amount in the account is (18.6 million) with my positions as
a staff of this bank, i am handicapped because i cannot operate
foreign accounts and cannot lay benefice claim over this money. The
client was a foreign national and you will only be asked to act as his
next of kin and i will supply you with all the necessary information
and bank data to assist you in being able to transfer this money to
any bank of your choice where this money could be transferred into.

The total sum will be shared as follows: 50% for me, 50% for you, and
expenses incidental occur during the transfer will be incur by both of
us. The transfer is risk free on both sides hence you are going to
follow my instruction till the fund transfer to your account. Since I
work in this bank that is why you should be confident in the success
of this transaction because you will be updated with information’s as
at when desired.

I will wish you to keep this transaction secret and confidential as I
am hoping to retire with my share of this money at the end of
transaction which will be when this money is safety in your account. I
will then come over to your country for sharing according to the
previously agreed percentages. You might even have to advise me on
possibilities of investment in your country or elsewhere of our
choice. May god help you to help me to a restive retirement?

(1) Your full name..
(2) Your age:
(3) Sex:.
(4) Your telephone number:.
(5) Your occupation:.
(6) Your country:.

Yours sincerely,
Dr Bryan Bouchet


Re: [PATCH 1/4] fsi: occ: Don't accept response from un-initialized OCC

2021-04-06 Thread Joel Stanley
On Tue, 9 Feb 2021 at 17:12, Eddie James  wrote:
>
> If the OCC is not initialized and responds as such, the driver
> should continue waiting for a valid response until the timeout
> expires.
>
> Signed-off-by: Eddie James 

Reviewed-by: Joel Stanley 

I guess we should add this too?

Fixes: 7ed98dddb764 ("fsi: Add On-Chip Controller (OCC) driver")


> ---
>  drivers/fsi/fsi-occ.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/fsi/fsi-occ.c b/drivers/fsi/fsi-occ.c
> index 10ca2e290655..cb05b6dacc9d 100644
> --- a/drivers/fsi/fsi-occ.c
> +++ b/drivers/fsi/fsi-occ.c
> @@ -495,6 +495,7 @@ int fsi_occ_submit(struct device *dev, const void 
> *request, size_t req_len,
> goto done;
>
> if (resp->return_status == OCC_RESP_CMD_IN_PRG ||
> +   resp->return_status == OCC_RESP_CRIT_INIT ||
> resp->seq_no != seq_no) {
> rc = -ETIMEDOUT;
>
> --
> 2.27.0
>


I wait for your prompt response,

2021-03-31 Thread Patricia Leson
Dear Friend,
May the grace, peace, love and the truth in the word of God be with
you and all those that you love and care for. Please permit me to
share with you, my desire to go into this Godly business partnership
with you as I believe that You and I can cooperate together in this
humanitarian social project only for the glory and honor of God.  My
names are Mrs. Patricia Leson,  I am a dying widow hospitalized
undergoing treatment for brain tumor disease. Because of this reason i
decided to seek for your sincerity and ability to carry out this
transaction and fulfill my final wish in implementing the charitable
social project in your country as it requires absolute trust and
devotion without any failure, which i believe that you are a reliable
person and you will not expose or betray this trust and confident that
I'm about to entrust on you. My late husband made a substantial
deposit with the bank with my name as the beneficiary which I decided
to hand over and entrust the sum of ($ 12,500,000.00, Dollars) in the
account to you to invest into the humanitarian social project. Based
on my present health status as I'm permanently indisposed to handle
finances or any financial related project, following my diagnoses.
Having known my present health condition, I decided to seek for your
assistance in reclaiming the fund for the support and mutual benefit
of the less privileged as I don't have any relation, and I have been
touched by God to donate from what I have to the needy because it will
be a great loss in spending the fund on my health treatment hence my
doctor has confirmed to me that i will not survive this illness.

This is the reason I contacted you for your support and help to stand
as my rightful beneficiary and claim the money for humanitarian
purposes for the mutual benefits of the less privileged ones. Because
If the money remains unclaimed with the bank after my death, those
greedy bank executives will place the money as an unclaimed Fund and
share it for their selfish and worthless ventures. It will be my
pleasure to compensate you with part of the money as my Investment
Manager/Partner for your effort in handling the transaction, while the
remaining amount of the money will be invested into the charity
project there in your country.

IF YOU ARE WILLING TO ACCEPT MY OFFER AND DO EXACTLY AS I HAVE STATED
ABOVE. YOU SHOULD IMMEDIATELY GET BACK TO ME FOR FURTHER DETAILS OF
THE TRANSACTION.

May God Bless You.
Regards. Mrs. Patricia Leson.


[PATCH v7 07/11] scsi: ufshpb: Add hpb dev reset response

2021-03-31 Thread Avri Altman
The spec does not define what is the host's recommended response when
the device send hpb dev reset response (oper 0x2).

We will update all active hpb regions: mark them and do that on the next
read.

Signed-off-by: Avri Altman 
---
 drivers/scsi/ufs/ufshpb.c | 32 +++-
 drivers/scsi/ufs/ufshpb.h |  1 +
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index fcc954f51bcf..1d99099ebd41 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -195,7 +195,8 @@ static void ufshpb_iterate_rgn(struct ufshpb_lu *hpb, int 
rgn_idx, int srgn_idx,
}
spin_unlock(>rgn_lock);
 
-   if (activate) {
+   if (activate ||
+   test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {
spin_lock_irqsave(>rsp_list_lock, flags);
ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
spin_unlock_irqrestore(>rsp_list_lock, flags);
@@ -1412,6 +1413,20 @@ static void ufshpb_rsp_req_region_update(struct 
ufshpb_lu *hpb,
queue_work(ufshpb_wq, >map_work);
 }
 
+static void ufshpb_dev_reset_handler(struct ufshpb_lu *hpb)
+{
+   struct victim_select_info *lru_info = >lru_info;
+   struct ufshpb_region *rgn;
+   unsigned long flags;
+
+   spin_lock_irqsave(>rgn_state_lock, flags);
+
+   list_for_each_entry(rgn, _info->lh_lru_rgn, list_lru_rgn)
+   set_bit(RGN_FLAG_UPDATE, >rgn_flags);
+
+   spin_unlock_irqrestore(>rgn_state_lock, flags);
+}
+
 /*
  * This function will parse recommended active subregion information in sense
  * data field of response UPIU with SAM_STAT_GOOD state.
@@ -1486,6 +1501,18 @@ void ufshpb_rsp_upiu(struct ufs_hba *hba, struct 
ufshcd_lrb *lrbp)
case HPB_RSP_DEV_RESET:
dev_warn(>sdev_ufs_lu->sdev_dev,
 "UFS device lost HPB information during PM.\n");
+
+   if (hpb->is_hcm) {
+   struct scsi_device *sdev;
+
+   __shost_for_each_device(sdev, hba->host) {
+   struct ufshpb_lu *h = sdev->hostdata;
+
+   if (h)
+   ufshpb_dev_reset_handler(h);
+   }
+   }
+
break;
default:
dev_notice(>sdev_ufs_lu->sdev_dev,
@@ -1812,6 +1839,8 @@ static int ufshpb_alloc_region_tbl(struct ufs_hba *hba, 
struct ufshpb_lu *hpb)
} else {
rgn->rgn_state = HPB_RGN_INACTIVE;
}
+
+   rgn->rgn_flags = 0;
}
 
return 0;
@@ -2139,6 +2168,7 @@ static void ufshpb_cancel_jobs(struct ufshpb_lu *hpb)
 {
if (hpb->is_hcm)
cancel_work_sync(>ufshpb_normalization_work);
+
cancel_work_sync(>map_work);
 }
 
diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
index 1ea58c17a4de..b863540e28d6 100644
--- a/drivers/scsi/ufs/ufshpb.h
+++ b/drivers/scsi/ufs/ufshpb.h
@@ -127,6 +127,7 @@ struct ufshpb_region {
struct list_head list_lru_rgn;
unsigned long rgn_flags;
 #define RGN_FLAG_DIRTY 0
+#define RGN_FLAG_UPDATE 1
 
/* region reads - for host mode */
spinlock_t rgn_lock;
-- 
2.25.1



[PATCH v6 06/10] scsi: ufshpb: Add hpb dev reset response

2021-03-22 Thread Avri Altman
The spec does not define what is the host's recommended response when
the device send hpb dev reset response (oper 0x2).

We will update all active hpb regions: mark them and do that on the next
read.

Signed-off-by: Avri Altman 
---
 drivers/scsi/ufs/ufshpb.c | 32 +++-
 drivers/scsi/ufs/ufshpb.h |  1 +
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index 1f0344eaa546..6e580111293f 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -640,7 +640,8 @@ int ufshpb_prep(struct ufs_hba *hba, struct ufshcd_lrb 
*lrbp)
if (rgn->reads == ACTIVATION_THRESHOLD)
activate = true;
spin_unlock(>rgn_lock);
-   if (activate) {
+   if (activate ||
+   test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {
spin_lock_irqsave(>rsp_list_lock, flags);
ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
spin_unlock_irqrestore(>rsp_list_lock, flags);
@@ -1402,6 +1403,20 @@ static void ufshpb_rsp_req_region_update(struct 
ufshpb_lu *hpb,
queue_work(ufshpb_wq, >map_work);
 }
 
+static void ufshpb_dev_reset_handler(struct ufshpb_lu *hpb)
+{
+   struct victim_select_info *lru_info = >lru_info;
+   struct ufshpb_region *rgn;
+   unsigned long flags;
+
+   spin_lock_irqsave(>rgn_state_lock, flags);
+
+   list_for_each_entry(rgn, _info->lh_lru_rgn, list_lru_rgn)
+   set_bit(RGN_FLAG_UPDATE, >rgn_flags);
+
+   spin_unlock_irqrestore(>rgn_state_lock, flags);
+}
+
 /*
  * This function will parse recommended active subregion information in sense
  * data field of response UPIU with SAM_STAT_GOOD state.
@@ -1476,6 +1491,18 @@ void ufshpb_rsp_upiu(struct ufs_hba *hba, struct 
ufshcd_lrb *lrbp)
case HPB_RSP_DEV_RESET:
dev_warn(>sdev_ufs_lu->sdev_dev,
 "UFS device lost HPB information during PM.\n");
+
+   if (hpb->is_hcm) {
+   struct scsi_device *sdev;
+
+   __shost_for_each_device(sdev, hba->host) {
+   struct ufshpb_lu *h = sdev->hostdata;
+
+   if (h)
+   ufshpb_dev_reset_handler(h);
+   }
+   }
+
break;
default:
dev_notice(>sdev_ufs_lu->sdev_dev,
@@ -1795,6 +1822,8 @@ static int ufshpb_alloc_region_tbl(struct ufs_hba *hba, 
struct ufshpb_lu *hpb)
} else {
rgn->rgn_state = HPB_RGN_INACTIVE;
}
+
+   rgn->rgn_flags = 0;
}
 
return 0;
@@ -2122,6 +2151,7 @@ static void ufshpb_cancel_jobs(struct ufshpb_lu *hpb)
 {
if (hpb->is_hcm)
cancel_work_sync(>ufshpb_normalization_work);
+
cancel_work_sync(>map_work);
 }
 
diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
index 7afc98e61c0a..24aa116c42c6 100644
--- a/drivers/scsi/ufs/ufshpb.h
+++ b/drivers/scsi/ufs/ufshpb.h
@@ -123,6 +123,7 @@ struct ufshpb_region {
struct list_head list_lru_rgn;
unsigned long rgn_flags;
 #define RGN_FLAG_DIRTY 0
+#define RGN_FLAG_UPDATE 1
 
/* region reads - for host mode */
spinlock_t rgn_lock;
-- 
2.25.1



RE: [PATCH v5 06/10] scsi: ufshpb: Add hpb dev reset response

2021-03-18 Thread Avri Altman
> On 2021-03-17 23:46, Avri Altman wrote:
> >> >> >> >>
> >> >> >> >> Just curious, directly doing below things inside ufshpb_rsp_upiu()
> >> >> >> >> does
> >> >> >> >> not
> >> >> >> >> seem a problem to me, does this really deserve a separate work?
> >> >> >> > I don't know, I never even consider of doing this.
> >> >> >> > The active region list may contain up to few thousands of regions -
> >> >> >> > It is not rare to see configurations that covers the entire device.
> >> >> >> >
> >> >> >>
> >> >> >> Yes, true, it can be a huge list. But what does the ops
> >> >> >> "HPB_RSP_DEV_RESET"
> >> >> >> really mean? The specs says "Device reset HPB Regions information",
> >> >> >> but
> >> >> >> I
> >> >> >> don't know what is really happening. Could you please elaborate?
> >> >> > It means that the device informs the host that the L2P cache is no
> >> >> > longer valid.
> >> >> > The spec doesn't say what to do in that case.
> >> >>
> >> >> Then it means that all the clean (without DIRTY flag set) HPB entries
> >> >> (ppns)
> >> >> in active rgns in host memory side may not be valid to the device
> >> >> anymore.
> >> >> Please correct me if I am wrong.
> >> >>
> >> >> > We thought that in host mode, it make sense to update all the active
> >> >> > regions.
> >> >>
> >> >> But current logic does not set the state of the sub-regions (in active
> >> >> regions) to
> >> >> INVALID, it only marks all active regions as UPDATE.
> >> >>
> >> >> Although one of subsequent read cmds shall put the sub-region back to
> >> >> activate_list,
> >> >> ufshpb_test_ppn_dirty() can still return false, thus these read cmds
> >> >> still think the
> >> >> ppns are valid and they shall move forward to send HPB Write Buffer
> >> >> (buffer id = 0x2,
> >> >> in case of HPB2.0) and HPB Read cmds.
> >> >>
> >> >> HPB Read cmds with invalid ppns will be treated as normal Read cmds by
> >> >> device as the
> >> >> specs says, but what would happen to HPB Write Buffer cmds (buffer id
> >> >> =
> >> >> 0x2, in case
> >> >> of HPB2.0) with invalid ppns? Can this be a real problem?
> >> > No need to control the ppn dirty / invalid state for this case.
> >> > The device send device reset so it is aware that all the L2P cache is
> >> > invalid.
> >> > Any HPB_READ is treated like normal READ10.
> >> >
> >> > Only once HPB-READ-BUFFER is completed,
> >> > the device will relate back to the physical address.
> >>
> >> What about HPB-WRITE-BUFFER (buffer id = 0x2) cmds?
> > Same.
> > Oper 0x2 is a relative simple case.
> > The device is expected to manage some versioning framework not to be
> > "fooled" by erroneous ppn.
> > There are some more challenging races that the device should meet.
> >
> 
> But I don't find the handling w.r.t this scenario on HPB2.0 specs -
> how would the device re-act/respond to HPB-WRITE-BUFFER cmds with
> invalid HPB entries? Could you please point me to relevant
> section/paragraph?
The spec does not handle that.
HPB-WRITE-BUFFER 0x2 is not a stand-alone command, it always tagged to a 
HPB-READ command.
It is up to the device to handle invalid ppn and always return the correct data.
The expected performance in that case is like a regular READ10.

Thanks,
Avri 

> 
> Thanks,
> Can Guo.
> 
> > Thanks,
> > Avri
> >>
> >> Thanks,
> >> Can Guo.
> >>
> >> >
> >> >>
> >> >> >
> >> >> > I think I will go with your suggestion.
> >> >> > Effectively, in host mode, since it is deactivating "cold" regions,
> >> >> > the lru list is kept relatively small, and contains only "hot" 
> >> >> > regions.
> >> >>
> >> >> hmm... I don't really have a idea on this, please go with whatever you
> >> >> and Daejun think is fine here.
> >> > I will take your advice and remove the worker.
> >> >
> >> >
> >> > Thanks,
> >> > Avri
> >> >
> >> >>
> >> >> Thanks,
> >> >> Can Guo.
> >> >>
> >> >> >
> >> >> > Thanks,
> >> >> > Avri
> >> >> >
> >> >> >>
> >> >> >> Thanks,
> >> >> >> Can Guo.
> >> >> >>
> >> >> >> > But yes, I can do that.
> >> >> >> > Better to get ack from Daejun first.
> >> >> >> >
> >> >> >> > Thanks,
> >> >> >> > Avri
> >> >> >> >
> >> >> >> >>
> >> >> >> >> Thanks,
> >> >> >> >> Can Guo.
> >> >> >> >>
> >> >> >> >> > +{
> >> >> >> >> > + struct ufshpb_lu *hpb;
> >> >> >> >> > + struct victim_select_info *lru_info;
> >> >> >> >> > + struct ufshpb_region *rgn;
> >> >> >> >> > + unsigned long flags;
> >> >> >> >> > +
> >> >> >> >> > + hpb = container_of(work, struct ufshpb_lu,
> >> >> ufshpb_lun_reset_work);
> >> >> >> >> > +
> >> >> >> >> > + lru_info = >lru_info;
> >> >> >> >> > +
> >> >> >> >> > + spin_lock_irqsave(>rgn_state_lock, flags);
> >> >> >> >> > +
> >> >> >> >> > + list_for_each_entry(rgn, _info->lh_lru_rgn, 
> >> >> >> >> > list_lru_rgn)
> >> >> >> >> > + set_bit(RGN_FLAG_UPDATE, >rgn_flags);
> >> >> >> >> > +
> >> >> >> >> > + spin_unlock_irqrestore(>rgn_state_lock, flags);
> >> >> >> >> > +}
> >> >> >> >> > +
> >> >> >> >> >  static void 

Re: [PATCH v5 06/10] scsi: ufshpb: Add hpb dev reset response

2021-03-17 Thread Can Guo

On 2021-03-17 23:46, Avri Altman wrote:

>> >> >>
>> >> >> Just curious, directly doing below things inside ufshpb_rsp_upiu()
>> >> >> does
>> >> >> not
>> >> >> seem a problem to me, does this really deserve a separate work?
>> >> > I don't know, I never even consider of doing this.
>> >> > The active region list may contain up to few thousands of regions -
>> >> > It is not rare to see configurations that covers the entire device.
>> >> >
>> >>
>> >> Yes, true, it can be a huge list. But what does the ops
>> >> "HPB_RSP_DEV_RESET"
>> >> really mean? The specs says "Device reset HPB Regions information",
>> >> but
>> >> I
>> >> don't know what is really happening. Could you please elaborate?
>> > It means that the device informs the host that the L2P cache is no
>> > longer valid.
>> > The spec doesn't say what to do in that case.
>>
>> Then it means that all the clean (without DIRTY flag set) HPB entries
>> (ppns)
>> in active rgns in host memory side may not be valid to the device
>> anymore.
>> Please correct me if I am wrong.
>>
>> > We thought that in host mode, it make sense to update all the active
>> > regions.
>>
>> But current logic does not set the state of the sub-regions (in active
>> regions) to
>> INVALID, it only marks all active regions as UPDATE.
>>
>> Although one of subsequent read cmds shall put the sub-region back to
>> activate_list,
>> ufshpb_test_ppn_dirty() can still return false, thus these read cmds
>> still think the
>> ppns are valid and they shall move forward to send HPB Write Buffer
>> (buffer id = 0x2,
>> in case of HPB2.0) and HPB Read cmds.
>>
>> HPB Read cmds with invalid ppns will be treated as normal Read cmds by
>> device as the
>> specs says, but what would happen to HPB Write Buffer cmds (buffer id
>> =
>> 0x2, in case
>> of HPB2.0) with invalid ppns? Can this be a real problem?
> No need to control the ppn dirty / invalid state for this case.
> The device send device reset so it is aware that all the L2P cache is
> invalid.
> Any HPB_READ is treated like normal READ10.
>
> Only once HPB-READ-BUFFER is completed,
> the device will relate back to the physical address.

What about HPB-WRITE-BUFFER (buffer id = 0x2) cmds?

Same.
Oper 0x2 is a relative simple case.
The device is expected to manage some versioning framework not to be
"fooled" by erroneous ppn.
There are some more challenging races that the device should meet.



But I don't find the handling w.r.t this scenario on HPB2.0 specs -
how would the device re-act/respond to HPB-WRITE-BUFFER cmds with
invalid HPB entries? Could you please point me to relevant 
section/paragraph?


Thanks,
Can Guo.


Thanks,
Avri


Thanks,
Can Guo.

>
>>
>> >
>> > I think I will go with your suggestion.
>> > Effectively, in host mode, since it is deactivating "cold" regions,
>> > the lru list is kept relatively small, and contains only "hot" regions.
>>
>> hmm... I don't really have a idea on this, please go with whatever you
>> and Daejun think is fine here.
> I will take your advice and remove the worker.
>
>
> Thanks,
> Avri
>
>>
>> Thanks,
>> Can Guo.
>>
>> >
>> > Thanks,
>> > Avri
>> >
>> >>
>> >> Thanks,
>> >> Can Guo.
>> >>
>> >> > But yes, I can do that.
>> >> > Better to get ack from Daejun first.
>> >> >
>> >> > Thanks,
>> >> > Avri
>> >> >
>> >> >>
>> >> >> Thanks,
>> >> >> Can Guo.
>> >> >>
>> >> >> > +{
>> >> >> > + struct ufshpb_lu *hpb;
>> >> >> > + struct victim_select_info *lru_info;
>> >> >> > + struct ufshpb_region *rgn;
>> >> >> > + unsigned long flags;
>> >> >> > +
>> >> >> > + hpb = container_of(work, struct ufshpb_lu,
>> ufshpb_lun_reset_work);
>> >> >> > +
>> >> >> > + lru_info = >lru_info;
>> >> >> > +
>> >> >> > + spin_lock_irqsave(>rgn_state_lock, flags);
>> >> >> > +
>> >> >> > + list_for_each_entry(rgn, _info->lh_lru_rgn, list_lru_rgn)
>> >> >> > + set_bit(RGN_FLAG_UPDATE, >rgn_flags);
>> >> >> > +
>> >> >> > + spin_unlock_irqrestore(>rgn_state_lock, flags);
>> >> >> > +}
>> >> >> > +
>> >> >> >  static void ufshpb_normalization_work_handler(struct work_struct
>> >> >> > *work)
>> >> >> >  {
>> >> >> >   struct ufshpb_lu *hpb;
>> >> >> > @@ -1798,6 +1832,8 @@ static int ufshpb_alloc_region_tbl(struct
>> >> >> > ufs_hba *hba, struct ufshpb_lu *hpb)
>> >> >> >   } else {
>> >> >> >   rgn->rgn_state = HPB_RGN_INACTIVE;
>> >> >> >   }
>> >> >> > +
>> >> >> > + rgn->rgn_flags = 0;
>> >> >> >   }
>> >> >> >
>> >> >> >   return 0;
>> >> >> > @@ -2012,9 +2048,12 @@ static int ufshpb_lu_hpb_init(struct
>> ufs_hba
>> >> >> > *hba, struct ufshpb_lu *hpb)
>> >> >> >   INIT_LIST_HEAD(>list_hpb_lu);
>> >> >> >
>> >> >> >   INIT_WORK(>map_work, ufshpb_map_work_handler);
>> >> >> > - if (hpb->is_hcm)
>> >> >> > + if (hpb->is_hcm) {
>> >> >> >   INIT_WORK(>ufshpb_normalization_work,
>> >> >> > ufshpb_normalization_work_handler);
>> >> >> > + 

RE: [PATCH v5 06/10] scsi: ufshpb: Add hpb dev reset response

2021-03-17 Thread Avri Altman
> >> >> >>
> >> >> >> Just curious, directly doing below things inside ufshpb_rsp_upiu()
> >> >> >> does
> >> >> >> not
> >> >> >> seem a problem to me, does this really deserve a separate work?
> >> >> > I don't know, I never even consider of doing this.
> >> >> > The active region list may contain up to few thousands of regions -
> >> >> > It is not rare to see configurations that covers the entire device.
> >> >> >
> >> >>
> >> >> Yes, true, it can be a huge list. But what does the ops
> >> >> "HPB_RSP_DEV_RESET"
> >> >> really mean? The specs says "Device reset HPB Regions information",
> >> >> but
> >> >> I
> >> >> don't know what is really happening. Could you please elaborate?
> >> > It means that the device informs the host that the L2P cache is no
> >> > longer valid.
> >> > The spec doesn't say what to do in that case.
> >>
> >> Then it means that all the clean (without DIRTY flag set) HPB entries
> >> (ppns)
> >> in active rgns in host memory side may not be valid to the device
> >> anymore.
> >> Please correct me if I am wrong.
> >>
> >> > We thought that in host mode, it make sense to update all the active
> >> > regions.
> >>
> >> But current logic does not set the state of the sub-regions (in active
> >> regions) to
> >> INVALID, it only marks all active regions as UPDATE.
> >>
> >> Although one of subsequent read cmds shall put the sub-region back to
> >> activate_list,
> >> ufshpb_test_ppn_dirty() can still return false, thus these read cmds
> >> still think the
> >> ppns are valid and they shall move forward to send HPB Write Buffer
> >> (buffer id = 0x2,
> >> in case of HPB2.0) and HPB Read cmds.
> >>
> >> HPB Read cmds with invalid ppns will be treated as normal Read cmds by
> >> device as the
> >> specs says, but what would happen to HPB Write Buffer cmds (buffer id
> >> =
> >> 0x2, in case
> >> of HPB2.0) with invalid ppns? Can this be a real problem?
> > No need to control the ppn dirty / invalid state for this case.
> > The device send device reset so it is aware that all the L2P cache is
> > invalid.
> > Any HPB_READ is treated like normal READ10.
> >
> > Only once HPB-READ-BUFFER is completed,
> > the device will relate back to the physical address.
> 
> What about HPB-WRITE-BUFFER (buffer id = 0x2) cmds?
Same.
Oper 0x2 is a relative simple case.
The device is expected to manage some versioning framework not to be "fooled" 
by erroneous ppn.
There are some more challenging races that the device should meet.

Thanks,
Avri
> 
> Thanks,
> Can Guo.
> 
> >
> >>
> >> >
> >> > I think I will go with your suggestion.
> >> > Effectively, in host mode, since it is deactivating "cold" regions,
> >> > the lru list is kept relatively small, and contains only "hot" regions.
> >>
> >> hmm... I don't really have a idea on this, please go with whatever you
> >> and Daejun think is fine here.
> > I will take your advice and remove the worker.
> >
> >
> > Thanks,
> > Avri
> >
> >>
> >> Thanks,
> >> Can Guo.
> >>
> >> >
> >> > Thanks,
> >> > Avri
> >> >
> >> >>
> >> >> Thanks,
> >> >> Can Guo.
> >> >>
> >> >> > But yes, I can do that.
> >> >> > Better to get ack from Daejun first.
> >> >> >
> >> >> > Thanks,
> >> >> > Avri
> >> >> >
> >> >> >>
> >> >> >> Thanks,
> >> >> >> Can Guo.
> >> >> >>
> >> >> >> > +{
> >> >> >> > + struct ufshpb_lu *hpb;
> >> >> >> > + struct victim_select_info *lru_info;
> >> >> >> > + struct ufshpb_region *rgn;
> >> >> >> > + unsigned long flags;
> >> >> >> > +
> >> >> >> > + hpb = container_of(work, struct ufshpb_lu,
> >> ufshpb_lun_reset_work);
> >> >> >> > +
> >> >> >> > + lru_info = >lru_info;
> >> >> >> > +
> >> >> >> > + spin_lock_irqsave(>rgn_state_lock, flags);
> >> >> >> > +
> >> >> >> > + list_for_each_entry(rgn, _info->lh_lru_rgn, list_lru_rgn)
> >> >> >> > + set_bit(RGN_FLAG_UPDATE, >rgn_flags);
> >> >> >> > +
> >> >> >> > + spin_unlock_irqrestore(>rgn_state_lock, flags);
> >> >> >> > +}
> >> >> >> > +
> >> >> >> >  static void ufshpb_normalization_work_handler(struct work_struct
> >> >> >> > *work)
> >> >> >> >  {
> >> >> >> >   struct ufshpb_lu *hpb;
> >> >> >> > @@ -1798,6 +1832,8 @@ static int ufshpb_alloc_region_tbl(struct
> >> >> >> > ufs_hba *hba, struct ufshpb_lu *hpb)
> >> >> >> >   } else {
> >> >> >> >   rgn->rgn_state = HPB_RGN_INACTIVE;
> >> >> >> >   }
> >> >> >> > +
> >> >> >> > + rgn->rgn_flags = 0;
> >> >> >> >   }
> >> >> >> >
> >> >> >> >   return 0;
> >> >> >> > @@ -2012,9 +2048,12 @@ static int ufshpb_lu_hpb_init(struct
> >> ufs_hba
> >> >> >> > *hba, struct ufshpb_lu *hpb)
> >> >> >> >   INIT_LIST_HEAD(>list_hpb_lu);
> >> >> >> >
> >> >> >> >   INIT_WORK(>map_work, ufshpb_map_work_handler);
> >> >> >> > - if (hpb->is_hcm)
> >> >> >> > + if (hpb->is_hcm) {
> >> >> >> >   INIT_WORK(>ufshpb_normalization_work,
> >> >> >> > ufshpb_normalization_work_handler);
> >> >> >> > +  

Re: [PATCH v5 06/10] scsi: ufshpb: Add hpb dev reset response

2021-03-17 Thread Can Guo

On 2021-03-17 22:22, Avri Altman wrote:


On 2021-03-17 20:22, Avri Altman wrote:
>>
>> On 2021-03-17 19:23, Avri Altman wrote:
>> >>
>> >> On 2021-03-02 21:24, Avri Altman wrote:
>> >> > The spec does not define what is the host's recommended response
when
>> >> > the device send hpb dev reset response (oper 0x2).
>> >> >
>> >> > We will update all active hpb regions: mark them and do that on the
>> >> > next
>> >> > read.
>> >> >
>> >> > Signed-off-by: Avri Altman 
>> >> > ---
>> >> >  drivers/scsi/ufs/ufshpb.c | 47
>> >> ---
>> >> >  drivers/scsi/ufs/ufshpb.h |  2 ++
>> >> >  2 files changed, 46 insertions(+), 3 deletions(-)
>> >> >
>> >> > diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
>> >> > index 0744feb4d484..0034fa03fdc6 100644
>> >> > --- a/drivers/scsi/ufs/ufshpb.c
>> >> > +++ b/drivers/scsi/ufs/ufshpb.c
>> >> > @@ -642,7 +642,8 @@ int ufshpb_prep(struct ufs_hba *hba, struct
>> >> > ufshcd_lrb *lrbp)
>> >> >   if (rgn->reads == ACTIVATION_THRESHOLD)
>> >> >   activate = true;
>> >> >   spin_unlock_irqrestore(>rgn_lock, flags);
>> >> > - if (activate) {
>> >> > + if (activate ||
>> >> > + test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) 
{

Other than this place, do we also need to clear this bit in places 
like

ufshpb_map_req_compl_fn() and/or ufshpb_cleanup_lru_info()? Otherwise,
this flag may be left there even after the rgn is inactivated.

I don't think so - may cause a race if device reset arrives when map
request just finished.


hmm.. that does not look racy to me, in that case the bit is either
set or not set, which does not hurt anything. Anyways, it is up to you.


Better to be in one place.



>> >> >   spin_lock_irqsave(>rsp_list_lock, flags);
>> >> >   ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
>> >> >   hpb->stats.rb_active_cnt++;
>> >> > @@ -1480,6 +1481,20 @@ void ufshpb_rsp_upiu(struct ufs_hba
*hba,
>> >> > struct ufshcd_lrb *lrbp)
>> >> >   case HPB_RSP_DEV_RESET:
>> >> >   dev_warn(>sdev_ufs_lu->sdev_dev,
>> >> >"UFS device lost HPB information during PM.\n");
>> >> > +
>> >> > + if (hpb->is_hcm) {
>> >> > + struct scsi_device *sdev;
>> >> > +
>> >> > + __shost_for_each_device(sdev, hba->host) {
>> >> > + struct ufshpb_lu *h = sdev->hostdata;
>> >> > +
>> >> > + if (!h)
>> >> > + continue;
>> >> > +
>> >> > + 
schedule_work(>ufshpb_lun_reset_work);
>> >> > + }
>> >> > + }
>> >> > +
>> >> >   break;
>> >> >   default:
>> >> >   dev_notice(>sdev_ufs_lu->sdev_dev,
>> >> > @@ -1594,6 +1609,25 @@ static void
>> >> > ufshpb_run_inactive_region_list(struct ufshpb_lu *hpb)
>> >> >   spin_unlock_irqrestore(>rsp_list_lock, flags);
>> >> >  }
>> >> >
>> >> > +static void ufshpb_reset_work_handler(struct work_struct *work)
>> >>
>> >> Just curious, directly doing below things inside ufshpb_rsp_upiu()
>> >> does
>> >> not
>> >> seem a problem to me, does this really deserve a separate work?
>> > I don't know, I never even consider of doing this.
>> > The active region list may contain up to few thousands of regions -
>> > It is not rare to see configurations that covers the entire device.
>> >
>>
>> Yes, true, it can be a huge list. But what does the ops
>> "HPB_RSP_DEV_RESET"
>> really mean? The specs says "Device reset HPB Regions information",
>> but
>> I
>> don't know what is really happening. Could you please elaborate?
> It means that the device informs the host that the L2P cache is no
> longer valid.
> The spec doesn

RE: [PATCH v5 06/10] scsi: ufshpb: Add hpb dev reset response

2021-03-17 Thread Avri Altman
 
> 
> On 2021-03-17 20:22, Avri Altman wrote:
> >>
> >> On 2021-03-17 19:23, Avri Altman wrote:
> >> >>
> >> >> On 2021-03-02 21:24, Avri Altman wrote:
> >> >> > The spec does not define what is the host's recommended response
> when
> >> >> > the device send hpb dev reset response (oper 0x2).
> >> >> >
> >> >> > We will update all active hpb regions: mark them and do that on the
> >> >> > next
> >> >> > read.
> >> >> >
> >> >> > Signed-off-by: Avri Altman 
> >> >> > ---
> >> >> >  drivers/scsi/ufs/ufshpb.c | 47
> >> >> ---
> >> >> >  drivers/scsi/ufs/ufshpb.h |  2 ++
> >> >> >  2 files changed, 46 insertions(+), 3 deletions(-)
> >> >> >
> >> >> > diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
> >> >> > index 0744feb4d484..0034fa03fdc6 100644
> >> >> > --- a/drivers/scsi/ufs/ufshpb.c
> >> >> > +++ b/drivers/scsi/ufs/ufshpb.c
> >> >> > @@ -642,7 +642,8 @@ int ufshpb_prep(struct ufs_hba *hba, struct
> >> >> > ufshcd_lrb *lrbp)
> >> >> >   if (rgn->reads == ACTIVATION_THRESHOLD)
> >> >> >   activate = true;
> >> >> >   spin_unlock_irqrestore(>rgn_lock, flags);
> >> >> > - if (activate) {
> >> >> > + if (activate ||
> >> >> > + test_and_clear_bit(RGN_FLAG_UPDATE, 
> >> >> > >rgn_flags)) {
> 
> Other than this place, do we also need to clear this bit in places like
> ufshpb_map_req_compl_fn() and/or ufshpb_cleanup_lru_info()? Otherwise,
> this flag may be left there even after the rgn is inactivated.
I don't think so - may cause a race if device reset arrives when map request 
just finished.
Better to be in one place.

> 
> >> >> >   spin_lock_irqsave(>rsp_list_lock, flags);
> >> >> >   ufshpb_update_active_info(hpb, rgn_idx, 
> >> >> > srgn_idx);
> >> >> >   hpb->stats.rb_active_cnt++;
> >> >> > @@ -1480,6 +1481,20 @@ void ufshpb_rsp_upiu(struct ufs_hba
> *hba,
> >> >> > struct ufshcd_lrb *lrbp)
> >> >> >   case HPB_RSP_DEV_RESET:
> >> >> >   dev_warn(>sdev_ufs_lu->sdev_dev,
> >> >> >"UFS device lost HPB information during 
> >> >> > PM.\n");
> >> >> > +
> >> >> > + if (hpb->is_hcm) {
> >> >> > + struct scsi_device *sdev;
> >> >> > +
> >> >> > + __shost_for_each_device(sdev, hba->host) {
> >> >> > + struct ufshpb_lu *h = sdev->hostdata;
> >> >> > +
> >> >> > + if (!h)
> >> >> > + continue;
> >> >> > +
> >> >> > + 
> >> >> > schedule_work(>ufshpb_lun_reset_work);
> >> >> > + }
> >> >> > + }
> >> >> > +
> >> >> >   break;
> >> >> >   default:
> >> >> >   dev_notice(>sdev_ufs_lu->sdev_dev,
> >> >> > @@ -1594,6 +1609,25 @@ static void
> >> >> > ufshpb_run_inactive_region_list(struct ufshpb_lu *hpb)
> >> >> >   spin_unlock_irqrestore(>rsp_list_lock, flags);
> >> >> >  }
> >> >> >
> >> >> > +static void ufshpb_reset_work_handler(struct work_struct *work)
> >> >>
> >> >> Just curious, directly doing below things inside ufshpb_rsp_upiu()
> >> >> does
> >> >> not
> >> >> seem a problem to me, does this really deserve a separate work?
> >> > I don't know, I never even consider of doing this.
> >> > The active region list may contain up to few thousands of regions -
> >> > It is not rare to see configurations that covers the entire device.
> >> >
> >>
> >> Yes, true, it can be a huge list. But what does 

Re: [PATCH v5 06/10] scsi: ufshpb: Add hpb dev reset response

2021-03-17 Thread Can Guo

On 2021-03-17 20:22, Avri Altman wrote:


On 2021-03-17 19:23, Avri Altman wrote:
>>
>> On 2021-03-02 21:24, Avri Altman wrote:
>> > The spec does not define what is the host's recommended response when
>> > the device send hpb dev reset response (oper 0x2).
>> >
>> > We will update all active hpb regions: mark them and do that on the
>> > next
>> > read.
>> >
>> > Signed-off-by: Avri Altman 
>> > ---
>> >  drivers/scsi/ufs/ufshpb.c | 47
>> ---
>> >  drivers/scsi/ufs/ufshpb.h |  2 ++
>> >  2 files changed, 46 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
>> > index 0744feb4d484..0034fa03fdc6 100644
>> > --- a/drivers/scsi/ufs/ufshpb.c
>> > +++ b/drivers/scsi/ufs/ufshpb.c
>> > @@ -642,7 +642,8 @@ int ufshpb_prep(struct ufs_hba *hba, struct
>> > ufshcd_lrb *lrbp)
>> >   if (rgn->reads == ACTIVATION_THRESHOLD)
>> >   activate = true;
>> >   spin_unlock_irqrestore(>rgn_lock, flags);
>> > - if (activate) {
>> > + if (activate ||
>> > + test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {


Other than this place, do we also need to clear this bit in places like
ufshpb_map_req_compl_fn() and/or ufshpb_cleanup_lru_info()? Otherwise,
this flag may be left there even after the rgn is inactivated.


>> >   spin_lock_irqsave(>rsp_list_lock, flags);
>> >   ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
>> >   hpb->stats.rb_active_cnt++;
>> > @@ -1480,6 +1481,20 @@ void ufshpb_rsp_upiu(struct ufs_hba *hba,
>> > struct ufshcd_lrb *lrbp)
>> >   case HPB_RSP_DEV_RESET:
>> >   dev_warn(>sdev_ufs_lu->sdev_dev,
>> >"UFS device lost HPB information during PM.\n");
>> > +
>> > + if (hpb->is_hcm) {
>> > + struct scsi_device *sdev;
>> > +
>> > + __shost_for_each_device(sdev, hba->host) {
>> > + struct ufshpb_lu *h = sdev->hostdata;
>> > +
>> > + if (!h)
>> > + continue;
>> > +
>> > + schedule_work(>ufshpb_lun_reset_work);
>> > + }
>> > + }
>> > +
>> >   break;
>> >   default:
>> >   dev_notice(>sdev_ufs_lu->sdev_dev,
>> > @@ -1594,6 +1609,25 @@ static void
>> > ufshpb_run_inactive_region_list(struct ufshpb_lu *hpb)
>> >   spin_unlock_irqrestore(>rsp_list_lock, flags);
>> >  }
>> >
>> > +static void ufshpb_reset_work_handler(struct work_struct *work)
>>
>> Just curious, directly doing below things inside ufshpb_rsp_upiu()
>> does
>> not
>> seem a problem to me, does this really deserve a separate work?
> I don't know, I never even consider of doing this.
> The active region list may contain up to few thousands of regions -
> It is not rare to see configurations that covers the entire device.
>

Yes, true, it can be a huge list. But what does the ops
"HPB_RSP_DEV_RESET"
really mean? The specs says "Device reset HPB Regions information", 
but

I
don't know what is really happening. Could you please elaborate?
It means that the device informs the host that the L2P cache is no 
longer valid.

The spec doesn't say what to do in that case.


Then it means that all the clean (without DIRTY flag set) HPB entries 
(ppns)
in active rgns in host memory side may not be valid to the device 
anymore.

Please correct me if I am wrong.

We thought that in host mode, it make sense to update all the active 
regions.


But current logic does not set the state of the sub-regions (in active 
regions) to

INVALID, it only marks all active regions as UPDATE.

Although one of subsequent read cmds shall put the sub-region back to 
activate_list,
ufshpb_test_ppn_dirty() can still return false, thus these read cmds 
still think the
ppns are valid and they shall move forward to send HPB Write Buffer 
(buffer id = 0x2,

in case of HPB2.0) and HPB Read cmds.

HPB Read cmds with invalid ppns will be treated as normal Read cmds by 
device as the
specs says, but what would happen to HPB Write Buffer cmds (buffer id = 
0x2, in case

of HPB2.0) with invalid ppns? Can this be a real problem?



I think I will go with your s

RE: [PATCH v5 06/10] scsi: ufshpb: Add hpb dev reset response

2021-03-17 Thread Avri Altman
> 
> On 2021-03-17 19:23, Avri Altman wrote:
> >>
> >> On 2021-03-02 21:24, Avri Altman wrote:
> >> > The spec does not define what is the host's recommended response when
> >> > the device send hpb dev reset response (oper 0x2).
> >> >
> >> > We will update all active hpb regions: mark them and do that on the
> >> > next
> >> > read.
> >> >
> >> > Signed-off-by: Avri Altman 
> >> > ---
> >> >  drivers/scsi/ufs/ufshpb.c | 47
> >> ---
> >> >  drivers/scsi/ufs/ufshpb.h |  2 ++
> >> >  2 files changed, 46 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
> >> > index 0744feb4d484..0034fa03fdc6 100644
> >> > --- a/drivers/scsi/ufs/ufshpb.c
> >> > +++ b/drivers/scsi/ufs/ufshpb.c
> >> > @@ -642,7 +642,8 @@ int ufshpb_prep(struct ufs_hba *hba, struct
> >> > ufshcd_lrb *lrbp)
> >> >   if (rgn->reads == ACTIVATION_THRESHOLD)
> >> >   activate = true;
> >> >   spin_unlock_irqrestore(>rgn_lock, flags);
> >> > - if (activate) {
> >> > + if (activate ||
> >> > + test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {
> >> >   spin_lock_irqsave(>rsp_list_lock, flags);
> >> >   ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
> >> >   hpb->stats.rb_active_cnt++;
> >> > @@ -1480,6 +1481,20 @@ void ufshpb_rsp_upiu(struct ufs_hba *hba,
> >> > struct ufshcd_lrb *lrbp)
> >> >   case HPB_RSP_DEV_RESET:
> >> >   dev_warn(>sdev_ufs_lu->sdev_dev,
> >> >"UFS device lost HPB information during PM.\n");
> >> > +
> >> > + if (hpb->is_hcm) {
> >> > + struct scsi_device *sdev;
> >> > +
> >> > + __shost_for_each_device(sdev, hba->host) {
> >> > + struct ufshpb_lu *h = sdev->hostdata;
> >> > +
> >> > + if (!h)
> >> > + continue;
> >> > +
> >> > + schedule_work(>ufshpb_lun_reset_work);
> >> > + }
> >> > + }
> >> > +
> >> >   break;
> >> >   default:
> >> >   dev_notice(>sdev_ufs_lu->sdev_dev,
> >> > @@ -1594,6 +1609,25 @@ static void
> >> > ufshpb_run_inactive_region_list(struct ufshpb_lu *hpb)
> >> >   spin_unlock_irqrestore(>rsp_list_lock, flags);
> >> >  }
> >> >
> >> > +static void ufshpb_reset_work_handler(struct work_struct *work)
> >>
> >> Just curious, directly doing below things inside ufshpb_rsp_upiu()
> >> does
> >> not
> >> seem a problem to me, does this really deserve a separate work?
> > I don't know, I never even consider of doing this.
> > The active region list may contain up to few thousands of regions -
> > It is not rare to see configurations that covers the entire device.
> >
> 
> Yes, true, it can be a huge list. But what does the ops
> "HPB_RSP_DEV_RESET"
> really mean? The specs says "Device reset HPB Regions information", but
> I
> don't know what is really happening. Could you please elaborate?
It means that the device informs the host that the L2P cache is no longer valid.
The spec doesn't say what to do in that case.
We thought that in host mode, it make sense to update all the active regions.

I think I will go with your suggestion.
Effectively, in host mode, since it is deactivating "cold" regions,
the lru list is kept relatively small, and contains only "hot" regions.

Thanks,
Avri

> 
> Thanks,
> Can Guo.
> 
> > But yes, I can do that.
> > Better to get ack from Daejun first.
> >
> > Thanks,
> > Avri
> >
> >>
> >> Thanks,
> >> Can Guo.
> >>
> >> > +{
> >> > + struct ufshpb_lu *hpb;
> >> > + struct victim_select_info *lru_info;
> >> > + struct ufshpb_region *rgn;
> >> > + unsigned long flags;
> >> > +
> >> > + hpb = container_of(work, struc

Re: [PATCH v5 06/10] scsi: ufshpb: Add hpb dev reset response

2021-03-17 Thread Can Guo

On 2021-03-17 19:23, Avri Altman wrote:


On 2021-03-02 21:24, Avri Altman wrote:
> The spec does not define what is the host's recommended response when
> the device send hpb dev reset response (oper 0x2).
>
> We will update all active hpb regions: mark them and do that on the
> next
> read.
>
> Signed-off-by: Avri Altman 
> ---
>  drivers/scsi/ufs/ufshpb.c | 47
---
>  drivers/scsi/ufs/ufshpb.h |  2 ++
>  2 files changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
> index 0744feb4d484..0034fa03fdc6 100644
> --- a/drivers/scsi/ufs/ufshpb.c
> +++ b/drivers/scsi/ufs/ufshpb.c
> @@ -642,7 +642,8 @@ int ufshpb_prep(struct ufs_hba *hba, struct
> ufshcd_lrb *lrbp)
>   if (rgn->reads == ACTIVATION_THRESHOLD)
>   activate = true;
>   spin_unlock_irqrestore(>rgn_lock, flags);
> - if (activate) {
> + if (activate ||
> + test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {
>   spin_lock_irqsave(>rsp_list_lock, flags);
>   ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
>   hpb->stats.rb_active_cnt++;
> @@ -1480,6 +1481,20 @@ void ufshpb_rsp_upiu(struct ufs_hba *hba,
> struct ufshcd_lrb *lrbp)
>   case HPB_RSP_DEV_RESET:
>   dev_warn(>sdev_ufs_lu->sdev_dev,
>"UFS device lost HPB information during PM.\n");
> +
> + if (hpb->is_hcm) {
> + struct scsi_device *sdev;
> +
> + __shost_for_each_device(sdev, hba->host) {
> + struct ufshpb_lu *h = sdev->hostdata;
> +
> + if (!h)
> + continue;
> +
> + schedule_work(>ufshpb_lun_reset_work);
> + }
> + }
> +
>   break;
>   default:
>   dev_notice(>sdev_ufs_lu->sdev_dev,
> @@ -1594,6 +1609,25 @@ static void
> ufshpb_run_inactive_region_list(struct ufshpb_lu *hpb)
>   spin_unlock_irqrestore(>rsp_list_lock, flags);
>  }
>
> +static void ufshpb_reset_work_handler(struct work_struct *work)

Just curious, directly doing below things inside ufshpb_rsp_upiu() 
does

not
seem a problem to me, does this really deserve a separate work?

I don't know, I never even consider of doing this.
The active region list may contain up to few thousands of regions -
It is not rare to see configurations that covers the entire device.



Yes, true, it can be a huge list. But what does the ops 
"HPB_RSP_DEV_RESET"
really mean? The specs says "Device reset HPB Regions information", but 
I

don't know what is really happening. Could you please elaborate?

Thanks,
Can Guo.


But yes, I can do that.
Better to get ack from Daejun first.

Thanks,
Avri



Thanks,
Can Guo.

> +{
> + struct ufshpb_lu *hpb;
> + struct victim_select_info *lru_info;
> + struct ufshpb_region *rgn;
> + unsigned long flags;
> +
> + hpb = container_of(work, struct ufshpb_lu, ufshpb_lun_reset_work);
> +
> + lru_info = >lru_info;
> +
> + spin_lock_irqsave(>rgn_state_lock, flags);
> +
> + list_for_each_entry(rgn, _info->lh_lru_rgn, list_lru_rgn)
> + set_bit(RGN_FLAG_UPDATE, >rgn_flags);
> +
> + spin_unlock_irqrestore(>rgn_state_lock, flags);
> +}
> +
>  static void ufshpb_normalization_work_handler(struct work_struct
> *work)
>  {
>   struct ufshpb_lu *hpb;
> @@ -1798,6 +1832,8 @@ static int ufshpb_alloc_region_tbl(struct
> ufs_hba *hba, struct ufshpb_lu *hpb)
>   } else {
>   rgn->rgn_state = HPB_RGN_INACTIVE;
>   }
> +
> + rgn->rgn_flags = 0;
>   }
>
>   return 0;
> @@ -2012,9 +2048,12 @@ static int ufshpb_lu_hpb_init(struct ufs_hba
> *hba, struct ufshpb_lu *hpb)
>   INIT_LIST_HEAD(>list_hpb_lu);
>
>   INIT_WORK(>map_work, ufshpb_map_work_handler);
> - if (hpb->is_hcm)
> + if (hpb->is_hcm) {
>   INIT_WORK(>ufshpb_normalization_work,
> ufshpb_normalization_work_handler);
> + INIT_WORK(>ufshpb_lun_reset_work,
> +   ufshpb_reset_work_handler);
> + }
>
>   hpb->map_req_cache = kmem_cache_create("ufshpb_req_cache",
> sizeof(struct ufshpb_req), 0, 0, NULL);
> @@ -2114,8 +2153,10 @@ static void ufshpb_discard_rsp_lists(struct
> ufshpb_lu *hpb)
>
>  static void ufshpb

RE: [PATCH v5 06/10] scsi: ufshpb: Add hpb dev reset response

2021-03-17 Thread Avri Altman
> 
> On 2021-03-02 21:24, Avri Altman wrote:
> > The spec does not define what is the host's recommended response when
> > the device send hpb dev reset response (oper 0x2).
> >
> > We will update all active hpb regions: mark them and do that on the
> > next
> > read.
> >
> > Signed-off-by: Avri Altman 
> > ---
> >  drivers/scsi/ufs/ufshpb.c | 47
> ---
> >  drivers/scsi/ufs/ufshpb.h |  2 ++
> >  2 files changed, 46 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
> > index 0744feb4d484..0034fa03fdc6 100644
> > --- a/drivers/scsi/ufs/ufshpb.c
> > +++ b/drivers/scsi/ufs/ufshpb.c
> > @@ -642,7 +642,8 @@ int ufshpb_prep(struct ufs_hba *hba, struct
> > ufshcd_lrb *lrbp)
> >   if (rgn->reads == ACTIVATION_THRESHOLD)
> >   activate = true;
> >   spin_unlock_irqrestore(>rgn_lock, flags);
> > - if (activate) {
> > + if (activate ||
> > + test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {
> >   spin_lock_irqsave(>rsp_list_lock, flags);
> >   ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
> >   hpb->stats.rb_active_cnt++;
> > @@ -1480,6 +1481,20 @@ void ufshpb_rsp_upiu(struct ufs_hba *hba,
> > struct ufshcd_lrb *lrbp)
> >   case HPB_RSP_DEV_RESET:
> >   dev_warn(>sdev_ufs_lu->sdev_dev,
> >"UFS device lost HPB information during PM.\n");
> > +
> > + if (hpb->is_hcm) {
> > + struct scsi_device *sdev;
> > +
> > + __shost_for_each_device(sdev, hba->host) {
> > + struct ufshpb_lu *h = sdev->hostdata;
> > +
> > + if (!h)
> > + continue;
> > +
> > + schedule_work(>ufshpb_lun_reset_work);
> > + }
> > + }
> > +
> >   break;
> >   default:
> >   dev_notice(>sdev_ufs_lu->sdev_dev,
> > @@ -1594,6 +1609,25 @@ static void
> > ufshpb_run_inactive_region_list(struct ufshpb_lu *hpb)
> >   spin_unlock_irqrestore(>rsp_list_lock, flags);
> >  }
> >
> > +static void ufshpb_reset_work_handler(struct work_struct *work)
> 
> Just curious, directly doing below things inside ufshpb_rsp_upiu() does
> not
> seem a problem to me, does this really deserve a separate work?
I don't know, I never even consider of doing this.
The active region list may contain up to few thousands of regions - 
It is not rare to see configurations that covers the entire device.

But yes, I can do that.
Better to get ack from Daejun first.

Thanks,
Avri

> 
> Thanks,
> Can Guo.
> 
> > +{
> > + struct ufshpb_lu *hpb;
> > + struct victim_select_info *lru_info;
> > + struct ufshpb_region *rgn;
> > + unsigned long flags;
> > +
> > + hpb = container_of(work, struct ufshpb_lu, ufshpb_lun_reset_work);
> > +
> > + lru_info = >lru_info;
> > +
> > + spin_lock_irqsave(>rgn_state_lock, flags);
> > +
> > + list_for_each_entry(rgn, _info->lh_lru_rgn, list_lru_rgn)
> > + set_bit(RGN_FLAG_UPDATE, >rgn_flags);
> > +
> > + spin_unlock_irqrestore(>rgn_state_lock, flags);
> > +}
> > +
> >  static void ufshpb_normalization_work_handler(struct work_struct
> > *work)
> >  {
> >   struct ufshpb_lu *hpb;
> > @@ -1798,6 +1832,8 @@ static int ufshpb_alloc_region_tbl(struct
> > ufs_hba *hba, struct ufshpb_lu *hpb)
> >   } else {
> >   rgn->rgn_state = HPB_RGN_INACTIVE;
> >   }
> > +
> > + rgn->rgn_flags = 0;
> >   }
> >
> >   return 0;
> > @@ -2012,9 +2048,12 @@ static int ufshpb_lu_hpb_init(struct ufs_hba
> > *hba, struct ufshpb_lu *hpb)
> >   INIT_LIST_HEAD(>list_hpb_lu);
> >
> >   INIT_WORK(>map_work, ufshpb_map_work_handler);
> > - if (hpb->is_hcm)
> > + if (hpb->is_hcm) {
> >   INIT_WORK(>ufshpb_normalization_work,
> > ufshpb_normalization_work_handler);
> > + INIT_WORK(>ufshpb_lun_reset_work,
> > +   ufshpb_reset_work_handler);
> > + }
> >
> >   hpb->map

Re: [PATCH v5 06/10] scsi: ufshpb: Add hpb dev reset response

2021-03-17 Thread Can Guo

On 2021-03-02 21:24, Avri Altman wrote:

The spec does not define what is the host's recommended response when
the device send hpb dev reset response (oper 0x2).

We will update all active hpb regions: mark them and do that on the 
next

read.

Signed-off-by: Avri Altman 
---
 drivers/scsi/ufs/ufshpb.c | 47 ---
 drivers/scsi/ufs/ufshpb.h |  2 ++
 2 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index 0744feb4d484..0034fa03fdc6 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -642,7 +642,8 @@ int ufshpb_prep(struct ufs_hba *hba, struct
ufshcd_lrb *lrbp)
if (rgn->reads == ACTIVATION_THRESHOLD)
activate = true;
spin_unlock_irqrestore(>rgn_lock, flags);
-   if (activate) {
+   if (activate ||
+   test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {
spin_lock_irqsave(>rsp_list_lock, flags);
ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
hpb->stats.rb_active_cnt++;
@@ -1480,6 +1481,20 @@ void ufshpb_rsp_upiu(struct ufs_hba *hba,
struct ufshcd_lrb *lrbp)
case HPB_RSP_DEV_RESET:
dev_warn(>sdev_ufs_lu->sdev_dev,
 "UFS device lost HPB information during PM.\n");
+
+   if (hpb->is_hcm) {
+   struct scsi_device *sdev;
+
+   __shost_for_each_device(sdev, hba->host) {
+   struct ufshpb_lu *h = sdev->hostdata;
+
+   if (!h)
+   continue;
+
+   schedule_work(>ufshpb_lun_reset_work);
+   }
+   }
+
break;
default:
dev_notice(>sdev_ufs_lu->sdev_dev,
@@ -1594,6 +1609,25 @@ static void
ufshpb_run_inactive_region_list(struct ufshpb_lu *hpb)
spin_unlock_irqrestore(>rsp_list_lock, flags);
 }

+static void ufshpb_reset_work_handler(struct work_struct *work)


Just curious, directly doing below things inside ufshpb_rsp_upiu() does 
not

seem a problem to me, does this really deserve a separate work?

Thanks,
Can Guo.


+{
+   struct ufshpb_lu *hpb;
+   struct victim_select_info *lru_info;
+   struct ufshpb_region *rgn;
+   unsigned long flags;
+
+   hpb = container_of(work, struct ufshpb_lu, ufshpb_lun_reset_work);
+
+   lru_info = >lru_info;
+
+   spin_lock_irqsave(>rgn_state_lock, flags);
+
+   list_for_each_entry(rgn, _info->lh_lru_rgn, list_lru_rgn)
+   set_bit(RGN_FLAG_UPDATE, >rgn_flags);
+
+   spin_unlock_irqrestore(>rgn_state_lock, flags);
+}
+
 static void ufshpb_normalization_work_handler(struct work_struct 
*work)

 {
struct ufshpb_lu *hpb;
@@ -1798,6 +1832,8 @@ static int ufshpb_alloc_region_tbl(struct
ufs_hba *hba, struct ufshpb_lu *hpb)
} else {
rgn->rgn_state = HPB_RGN_INACTIVE;
}
+
+   rgn->rgn_flags = 0;
}

return 0;
@@ -2012,9 +2048,12 @@ static int ufshpb_lu_hpb_init(struct ufs_hba
*hba, struct ufshpb_lu *hpb)
INIT_LIST_HEAD(>list_hpb_lu);

INIT_WORK(>map_work, ufshpb_map_work_handler);
-   if (hpb->is_hcm)
+   if (hpb->is_hcm) {
INIT_WORK(>ufshpb_normalization_work,
  ufshpb_normalization_work_handler);
+   INIT_WORK(>ufshpb_lun_reset_work,
+ ufshpb_reset_work_handler);
+   }

hpb->map_req_cache = kmem_cache_create("ufshpb_req_cache",
  sizeof(struct ufshpb_req), 0, 0, NULL);
@@ -2114,8 +2153,10 @@ static void ufshpb_discard_rsp_lists(struct
ufshpb_lu *hpb)

 static void ufshpb_cancel_jobs(struct ufshpb_lu *hpb)
 {
-   if (hpb->is_hcm)
+   if (hpb->is_hcm) {
+   cancel_work_sync(>ufshpb_lun_reset_work);
cancel_work_sync(>ufshpb_normalization_work);
+   }
cancel_work_sync(>map_work);
 }

diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
index 84598a317897..37c1b0ea0c0a 100644
--- a/drivers/scsi/ufs/ufshpb.h
+++ b/drivers/scsi/ufs/ufshpb.h
@@ -121,6 +121,7 @@ struct ufshpb_region {
struct list_head list_lru_rgn;
unsigned long rgn_flags;
 #define RGN_FLAG_DIRTY 0
+#define RGN_FLAG_UPDATE 1

/* region reads - for host mode */
spinlock_t rgn_lock;
@@ -217,6 +218,7 @@ struct ufshpb_lu {
/* for selecting victim */
struct victim_select_info lru_info;
struct work_struct ufshpb_normalization_work;
+   struct work_struct ufshpb_lun_reset_work;

/* pinned region information */
u32 lu_pinned_start;


YOUR URGENT RESPONSE IS NEEDED NOW

2021-03-15 Thread ibrahim aliu
-- 
I am contacting you on a business deal of $17.5 Million US Dollars,
ready for transfer into your account

if we make this claim, we will share it 60%/40%.100% risk free and it
will be legally backed up with government approved If you are
interested reply for more details.

Kindly reply  for more details Waiting for your reply  Make Sure You
Write To My privat

Best regards,

Ibrahim Aliu


RE: [PATCH v5 06/10] scsi: ufshpb: Add hpb dev reset response

2021-03-15 Thread Avri Altman
> > +static void ufshpb_reset_work_handler(struct work_struct *work)
> > +{
> > + struct ufshpb_lu *hpb;
> 
>  struct ufshpb_lu *hpb = container_of(work, struct ufshpb_lu,
> ufshpb_lun_reset_work);
> 
> > + struct victim_select_info *lru_info;
> 
>  struct victim_select_info *lru_info = >lru_info;
> 
> This can save some lines.
Done.

Thanks,
Avri
> 
> Thanks,
> Can Guo.
> 


Re: [PATCH v5 06/10] scsi: ufshpb: Add hpb dev reset response

2021-03-15 Thread Can Guo

On 2021-03-15 09:34, Can Guo wrote:

On 2021-03-02 21:24, Avri Altman wrote:

The spec does not define what is the host's recommended response when
the device send hpb dev reset response (oper 0x2).

We will update all active hpb regions: mark them and do that on the 
next

read.

Signed-off-by: Avri Altman 
---
 drivers/scsi/ufs/ufshpb.c | 47 
---

 drivers/scsi/ufs/ufshpb.h |  2 ++
 2 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index 0744feb4d484..0034fa03fdc6 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -642,7 +642,8 @@ int ufshpb_prep(struct ufs_hba *hba, struct
ufshcd_lrb *lrbp)
if (rgn->reads == ACTIVATION_THRESHOLD)
activate = true;
spin_unlock_irqrestore(>rgn_lock, flags);
-   if (activate) {
+   if (activate ||
+   test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {
spin_lock_irqsave(>rsp_list_lock, flags);
ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
hpb->stats.rb_active_cnt++;
@@ -1480,6 +1481,20 @@ void ufshpb_rsp_upiu(struct ufs_hba *hba,
struct ufshcd_lrb *lrbp)
case HPB_RSP_DEV_RESET:
dev_warn(>sdev_ufs_lu->sdev_dev,
 "UFS device lost HPB information during PM.\n");
+
+   if (hpb->is_hcm) {
+   struct scsi_device *sdev;

bool need_reset = false;

+
+   __shost_for_each_device(sdev, hba->host) {
+   struct ufshpb_lu *h = sdev->hostdata;
+
+   if (!h)
+   continue;
+
+   need_reset = true;
+   }


if (need_reset)
schedule_work(>ufshpb_lun_reset_work);

At last, scheduling only one reset work shall be enough, otherwise 
multiple

reset work can be flying in parallel, so maybe above changes?


Forget about this one, I misunderstood it - reset work is for each 
ufshpb_lu...


Regards,
Can Guo.




+   }
+
break;
default:
dev_notice(>sdev_ufs_lu->sdev_dev,
@@ -1594,6 +1609,25 @@ static void
ufshpb_run_inactive_region_list(struct ufshpb_lu *hpb)
spin_unlock_irqrestore(>rsp_list_lock, flags);
 }

+static void ufshpb_reset_work_handler(struct work_struct *work)
+{
+   struct ufshpb_lu *hpb;


struct ufshpb_lu *hpb = container_of(work, struct ufshpb_lu,
ufshpb_lun_reset_work);


+   struct victim_select_info *lru_info;


struct victim_select_info *lru_info = >lru_info;

This can save some lines.

Thanks,
Can Guo.


+   struct ufshpb_region *rgn;
+   unsigned long flags;
+
+   spin_lock_irqsave(>rgn_state_lock, flags);
+
+   list_for_each_entry(rgn, _info->lh_lru_rgn, list_lru_rgn)
+   set_bit(RGN_FLAG_UPDATE, >rgn_flags);
+
+   spin_unlock_irqrestore(>rgn_state_lock, flags);
+}
+
 static void ufshpb_normalization_work_handler(struct work_struct 
*work)

 {
struct ufshpb_lu *hpb;
@@ -1798,6 +1832,8 @@ static int ufshpb_alloc_region_tbl(struct
ufs_hba *hba, struct ufshpb_lu *hpb)
} else {
rgn->rgn_state = HPB_RGN_INACTIVE;
}
+
+   rgn->rgn_flags = 0;
}

return 0;
@@ -2012,9 +2048,12 @@ static int ufshpb_lu_hpb_init(struct ufs_hba
*hba, struct ufshpb_lu *hpb)
INIT_LIST_HEAD(>list_hpb_lu);

INIT_WORK(>map_work, ufshpb_map_work_handler);
-   if (hpb->is_hcm)
+   if (hpb->is_hcm) {
INIT_WORK(>ufshpb_normalization_work,
  ufshpb_normalization_work_handler);
+   INIT_WORK(>ufshpb_lun_reset_work,
+ ufshpb_reset_work_handler);
+   }

hpb->map_req_cache = kmem_cache_create("ufshpb_req_cache",
  sizeof(struct ufshpb_req), 0, 0, NULL);
@@ -2114,8 +2153,10 @@ static void ufshpb_discard_rsp_lists(struct
ufshpb_lu *hpb)

 static void ufshpb_cancel_jobs(struct ufshpb_lu *hpb)
 {
-   if (hpb->is_hcm)
+   if (hpb->is_hcm) {
+   cancel_work_sync(>ufshpb_lun_reset_work);
cancel_work_sync(>ufshpb_normalization_work);
+   }
cancel_work_sync(>map_work);
 }

diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
index 84598a317897..37c1b0ea0c0a 100644
--- a/drivers/scsi/ufs/ufshpb.h
+++ b/drivers/scsi/ufs/ufshpb.h
@@ -121,6 +121,7 @@ struct ufshpb_region {
struct list_head list_lru_rgn;
unsigned long rgn_flags;
 #define RGN_FLAG_DIRTY 0
+#define RGN_FLAG_UPDATE 1

/* regio

Re: [PATCH v5 06/10] scsi: ufshpb: Add hpb dev reset response

2021-03-14 Thread Can Guo

On 2021-03-02 21:24, Avri Altman wrote:

The spec does not define what is the host's recommended response when
the device send hpb dev reset response (oper 0x2).

We will update all active hpb regions: mark them and do that on the 
next

read.

Signed-off-by: Avri Altman 
---
 drivers/scsi/ufs/ufshpb.c | 47 ---
 drivers/scsi/ufs/ufshpb.h |  2 ++
 2 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index 0744feb4d484..0034fa03fdc6 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -642,7 +642,8 @@ int ufshpb_prep(struct ufs_hba *hba, struct
ufshcd_lrb *lrbp)
if (rgn->reads == ACTIVATION_THRESHOLD)
activate = true;
spin_unlock_irqrestore(>rgn_lock, flags);
-   if (activate) {
+   if (activate ||
+   test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {
spin_lock_irqsave(>rsp_list_lock, flags);
ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
hpb->stats.rb_active_cnt++;
@@ -1480,6 +1481,20 @@ void ufshpb_rsp_upiu(struct ufs_hba *hba,
struct ufshcd_lrb *lrbp)
case HPB_RSP_DEV_RESET:
dev_warn(>sdev_ufs_lu->sdev_dev,
 "UFS device lost HPB information during PM.\n");
+
+   if (hpb->is_hcm) {
+   struct scsi_device *sdev;

bool need_reset = false;

+
+   __shost_for_each_device(sdev, hba->host) {
+   struct ufshpb_lu *h = sdev->hostdata;
+
+   if (!h)
+   continue;
+
+   need_reset = true;
+   }


if (need_reset)
schedule_work(>ufshpb_lun_reset_work);

At last, scheduling only one reset work shall be enough, otherwise 
multiple

reset work can be flying in parallel, so maybe above changes?


+   }
+
break;
default:
dev_notice(>sdev_ufs_lu->sdev_dev,
@@ -1594,6 +1609,25 @@ static void
ufshpb_run_inactive_region_list(struct ufshpb_lu *hpb)
spin_unlock_irqrestore(>rsp_list_lock, flags);
 }

+static void ufshpb_reset_work_handler(struct work_struct *work)
+{
+   struct ufshpb_lu *hpb;


struct ufshpb_lu *hpb = container_of(work, struct ufshpb_lu, 
ufshpb_lun_reset_work);



+   struct victim_select_info *lru_info;


struct victim_select_info *lru_info = >lru_info;

This can save some lines.

Thanks,
Can Guo.


+   struct ufshpb_region *rgn;
+   unsigned long flags;
+
+   spin_lock_irqsave(>rgn_state_lock, flags);
+
+   list_for_each_entry(rgn, _info->lh_lru_rgn, list_lru_rgn)
+   set_bit(RGN_FLAG_UPDATE, >rgn_flags);
+
+   spin_unlock_irqrestore(>rgn_state_lock, flags);
+}
+
 static void ufshpb_normalization_work_handler(struct work_struct 
*work)

 {
struct ufshpb_lu *hpb;
@@ -1798,6 +1832,8 @@ static int ufshpb_alloc_region_tbl(struct
ufs_hba *hba, struct ufshpb_lu *hpb)
} else {
rgn->rgn_state = HPB_RGN_INACTIVE;
}
+
+   rgn->rgn_flags = 0;
}

return 0;
@@ -2012,9 +2048,12 @@ static int ufshpb_lu_hpb_init(struct ufs_hba
*hba, struct ufshpb_lu *hpb)
INIT_LIST_HEAD(>list_hpb_lu);

INIT_WORK(>map_work, ufshpb_map_work_handler);
-   if (hpb->is_hcm)
+   if (hpb->is_hcm) {
INIT_WORK(>ufshpb_normalization_work,
  ufshpb_normalization_work_handler);
+   INIT_WORK(>ufshpb_lun_reset_work,
+ ufshpb_reset_work_handler);
+   }

hpb->map_req_cache = kmem_cache_create("ufshpb_req_cache",
  sizeof(struct ufshpb_req), 0, 0, NULL);
@@ -2114,8 +2153,10 @@ static void ufshpb_discard_rsp_lists(struct
ufshpb_lu *hpb)

 static void ufshpb_cancel_jobs(struct ufshpb_lu *hpb)
 {
-   if (hpb->is_hcm)
+   if (hpb->is_hcm) {
+   cancel_work_sync(>ufshpb_lun_reset_work);
cancel_work_sync(>ufshpb_normalization_work);
+   }
cancel_work_sync(>map_work);
 }

diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
index 84598a317897..37c1b0ea0c0a 100644
--- a/drivers/scsi/ufs/ufshpb.h
+++ b/drivers/scsi/ufs/ufshpb.h
@@ -121,6 +121,7 @@ struct ufshpb_region {
struct list_head list_lru_rgn;
unsigned long rgn_flags;
 #define RGN_FLAG_DIRTY 0
+#define RGN_FLAG_UPDATE 1

/* region reads - for host mode */
spinlock_t rgn_lock;
@@ -217,6 +218,7 @@ struct ufshpb_lu {
/* for selecting victim */
 

[PATCH v5 06/10] scsi: ufshpb: Add hpb dev reset response

2021-03-02 Thread Avri Altman
The spec does not define what is the host's recommended response when
the device send hpb dev reset response (oper 0x2).

We will update all active hpb regions: mark them and do that on the next
read.

Signed-off-by: Avri Altman 
---
 drivers/scsi/ufs/ufshpb.c | 47 ---
 drivers/scsi/ufs/ufshpb.h |  2 ++
 2 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index 0744feb4d484..0034fa03fdc6 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -642,7 +642,8 @@ int ufshpb_prep(struct ufs_hba *hba, struct ufshcd_lrb 
*lrbp)
if (rgn->reads == ACTIVATION_THRESHOLD)
activate = true;
spin_unlock_irqrestore(>rgn_lock, flags);
-   if (activate) {
+   if (activate ||
+   test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {
spin_lock_irqsave(>rsp_list_lock, flags);
ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
hpb->stats.rb_active_cnt++;
@@ -1480,6 +1481,20 @@ void ufshpb_rsp_upiu(struct ufs_hba *hba, struct 
ufshcd_lrb *lrbp)
case HPB_RSP_DEV_RESET:
dev_warn(>sdev_ufs_lu->sdev_dev,
 "UFS device lost HPB information during PM.\n");
+
+   if (hpb->is_hcm) {
+   struct scsi_device *sdev;
+
+   __shost_for_each_device(sdev, hba->host) {
+   struct ufshpb_lu *h = sdev->hostdata;
+
+   if (!h)
+   continue;
+
+   schedule_work(>ufshpb_lun_reset_work);
+   }
+   }
+
break;
default:
dev_notice(>sdev_ufs_lu->sdev_dev,
@@ -1594,6 +1609,25 @@ static void ufshpb_run_inactive_region_list(struct 
ufshpb_lu *hpb)
spin_unlock_irqrestore(>rsp_list_lock, flags);
 }
 
+static void ufshpb_reset_work_handler(struct work_struct *work)
+{
+   struct ufshpb_lu *hpb;
+   struct victim_select_info *lru_info;
+   struct ufshpb_region *rgn;
+   unsigned long flags;
+
+   hpb = container_of(work, struct ufshpb_lu, ufshpb_lun_reset_work);
+
+   lru_info = >lru_info;
+
+   spin_lock_irqsave(>rgn_state_lock, flags);
+
+   list_for_each_entry(rgn, _info->lh_lru_rgn, list_lru_rgn)
+   set_bit(RGN_FLAG_UPDATE, >rgn_flags);
+
+   spin_unlock_irqrestore(>rgn_state_lock, flags);
+}
+
 static void ufshpb_normalization_work_handler(struct work_struct *work)
 {
struct ufshpb_lu *hpb;
@@ -1798,6 +1832,8 @@ static int ufshpb_alloc_region_tbl(struct ufs_hba *hba, 
struct ufshpb_lu *hpb)
} else {
rgn->rgn_state = HPB_RGN_INACTIVE;
}
+
+   rgn->rgn_flags = 0;
}
 
return 0;
@@ -2012,9 +2048,12 @@ static int ufshpb_lu_hpb_init(struct ufs_hba *hba, 
struct ufshpb_lu *hpb)
INIT_LIST_HEAD(>list_hpb_lu);
 
INIT_WORK(>map_work, ufshpb_map_work_handler);
-   if (hpb->is_hcm)
+   if (hpb->is_hcm) {
INIT_WORK(>ufshpb_normalization_work,
  ufshpb_normalization_work_handler);
+   INIT_WORK(>ufshpb_lun_reset_work,
+ ufshpb_reset_work_handler);
+   }
 
hpb->map_req_cache = kmem_cache_create("ufshpb_req_cache",
  sizeof(struct ufshpb_req), 0, 0, NULL);
@@ -2114,8 +2153,10 @@ static void ufshpb_discard_rsp_lists(struct ufshpb_lu 
*hpb)
 
 static void ufshpb_cancel_jobs(struct ufshpb_lu *hpb)
 {
-   if (hpb->is_hcm)
+   if (hpb->is_hcm) {
+   cancel_work_sync(>ufshpb_lun_reset_work);
cancel_work_sync(>ufshpb_normalization_work);
+   }
cancel_work_sync(>map_work);
 }
 
diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
index 84598a317897..37c1b0ea0c0a 100644
--- a/drivers/scsi/ufs/ufshpb.h
+++ b/drivers/scsi/ufs/ufshpb.h
@@ -121,6 +121,7 @@ struct ufshpb_region {
struct list_head list_lru_rgn;
unsigned long rgn_flags;
 #define RGN_FLAG_DIRTY 0
+#define RGN_FLAG_UPDATE 1
 
/* region reads - for host mode */
spinlock_t rgn_lock;
@@ -217,6 +218,7 @@ struct ufshpb_lu {
/* for selecting victim */
struct victim_select_info lru_info;
struct work_struct ufshpb_normalization_work;
+   struct work_struct ufshpb_lun_reset_work;
 
/* pinned region information */
u32 lu_pinned_start;
-- 
2.25.1



RE: [PATCH v4 6/9] scsi: ufshpb: Add hpb dev reset response

2021-03-02 Thread Avri Altman
> 
> Hi Avri,
> 
> > diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
> > index cf704b82e72a..f33aa28e0a0a 100644
> > --- a/drivers/scsi/ufs/ufshpb.c
> > +++ b/drivers/scsi/ufs/ufshpb.c
> > @@ -642,7 +642,8 @@ int ufshpb_prep(struct ufs_hba *hba, struct
> ufshcd_lrb *lrbp)
> >  if (rgn->reads == ACTIVATION_THRESHOLD)
> >  activate = true;
> >  spin_unlock_irqrestore(>rgn_lock, flags);
> > -if (activate) {
> > +if (activate ||
> > +test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {
> 
> How about merge rgn->rgn_flags to rgn_state?
This will actually not work, because a region can be e.g. active/inactive and 
dirty,
And I don't want to mess with the regions state machine.

Thanks,
Avri

> 
> Thanks,
> Daejun


RE: [PATCH v4 6/9] scsi: ufshpb: Add hpb dev reset response

2021-03-02 Thread Avri Altman
> Hi Avri,
> 
> > diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
> > index cf704b82e72a..f33aa28e0a0a 100644
> > --- a/drivers/scsi/ufs/ufshpb.c
> > +++ b/drivers/scsi/ufs/ufshpb.c
> > @@ -642,7 +642,8 @@ int ufshpb_prep(struct ufs_hba *hba, struct
> ufshcd_lrb *lrbp)
> >  if (rgn->reads == ACTIVATION_THRESHOLD)
> >  activate = true;
> >  spin_unlock_irqrestore(>rgn_lock, flags);
> > -if (activate) {
> > +if (activate ||
> > +test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {
> 
> How about merge rgn->rgn_flags to rgn_state?
Done.

Thanks,
Avri

> 
> Thanks,
> Daejun


RE: [PATCH v4 6/9] scsi: ufshpb: Add hpb dev reset response

2021-03-02 Thread Daejun Park
Hi Avri,

> diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
> index cf704b82e72a..f33aa28e0a0a 100644
> --- a/drivers/scsi/ufs/ufshpb.c
> +++ b/drivers/scsi/ufs/ufshpb.c
> @@ -642,7 +642,8 @@ int ufshpb_prep(struct ufs_hba *hba, struct ufshcd_lrb 
> *lrbp)
>  if (rgn->reads == ACTIVATION_THRESHOLD)
>  activate = true;
>  spin_unlock_irqrestore(>rgn_lock, flags);
> -if (activate) {
> +if (activate ||
> +test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {

How about merge rgn->rgn_flags to rgn_state?

Thanks,
Daejun


[PATCH 5.11 491/775] mei: hbm: call mei_set_devstate() on hbm stop response

2021-03-01 Thread Greg Kroah-Hartman
From: Alexander Usyskin 

[ Upstream commit 3a77df62deb2e62de0dc26c1cb763cc152329287 ]

Use mei_set_devstate() wrapper upon hbm stop command response,
to trigger sysfs event.

Fixes: 43b8a7ed4739 ("mei: expose device state in sysfs")
Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
Link: https://lore.kernel.org/r/20210129120752.850325-3-tomas.wink...@intel.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/misc/mei/hbm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index 686e8b6a4c55e..0cba3c6dfb148 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -1373,7 +1373,7 @@ int mei_hbm_dispatch(struct mei_device *dev, struct 
mei_msg_hdr *hdr)
return -EPROTO;
}
 
-   dev->dev_state = MEI_DEV_POWER_DOWN;
+   mei_set_devstate(dev, MEI_DEV_POWER_DOWN);
dev_info(dev->dev, "hbm: stop response: resetting.\n");
/* force the reset */
return -EPROTO;
-- 
2.27.0





[PATCH 5.11 026/775] Bluetooth: Fix initializing response id after clearing struct

2021-03-01 Thread Greg Kroah-Hartman
From: Christopher William Snowhill 

[ Upstream commit a5687c644015a097304a2e47476c0ecab2065734 ]

Looks like this was missed when patching the source to clear the structures
throughout, causing this one instance to clear the struct after the response
id is assigned.

Fixes: eddb7732119d ("Bluetooth: A2MP: Fix not initializing all members")
Signed-off-by: Christopher William Snowhill 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 net/bluetooth/a2mp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/a2mp.c b/net/bluetooth/a2mp.c
index da7fd7c8c2dc0..cc26e4c047ad0 100644
--- a/net/bluetooth/a2mp.c
+++ b/net/bluetooth/a2mp.c
@@ -381,9 +381,9 @@ static int a2mp_getampassoc_req(struct amp_mgr *mgr, struct 
sk_buff *skb,
hdev = hci_dev_get(req->id);
if (!hdev || hdev->amp_type == AMP_TYPE_BREDR || tmp) {
struct a2mp_amp_assoc_rsp rsp;
-   rsp.id = req->id;
 
memset(, 0, sizeof(rsp));
+   rsp.id = req->id;
 
if (tmp) {
rsp.status = A2MP_STATUS_COLLISION_OCCURED;
-- 
2.27.0





[PATCH 5.10 407/663] mei: hbm: call mei_set_devstate() on hbm stop response

2021-03-01 Thread Greg Kroah-Hartman
From: Alexander Usyskin 

[ Upstream commit 3a77df62deb2e62de0dc26c1cb763cc152329287 ]

Use mei_set_devstate() wrapper upon hbm stop command response,
to trigger sysfs event.

Fixes: 43b8a7ed4739 ("mei: expose device state in sysfs")
Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
Link: https://lore.kernel.org/r/20210129120752.850325-3-tomas.wink...@intel.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/misc/mei/hbm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index a97eb5d47705d..33579d9795c32 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -1373,7 +1373,7 @@ int mei_hbm_dispatch(struct mei_device *dev, struct 
mei_msg_hdr *hdr)
return -EPROTO;
}
 
-   dev->dev_state = MEI_DEV_POWER_DOWN;
+   mei_set_devstate(dev, MEI_DEV_POWER_DOWN);
dev_info(dev->dev, "hbm: stop response: resetting.\n");
/* force the reset */
return -EPROTO;
-- 
2.27.0





[PATCH 5.10 024/663] Bluetooth: Fix initializing response id after clearing struct

2021-03-01 Thread Greg Kroah-Hartman
From: Christopher William Snowhill 

[ Upstream commit a5687c644015a097304a2e47476c0ecab2065734 ]

Looks like this was missed when patching the source to clear the structures
throughout, causing this one instance to clear the struct after the response
id is assigned.

Fixes: eddb7732119d ("Bluetooth: A2MP: Fix not initializing all members")
Signed-off-by: Christopher William Snowhill 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 net/bluetooth/a2mp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/a2mp.c b/net/bluetooth/a2mp.c
index da7fd7c8c2dc0..cc26e4c047ad0 100644
--- a/net/bluetooth/a2mp.c
+++ b/net/bluetooth/a2mp.c
@@ -381,9 +381,9 @@ static int a2mp_getampassoc_req(struct amp_mgr *mgr, struct 
sk_buff *skb,
hdev = hci_dev_get(req->id);
if (!hdev || hdev->amp_type == AMP_TYPE_BREDR || tmp) {
struct a2mp_amp_assoc_rsp rsp;
-   rsp.id = req->id;
 
memset(, 0, sizeof(rsp));
+   rsp.id = req->id;
 
if (tmp) {
rsp.status = A2MP_STATUS_COLLISION_OCCURED;
-- 
2.27.0





[PATCH 5.4 208/340] mei: hbm: call mei_set_devstate() on hbm stop response

2021-03-01 Thread Greg Kroah-Hartman
From: Alexander Usyskin 

[ Upstream commit 3a77df62deb2e62de0dc26c1cb763cc152329287 ]

Use mei_set_devstate() wrapper upon hbm stop command response,
to trigger sysfs event.

Fixes: 43b8a7ed4739 ("mei: expose device state in sysfs")
Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
Link: https://lore.kernel.org/r/20210129120752.850325-3-tomas.wink...@intel.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/misc/mei/hbm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index a44094cdbc36c..d20b2b99c6f24 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -1300,7 +1300,7 @@ int mei_hbm_dispatch(struct mei_device *dev, struct 
mei_msg_hdr *hdr)
return -EPROTO;
}
 
-   dev->dev_state = MEI_DEV_POWER_DOWN;
+   mei_set_devstate(dev, MEI_DEV_POWER_DOWN);
dev_info(dev->dev, "hbm: stop response: resetting.\n");
/* force the reset */
return -EPROTO;
-- 
2.27.0





[PATCH 5.4 016/340] Bluetooth: Fix initializing response id after clearing struct

2021-03-01 Thread Greg Kroah-Hartman
From: Christopher William Snowhill 

[ Upstream commit a5687c644015a097304a2e47476c0ecab2065734 ]

Looks like this was missed when patching the source to clear the structures
throughout, causing this one instance to clear the struct after the response
id is assigned.

Fixes: eddb7732119d ("Bluetooth: A2MP: Fix not initializing all members")
Signed-off-by: Christopher William Snowhill 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 net/bluetooth/a2mp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/a2mp.c b/net/bluetooth/a2mp.c
index da7fd7c8c2dc0..cc26e4c047ad0 100644
--- a/net/bluetooth/a2mp.c
+++ b/net/bluetooth/a2mp.c
@@ -381,9 +381,9 @@ static int a2mp_getampassoc_req(struct amp_mgr *mgr, struct 
sk_buff *skb,
hdev = hci_dev_get(req->id);
if (!hdev || hdev->amp_type == AMP_TYPE_BREDR || tmp) {
struct a2mp_amp_assoc_rsp rsp;
-   rsp.id = req->id;
 
memset(, 0, sizeof(rsp));
+   rsp.id = req->id;
 
if (tmp) {
rsp.status = A2MP_STATUS_COLLISION_OCCURED;
-- 
2.27.0





[PATCH 4.19 026/247] Bluetooth: Fix initializing response id after clearing struct

2021-03-01 Thread Greg Kroah-Hartman
From: Christopher William Snowhill 

[ Upstream commit a5687c644015a097304a2e47476c0ecab2065734 ]

Looks like this was missed when patching the source to clear the structures
throughout, causing this one instance to clear the struct after the response
id is assigned.

Fixes: eddb7732119d ("Bluetooth: A2MP: Fix not initializing all members")
Signed-off-by: Christopher William Snowhill 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 net/bluetooth/a2mp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/a2mp.c b/net/bluetooth/a2mp.c
index be9640e9ca006..13342cfc8 100644
--- a/net/bluetooth/a2mp.c
+++ b/net/bluetooth/a2mp.c
@@ -388,9 +388,9 @@ static int a2mp_getampassoc_req(struct amp_mgr *mgr, struct 
sk_buff *skb,
hdev = hci_dev_get(req->id);
if (!hdev || hdev->amp_type == AMP_TYPE_BREDR || tmp) {
struct a2mp_amp_assoc_rsp rsp;
-   rsp.id = req->id;
 
memset(, 0, sizeof(rsp));
+   rsp.id = req->id;
 
if (tmp) {
rsp.status = A2MP_STATUS_COLLISION_OCCURED;
-- 
2.27.0





[PATCH 4.14 013/176] Bluetooth: Fix initializing response id after clearing struct

2021-03-01 Thread Greg Kroah-Hartman
From: Christopher William Snowhill 

[ Upstream commit a5687c644015a097304a2e47476c0ecab2065734 ]

Looks like this was missed when patching the source to clear the structures
throughout, causing this one instance to clear the struct after the response
id is assigned.

Fixes: eddb7732119d ("Bluetooth: A2MP: Fix not initializing all members")
Signed-off-by: Christopher William Snowhill 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 net/bluetooth/a2mp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/a2mp.c b/net/bluetooth/a2mp.c
index cd20c35daa6c7..3266264bc61ce 100644
--- a/net/bluetooth/a2mp.c
+++ b/net/bluetooth/a2mp.c
@@ -388,9 +388,9 @@ static int a2mp_getampassoc_req(struct amp_mgr *mgr, struct 
sk_buff *skb,
hdev = hci_dev_get(req->id);
if (!hdev || hdev->amp_type == AMP_TYPE_BREDR || tmp) {
struct a2mp_amp_assoc_rsp rsp;
-   rsp.id = req->id;
 
memset(, 0, sizeof(rsp));
+   rsp.id = req->id;
 
if (tmp) {
rsp.status = A2MP_STATUS_COLLISION_OCCURED;
-- 
2.27.0





[PATCH 4.9 013/134] Bluetooth: Fix initializing response id after clearing struct

2021-03-01 Thread Greg Kroah-Hartman
From: Christopher William Snowhill 

[ Upstream commit a5687c644015a097304a2e47476c0ecab2065734 ]

Looks like this was missed when patching the source to clear the structures
throughout, causing this one instance to clear the struct after the response
id is assigned.

Fixes: eddb7732119d ("Bluetooth: A2MP: Fix not initializing all members")
Signed-off-by: Christopher William Snowhill 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 net/bluetooth/a2mp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/a2mp.c b/net/bluetooth/a2mp.c
index 8f918155685db..242ef2abd0911 100644
--- a/net/bluetooth/a2mp.c
+++ b/net/bluetooth/a2mp.c
@@ -388,9 +388,9 @@ static int a2mp_getampassoc_req(struct amp_mgr *mgr, struct 
sk_buff *skb,
hdev = hci_dev_get(req->id);
if (!hdev || hdev->amp_type == AMP_TYPE_BREDR || tmp) {
struct a2mp_amp_assoc_rsp rsp;
-   rsp.id = req->id;
 
memset(, 0, sizeof(rsp));
+   rsp.id = req->id;
 
if (tmp) {
rsp.status = A2MP_STATUS_COLLISION_OCCURED;
-- 
2.27.0





[PATCH 4.4 09/93] Bluetooth: Fix initializing response id after clearing struct

2021-03-01 Thread Greg Kroah-Hartman
From: Christopher William Snowhill 

[ Upstream commit a5687c644015a097304a2e47476c0ecab2065734 ]

Looks like this was missed when patching the source to clear the structures
throughout, causing this one instance to clear the struct after the response
id is assigned.

Fixes: eddb7732119d ("Bluetooth: A2MP: Fix not initializing all members")
Signed-off-by: Christopher William Snowhill 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 net/bluetooth/a2mp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/a2mp.c b/net/bluetooth/a2mp.c
index 8f918155685db..242ef2abd0911 100644
--- a/net/bluetooth/a2mp.c
+++ b/net/bluetooth/a2mp.c
@@ -388,9 +388,9 @@ static int a2mp_getampassoc_req(struct amp_mgr *mgr, struct 
sk_buff *skb,
hdev = hci_dev_get(req->id);
if (!hdev || hdev->amp_type == AMP_TYPE_BREDR || tmp) {
struct a2mp_amp_assoc_rsp rsp;
-   rsp.id = req->id;
 
memset(, 0, sizeof(rsp));
+   rsp.id = req->id;
 
if (tmp) {
rsp.status = A2MP_STATUS_COLLISION_OCCURED;
-- 
2.27.0





[PATCH v4 6/9] scsi: ufshpb: Add hpb dev reset response

2021-02-26 Thread Avri Altman
The spec does not define what is the host's recommended response when
the device send hpb dev reset response (oper 0x2).

We will update all active hpb regions: mark them and do that on the next
read.

Signed-off-by: Avri Altman 
---
 drivers/scsi/ufs/ufshpb.c | 53 ---
 drivers/scsi/ufs/ufshpb.h |  3 +++
 2 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index cf704b82e72a..f33aa28e0a0a 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -642,7 +642,8 @@ int ufshpb_prep(struct ufs_hba *hba, struct ufshcd_lrb 
*lrbp)
if (rgn->reads == ACTIVATION_THRESHOLD)
activate = true;
spin_unlock_irqrestore(>rgn_lock, flags);
-   if (activate) {
+   if (activate ||
+   test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {
spin_lock_irqsave(>rsp_list_lock, flags);
ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
hpb->stats.rb_active_cnt++;
@@ -1481,6 +1482,24 @@ void ufshpb_rsp_upiu(struct ufs_hba *hba, struct 
ufshcd_lrb *lrbp)
case HPB_RSP_DEV_RESET:
dev_warn(>sdev_ufs_lu->sdev_dev,
 "UFS device lost HPB information during PM.\n");
+
+   if (hpb->is_hcm) {
+   struct scsi_device *sdev;
+
+   __shost_for_each_device(sdev, hba->host) {
+   struct ufshpb_lu *h = sdev->hostdata;
+
+   if (!h)
+   continue;
+
+   if (test_and_set_bit(RESET_PENDING,
+>work_data_bits))
+   continue;
+
+   schedule_work(>ufshpb_lun_reset_work);
+   }
+   }
+
break;
default:
dev_notice(>sdev_ufs_lu->sdev_dev,
@@ -1595,6 +1614,27 @@ static void ufshpb_run_inactive_region_list(struct 
ufshpb_lu *hpb)
spin_unlock_irqrestore(>rsp_list_lock, flags);
 }
 
+static void ufshpb_reset_work_handler(struct work_struct *work)
+{
+   struct ufshpb_lu *hpb;
+   struct victim_select_info *lru_info;
+   struct ufshpb_region *rgn;
+   unsigned long flags;
+
+   hpb = container_of(work, struct ufshpb_lu, ufshpb_lun_reset_work);
+
+   lru_info = >lru_info;
+
+   spin_lock_irqsave(>rgn_state_lock, flags);
+
+   list_for_each_entry(rgn, _info->lh_lru_rgn, list_lru_rgn)
+   set_bit(RGN_FLAG_UPDATE, >rgn_flags);
+
+   spin_unlock_irqrestore(>rgn_state_lock, flags);
+
+   clear_bit(RESET_PENDING, >work_data_bits);
+}
+
 static void ufshpb_normalization_work_handler(struct work_struct *work)
 {
struct ufshpb_lu *hpb;
@@ -1804,6 +1844,8 @@ static int ufshpb_alloc_region_tbl(struct ufs_hba *hba, 
struct ufshpb_lu *hpb)
} else {
rgn->rgn_state = HPB_RGN_INACTIVE;
}
+
+   rgn->rgn_flags = 0;
}
 
return 0;
@@ -2018,9 +2060,12 @@ static int ufshpb_lu_hpb_init(struct ufs_hba *hba, 
struct ufshpb_lu *hpb)
INIT_LIST_HEAD(>list_hpb_lu);
 
INIT_WORK(>map_work, ufshpb_map_work_handler);
-   if (hpb->is_hcm)
+   if (hpb->is_hcm) {
INIT_WORK(>ufshpb_normalization_work,
  ufshpb_normalization_work_handler);
+   INIT_WORK(>ufshpb_lun_reset_work,
+ ufshpb_reset_work_handler);
+   }
 
hpb->map_req_cache = kmem_cache_create("ufshpb_req_cache",
  sizeof(struct ufshpb_req), 0, 0, NULL);
@@ -2120,8 +2165,10 @@ static void ufshpb_discard_rsp_lists(struct ufshpb_lu 
*hpb)
 
 static void ufshpb_cancel_jobs(struct ufshpb_lu *hpb)
 {
-   if (hpb->is_hcm)
+   if (hpb->is_hcm) {
+   cancel_work_sync(>ufshpb_lun_reset_work);
cancel_work_sync(>ufshpb_normalization_work);
+   }
cancel_work_sync(>map_work);
 }
 
diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
index b78ccb67b765..60bf5564397b 100644
--- a/drivers/scsi/ufs/ufshpb.h
+++ b/drivers/scsi/ufs/ufshpb.h
@@ -121,6 +121,7 @@ struct ufshpb_region {
struct list_head list_lru_rgn;
unsigned long rgn_flags;
 #define RGN_FLAG_DIRTY 0
+#define RGN_FLAG_UPDATE 1
 
/* region reads - for host mode */
spinlock_t rgn_lock;
@@ -217,8 +218,10 @@ struct ufshpb_lu {
/* for selecting victim */
struct victim_select_info lru_info;
struct work_struct ufshpb_normalization_work;
+   struct work_struct ufshpb_lun_reset_work;
unsigne

[PATCH v12 12/13] vfio/pci: Register a DMA fault response region

2021-02-23 Thread Eric Auger
In preparation for vSVA, let's register a DMA fault response region,
where the userspace will push the page responses and increment the
head of the buffer. The kernel will pop those responses and inject them
on iommu side.

Signed-off-by: Eric Auger 

---

v11 -> v12:
- use DMA_FAULT_RESPONSE cap [Shameer]
- struct vfio_pci_device dma_fault_response_wq field introduced in
  this patch
- return 0 if the domain is NULL
- pass an int pointer to iommu_domain_get_attr
---
 drivers/vfio/pci/vfio_pci.c | 125 ++--
 drivers/vfio/pci/vfio_pci_private.h |   6 ++
 drivers/vfio/pci/vfio_pci_rdwr.c|  39 +
 include/uapi/linux/vfio.h   |  32 +++
 4 files changed, 193 insertions(+), 9 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index f3fa6d4318ae..9f1f5008e556 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -316,9 +316,20 @@ static void vfio_pci_dma_fault_release(struct 
vfio_pci_device *vdev,
kfree(vdev->fault_pages);
 }
 
-static int vfio_pci_dma_fault_mmap(struct vfio_pci_device *vdev,
-  struct vfio_pci_region *region,
-  struct vm_area_struct *vma)
+static void
+vfio_pci_dma_fault_response_release(struct vfio_pci_device *vdev,
+   struct vfio_pci_region *region)
+{
+   if (vdev->dma_fault_response_wq)
+   destroy_workqueue(vdev->dma_fault_response_wq);
+   kfree(vdev->fault_response_pages);
+   vdev->fault_response_pages = NULL;
+}
+
+static int __vfio_pci_dma_fault_mmap(struct vfio_pci_device *vdev,
+struct vfio_pci_region *region,
+struct vm_area_struct *vma,
+u8 *pages)
 {
u64 phys_len, req_len, pgoff, req_start;
unsigned long long addr;
@@ -331,14 +342,14 @@ static int vfio_pci_dma_fault_mmap(struct vfio_pci_device 
*vdev,
((1U << (VFIO_PCI_OFFSET_SHIFT - PAGE_SHIFT)) - 1);
req_start = pgoff << PAGE_SHIFT;
 
-   /* only the second page of the producer fault region is mmappable */
+   /* only the second page of the fault region is mmappable */
if (req_start < PAGE_SIZE)
return -EINVAL;
 
if (req_start + req_len > phys_len)
return -EINVAL;
 
-   addr = virt_to_phys(vdev->fault_pages);
+   addr = virt_to_phys(pages);
vma->vm_private_data = vdev;
vma->vm_pgoff = (addr >> PAGE_SHIFT) + pgoff;
 
@@ -347,13 +358,29 @@ static int vfio_pci_dma_fault_mmap(struct vfio_pci_device 
*vdev,
return ret;
 }
 
-static int vfio_pci_dma_fault_add_capability(struct vfio_pci_device *vdev,
-struct vfio_pci_region *region,
-struct vfio_info_cap *caps)
+static int vfio_pci_dma_fault_mmap(struct vfio_pci_device *vdev,
+  struct vfio_pci_region *region,
+  struct vm_area_struct *vma)
+{
+   return __vfio_pci_dma_fault_mmap(vdev, region, vma, vdev->fault_pages);
+}
+
+static int
+vfio_pci_dma_fault_response_mmap(struct vfio_pci_device *vdev,
+   struct vfio_pci_region *region,
+   struct vm_area_struct *vma)
+{
+   return __vfio_pci_dma_fault_mmap(vdev, region, vma, 
vdev->fault_response_pages);
+}
+
+static int __vfio_pci_dma_fault_add_capability(struct vfio_pci_device *vdev,
+  struct vfio_pci_region *region,
+  struct vfio_info_cap *caps,
+  u32 cap_id)
 {
struct vfio_region_info_cap_sparse_mmap *sparse = NULL;
struct vfio_region_info_cap_fault cap = {
-   .header.id = VFIO_REGION_INFO_CAP_DMA_FAULT,
+   .header.id = cap_id,
.header.version = 1,
.version = 1,
};
@@ -381,6 +408,23 @@ static int vfio_pci_dma_fault_add_capability(struct 
vfio_pci_device *vdev,
return ret;
 }
 
+static int vfio_pci_dma_fault_add_capability(struct vfio_pci_device *vdev,
+struct vfio_pci_region *region,
+struct vfio_info_cap *caps)
+{
+   return __vfio_pci_dma_fault_add_capability(vdev, region, caps,
+  
VFIO_REGION_INFO_CAP_DMA_FAULT);
+}
+
+static int
+vfio_pci_dma_fault_response_add_capability(struct vfio_pci_device *vdev,
+  struct vfio_pci_region *region,
+  struct vfio_info_cap *caps)
+{
+   retu

[PATCH v12 13/13] vfio/pci: Inject page response upon response region fill

2021-02-23 Thread Eric Auger
When the userspace increments the head of the page response
buffer ring, let's push the response into the iommu layer.
This is done through a workqueue that pops the responses from
the ring buffer and increment the tail.

Signed-off-by: Eric Auger 
---
 drivers/vfio/pci/vfio_pci.c | 40 +
 drivers/vfio/pci/vfio_pci_private.h |  7 +
 drivers/vfio/pci/vfio_pci_rdwr.c|  1 +
 3 files changed, 48 insertions(+)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 9f1f5008e556..a41497779a68 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -552,6 +552,32 @@ static int vfio_pci_dma_fault_init(struct vfio_pci_device 
*vdev)
return ret;
 }
 
+static void dma_response_inject(struct work_struct *work)
+{
+   struct vfio_pci_dma_fault_response_work *rwork =
+   container_of(work, struct vfio_pci_dma_fault_response_work, 
inject);
+   struct vfio_region_dma_fault_response *header = rwork->header;
+   struct vfio_pci_device *vdev = rwork->vdev;
+   struct iommu_page_response *resp;
+   u32 tail, head, size;
+
+   mutex_lock(>fault_response_queue_lock);
+
+   tail = header->tail;
+   head = header->head;
+   size = header->nb_entries;
+
+   while (CIRC_CNT(head, tail, size) >= 1) {
+   resp = (struct iommu_page_response 
*)(vdev->fault_response_pages + header->offset +
+   tail * header->entry_size);
+
+   /* TODO: properly handle the return value */
+   iommu_page_response(>pdev->dev, resp);
+   header->tail = tail = (tail + 1) % size;
+   }
+   mutex_unlock(>fault_response_queue_lock);
+}
+
 #define DMA_FAULT_RESPONSE_RING_LENGTH 512
 
 static int vfio_pci_dma_fault_response_init(struct vfio_pci_device *vdev)
@@ -597,8 +623,22 @@ static int vfio_pci_dma_fault_response_init(struct 
vfio_pci_device *vdev)
header->nb_entries = DMA_FAULT_RESPONSE_RING_LENGTH;
header->offset = PAGE_SIZE;
 
+   vdev->response_work = kzalloc(sizeof(*vdev->response_work), GFP_KERNEL);
+   if (!vdev->response_work)
+   goto out;
+   vdev->response_work->header = header;
+   vdev->response_work->vdev = vdev;
+
+   /* launch the thread that will extract the response */
+   INIT_WORK(>response_work->inject, dma_response_inject);
+   vdev->dma_fault_response_wq =
+   create_singlethread_workqueue("vfio-dma-fault-response");
+   if (!vdev->dma_fault_response_wq)
+   return -ENOMEM;
+
return 0;
 out:
+   kfree(vdev->fault_response_pages);
vdev->fault_response_pages = NULL;
return ret;
 }
diff --git a/drivers/vfio/pci/vfio_pci_private.h 
b/drivers/vfio/pci/vfio_pci_private.h
index 82a883c101c9..5944f96ced0c 100644
--- a/drivers/vfio/pci/vfio_pci_private.h
+++ b/drivers/vfio/pci/vfio_pci_private.h
@@ -52,6 +52,12 @@ struct vfio_pci_irq_ctx {
struct irq_bypass_producer  producer;
 };
 
+struct vfio_pci_dma_fault_response_work {
+   struct work_struct inject;
+   struct vfio_region_dma_fault_response *header;
+   struct vfio_pci_device *vdev;
+};
+
 struct vfio_pci_device;
 struct vfio_pci_region;
 
@@ -146,6 +152,7 @@ struct vfio_pci_device {
u8  *fault_pages;
u8  *fault_response_pages;
struct workqueue_struct *dma_fault_response_wq;
+   struct vfio_pci_dma_fault_response_work *response_work;
struct mutexfault_queue_lock;
struct mutexfault_response_queue_lock;
struct list_headdummy_resources_list;
diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
index efde0793360b..78c494fe35cc 100644
--- a/drivers/vfio/pci/vfio_pci_rdwr.c
+++ b/drivers/vfio/pci/vfio_pci_rdwr.c
@@ -430,6 +430,7 @@ size_t vfio_pci_dma_fault_response_rw(struct 
vfio_pci_device *vdev, char __user
mutex_lock(>fault_response_queue_lock);
header->head = new_head;
mutex_unlock(>fault_response_queue_lock);
+   queue_work(vdev->dma_fault_response_wq, 
>response_work->inject);
} else {
if (copy_to_user(buf, base + pos, count))
return -EFAULT;
-- 
2.26.2



Urgent Response

2021-02-20 Thread Alexandra Kelly
Dear friend,

I am contacting you independently of my investigation in
my bank and no one is informed of this communication. I need your
urgent assistance in transferring the sum of $5.3 million dollars to
your private account,that belongs to one of our foreign customers who
died a longtime with his supposed NEXT OF KIN since July 22, 2003. The
money has been here in our Bank lying dormant for years now without
anybody coming for the claim of it.

I want to release the money to you as the relative to our deceased
customer , the Banking laws here does not allow such money to stay
more than 18 years, because the money will be recalled to the Bank
treasury account as unclaimed fund. I am ready to share with you 40%
for you and 60% will be kept for me, by indicating your interest i
will send you the full details on how the business will be executed, i
will be waiting for your urgent response.


[PATCH v3 6/9] scsi: ufshpb: Add hpb dev reset response

2021-02-18 Thread Avri Altman
The spec does not define what is the host's recommended response when
the device send hpb dev reset response (oper 0x2).

We will update all active hpb regions: mark them and do that on the next
read.

Signed-off-by: Avri Altman 
---
 drivers/scsi/ufs/ufshpb.c | 40 ---
 drivers/scsi/ufs/ufshpb.h |  3 +++
 2 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index 3435a5507853..15755f677097 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -658,7 +658,8 @@ int ufshpb_prep(struct ufs_hba *hba, struct ufshcd_lrb 
*lrbp)
if (rgn->reads == ACTIVATION_THRESHOLD)
activate = true;
spin_unlock_irqrestore(>rgn_lock, flags);
-   if (activate) {
+   if (activate ||
+   test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {
spin_lock_irqsave(>rsp_list_lock, flags);
ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
hpb->stats.rb_active_cnt++;
@@ -1446,6 +1447,11 @@ void ufshpb_rsp_upiu(struct ufs_hba *hba, struct 
ufshcd_lrb *lrbp)
case HPB_RSP_DEV_RESET:
dev_warn(>sdev_ufs_lu->sdev_dev,
 "UFS device lost HPB information during PM.\n");
+
+   if (hpb->is_hcm &&
+   !test_and_set_bit(RESET_PENDING, >work_data_bits))
+   schedule_work(>ufshpb_lun_reset_work);
+
break;
default:
dev_notice(>sdev_ufs_lu->sdev_dev,
@@ -1560,6 +1566,27 @@ static void ufshpb_run_inactive_region_list(struct 
ufshpb_lu *hpb)
spin_unlock_irqrestore(>rsp_list_lock, flags);
 }
 
+static void ufshpb_reset_work_handler(struct work_struct *work)
+{
+   struct ufshpb_lu *hpb;
+   struct victim_select_info *lru_info;
+   struct ufshpb_region *rgn;
+   unsigned long flags;
+
+   hpb = container_of(work, struct ufshpb_lu, ufshpb_lun_reset_work);
+
+   lru_info = >lru_info;
+
+   spin_lock_irqsave(>rgn_state_lock, flags);
+
+   list_for_each_entry(rgn, _info->lh_lru_rgn, list_lru_rgn)
+   set_bit(RGN_FLAG_UPDATE, >rgn_flags);
+
+   spin_unlock_irqrestore(>rgn_state_lock, flags);
+
+   clear_bit(RESET_PENDING, >work_data_bits);
+}
+
 static void ufshpb_normalization_work_handler(struct work_struct *work)
 {
struct ufshpb_lu *hpb;
@@ -1770,6 +1797,8 @@ static int ufshpb_alloc_region_tbl(struct ufs_hba *hba, 
struct ufshpb_lu *hpb)
} else {
rgn->rgn_state = HPB_RGN_INACTIVE;
}
+
+   rgn->rgn_flags = 0;
}
 
return 0;
@@ -1983,9 +2012,12 @@ static int ufshpb_lu_hpb_init(struct ufs_hba *hba, 
struct ufshpb_lu *hpb)
INIT_LIST_HEAD(>list_hpb_lu);
 
INIT_WORK(>map_work, ufshpb_map_work_handler);
-   if (hpb->is_hcm)
+   if (hpb->is_hcm) {
INIT_WORK(>ufshpb_normalization_work,
  ufshpb_normalization_work_handler);
+   INIT_WORK(>ufshpb_lun_reset_work,
+ ufshpb_reset_work_handler);
+   }
 
hpb->map_req_cache = kmem_cache_create("ufshpb_req_cache",
  sizeof(struct ufshpb_req), 0, 0, NULL);
@@ -2085,8 +2117,10 @@ static void ufshpb_discard_rsp_lists(struct ufshpb_lu 
*hpb)
 
 static void ufshpb_cancel_jobs(struct ufshpb_lu *hpb)
 {
-   if (hpb->is_hcm)
+   if (hpb->is_hcm) {
+   cancel_work_sync(>ufshpb_lun_reset_work);
cancel_work_sync(>ufshpb_normalization_work);
+   }
cancel_work_sync(>map_work);
 }
 
diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
index 13ec49ba260d..a3b85d2df224 100644
--- a/drivers/scsi/ufs/ufshpb.h
+++ b/drivers/scsi/ufs/ufshpb.h
@@ -119,6 +119,7 @@ struct ufshpb_region {
struct list_head list_lru_rgn;
unsigned long rgn_flags;
 #define RGN_FLAG_DIRTY 0
+#define RGN_FLAG_UPDATE 1
 
/* region reads - for host mode */
spinlock_t rgn_lock;
@@ -215,8 +216,10 @@ struct ufshpb_lu {
/* for selecting victim */
struct victim_select_info lru_info;
struct work_struct ufshpb_normalization_work;
+   struct work_struct ufshpb_lun_reset_work;
unsigned long work_data_bits;
 #define WORK_PENDING 0
+#define RESET_PENDING 1
 
/* pinned region information */
u32 lu_pinned_start;
-- 
2.25.1



Re: [PATCH v11 12/13] vfio/pci: Register a DMA fault response region

2021-02-18 Thread Auger Eric
Hi Shameer,

On 2/18/21 11:36 AM, Shameerali Kolothum Thodi wrote:
> Hi Eric,
> 
>>> -Original Message-
>>> From: Eric Auger [mailto:eric.au...@redhat.com]
>>> Sent: 16 November 2020 11:00
>>> To: eric.auger@gmail.com; eric.au...@redhat.com;
>>> io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
>>> k...@vger.kernel.org; kvm...@lists.cs.columbia.edu; w...@kernel.org;
>>> j...@8bytes.org; m...@kernel.org; robin.mur...@arm.com;
>>> alex.william...@redhat.com
>>> Cc: jean-phili...@linaro.org; zhangfei@linaro.org;
>>> zhangfei@gmail.com; vivek.gau...@arm.com; Shameerali Kolothum
>>> Thodi ;
>>> jacob.jun@linux.intel.com; yi.l@intel.com; t...@semihalf.com;
>>> nicoleots...@gmail.com; yuzenghui 
>>> Subject: [PATCH v11 12/13] vfio/pci: Register a DMA fault response
>>> region
>>>
>>> In preparation for vSVA, let's register a DMA fault response region,
>>> where the userspace will push the page responses and increment the
>>> head of the buffer. The kernel will pop those responses and inject
>>> them on iommu side.
>>>
>>> Signed-off-by: Eric Auger 
>>> ---
>>>  drivers/vfio/pci/vfio_pci.c | 114 +---
>>>  drivers/vfio/pci/vfio_pci_private.h |   5 ++
>>>  drivers/vfio/pci/vfio_pci_rdwr.c|  39 ++
>>>  include/uapi/linux/vfio.h   |  32 
>>>  4 files changed, 181 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
>>> index 65a83fd0e8c0..e9a904ce3f0d 100644
>>> --- a/drivers/vfio/pci/vfio_pci.c
>>> +++ b/drivers/vfio/pci/vfio_pci.c
>>> @@ -318,9 +318,20 @@ static void vfio_pci_dma_fault_release(struct
>>> vfio_pci_device *vdev,
>>> kfree(vdev->fault_pages);
>>>  }
>>>
>>> -static int vfio_pci_dma_fault_mmap(struct vfio_pci_device *vdev,
>>> -  struct vfio_pci_region *region,
>>> -  struct vm_area_struct *vma)
>>> +static void
>>> +vfio_pci_dma_fault_response_release(struct vfio_pci_device *vdev,
>>> +   struct vfio_pci_region *region) {
>>> +   if (vdev->dma_fault_response_wq)
>>> +   destroy_workqueue(vdev->dma_fault_response_wq);
>>> +   kfree(vdev->fault_response_pages);
>>> +   vdev->fault_response_pages = NULL;
>>> +}
>>> +
>>> +static int __vfio_pci_dma_fault_mmap(struct vfio_pci_device *vdev,
>>> +struct vfio_pci_region *region,
>>> +struct vm_area_struct *vma,
>>> +u8 *pages)
>>>  {
>>> u64 phys_len, req_len, pgoff, req_start;
>>> unsigned long long addr;
>>> @@ -333,14 +344,14 @@ static int vfio_pci_dma_fault_mmap(struct
>>> vfio_pci_device *vdev,
>>> ((1U << (VFIO_PCI_OFFSET_SHIFT - PAGE_SHIFT)) - 1);
>>> req_start = pgoff << PAGE_SHIFT;
>>>
>>> -   /* only the second page of the producer fault region is mmappable */
>>> +   /* only the second page of the fault region is mmappable */
>>> if (req_start < PAGE_SIZE)
>>> return -EINVAL;
>>>
>>> if (req_start + req_len > phys_len)
>>> return -EINVAL;
>>>
>>> -   addr = virt_to_phys(vdev->fault_pages);
>>> +   addr = virt_to_phys(pages);
>>> vma->vm_private_data = vdev;
>>> vma->vm_pgoff = (addr >> PAGE_SHIFT) + pgoff;
>>>
>>> @@ -349,13 +360,29 @@ static int vfio_pci_dma_fault_mmap(struct
>>> vfio_pci_device *vdev,
>>> return ret;
>>>  }
>>>
>>> -static int vfio_pci_dma_fault_add_capability(struct vfio_pci_device *vdev,
>>> -struct vfio_pci_region *region,
>>> -struct vfio_info_cap *caps)
>>> +static int vfio_pci_dma_fault_mmap(struct vfio_pci_device *vdev,
>>> +  struct vfio_pci_region *region,
>>> +  struct vm_area_struct *vma)
>>> +{
>>> +   return __vfio_pci_dma_fault_mmap(vdev, region, vma,
>>> vdev->fault_pages);
>>> +}
>>> +
>>> +static int
>>> +vfio_pci_dma_fault_response_mmap(struct vfio_pci_device *vdev,
>>> +  

RE: [PATCH v11 12/13] vfio/pci: Register a DMA fault response region

2021-02-18 Thread Shameerali Kolothum Thodi
Hi Eric,

> > -Original Message-
> > From: Eric Auger [mailto:eric.au...@redhat.com]
> > Sent: 16 November 2020 11:00
> > To: eric.auger@gmail.com; eric.au...@redhat.com;
> > io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
> > k...@vger.kernel.org; kvm...@lists.cs.columbia.edu; w...@kernel.org;
> > j...@8bytes.org; m...@kernel.org; robin.mur...@arm.com;
> > alex.william...@redhat.com
> > Cc: jean-phili...@linaro.org; zhangfei@linaro.org;
> > zhangfei@gmail.com; vivek.gau...@arm.com; Shameerali Kolothum
> > Thodi ;
> > jacob.jun@linux.intel.com; yi.l@intel.com; t...@semihalf.com;
> > nicoleots...@gmail.com; yuzenghui 
> > Subject: [PATCH v11 12/13] vfio/pci: Register a DMA fault response
> > region
> >
> > In preparation for vSVA, let's register a DMA fault response region,
> > where the userspace will push the page responses and increment the
> > head of the buffer. The kernel will pop those responses and inject
> > them on iommu side.
> >
> > Signed-off-by: Eric Auger 
> > ---
> >  drivers/vfio/pci/vfio_pci.c | 114 +---
> >  drivers/vfio/pci/vfio_pci_private.h |   5 ++
> >  drivers/vfio/pci/vfio_pci_rdwr.c|  39 ++
> >  include/uapi/linux/vfio.h   |  32 
> >  4 files changed, 181 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> > index 65a83fd0e8c0..e9a904ce3f0d 100644
> > --- a/drivers/vfio/pci/vfio_pci.c
> > +++ b/drivers/vfio/pci/vfio_pci.c
> > @@ -318,9 +318,20 @@ static void vfio_pci_dma_fault_release(struct
> > vfio_pci_device *vdev,
> > kfree(vdev->fault_pages);
> >  }
> >
> > -static int vfio_pci_dma_fault_mmap(struct vfio_pci_device *vdev,
> > -  struct vfio_pci_region *region,
> > -  struct vm_area_struct *vma)
> > +static void
> > +vfio_pci_dma_fault_response_release(struct vfio_pci_device *vdev,
> > +   struct vfio_pci_region *region) {
> > +   if (vdev->dma_fault_response_wq)
> > +   destroy_workqueue(vdev->dma_fault_response_wq);
> > +   kfree(vdev->fault_response_pages);
> > +   vdev->fault_response_pages = NULL;
> > +}
> > +
> > +static int __vfio_pci_dma_fault_mmap(struct vfio_pci_device *vdev,
> > +struct vfio_pci_region *region,
> > +struct vm_area_struct *vma,
> > +u8 *pages)
> >  {
> > u64 phys_len, req_len, pgoff, req_start;
> > unsigned long long addr;
> > @@ -333,14 +344,14 @@ static int vfio_pci_dma_fault_mmap(struct
> > vfio_pci_device *vdev,
> > ((1U << (VFIO_PCI_OFFSET_SHIFT - PAGE_SHIFT)) - 1);
> > req_start = pgoff << PAGE_SHIFT;
> >
> > -   /* only the second page of the producer fault region is mmappable */
> > +   /* only the second page of the fault region is mmappable */
> > if (req_start < PAGE_SIZE)
> > return -EINVAL;
> >
> > if (req_start + req_len > phys_len)
> > return -EINVAL;
> >
> > -   addr = virt_to_phys(vdev->fault_pages);
> > +   addr = virt_to_phys(pages);
> > vma->vm_private_data = vdev;
> > vma->vm_pgoff = (addr >> PAGE_SHIFT) + pgoff;
> >
> > @@ -349,13 +360,29 @@ static int vfio_pci_dma_fault_mmap(struct
> > vfio_pci_device *vdev,
> > return ret;
> >  }
> >
> > -static int vfio_pci_dma_fault_add_capability(struct vfio_pci_device *vdev,
> > -struct vfio_pci_region *region,
> > -struct vfio_info_cap *caps)
> > +static int vfio_pci_dma_fault_mmap(struct vfio_pci_device *vdev,
> > +  struct vfio_pci_region *region,
> > +  struct vm_area_struct *vma)
> > +{
> > +   return __vfio_pci_dma_fault_mmap(vdev, region, vma,
> > vdev->fault_pages);
> > +}
> > +
> > +static int
> > +vfio_pci_dma_fault_response_mmap(struct vfio_pci_device *vdev,
> > +   struct vfio_pci_region *region,
> > +   struct vm_area_struct *vma)
> > +{
> > +   return __vfio_pci_dma_fault_mmap(vdev, region, vma,
> > vdev->fault_response_pages);
> > +}
> > +
> > +static int __vfio_pci_dma_fault_add_capability(struct vfio_pci_device 
> > *vdev

Re: [PATCH 4/4] hwmon: (occ) Print response status in first poll error message

2021-02-09 Thread Guenter Roeck
On Tue, Feb 09, 2021 at 11:12:35AM -0600, Eddie James wrote:
> In order to better debug problems starting up the driver, print
> the response status from the OCC in the error logged when the first
> poll command fails.
> 
> Signed-off-by: Eddie James 

Acked-by: Guenter Roeck 

> ---
>  drivers/hwmon/occ/common.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
> index ee0c5d12dfdf..f71d62b57468 100644
> --- a/drivers/hwmon/occ/common.c
> +++ b/drivers/hwmon/occ/common.c
> @@ -1161,8 +1161,9 @@ int occ_setup(struct occ *occ, const char *name)
>   dev_info(occ->bus_dev, "host is not ready\n");
>   return rc;
>   } else if (rc < 0) {
> - dev_err(occ->bus_dev, "failed to get OCC poll response: %d\n",
> - rc);
> +     dev_err(occ->bus_dev,
> + "failed to get OCC poll response=%02x: %d\n",
> + occ->resp.return_status, rc);
>   return rc;
>   }
>  
> -- 
> 2.27.0
> 


[PATCH 4/4] hwmon: (occ) Print response status in first poll error message

2021-02-09 Thread Eddie James
In order to better debug problems starting up the driver, print
the response status from the OCC in the error logged when the first
poll command fails.

Signed-off-by: Eddie James 
---
 drivers/hwmon/occ/common.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
index ee0c5d12dfdf..f71d62b57468 100644
--- a/drivers/hwmon/occ/common.c
+++ b/drivers/hwmon/occ/common.c
@@ -1161,8 +1161,9 @@ int occ_setup(struct occ *occ, const char *name)
dev_info(occ->bus_dev, "host is not ready\n");
return rc;
} else if (rc < 0) {
-   dev_err(occ->bus_dev, "failed to get OCC poll response: %d\n",
-   rc);
+   dev_err(occ->bus_dev,
+   "failed to get OCC poll response=%02x: %d\n",
+   occ->resp.return_status, rc);
return rc;
}
 
-- 
2.27.0



[PATCH 1/4] fsi: occ: Don't accept response from un-initialized OCC

2021-02-09 Thread Eddie James
If the OCC is not initialized and responds as such, the driver
should continue waiting for a valid response until the timeout
expires.

Signed-off-by: Eddie James 
---
 drivers/fsi/fsi-occ.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/fsi/fsi-occ.c b/drivers/fsi/fsi-occ.c
index 10ca2e290655..cb05b6dacc9d 100644
--- a/drivers/fsi/fsi-occ.c
+++ b/drivers/fsi/fsi-occ.c
@@ -495,6 +495,7 @@ int fsi_occ_submit(struct device *dev, const void *request, 
size_t req_len,
goto done;
 
if (resp->return_status == OCC_RESP_CMD_IN_PRG ||
+   resp->return_status == OCC_RESP_CRIT_INIT ||
resp->seq_no != seq_no) {
rc = -ETIMEDOUT;
 
-- 
2.27.0



[PATCH 4.9 14/43] scsi: libfc: Avoid invoking response handler twice if ep is already completed

2021-02-08 Thread Greg Kroah-Hartman
From: Javed Hasan 

[ Upstream commit b2b0f16fa65e910a3ec8771206bb49ee87a54ac5 ]

A race condition exists between the response handler getting called because
of exchange_mgr_reset() (which clears out all the active XIDs) and the
response we get via an interrupt.

Sequence of events:

 rport ba0200: Port timeout, state PLOGI
 rport ba0200: Port entered PLOGI state from PLOGI state
 xid 1052: Exchange timer armed : 2 msecs  xid timer armed here
 rport ba0200: Received LOGO request while in state PLOGI
 rport ba0200: Delete port
 rport ba0200: work event 3
 rport ba0200: lld callback ev 3
 bnx2fc: rport_event_hdlr: event = 3, port_id = 0xba0200
 bnx2fc: ba0200 - rport not created Yet!!
 /* Here we reset any outstanding exchanges before
 freeing rport using the exch_mgr_reset() */
 xid 1052: Exchange timer canceled
 /* Here we got two responses for one xid */
 xid 1052: invoking resp(), esb 2000 state 3
 xid 1052: invoking resp(), esb 2000 state 3
 xid 1052: fc_rport_plogi_resp() : ep->resp_active 2
 xid 1052: fc_rport_plogi_resp() : ep->resp_active 2

Skip the response if the exchange is already completed.

Link: https://lore.kernel.org/r/20201215194731.2326-1-jha...@marvell.com
Signed-off-by: Javed Hasan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/libfc/fc_exch.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/libfc/fc_exch.c b/drivers/scsi/libfc/fc_exch.c
index d0a86ef806522..59fd6101f188b 100644
--- a/drivers/scsi/libfc/fc_exch.c
+++ b/drivers/scsi/libfc/fc_exch.c
@@ -1585,8 +1585,13 @@ static void fc_exch_recv_seq_resp(struct fc_exch_mgr 
*mp, struct fc_frame *fp)
rc = fc_exch_done_locked(ep);
WARN_ON(fc_seq_exch(sp) != ep);
spin_unlock_bh(>ex_lock);
-   if (!rc)
+   if (!rc) {
fc_exch_delete(ep);
+   } else {
+   FC_EXCH_DBG(ep, "ep is completed already,"
+   "hence skip calling the resp\n");
+   goto skip_resp;
+   }
}
 
/*
@@ -1605,6 +1610,7 @@ static void fc_exch_recv_seq_resp(struct fc_exch_mgr *mp, 
struct fc_frame *fp)
if (!fc_invoke_resp(ep, sp, fp))
fc_frame_free(fp);
 
+skip_resp:
fc_exch_release(ep);
return;
 rel:
@@ -1848,10 +1854,16 @@ static void fc_exch_reset(struct fc_exch *ep)
 
fc_exch_hold(ep);
 
-   if (!rc)
+   if (!rc) {
fc_exch_delete(ep);
+   } else {
+   FC_EXCH_DBG(ep, "ep is completed already,"
+   "hence skip calling the resp\n");
+   goto skip_resp;
+   }
 
fc_invoke_resp(ep, sp, ERR_PTR(-FC_EX_CLOSED));
+skip_resp:
fc_seq_set_resp(sp, NULL, ep->arg);
fc_exch_release(ep);
 }
-- 
2.27.0





[PATCH 4.4 13/38] scsi: libfc: Avoid invoking response handler twice if ep is already completed

2021-02-08 Thread Greg Kroah-Hartman
From: Javed Hasan 

[ Upstream commit b2b0f16fa65e910a3ec8771206bb49ee87a54ac5 ]

A race condition exists between the response handler getting called because
of exchange_mgr_reset() (which clears out all the active XIDs) and the
response we get via an interrupt.

Sequence of events:

 rport ba0200: Port timeout, state PLOGI
 rport ba0200: Port entered PLOGI state from PLOGI state
 xid 1052: Exchange timer armed : 2 msecs  xid timer armed here
 rport ba0200: Received LOGO request while in state PLOGI
 rport ba0200: Delete port
 rport ba0200: work event 3
 rport ba0200: lld callback ev 3
 bnx2fc: rport_event_hdlr: event = 3, port_id = 0xba0200
 bnx2fc: ba0200 - rport not created Yet!!
 /* Here we reset any outstanding exchanges before
 freeing rport using the exch_mgr_reset() */
 xid 1052: Exchange timer canceled
 /* Here we got two responses for one xid */
 xid 1052: invoking resp(), esb 2000 state 3
 xid 1052: invoking resp(), esb 2000 state 3
 xid 1052: fc_rport_plogi_resp() : ep->resp_active 2
 xid 1052: fc_rport_plogi_resp() : ep->resp_active 2

Skip the response if the exchange is already completed.

Link: https://lore.kernel.org/r/20201215194731.2326-1-jha...@marvell.com
Signed-off-by: Javed Hasan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/libfc/fc_exch.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/libfc/fc_exch.c b/drivers/scsi/libfc/fc_exch.c
index b20c575564e43..a088f74a157c7 100644
--- a/drivers/scsi/libfc/fc_exch.c
+++ b/drivers/scsi/libfc/fc_exch.c
@@ -1577,8 +1577,13 @@ static void fc_exch_recv_seq_resp(struct fc_exch_mgr 
*mp, struct fc_frame *fp)
rc = fc_exch_done_locked(ep);
WARN_ON(fc_seq_exch(sp) != ep);
spin_unlock_bh(>ex_lock);
-   if (!rc)
+   if (!rc) {
fc_exch_delete(ep);
+   } else {
+   FC_EXCH_DBG(ep, "ep is completed already,"
+   "hence skip calling the resp\n");
+   goto skip_resp;
+   }
}
 
/*
@@ -1597,6 +1602,7 @@ static void fc_exch_recv_seq_resp(struct fc_exch_mgr *mp, 
struct fc_frame *fp)
if (!fc_invoke_resp(ep, sp, fp))
fc_frame_free(fp);
 
+skip_resp:
fc_exch_release(ep);
return;
 rel:
@@ -1841,10 +1847,16 @@ static void fc_exch_reset(struct fc_exch *ep)
 
fc_exch_hold(ep);
 
-   if (!rc)
+   if (!rc) {
fc_exch_delete(ep);
+   } else {
+   FC_EXCH_DBG(ep, "ep is completed already,"
+   "hence skip calling the resp\n");
+   goto skip_resp;
+   }
 
fc_invoke_resp(ep, sp, ERR_PTR(-FC_EX_CLOSED));
+skip_resp:
fc_seq_set_resp(sp, NULL, ep->arg);
fc_exch_release(ep);
 }
-- 
2.27.0





RE: [PATCH v2 6/9] scsi: ufshpb: Add hpb dev reset response

2021-02-07 Thread Avri Altman
> > + if (hpb->is_hcm) {
> > + struct ufshpb_lu *h;
> > + struct scsi_device *sdev;
> > +
> > + shost_for_each_device(sdev, hba->host) {
> 
> I haven't test it yet, but this line shall cause recursive spin lock -
> in current code base, ufshpb_rsp_upiu() is called with host_lock held.
Yayks Ouch.  Will fix.

Thanks,
Avri


Re: [PATCH v2 6/9] scsi: ufshpb: Add hpb dev reset response

2021-02-07 Thread Can Guo

On 2021-02-02 16:30, Avri Altman wrote:

The spec does not define what is the host's recommended response when
the device send hpb dev reset response (oper 0x2).

We will update all active hpb regions: mark them and do that on the 
next

read.

Signed-off-by: Avri Altman 
---
 drivers/scsi/ufs/ufshpb.c | 54 ---
 drivers/scsi/ufs/ufshpb.h |  1 +
 2 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index 49c74de539b7..28e0025507a1 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -17,6 +17,7 @@
 #include "../sd.h"

 #define WORK_PENDING 0
+#define RESET_PENDING 1
 #define ACTIVATION_THRSHLD 4 /* 4 IOs */
 #define EVICTION_THRSHLD (ACTIVATION_THRSHLD << 6) /* 256 IOs */

@@ -349,7 +350,8 @@ void ufshpb_prep(struct ufs_hba *hba, struct
ufshcd_lrb *lrbp)
if (rgn->reads == ACTIVATION_THRSHLD)
activate = true;
spin_unlock_irqrestore(>rgn_lock, flags);
-   if (activate) {
+   if (activate ||
+   test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {
spin_lock_irqsave(>rsp_list_lock, flags);
ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
hpb->stats.rb_active_cnt++;
@@ -1068,6 +1070,24 @@ void ufshpb_rsp_upiu(struct ufs_hba *hba,
struct ufshcd_lrb *lrbp)
case HPB_RSP_DEV_RESET:
dev_warn(>sdev_ufs_lu->sdev_dev,
 "UFS device lost HPB information during PM.\n");
+
+   if (hpb->is_hcm) {
+   struct ufshpb_lu *h;
+   struct scsi_device *sdev;
+
+   shost_for_each_device(sdev, hba->host) {


I haven't test it yet, but this line shall cause recursive spin lock -
in current code base, ufshpb_rsp_upiu() is called with host_lock held.

Regards,

Can Guo.


+   h = sdev->hostdata;
+   if (!h)
+   continue;
+
+   if (test_and_set_bit(RESET_PENDING,
+>work_data_bits))
+   continue;
+
+   schedule_work(>ufshpb_lun_reset_work);
+   }
+   }
+
break;
default:
dev_notice(>sdev_ufs_lu->sdev_dev,
@@ -1200,6 +1220,27 @@ static void
ufshpb_run_inactive_region_list(struct ufshpb_lu *hpb)
spin_unlock_irqrestore(>rsp_list_lock, flags);
 }

+static void ufshpb_reset_work_handler(struct work_struct *work)
+{
+   struct ufshpb_lu *hpb;
+   struct victim_select_info *lru_info;
+   struct ufshpb_region *rgn;
+   unsigned long flags;
+
+   hpb = container_of(work, struct ufshpb_lu, ufshpb_lun_reset_work);
+
+   lru_info = >lru_info;
+
+   spin_lock_irqsave(>rgn_state_lock, flags);
+
+   list_for_each_entry(rgn, _info->lh_lru_rgn, list_lru_rgn)
+   set_bit(RGN_FLAG_UPDATE, >rgn_flags);
+
+   spin_unlock_irqrestore(>rgn_state_lock, flags);
+
+   clear_bit(RESET_PENDING, >work_data_bits);
+}
+
 static void ufshpb_normalization_work_handler(struct work_struct 
*work)

 {
struct ufshpb_lu *hpb;
@@ -1392,6 +1433,8 @@ static int ufshpb_alloc_region_tbl(struct
ufs_hba *hba, struct ufshpb_lu *hpb)
} else {
rgn->rgn_state = HPB_RGN_INACTIVE;
}
+
+   rgn->rgn_flags = 0;
}

return 0;
@@ -1502,9 +1545,12 @@ static int ufshpb_lu_hpb_init(struct ufs_hba
*hba, struct ufshpb_lu *hpb)
INIT_LIST_HEAD(>list_hpb_lu);

INIT_WORK(>map_work, ufshpb_map_work_handler);
-   if (hpb->is_hcm)
+   if (hpb->is_hcm) {
INIT_WORK(>ufshpb_normalization_work,
  ufshpb_normalization_work_handler);
+   INIT_WORK(>ufshpb_lun_reset_work,
+ ufshpb_reset_work_handler);
+   }

hpb->map_req_cache = kmem_cache_create("ufshpb_req_cache",
  sizeof(struct ufshpb_req), 0, 0, NULL);
@@ -1591,8 +1637,10 @@ static void ufshpb_discard_rsp_lists(struct
ufshpb_lu *hpb)

 static void ufshpb_cancel_jobs(struct ufshpb_lu *hpb)
 {
-   if (hpb->is_hcm)
+   if (hpb->is_hcm) {
+   cancel_work_sync(>ufshpb_lun_reset_work);
cancel_work_sync(>ufshpb_normalization_work);
+   }
cancel_work_sync(>map_work);
 }

diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
index 71b082ee7876..e55892ceb3fc 100644
--- a/drivers/scsi/ufs/ufshpb.h
+++ b/drivers/scsi/ufs/ufshpb.h
@@ -184,6 +184,7 @@ struct ufshpb_lu {
/* for sel

[PATCH 4.14 11/15] scsi: libfc: Avoid invoking response handler twice if ep is already completed

2021-02-05 Thread Greg Kroah-Hartman
From: Javed Hasan 

[ Upstream commit b2b0f16fa65e910a3ec8771206bb49ee87a54ac5 ]

A race condition exists between the response handler getting called because
of exchange_mgr_reset() (which clears out all the active XIDs) and the
response we get via an interrupt.

Sequence of events:

 rport ba0200: Port timeout, state PLOGI
 rport ba0200: Port entered PLOGI state from PLOGI state
 xid 1052: Exchange timer armed : 2 msecs  xid timer armed here
 rport ba0200: Received LOGO request while in state PLOGI
 rport ba0200: Delete port
 rport ba0200: work event 3
 rport ba0200: lld callback ev 3
 bnx2fc: rport_event_hdlr: event = 3, port_id = 0xba0200
 bnx2fc: ba0200 - rport not created Yet!!
 /* Here we reset any outstanding exchanges before
 freeing rport using the exch_mgr_reset() */
 xid 1052: Exchange timer canceled
 /* Here we got two responses for one xid */
 xid 1052: invoking resp(), esb 2000 state 3
 xid 1052: invoking resp(), esb 2000 state 3
 xid 1052: fc_rport_plogi_resp() : ep->resp_active 2
 xid 1052: fc_rport_plogi_resp() : ep->resp_active 2

Skip the response if the exchange is already completed.

Link: https://lore.kernel.org/r/20201215194731.2326-1-jha...@marvell.com
Signed-off-by: Javed Hasan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/libfc/fc_exch.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/libfc/fc_exch.c b/drivers/scsi/libfc/fc_exch.c
index 6ba257cbc6d94..384458d1f73c3 100644
--- a/drivers/scsi/libfc/fc_exch.c
+++ b/drivers/scsi/libfc/fc_exch.c
@@ -1631,8 +1631,13 @@ static void fc_exch_recv_seq_resp(struct fc_exch_mgr 
*mp, struct fc_frame *fp)
rc = fc_exch_done_locked(ep);
WARN_ON(fc_seq_exch(sp) != ep);
spin_unlock_bh(>ex_lock);
-   if (!rc)
+   if (!rc) {
fc_exch_delete(ep);
+   } else {
+   FC_EXCH_DBG(ep, "ep is completed already,"
+   "hence skip calling the resp\n");
+   goto skip_resp;
+   }
}
 
/*
@@ -1651,6 +1656,7 @@ static void fc_exch_recv_seq_resp(struct fc_exch_mgr *mp, 
struct fc_frame *fp)
if (!fc_invoke_resp(ep, sp, fp))
fc_frame_free(fp);
 
+skip_resp:
fc_exch_release(ep);
return;
 rel:
@@ -1907,10 +1913,16 @@ static void fc_exch_reset(struct fc_exch *ep)
 
fc_exch_hold(ep);
 
-   if (!rc)
+   if (!rc) {
fc_exch_delete(ep);
+   } else {
+   FC_EXCH_DBG(ep, "ep is completed already,"
+   "hence skip calling the resp\n");
+   goto skip_resp;
+   }
 
fc_invoke_resp(ep, sp, ERR_PTR(-FC_EX_CLOSED));
+skip_resp:
fc_seq_set_resp(sp, NULL, ep->arg);
fc_exch_release(ep);
 }
-- 
2.27.0





[PATCH 4.19 11/17] scsi: libfc: Avoid invoking response handler twice if ep is already completed

2021-02-05 Thread Greg Kroah-Hartman
From: Javed Hasan 

[ Upstream commit b2b0f16fa65e910a3ec8771206bb49ee87a54ac5 ]

A race condition exists between the response handler getting called because
of exchange_mgr_reset() (which clears out all the active XIDs) and the
response we get via an interrupt.

Sequence of events:

 rport ba0200: Port timeout, state PLOGI
 rport ba0200: Port entered PLOGI state from PLOGI state
 xid 1052: Exchange timer armed : 2 msecs  xid timer armed here
 rport ba0200: Received LOGO request while in state PLOGI
 rport ba0200: Delete port
 rport ba0200: work event 3
 rport ba0200: lld callback ev 3
 bnx2fc: rport_event_hdlr: event = 3, port_id = 0xba0200
 bnx2fc: ba0200 - rport not created Yet!!
 /* Here we reset any outstanding exchanges before
 freeing rport using the exch_mgr_reset() */
 xid 1052: Exchange timer canceled
 /* Here we got two responses for one xid */
 xid 1052: invoking resp(), esb 2000 state 3
 xid 1052: invoking resp(), esb 2000 state 3
 xid 1052: fc_rport_plogi_resp() : ep->resp_active 2
 xid 1052: fc_rport_plogi_resp() : ep->resp_active 2

Skip the response if the exchange is already completed.

Link: https://lore.kernel.org/r/20201215194731.2326-1-jha...@marvell.com
Signed-off-by: Javed Hasan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/libfc/fc_exch.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/libfc/fc_exch.c b/drivers/scsi/libfc/fc_exch.c
index 6ba257cbc6d94..384458d1f73c3 100644
--- a/drivers/scsi/libfc/fc_exch.c
+++ b/drivers/scsi/libfc/fc_exch.c
@@ -1631,8 +1631,13 @@ static void fc_exch_recv_seq_resp(struct fc_exch_mgr 
*mp, struct fc_frame *fp)
rc = fc_exch_done_locked(ep);
WARN_ON(fc_seq_exch(sp) != ep);
spin_unlock_bh(>ex_lock);
-   if (!rc)
+   if (!rc) {
fc_exch_delete(ep);
+   } else {
+   FC_EXCH_DBG(ep, "ep is completed already,"
+   "hence skip calling the resp\n");
+   goto skip_resp;
+   }
}
 
/*
@@ -1651,6 +1656,7 @@ static void fc_exch_recv_seq_resp(struct fc_exch_mgr *mp, 
struct fc_frame *fp)
if (!fc_invoke_resp(ep, sp, fp))
fc_frame_free(fp);
 
+skip_resp:
fc_exch_release(ep);
return;
 rel:
@@ -1907,10 +1913,16 @@ static void fc_exch_reset(struct fc_exch *ep)
 
fc_exch_hold(ep);
 
-   if (!rc)
+   if (!rc) {
fc_exch_delete(ep);
+   } else {
+   FC_EXCH_DBG(ep, "ep is completed already,"
+   "hence skip calling the resp\n");
+   goto skip_resp;
+   }
 
fc_invoke_resp(ep, sp, ERR_PTR(-FC_EX_CLOSED));
+skip_resp:
fc_seq_set_resp(sp, NULL, ep->arg);
fc_exch_release(ep);
 }
-- 
2.27.0





[PATCH 5.10 27/57] scsi: libfc: Avoid invoking response handler twice if ep is already completed

2021-02-05 Thread Greg Kroah-Hartman
From: Javed Hasan 

[ Upstream commit b2b0f16fa65e910a3ec8771206bb49ee87a54ac5 ]

A race condition exists between the response handler getting called because
of exchange_mgr_reset() (which clears out all the active XIDs) and the
response we get via an interrupt.

Sequence of events:

 rport ba0200: Port timeout, state PLOGI
 rport ba0200: Port entered PLOGI state from PLOGI state
 xid 1052: Exchange timer armed : 2 msecs  xid timer armed here
 rport ba0200: Received LOGO request while in state PLOGI
 rport ba0200: Delete port
 rport ba0200: work event 3
 rport ba0200: lld callback ev 3
 bnx2fc: rport_event_hdlr: event = 3, port_id = 0xba0200
 bnx2fc: ba0200 - rport not created Yet!!
 /* Here we reset any outstanding exchanges before
 freeing rport using the exch_mgr_reset() */
 xid 1052: Exchange timer canceled
 /* Here we got two responses for one xid */
 xid 1052: invoking resp(), esb 2000 state 3
 xid 1052: invoking resp(), esb 2000 state 3
 xid 1052: fc_rport_plogi_resp() : ep->resp_active 2
 xid 1052: fc_rport_plogi_resp() : ep->resp_active 2

Skip the response if the exchange is already completed.

Link: https://lore.kernel.org/r/20201215194731.2326-1-jha...@marvell.com
Signed-off-by: Javed Hasan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/libfc/fc_exch.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/libfc/fc_exch.c b/drivers/scsi/libfc/fc_exch.c
index 96a2952cf626b..a50f1eef0e0cd 100644
--- a/drivers/scsi/libfc/fc_exch.c
+++ b/drivers/scsi/libfc/fc_exch.c
@@ -1624,8 +1624,13 @@ static void fc_exch_recv_seq_resp(struct fc_exch_mgr 
*mp, struct fc_frame *fp)
rc = fc_exch_done_locked(ep);
WARN_ON(fc_seq_exch(sp) != ep);
spin_unlock_bh(>ex_lock);
-   if (!rc)
+   if (!rc) {
fc_exch_delete(ep);
+   } else {
+   FC_EXCH_DBG(ep, "ep is completed already,"
+   "hence skip calling the resp\n");
+   goto skip_resp;
+   }
}
 
/*
@@ -1644,6 +1649,7 @@ static void fc_exch_recv_seq_resp(struct fc_exch_mgr *mp, 
struct fc_frame *fp)
if (!fc_invoke_resp(ep, sp, fp))
fc_frame_free(fp);
 
+skip_resp:
fc_exch_release(ep);
return;
 rel:
@@ -1900,10 +1906,16 @@ static void fc_exch_reset(struct fc_exch *ep)
 
fc_exch_hold(ep);
 
-   if (!rc)
+   if (!rc) {
fc_exch_delete(ep);
+   } else {
+   FC_EXCH_DBG(ep, "ep is completed already,"
+   "hence skip calling the resp\n");
+   goto skip_resp;
+   }
 
fc_invoke_resp(ep, sp, ERR_PTR(-FC_EX_CLOSED));
+skip_resp:
fc_seq_set_resp(sp, NULL, ep->arg);
fc_exch_release(ep);
 }
-- 
2.27.0





[PATCH 5.4 19/32] scsi: libfc: Avoid invoking response handler twice if ep is already completed

2021-02-05 Thread Greg Kroah-Hartman
From: Javed Hasan 

[ Upstream commit b2b0f16fa65e910a3ec8771206bb49ee87a54ac5 ]

A race condition exists between the response handler getting called because
of exchange_mgr_reset() (which clears out all the active XIDs) and the
response we get via an interrupt.

Sequence of events:

 rport ba0200: Port timeout, state PLOGI
 rport ba0200: Port entered PLOGI state from PLOGI state
 xid 1052: Exchange timer armed : 2 msecs  xid timer armed here
 rport ba0200: Received LOGO request while in state PLOGI
 rport ba0200: Delete port
 rport ba0200: work event 3
 rport ba0200: lld callback ev 3
 bnx2fc: rport_event_hdlr: event = 3, port_id = 0xba0200
 bnx2fc: ba0200 - rport not created Yet!!
 /* Here we reset any outstanding exchanges before
 freeing rport using the exch_mgr_reset() */
 xid 1052: Exchange timer canceled
 /* Here we got two responses for one xid */
 xid 1052: invoking resp(), esb 2000 state 3
 xid 1052: invoking resp(), esb 2000 state 3
 xid 1052: fc_rport_plogi_resp() : ep->resp_active 2
 xid 1052: fc_rport_plogi_resp() : ep->resp_active 2

Skip the response if the exchange is already completed.

Link: https://lore.kernel.org/r/20201215194731.2326-1-jha...@marvell.com
Signed-off-by: Javed Hasan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/libfc/fc_exch.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/libfc/fc_exch.c b/drivers/scsi/libfc/fc_exch.c
index 52e8666598531..e5b18e5d46dac 100644
--- a/drivers/scsi/libfc/fc_exch.c
+++ b/drivers/scsi/libfc/fc_exch.c
@@ -1619,8 +1619,13 @@ static void fc_exch_recv_seq_resp(struct fc_exch_mgr 
*mp, struct fc_frame *fp)
rc = fc_exch_done_locked(ep);
WARN_ON(fc_seq_exch(sp) != ep);
spin_unlock_bh(>ex_lock);
-   if (!rc)
+   if (!rc) {
fc_exch_delete(ep);
+   } else {
+   FC_EXCH_DBG(ep, "ep is completed already,"
+   "hence skip calling the resp\n");
+   goto skip_resp;
+   }
}
 
/*
@@ -1639,6 +1644,7 @@ static void fc_exch_recv_seq_resp(struct fc_exch_mgr *mp, 
struct fc_frame *fp)
if (!fc_invoke_resp(ep, sp, fp))
fc_frame_free(fp);
 
+skip_resp:
fc_exch_release(ep);
return;
 rel:
@@ -1895,10 +1901,16 @@ static void fc_exch_reset(struct fc_exch *ep)
 
fc_exch_hold(ep);
 
-   if (!rc)
+   if (!rc) {
fc_exch_delete(ep);
+   } else {
+   FC_EXCH_DBG(ep, "ep is completed already,"
+   "hence skip calling the resp\n");
+   goto skip_resp;
+   }
 
fc_invoke_resp(ep, sp, ERR_PTR(-FC_EX_CLOSED));
+skip_resp:
fc_seq_set_resp(sp, NULL, ep->arg);
fc_exch_release(ep);
 }
-- 
2.27.0





[PATCH v2 6/9] scsi: ufshpb: Add hpb dev reset response

2021-02-02 Thread Avri Altman
The spec does not define what is the host's recommended response when
the device send hpb dev reset response (oper 0x2).

We will update all active hpb regions: mark them and do that on the next
read.

Signed-off-by: Avri Altman 
---
 drivers/scsi/ufs/ufshpb.c | 54 ---
 drivers/scsi/ufs/ufshpb.h |  1 +
 2 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index 49c74de539b7..28e0025507a1 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -17,6 +17,7 @@
 #include "../sd.h"
 
 #define WORK_PENDING 0
+#define RESET_PENDING 1
 #define ACTIVATION_THRSHLD 4 /* 4 IOs */
 #define EVICTION_THRSHLD (ACTIVATION_THRSHLD << 6) /* 256 IOs */
 
@@ -349,7 +350,8 @@ void ufshpb_prep(struct ufs_hba *hba, struct ufshcd_lrb 
*lrbp)
if (rgn->reads == ACTIVATION_THRSHLD)
activate = true;
spin_unlock_irqrestore(>rgn_lock, flags);
-   if (activate) {
+   if (activate ||
+   test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {
spin_lock_irqsave(>rsp_list_lock, flags);
ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
hpb->stats.rb_active_cnt++;
@@ -1068,6 +1070,24 @@ void ufshpb_rsp_upiu(struct ufs_hba *hba, struct 
ufshcd_lrb *lrbp)
case HPB_RSP_DEV_RESET:
dev_warn(>sdev_ufs_lu->sdev_dev,
 "UFS device lost HPB information during PM.\n");
+
+   if (hpb->is_hcm) {
+   struct ufshpb_lu *h;
+   struct scsi_device *sdev;
+
+   shost_for_each_device(sdev, hba->host) {
+   h = sdev->hostdata;
+   if (!h)
+   continue;
+
+   if (test_and_set_bit(RESET_PENDING,
+>work_data_bits))
+   continue;
+
+   schedule_work(>ufshpb_lun_reset_work);
+   }
+   }
+
break;
default:
dev_notice(>sdev_ufs_lu->sdev_dev,
@@ -1200,6 +1220,27 @@ static void ufshpb_run_inactive_region_list(struct 
ufshpb_lu *hpb)
spin_unlock_irqrestore(>rsp_list_lock, flags);
 }
 
+static void ufshpb_reset_work_handler(struct work_struct *work)
+{
+   struct ufshpb_lu *hpb;
+   struct victim_select_info *lru_info;
+   struct ufshpb_region *rgn;
+   unsigned long flags;
+
+   hpb = container_of(work, struct ufshpb_lu, ufshpb_lun_reset_work);
+
+   lru_info = >lru_info;
+
+   spin_lock_irqsave(>rgn_state_lock, flags);
+
+   list_for_each_entry(rgn, _info->lh_lru_rgn, list_lru_rgn)
+   set_bit(RGN_FLAG_UPDATE, >rgn_flags);
+
+   spin_unlock_irqrestore(>rgn_state_lock, flags);
+
+   clear_bit(RESET_PENDING, >work_data_bits);
+}
+
 static void ufshpb_normalization_work_handler(struct work_struct *work)
 {
struct ufshpb_lu *hpb;
@@ -1392,6 +1433,8 @@ static int ufshpb_alloc_region_tbl(struct ufs_hba *hba, 
struct ufshpb_lu *hpb)
} else {
rgn->rgn_state = HPB_RGN_INACTIVE;
}
+
+   rgn->rgn_flags = 0;
}
 
return 0;
@@ -1502,9 +1545,12 @@ static int ufshpb_lu_hpb_init(struct ufs_hba *hba, 
struct ufshpb_lu *hpb)
INIT_LIST_HEAD(>list_hpb_lu);
 
INIT_WORK(>map_work, ufshpb_map_work_handler);
-   if (hpb->is_hcm)
+   if (hpb->is_hcm) {
INIT_WORK(>ufshpb_normalization_work,
  ufshpb_normalization_work_handler);
+   INIT_WORK(>ufshpb_lun_reset_work,
+ ufshpb_reset_work_handler);
+   }
 
hpb->map_req_cache = kmem_cache_create("ufshpb_req_cache",
  sizeof(struct ufshpb_req), 0, 0, NULL);
@@ -1591,8 +1637,10 @@ static void ufshpb_discard_rsp_lists(struct ufshpb_lu 
*hpb)
 
 static void ufshpb_cancel_jobs(struct ufshpb_lu *hpb)
 {
-   if (hpb->is_hcm)
+   if (hpb->is_hcm) {
+   cancel_work_sync(>ufshpb_lun_reset_work);
cancel_work_sync(>ufshpb_normalization_work);
+   }
cancel_work_sync(>map_work);
 }
 
diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
index 71b082ee7876..e55892ceb3fc 100644
--- a/drivers/scsi/ufs/ufshpb.h
+++ b/drivers/scsi/ufs/ufshpb.h
@@ -184,6 +184,7 @@ struct ufshpb_lu {
/* for selecting victim */
struct victim_select_info lru_info;
struct work_struct ufshpb_normalization_work;
+   struct work_struct ufshpb_lun_reset_work;
unsigned long work_data_bits;
 
/* pinned region information */
-- 
2.25.1



RE: [PATCH 6/8] scsi: ufshpb: Add hpb dev reset response

2021-01-31 Thread Avri Altman
> 
> Hi Avri,
> 
> > + list_for_each_entry_safe(rgn, next_rgn, _info->lh_lru_rgn,
> > +  list_lru_rgn)
> How about replace list_for_each_entry_safe to list_for_each_entry?
Done.
Can also use the relaxed version in the timeout handler as well (patch 7/8).

Thanks,
Avri


RE: [PATCH 6/8] scsi: ufshpb: Add hpb dev reset response

2021-01-31 Thread Daejun Park
Hi Avri,

> + list_for_each_entry_safe(rgn, next_rgn, _info->lh_lru_rgn,
> +  list_lru_rgn)
How about replace list_for_each_entry_safe to list_for_each_entry?

Thanks,
Daejun


[PATCH 6/8] scsi: ufshpb: Add hpb dev reset response

2021-01-27 Thread Avri Altman
The spec does not define what is the host's recommended response when
the device send hpb dev reset response (oper 0x2).

We will update all active hpb regions: mark them and do that on the next
read.

Signed-off-by: Avri Altman 
---
 drivers/scsi/ufs/ufshpb.c | 55 ---
 drivers/scsi/ufs/ufshpb.h |  1 +
 2 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index c09c8dce0745..cb99b57b4319 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -17,6 +17,7 @@
 #include "../sd.h"
 
 #define WORK_PENDING 0
+#define RESET_PENDING 1
 #define ACTIVATION_THRSHLD 4 /* 4 IOs */
 #define EVICTION_THRSHLD (ACTIVATION_THRSHLD << 6) /* 256 IOs */
 
@@ -344,7 +345,8 @@ void ufshpb_prep(struct ufs_hba *hba, struct ufshcd_lrb 
*lrbp)
 * in host control mode, reads are the main source for
 * activation trials.
 */
-   if (reads == ACTIVATION_THRSHLD) {
+   if (reads == ACTIVATION_THRSHLD ||
+   test_and_clear_bit(RGN_FLAG_UPDATE, >rgn_flags)) {
spin_lock_irqsave(>rsp_list_lock, flags);
ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
hpb->stats.rb_active_cnt++;
@@ -1061,6 +1063,24 @@ void ufshpb_rsp_upiu(struct ufs_hba *hba, struct 
ufshcd_lrb *lrbp)
case HPB_RSP_DEV_RESET:
dev_warn(>sdev_ufs_lu->sdev_dev,
 "UFS device lost HPB information during PM.\n");
+
+   if (ufshpb_mode == HPB_HOST_CONTROL) {
+   struct ufshpb_lu *h;
+   struct scsi_device *sdev;
+
+   shost_for_each_device(sdev, hba->host) {
+   h = sdev->hostdata;
+   if (!h)
+   continue;
+
+   if (test_and_set_bit(RESET_PENDING,
+>work_data_bits))
+   continue;
+
+   schedule_work(>ufshpb_lun_reset_work);
+   }
+   }
+
break;
default:
dev_notice(>sdev_ufs_lu->sdev_dev,
@@ -1193,6 +1213,28 @@ static void ufshpb_run_inactive_region_list(struct 
ufshpb_lu *hpb)
spin_unlock_irqrestore(>rsp_list_lock, flags);
 }
 
+static void ufshpb_reset_work_handler(struct work_struct *work)
+{
+   struct ufshpb_lu *hpb;
+   struct victim_select_info *lru_info;
+   struct ufshpb_region *rgn, *next_rgn;
+   unsigned long flags;
+
+   hpb = container_of(work, struct ufshpb_lu, ufshpb_lun_reset_work);
+
+   lru_info = >lru_info;
+
+   spin_lock_irqsave(>rgn_state_lock, flags);
+
+   list_for_each_entry_safe(rgn, next_rgn, _info->lh_lru_rgn,
+list_lru_rgn)
+   set_bit(RGN_FLAG_UPDATE, >rgn_flags);
+
+   spin_unlock_irqrestore(>rgn_state_lock, flags);
+
+   clear_bit(RESET_PENDING, >work_data_bits);
+}
+
 static void ufshpb_normalization_work_handler(struct work_struct *work)
 {
struct ufshpb_lu *hpb;
@@ -1379,6 +1421,8 @@ static int ufshpb_alloc_region_tbl(struct ufs_hba *hba, 
struct ufshpb_lu *hpb)
} else {
rgn->rgn_state = HPB_RGN_INACTIVE;
}
+
+   rgn->rgn_flags = 0;
}
 
return 0;
@@ -1487,9 +1531,12 @@ static int ufshpb_lu_hpb_init(struct ufs_hba *hba, 
struct ufshpb_lu *hpb)
INIT_LIST_HEAD(>list_hpb_lu);
 
INIT_WORK(>map_work, ufshpb_map_work_handler);
-   if (ufshpb_mode == HPB_HOST_CONTROL)
+   if (ufshpb_mode == HPB_HOST_CONTROL) {
INIT_WORK(>ufshpb_normalization_work,
  ufshpb_normalization_work_handler);
+   INIT_WORK(>ufshpb_lun_reset_work,
+ ufshpb_reset_work_handler);
+   }
 
hpb->map_req_cache = kmem_cache_create("ufshpb_req_cache",
  sizeof(struct ufshpb_req), 0, 0, NULL);
@@ -1576,8 +1623,10 @@ static void ufshpb_discard_rsp_lists(struct ufshpb_lu 
*hpb)
 
 static void ufshpb_cancel_jobs(struct ufshpb_lu *hpb)
 {
-   if (ufshpb_mode == HPB_HOST_CONTROL)
+   if (ufshpb_mode == HPB_HOST_CONTROL) {
+   cancel_work_sync(>ufshpb_lun_reset_work);
cancel_work_sync(>ufshpb_normalization_work);
+   }
cancel_work_sync(>map_work);
 }
 
diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
index 47a8877f9cdb..4bf77169af00 100644
--- a/drivers/scsi/ufs/ufshpb.h
+++ b/drivers/scsi/ufs/ufshpb.h
@@ -183,6 +183,7 @@ struct ufshpb_lu {
/* for selecting victim */
struct victim_sele

[PATCH v2 2/2] iommu/vt-d: Use INVALID response code instead of FAILURE

2021-01-26 Thread Lu Baolu
The VT-d IOMMU response RESPONSE_FAILURE for a page request in below
cases:

- When it gets a Page_Request with no PASID;
- When it gets a Page_Request with PASID that is not in use for this
  device.

This is allowed by the spec, but IOMMU driver doesn't support such cases
today. When the device receives RESPONSE_FAILURE, it sends the device
state machine to HALT state. Now if we try to unload the driver, it hangs
since the device doesn't send any outbound transactions to host when the
driver is trying to clear things up. The only possible responses would be
for invalidation requests.

Let's use RESPONSE_INVALID instead for now, so that the device state
machine doesn't enter HALT state.

Suggested-by: Ashok Raj 
Signed-off-by: Lu Baolu 
---
 drivers/iommu/intel/svm.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index d7c98c5fa4e7..574a7e657a9a 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -911,10 +911,8 @@ static irqreturn_t prq_event_thread(int irq, void *d)
u64 address;
 
handled = 1;
-
req = >prq[head / sizeof(*req)];
-
-   result = QI_RESP_FAILURE;
+   result = QI_RESP_INVALID;
address = (u64)req->addr << VTD_PAGE_SHIFT;
if (!req->pasid_present) {
pr_err("%s: Page request without PASID: %08llx 
%08llx\n",
@@ -952,7 +950,6 @@ static irqreturn_t prq_event_thread(int irq, void *d)
rcu_read_unlock();
}
 
-   result = QI_RESP_INVALID;
/* Since we're using init_mm.pgd directly, we should never take
 * any faults on kernel addresses. */
if (!svm->mm)
-- 
2.25.1



[PATCH 3/3] iommu/vt-d: Use INVALID response code instead of FAILURE

2021-01-20 Thread Lu Baolu
The VT-d IOMMU response RESPONSE_FAILURE for a page request in below
cases:

- When it gets a Page_Request with no PASID;
- When it gets a Page_Request with PASID that is not in use for this
  device.

This is allowed by the spec, but IOMMU driver doesn't support such cases
today. When the device receives RESPONSE_FAILURE, it sends the device
state machine to HALT state. Now if we try to unload the driver, it hangs
since the device doesn't send any outbound transactions to host when the
driver is trying to clear things up. The only possible responses would be
for invalidation requests.

Let's use RESPONSE_INVALID instead for now, so that the device state
machine doesn't enter HALT state.

Suggested-by: Ashok Raj 
Signed-off-by: Lu Baolu 
---
 drivers/iommu/intel/svm.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 77509a0a863e..021f58899c16 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -907,10 +907,8 @@ static irqreturn_t prq_event_thread(int irq, void *d)
u64 address;
 
handled = 1;
-
req = >prq[head / sizeof(*req)];
-
-   result = QI_RESP_FAILURE;
+   result = QI_RESP_INVALID;
address = (u64)req->addr << VTD_PAGE_SHIFT;
if (!req->pasid_present) {
pr_err("%s: Page request without PASID: %08llx 
%08llx\n",
@@ -948,7 +946,6 @@ static irqreturn_t prq_event_thread(int irq, void *d)
rcu_read_unlock();
}
 
-   result = QI_RESP_INVALID;
/* Since we're using init_mm.pgd directly, we should never take
 * any faults on kernel addresses. */
if (!svm->mm)
-- 
2.25.1



[PATCH 5/5] soundwire: cadence: adjust verbosity in response handling

2021-01-14 Thread Bard Liao
From: Pierre-Louis Bossart 

There are too many logs on startup, e.g.

[ 8811.851497] cdns_fill_msg_resp: 2 callbacks suppressed
[ 8811.851497] intel-sdw intel-sdw.0: Msg Ack not received
[ 8811.851498] intel-sdw intel-sdw.0: Msg Ack not received
[ 8811.851499] intel-sdw intel-sdw.0: Msg Ack not received
[ 8811.851499] intel-sdw intel-sdw.0: Msg Ack not received
[ 8811.851500] intel-sdw intel-sdw.0: Msg Ack not received
[ 8811.851500] intel-sdw intel-sdw.0: Msg Ack not received
[ 8811.851502] intel-sdw intel-sdw.0: Msg ignored for Slave 0
[ 8811.851503] soundwire sdw-master-0: No more devices to enumerate

We can skip the 'Msg Ack not received' since it's typical of the
enumeration end, and conversely add the information on which command
fails.

Signed-off-by: Pierre-Louis Bossart 
Signed-off-by: Bard Liao 
---
 drivers/soundwire/cadence_master.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/soundwire/cadence_master.c 
b/drivers/soundwire/cadence_master.c
index d3c9cf920cbd..8d7166ffd4ad 100644
--- a/drivers/soundwire/cadence_master.c
+++ b/drivers/soundwire/cadence_master.c
@@ -483,11 +483,11 @@ cdns_fill_msg_resp(struct sdw_cdns *cdns,
for (i = 0; i < count; i++) {
if (!(cdns->response_buf[i] & CDNS_MCP_RESP_ACK)) {
no_ack = 1;
-   dev_dbg_ratelimited(cdns->dev, "Msg Ack not 
received\n");
+   dev_vdbg(cdns->dev, "Msg Ack not received, cmd %d\n", 
i);
}
if (cdns->response_buf[i] & CDNS_MCP_RESP_NACK) {
nack = 1;
-   dev_err_ratelimited(cdns->dev, "Msg NACK received\n");
+   dev_err_ratelimited(cdns->dev, "Msg NACK received, cmd 
%d\n", i);
}
}
 
-- 
2.17.1



[PATCH 4.9 08/45] net/ncsi: Use real net-device for response handler

2021-01-11 Thread Greg Kroah-Hartman
From: John Wang 

[ Upstream commit 427c940558560bff2583d07fc119a21094675982 ]

When aggregating ncsi interfaces and dedicated interfaces to bond
interfaces, the ncsi response handler will use the wrong net device to
find ncsi_dev, so that the ncsi interface will not work properly.
Here, we use the original net device to fix it.

Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler")
Signed-off-by: John Wang 
Link: 
https://lore.kernel.org/r/20201223055523.2069-1-wangzhiqiang...@bytedance.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ncsi/ncsi-rsp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c
@@ -975,7 +975,7 @@ int ncsi_rcv_rsp(struct sk_buff *skb, st
int payload, i, ret;
 
/* Find the NCSI device */
-   nd = ncsi_find_dev(dev);
+   nd = ncsi_find_dev(orig_dev);
ndp = nd ? TO_NCSI_DEV_PRIV(nd) : NULL;
if (!ndp)
return -ENODEV;




[PATCH 5.10 019/145] net/ncsi: Use real net-device for response handler

2021-01-11 Thread Greg Kroah-Hartman
From: John Wang 

[ Upstream commit 427c940558560bff2583d07fc119a21094675982 ]

When aggregating ncsi interfaces and dedicated interfaces to bond
interfaces, the ncsi response handler will use the wrong net device to
find ncsi_dev, so that the ncsi interface will not work properly.
Here, we use the original net device to fix it.

Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler")
Signed-off-by: John Wang 
Link: 
https://lore.kernel.org/r/20201223055523.2069-1-wangzhiqiang...@bytedance.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ncsi/ncsi-rsp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c
@@ -1120,7 +1120,7 @@ int ncsi_rcv_rsp(struct sk_buff *skb, st
int payload, i, ret;
 
/* Find the NCSI device */
-   nd = ncsi_find_dev(dev);
+   nd = ncsi_find_dev(orig_dev);
ndp = nd ? TO_NCSI_DEV_PRIV(nd) : NULL;
if (!ndp)
return -ENODEV;




[PATCH 5.4 24/92] net/ncsi: Use real net-device for response handler

2021-01-11 Thread Greg Kroah-Hartman
From: John Wang 

[ Upstream commit 427c940558560bff2583d07fc119a21094675982 ]

When aggregating ncsi interfaces and dedicated interfaces to bond
interfaces, the ncsi response handler will use the wrong net device to
find ncsi_dev, so that the ncsi interface will not work properly.
Here, we use the original net device to fix it.

Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler")
Signed-off-by: John Wang 
Link: 
https://lore.kernel.org/r/20201223055523.2069-1-wangzhiqiang...@bytedance.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ncsi/ncsi-rsp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c
@@ -1114,7 +1114,7 @@ int ncsi_rcv_rsp(struct sk_buff *skb, st
int payload, i, ret;
 
/* Find the NCSI device */
-   nd = ncsi_find_dev(dev);
+   nd = ncsi_find_dev(orig_dev);
ndp = nd ? TO_NCSI_DEV_PRIV(nd) : NULL;
if (!ndp)
return -ENODEV;




[PATCH 4.19 21/77] net/ncsi: Use real net-device for response handler

2021-01-11 Thread Greg Kroah-Hartman
From: John Wang 

[ Upstream commit 427c940558560bff2583d07fc119a21094675982 ]

When aggregating ncsi interfaces and dedicated interfaces to bond
interfaces, the ncsi response handler will use the wrong net device to
find ncsi_dev, so that the ncsi interface will not work properly.
Here, we use the original net device to fix it.

Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler")
Signed-off-by: John Wang 
Link: 
https://lore.kernel.org/r/20201223055523.2069-1-wangzhiqiang...@bytedance.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ncsi/ncsi-rsp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c
@@ -949,7 +949,7 @@ int ncsi_rcv_rsp(struct sk_buff *skb, st
int payload, i, ret;
 
/* Find the NCSI device */
-   nd = ncsi_find_dev(dev);
+   nd = ncsi_find_dev(orig_dev);
ndp = nd ? TO_NCSI_DEV_PRIV(nd) : NULL;
if (!ndp)
return -ENODEV;




[PATCH 4.14 13/57] net/ncsi: Use real net-device for response handler

2021-01-11 Thread Greg Kroah-Hartman
From: John Wang 

[ Upstream commit 427c940558560bff2583d07fc119a21094675982 ]

When aggregating ncsi interfaces and dedicated interfaces to bond
interfaces, the ncsi response handler will use the wrong net device to
find ncsi_dev, so that the ncsi interface will not work properly.
Here, we use the original net device to fix it.

Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler")
Signed-off-by: John Wang 
Link: 
https://lore.kernel.org/r/20201223055523.2069-1-wangzhiqiang...@bytedance.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ncsi/ncsi-rsp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c
@@ -983,7 +983,7 @@ int ncsi_rcv_rsp(struct sk_buff *skb, st
int payload, i, ret;
 
/* Find the NCSI device */
-   nd = ncsi_find_dev(dev);
+   nd = ncsi_find_dev(orig_dev);
ndp = nd ? TO_NCSI_DEV_PRIV(nd) : NULL;
if (!ndp)
return -ENODEV;




RE: [PATCH v11 12/13] vfio/pci: Register a DMA fault response region

2021-01-08 Thread Shameerali Kolothum Thodi
Hi Eric,

> -Original Message-
> From: Eric Auger [mailto:eric.au...@redhat.com]
> Sent: 16 November 2020 11:00
> To: eric.auger@gmail.com; eric.au...@redhat.com;
> io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
> k...@vger.kernel.org; kvm...@lists.cs.columbia.edu; w...@kernel.org;
> j...@8bytes.org; m...@kernel.org; robin.mur...@arm.com;
> alex.william...@redhat.com
> Cc: jean-phili...@linaro.org; zhangfei@linaro.org;
> zhangfei@gmail.com; vivek.gau...@arm.com; Shameerali Kolothum
> Thodi ;
> jacob.jun@linux.intel.com; yi.l@intel.com; t...@semihalf.com;
> nicoleots...@gmail.com; yuzenghui 
> Subject: [PATCH v11 12/13] vfio/pci: Register a DMA fault response region
> 
> In preparation for vSVA, let's register a DMA fault response region,
> where the userspace will push the page responses and increment the
> head of the buffer. The kernel will pop those responses and inject them
> on iommu side.
> 
> Signed-off-by: Eric Auger 
> ---
>  drivers/vfio/pci/vfio_pci.c | 114 +---
>  drivers/vfio/pci/vfio_pci_private.h |   5 ++
>  drivers/vfio/pci/vfio_pci_rdwr.c|  39 ++
>  include/uapi/linux/vfio.h   |  32 
>  4 files changed, 181 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 65a83fd0e8c0..e9a904ce3f0d 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -318,9 +318,20 @@ static void vfio_pci_dma_fault_release(struct
> vfio_pci_device *vdev,
>   kfree(vdev->fault_pages);
>  }
> 
> -static int vfio_pci_dma_fault_mmap(struct vfio_pci_device *vdev,
> -struct vfio_pci_region *region,
> -struct vm_area_struct *vma)
> +static void
> +vfio_pci_dma_fault_response_release(struct vfio_pci_device *vdev,
> + struct vfio_pci_region *region)
> +{
> + if (vdev->dma_fault_response_wq)
> + destroy_workqueue(vdev->dma_fault_response_wq);
> + kfree(vdev->fault_response_pages);
> + vdev->fault_response_pages = NULL;
> +}
> +
> +static int __vfio_pci_dma_fault_mmap(struct vfio_pci_device *vdev,
> +  struct vfio_pci_region *region,
> +  struct vm_area_struct *vma,
> +  u8 *pages)
>  {
>   u64 phys_len, req_len, pgoff, req_start;
>   unsigned long long addr;
> @@ -333,14 +344,14 @@ static int vfio_pci_dma_fault_mmap(struct
> vfio_pci_device *vdev,
>   ((1U << (VFIO_PCI_OFFSET_SHIFT - PAGE_SHIFT)) - 1);
>   req_start = pgoff << PAGE_SHIFT;
> 
> - /* only the second page of the producer fault region is mmappable */
> + /* only the second page of the fault region is mmappable */
>   if (req_start < PAGE_SIZE)
>   return -EINVAL;
> 
>   if (req_start + req_len > phys_len)
>   return -EINVAL;
> 
> - addr = virt_to_phys(vdev->fault_pages);
> + addr = virt_to_phys(pages);
>   vma->vm_private_data = vdev;
>   vma->vm_pgoff = (addr >> PAGE_SHIFT) + pgoff;
> 
> @@ -349,13 +360,29 @@ static int vfio_pci_dma_fault_mmap(struct
> vfio_pci_device *vdev,
>   return ret;
>  }
> 
> -static int vfio_pci_dma_fault_add_capability(struct vfio_pci_device *vdev,
> -  struct vfio_pci_region *region,
> -  struct vfio_info_cap *caps)
> +static int vfio_pci_dma_fault_mmap(struct vfio_pci_device *vdev,
> +struct vfio_pci_region *region,
> +struct vm_area_struct *vma)
> +{
> + return __vfio_pci_dma_fault_mmap(vdev, region, vma,
> vdev->fault_pages);
> +}
> +
> +static int
> +vfio_pci_dma_fault_response_mmap(struct vfio_pci_device *vdev,
> + struct vfio_pci_region *region,
> + struct vm_area_struct *vma)
> +{
> + return __vfio_pci_dma_fault_mmap(vdev, region, vma,
> vdev->fault_response_pages);
> +}
> +
> +static int __vfio_pci_dma_fault_add_capability(struct vfio_pci_device *vdev,
> +struct vfio_pci_region *region,
> +struct vfio_info_cap *caps,
> +u32 cap_id)
>  {
>   struct vfio_region_info_cap_sparse_mmap *sparse = NULL;
>   struct vfio_region_info_cap_fault cap = {
> - .header.id = VFIO_REGION_INFO_CAP_DMA_FAULT,
> +

[PATCH v4 5/6] scsi: ufs: Distinguish between TM request UPIU and response UPIU in TM UPIU trace

2021-01-05 Thread Bean Huo
From: Bean Huo 

Distinguish between TM request UPIU and response UPIU in TM UPIU trace,
for the TM response, let TM UPIU trace print its TM response UPIU.

Acked-by: Avri Altman 
Acked-by: Steven Rostedt (VMware) 
Signed-off-by: Bean Huo 
---
 drivers/scsi/ufs/ufshcd.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 6ccf71ab3b9c..4df17005e398 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -341,8 +341,12 @@ static void ufshcd_add_tm_upiu_trace(struct ufs_hba *hba, 
unsigned int tag,
if (!trace_ufshcd_upiu_enabled())
return;
 
-   trace_ufshcd_upiu(dev_name(hba->dev), str_t, >req_header,
-   >input_param1);
+   if (str_t == UFS_TM_SEND)
+   trace_ufshcd_upiu(dev_name(hba->dev), str_t, >req_header,
+ >input_param1);
+   else
+   trace_ufshcd_upiu(dev_name(hba->dev), str_t, >rsp_header,
+ >output_param1);
 }
 
 static void ufshcd_add_uic_command_trace(struct ufs_hba *hba,
-- 
2.17.1



YOUR URGENT RESPONSE !!!!

2021-01-04 Thread Mr. Kim Leang
Greeting!

I am contacting you to receive and share with me an abandoned fund ( 
$21,537.000.00 ) left in our bank by a deceased customer. I was going through 
the Internet search when I found your email address. My name is Mr. Kim Leang.

I want to utilize this opportunity and make use of this fund if I should 
present your name to the bank to stand as his business associate/ trustee for 
the fund to be released to you via Visa card for easy withdrawals in any VISA 
ATM machine anywhere in the World.

The bank will also give you international online transfer options. With these 
you can transfer the funds without any risk.

Should you be interested in working with me in this project? Please reply back 
and let's benefit from this golden opportunity.You are my first contact. I 
shall wait a few days and if I do not hear from you, I shall look for another 
person.

Thanks and have a nice day,
Mr. Kim Leang


Re: [PATCH v2] net/ncsi: Use real net-device for response handler

2020-12-23 Thread patchwork-bot+netdevbpf
Hello:

This patch was applied to netdev/net.git (refs/heads/master):

On Wed, 23 Dec 2020 13:55:23 +0800 you wrote:
> When aggregating ncsi interfaces and dedicated interfaces to bond
> interfaces, the ncsi response handler will use the wrong net device to
> find ncsi_dev, so that the ncsi interface will not work properly.
> Here, we use the original net device to fix it.
> 
> Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler")
> Signed-off-by: John Wang 
> 
> [...]

Here is the summary with links:
  - [v2] net/ncsi: Use real net-device for response handler
https://git.kernel.org/netdev/net/c/427c94055856

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




[PATCH v2] net/ncsi: Use real net-device for response handler

2020-12-22 Thread John Wang
When aggregating ncsi interfaces and dedicated interfaces to bond
interfaces, the ncsi response handler will use the wrong net device to
find ncsi_dev, so that the ncsi interface will not work properly.
Here, we use the original net device to fix it.

Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler")
Signed-off-by: John Wang 
---
v2:
  Use orig_dev instead of pt->dev
---
 net/ncsi/ncsi-rsp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c
index a94bb59793f0..e1c6bb4ab98f 100644
--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c
@@ -1120,7 +1120,7 @@ int ncsi_rcv_rsp(struct sk_buff *skb, struct net_device 
*dev,
int payload, i, ret;
 
/* Find the NCSI device */
-   nd = ncsi_find_dev(dev);
+   nd = ncsi_find_dev(orig_dev);
ndp = nd ? TO_NCSI_DEV_PRIV(nd) : NULL;
if (!ndp)
return -ENODEV;
-- 
2.25.1



Re: [External] Re: [PATCH] net/ncsi: Use real net-device for response handler

2020-12-22 Thread John Wang
On Wed, Dec 23, 2020 at 10:25 AM Jakub Kicinski  wrote:
>
> On Tue, 22 Dec 2020 10:38:21 -0800 Samuel Mendoza-Jonas wrote:
> > On Tue, 2020-12-22 at 06:13 +, Joel Stanley wrote:
> > > On Sun, 20 Dec 2020 at 12:40, John Wang wrote:
> > > > When aggregating ncsi interfaces and dedicated interfaces to bond
> > > > interfaces, the ncsi response handler will use the wrong net device
> > > > to
> > > > find ncsi_dev, so that the ncsi interface will not work properly.
> > > > Here, we use the net device registered to packet_type to fix it.
> > > >
> > > > Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler")
> > > > Signed-off-by: John Wang 
>
> This sounds like exactly the case for which orig_dev was introduced.
> I think you should use the orig_dev argument, rather than pt->dev.

will send a v2

>
> Can you test if that works?

Yes,  it works.

>
> > > Can you show me how to reproduce this?

On g220a, eth1 is the dedicated interface, eth0 is the ncsi interface

kernel cfg:
CONFIG_BONDING=y

cat /etc/systemd/network/00-bmc-bond1.netdev
[NetDev]
Name=bond1
Description=Bond eth0 and eth1
Kind=bond

[Bond]
Mode=active-backup

cat /etc/systemd/network/00-bmc-eth0.network
[Match]
Name=eth0
[Network]
Bond=bond1

cat /etc/systemd/network/00-bmc-eth0.network
[Match]
Name=eth1
[Network]
Bond=bond1
PrimarySlave=true

ip addr

6: bond1:  mtu 1500 qdisc noqueue qlen 1000
link/ether b4:05:5d:8f:6a:ad brd ff:ff:ff:ff:ff:ff
inet 169.254.11.178/16 brd 169.254.255.255 scope link bond1
   valid_lft forever preferred_lft forever
inet 192.168.1.108/24 brd 192.168.1.255 scope global bond1
   valid_lft forever preferred_lft forever
inet 10.2.16.118/24 brd 10.2.16.255 scope global bond1
   valid_lft forever preferred_lft forever
inet6 fe80::b605:5dff:fe8f:6aad/64 scope link
...


Without this patch:
After bmc boots:
echo eth0 > /sys/class/net/bond1/bonding/active_slave
admin@g220a:~#
admin@g220a:~# echo eth0 > /sys/class/net/bond1/bonding/active_slave
[  105.964357] bond1: (slave eth0): making interface the new active one
admin@g220a:~# ping 10.2.16.1
PING 10.2.16.1 (10.2.16.1): 56 data bytes
64 bytes from 10.2.16.1: seq=0 ttl=255 time=7.096 ms
64 bytes from 10.2.16.1: seq=1 ttl=255 time=2.143 ms
64 bytes from 10.2.16.1: seq=2 ttl=255 time=2.111 ms
[  112.642734] ftgmac100 1e66.ethernet eth0: NCSI Channel 0 timed out!
64 bytes from 10.2.16.1: seq=3 ttl=255 time=2.039 ms
64 bytes from 10.2.16.1: seq=4 ttl=255 time=2.037 ms
[  117.842814] ftgmac100 1e66.ethernet eth0: NCSI: No channel with
link found, configuring channel 0
[  134.482746] ftgmac100 1e66.ethernet eth0: NCSI Channel 0 timed out!
[  139.682820] ftgmac100 1e66.ethernet eth0: NCSI: No channel with
link found, configuring channel 0

with this patch:
After bmc boots:

admin@g220a:~# echo eth0 > /sys/class/net/bond1/bonding/active_slave
[58332.123754] bond1: (slave eth0): making interface the new active one
admin@g220a:~# ping 10.2.16.1
PING 10.2.16.1 (10.2.16.1): 56 data bytes
64 bytes from 10.2.16.1: seq=0 ttl=255 time=7.279 ms
...
...
64 bytes from 10.2.16.1: seq=N ttl=255 time=2.037 ms



> > >
> > > I don't know the ncsi or net code well enough to know if this is the
> > > correct fix. If you are confident it is correct then I have no
> > > objections.
> >
> > This looks like it is probably right; pt->dev will be the original
> > device from ncsi_register_dev(), if a response comes in to
> > ncsi_rcv_rsp() associated with a different device then the driver will
> > fail to find the correct ncsi_dev_priv. An example of the broken case
> > would be good to see though.
>
> From the description sounds like the case is whenever the ncsi
> interface is in a bond, the netdev from the second argument is
> the bond not the interface from which the frame came. It should
> be possible to repro even with only one interface on the system,
> create a bond or a team and add the ncsi interface to it.
>
> Does that make sense? I'm likely missing the subtleties here.

:)  I guess so.


[PATCH AUTOSEL 5.4 111/130] iwlwifi: mvm: validate firmware sync response size

2020-12-22 Thread Sasha Levin
From: Johannes Berg 

[ Upstream commit b570e5b0592a56c5990ae3aa0fdb93dd9b545d43 ]

We send some data to the firmware and expect to get it back,
but we shouldn't really trust the firmware on this. Check the
size of all the data we send down to avoid using bad or just
uninitialized data when the firmware doesn't respond right.

Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho 
Link: 
https://lore.kernel.org/r/iwlwifi.20201209231352.a5a8173f16c7.I4fa68bb2b1c7dcc52ddd381c4042722d27c4a34d@changeid
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
index d0bfcee59a3a7..545a84e08816e 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
@@ -763,10 +763,18 @@ void iwl_mvm_rx_queue_notif(struct iwl_mvm *mvm, struct 
napi_struct *napi,
struct iwl_rx_packet *pkt = rxb_addr(rxb);
struct iwl_rxq_sync_notification *notif;
struct iwl_mvm_internal_rxq_notif *internal_notif;
+   u32 len = iwl_rx_packet_payload_len(pkt);
 
notif = (void *)pkt->data;
internal_notif = (void *)notif->payload;
 
+   if (WARN_ONCE(len < sizeof(*notif) + sizeof(*internal_notif),
+ "invalid notification size %d (%d)",
+ len, (int)(sizeof(*notif) + sizeof(*internal_notif
+   return;
+   /* remove only the firmware header, we want all of our payload below */
+   len -= sizeof(*notif);
+
if (internal_notif->sync &&
mvm->queue_sync_cookie != internal_notif->cookie) {
WARN_ONCE(1, "Received expired RX queue sync message\n");
@@ -775,11 +783,22 @@ void iwl_mvm_rx_queue_notif(struct iwl_mvm *mvm, struct 
napi_struct *napi,
 
switch (internal_notif->type) {
case IWL_MVM_RXQ_EMPTY:
+   WARN_ONCE(len != sizeof(*internal_notif),
+ "invalid empty notification size %d (%d)",
+ len, (int)sizeof(*internal_notif));
break;
case IWL_MVM_RXQ_NOTIF_DEL_BA:
+   if (WARN_ONCE(len != sizeof(struct iwl_mvm_rss_sync_notif),
+ "invalid delba notification size %d (%d)",
+ len, (int)sizeof(struct iwl_mvm_rss_sync_notif)))
+   break;
iwl_mvm_del_ba(mvm, queue, (void *)internal_notif->data);
break;
case IWL_MVM_RXQ_NSSN_SYNC:
+   if (WARN_ONCE(len != sizeof(struct iwl_mvm_rss_sync_notif),
+ "invalid nssn sync notification size %d (%d)",
+ len, (int)sizeof(struct iwl_mvm_rss_sync_notif)))
+   break;
iwl_mvm_nssn_sync(mvm, napi, queue,
  (void *)internal_notif->data);
break;
-- 
2.27.0



Re: [PATCH] net/ncsi: Use real net-device for response handler

2020-12-22 Thread Jakub Kicinski
On Tue, 22 Dec 2020 10:38:21 -0800 Samuel Mendoza-Jonas wrote:
> On Tue, 2020-12-22 at 06:13 +, Joel Stanley wrote:
> > On Sun, 20 Dec 2020 at 12:40, John Wang wrote:
> > > When aggregating ncsi interfaces and dedicated interfaces to bond
> > > interfaces, the ncsi response handler will use the wrong net device
> > > to
> > > find ncsi_dev, so that the ncsi interface will not work properly.
> > > Here, we use the net device registered to packet_type to fix it.
> > > 
> > > Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler")
> > > Signed-off-by: John Wang   

This sounds like exactly the case for which orig_dev was introduced.
I think you should use the orig_dev argument, rather than pt->dev.

Can you test if that works?

> > Can you show me how to reproduce this?
> > 
> > I don't know the ncsi or net code well enough to know if this is the
> > correct fix. If you are confident it is correct then I have no
> > objections.  
> 
> This looks like it is probably right; pt->dev will be the original
> device from ncsi_register_dev(), if a response comes in to
> ncsi_rcv_rsp() associated with a different device then the driver will
> fail to find the correct ncsi_dev_priv. An example of the broken case
> would be good to see though.

From the description sounds like the case is whenever the ncsi
interface is in a bond, the netdev from the second argument is 
the bond not the interface from which the frame came. It should 
be possible to repro even with only one interface on the system,
create a bond or a team and add the ncsi interface to it.

Does that make sense? I'm likely missing the subtleties here.


Re: [PATCH] net/ncsi: Use real net-device for response handler

2020-12-22 Thread Samuel Mendoza-Jonas
On Tue, 2020-12-22 at 06:13 +, Joel Stanley wrote:
> On Sun, 20 Dec 2020 at 12:40, John Wang <
> wangzhiqiang...@bytedance.com> wrote:
> > 
> > When aggregating ncsi interfaces and dedicated interfaces to bond
> > interfaces, the ncsi response handler will use the wrong net device
> > to
> > find ncsi_dev, so that the ncsi interface will not work properly.
> > Here, we use the net device registered to packet_type to fix it.
> > 
> > Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler")
> > Signed-off-by: John Wang 
> 
> Can you show me how to reproduce this?
> 
> I don't know the ncsi or net code well enough to know if this is the
> correct fix. If you are confident it is correct then I have no
> objections.

This looks like it is probably right; pt->dev will be the original
device from ncsi_register_dev(), if a response comes in to
ncsi_rcv_rsp() associated with a different device then the driver will
fail to find the correct ncsi_dev_priv. An example of the broken case
would be good to see though.

Cheers,
Sam

> 
> Cheers,
> 
> Joel
> 
> > ---
> >  net/ncsi/ncsi-rsp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c
> > index a94bb59793f0..60ae32682904 100644
> > --- a/net/ncsi/ncsi-rsp.c
> > +++ b/net/ncsi/ncsi-rsp.c
> > @@ -1120,7 +1120,7 @@ int ncsi_rcv_rsp(struct sk_buff *skb, struct
> > net_device *dev,
> >     int payload, i, ret;
> > 
> >     /* Find the NCSI device */
> > -   nd = ncsi_find_dev(dev);
> > +   nd = ncsi_find_dev(pt->dev);
> >     ndp = nd ? TO_NCSI_DEV_PRIV(nd) : NULL;
> >     if (!ndp)
> >     return -ENODEV;
> > --
> > 2.25.1
> > 




Re: [PATCH] net/ncsi: Use real net-device for response handler

2020-12-21 Thread Joel Stanley
On Sun, 20 Dec 2020 at 12:40, John Wang  wrote:
>
> When aggregating ncsi interfaces and dedicated interfaces to bond
> interfaces, the ncsi response handler will use the wrong net device to
> find ncsi_dev, so that the ncsi interface will not work properly.
> Here, we use the net device registered to packet_type to fix it.
>
> Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler")
> Signed-off-by: John Wang 

Can you show me how to reproduce this?

I don't know the ncsi or net code well enough to know if this is the
correct fix. If you are confident it is correct then I have no
objections.

Cheers,

Joel

> ---
>  net/ncsi/ncsi-rsp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c
> index a94bb59793f0..60ae32682904 100644
> --- a/net/ncsi/ncsi-rsp.c
> +++ b/net/ncsi/ncsi-rsp.c
> @@ -1120,7 +1120,7 @@ int ncsi_rcv_rsp(struct sk_buff *skb, struct net_device 
> *dev,
> int payload, i, ret;
>
> /* Find the NCSI device */
> -   nd = ncsi_find_dev(dev);
> +   nd = ncsi_find_dev(pt->dev);
> ndp = nd ? TO_NCSI_DEV_PRIV(nd) : NULL;
> if (!ndp)
> return -ENODEV;
> --
> 2.25.1
>


[PATCH] net/ncsi: Use real net-device for response handler

2020-12-20 Thread John Wang
When aggregating ncsi interfaces and dedicated interfaces to bond
interfaces, the ncsi response handler will use the wrong net device to
find ncsi_dev, so that the ncsi interface will not work properly.
Here, we use the net device registered to packet_type to fix it.

Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler")
Signed-off-by: John Wang 
---
 net/ncsi/ncsi-rsp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c
index a94bb59793f0..60ae32682904 100644
--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c
@@ -1120,7 +1120,7 @@ int ncsi_rcv_rsp(struct sk_buff *skb, struct net_device 
*dev,
int payload, i, ret;
 
/* Find the NCSI device */
-   nd = ncsi_find_dev(dev);
+   nd = ncsi_find_dev(pt->dev);
ndp = nd ? TO_NCSI_DEV_PRIV(nd) : NULL;
if (!ndp)
return -ENODEV;
-- 
2.25.1



[PATCH v3 5/6] scsi: ufs: Distinguish between TM request UPIU and response UPIU in TM UPIU trace

2020-12-14 Thread Bean Huo
From: Bean Huo 

Distinguish between TM request UPIU and response UPIU in TM UPIU trace,
for the TM response, let TM UPIU trace print its TM response UPIU.

Acked-by: Avri Altman 
Acked-by: Steven Rostedt (VMware) 
Signed-off-by: Bean Huo 
---
 drivers/scsi/ufs/ufshcd.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index d0b054aa0a3c..2cf983b3de1a 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -341,8 +341,12 @@ static void ufshcd_add_tm_upiu_trace(struct ufs_hba *hba, 
unsigned int tag,
if (!trace_ufshcd_upiu_enabled())
return;
 
-   trace_ufshcd_upiu(dev_name(hba->dev), str_t, >req_header,
-   >input_param1);
+   if (str_t == UFS_TM_SEND)
+   trace_ufshcd_upiu(dev_name(hba->dev), str_t, >req_header,
+ >input_param1);
+   else
+   trace_ufshcd_upiu(dev_name(hba->dev), str_t, >rsp_header,
+ >output_param1);
 }
 
 static void ufshcd_add_uic_command_trace(struct ufs_hba *hba,
-- 
2.17.1



[PATCH v2 5/6] scsi: ufs: Distinguish between TM request UPIU and response UPIU in TM UPIU trace

2020-12-14 Thread Bean Huo
From: Bean Huo 

Distinguish between TM request UPIU and response UPIU in TM UPIU trace,
for the TM response, let TM UPIU trace print its TM response UPIU.

Acked-by: Avri Altman 
Signed-off-by: Bean Huo 
---
 drivers/scsi/ufs/ufshcd.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 93d820b69617..742f5d11f8e5 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -344,8 +344,12 @@ static void ufshcd_add_tm_upiu_trace(struct ufs_hba *hba, 
unsigned int tag,
if (!trace_ufshcd_upiu_enabled())
return;
 
-   trace_ufshcd_upiu(dev_name(hba->dev), str_t, >req_header,
-   >input_param1);
+   if (str_t == UFS_TM_SEND)
+   trace_ufshcd_upiu(dev_name(hba->dev), str_t, >req_header,
+ >input_param1);
+   else
+   trace_ufshcd_upiu(dev_name(hba->dev), str_t, >rsp_header,
+ >output_param1);
 }
 
 static void ufshcd_add_uic_command_trace(struct ufs_hba *hba,
-- 
2.17.1



Please Urgent Response

2020-12-13 Thread Dr.Kasim Mohamed
-- 
I am Mr Kasim Mohamed

Hi Friend I am a bank director of the UBA Bank Plc bf .I want to
transfer an abandoned sum of 27.5 millions USD  to you through ATM
VISA CARD .50% will be for you. No risk involved. Contact me for more
details. Kindly reply me back to my alternative email
address(mrkasimmohame...@gmail.com) Mr kasim mohamed


Response Required

2020-12-11 Thread Moussa
Greeetings from Mali. I am sorry for contacting you like this but 
I do have a very urgent matter that I want to discuss with you. 
Before I proceed, I want you to keep an open mind while reading 
this proposal. My name is Moussa Traore, I am the Personal 
Assistant to Mr. Issa Saley Maiga who was the head of the civil 
aviation agency in Mali during the tenure of Ibrahim Boubacar 
Keïta, the former president of Mali. His tenure was overtaken by 
the military during a coup d'etat. I am sure you would have read 
about this in your country because it was covered by the 
international news agencies worldwide.

Anyway, my boss was also affected by the coup d'etat and he was 
arrested along with other high profile politicians. Also, all of 
his local assets (bother property and financial assets) were 
seized by the Government. Due to this situation, my boss belives 
that he is at risk and he is now very scared for the safety of 
his family especially his wife and kids. In order to ensure that 
his family is taken care of and protected incase anything happens 
to him, he has asked me to help him find a foreign investor who 
can help him accommodate and manage the finanical assets that he 
has in Europe. These assets was secured with the help of a proxy 
and it is currently held with an offshore financial bank so it is 
safe so secure. Also, the Government of his country do not know 
of this asset hence why they are unable to seize it as they have 
done his other assets.

My proposal to you is for you to help us manage these funds, and 
invest it in lucrative projects in your country that will yeild 
good profits. You also do not have to worry about if this is safe 
or not because everything will be handled in a legal and 
transparent manner. You will also be handosmely rewarded for your 
help if you decide to work with us. If this proposal interests 
you, please kindly respond so that I can give you more details. I 
hope to hear from you soon.

Regards,

Moussa.


Re: [PATCH] usb: typec: intel_pmc_mux: Use correct response message bits

2020-12-08 Thread Heikki Krogerus
On Thu, Dec 03, 2020 at 02:08:13PM -0800, Utkarsh Patel wrote:
> When Intel PMC Mux agent driver receives the response message from PMC, it
> checks for the same response bits for all the mux states.
> Corrected it by checking correct response message bits, Bit 8 & 9 for the
> SAFE Mode and Alternate Modes and Bit 16 & 17 for the Connect and
> Disconnect Modes.
> 
> Signed-off-by: Utkarsh Patel 

Reviewed-by: Heikki Krogerus 

> ---
>  drivers/usb/typec/mux/intel_pmc_mux.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/typec/mux/intel_pmc_mux.c 
> b/drivers/usb/typec/mux/intel_pmc_mux.c
> index aa3211f1c4c3..e58ae8a7fefb 100644
> --- a/drivers/usb/typec/mux/intel_pmc_mux.c
> +++ b/drivers/usb/typec/mux/intel_pmc_mux.c
> @@ -176,6 +176,7 @@ static int hsl_orientation(struct pmc_usb_port *port)
>  static int pmc_usb_command(struct pmc_usb_port *port, u8 *msg, u32 len)
>  {
>   u8 response[4];
> + u8 status_res;
>   int ret;
>  
>   /*
> @@ -189,9 +190,13 @@ static int pmc_usb_command(struct pmc_usb_port *port, u8 
> *msg, u32 len)
>   if (ret)
>   return ret;
>  
> - if (response[2] & PMC_USB_RESP_STATUS_FAILURE) {
> - if (response[2] & PMC_USB_RESP_STATUS_FATAL)
> + status_res = (msg[0] & 0xf) < PMC_USB_SAFE_MODE ?
> +  response[2] : response[1];
> +
> + if (status_res & PMC_USB_RESP_STATUS_FAILURE) {
> + if (status_res & PMC_USB_RESP_STATUS_FATAL)
>   return -EIO;
> +
>   return -EBUSY;
>   }
>  
> -- 
> 2.17.1

thanks,

-- 
heikki


RE: [PATCH v1 2/3] scsi: ufs: Distinguish between TM request UPIU and response UPIU in TM UPIU trace

2020-12-06 Thread Avri Altman
> 
> 
> From: Bean Huo 
> 
> Distinguish between TM request UPIU and response UPIU in TM UPIU trace,
> for the TM response, let TM UPIU trace print its TM response UPIU.
> 
> Signed-off-by: Bean Huo 
Acked-by: Avri Altman 

Again - same comment:
But you need to change the complete string so not to break the current parsers.
I would also pass to the  struct utp_upiu_header *,
so no comparison is needed.

Thanks,
Avri

> ---
>  drivers/scsi/ufs/ufshcd.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index e10de94adb3f..29d7240a61bf 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -338,8 +338,12 @@ static void ufshcd_add_tm_upiu_trace(struct
> ufs_hba *hba, unsigned int tag,
> int off = (int)tag - hba->nutrs;
> struct utp_task_req_desc *descp = >utmrdl_base_addr[off];
> 
> -   trace_ufshcd_upiu(dev_name(hba->dev), str, >req_header,
> -   >input_param1);
> +   if (!strcmp("tm_send", str))
> +   trace_ufshcd_upiu(dev_name(hba->dev), str, 
> >req_header,
> + >input_param1);
> +   else
> +   trace_ufshcd_upiu(dev_name(hba->dev), str, 
> >rsp_header,
> + >output_param1);
>  }
> 
>  static void ufshcd_add_uic_command_trace(struct ufs_hba *hba,
> --
> 2.17.1



Re: [PATCH v1 2/3] scsi: ufs: Distinguish between TM request UPIU and response UPIU in TM UPIU trace

2020-12-06 Thread Bart Van Assche
On 12/6/20 8:42 AM, Bean Huo wrote:
> From: Bean Huo 
> 
> Distinguish between TM request UPIU and response UPIU in TM UPIU trace,
> for the TM response, let TM UPIU trace print its TM response UPIU.
> 
> Signed-off-by: Bean Huo 
> ---
>  drivers/scsi/ufs/ufshcd.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index e10de94adb3f..29d7240a61bf 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -338,8 +338,12 @@ static void ufshcd_add_tm_upiu_trace(struct ufs_hba 
> *hba, unsigned int tag,
>   int off = (int)tag - hba->nutrs;
>   struct utp_task_req_desc *descp = >utmrdl_base_addr[off];
>  
> - trace_ufshcd_upiu(dev_name(hba->dev), str, >req_header,
> - >input_param1);
> + if (!strcmp("tm_send", str))
> + trace_ufshcd_upiu(dev_name(hba->dev), str, >req_header,
> +   >input_param1);
> + else
> + trace_ufshcd_upiu(dev_name(hba->dev), str, >rsp_header,
> +   >output_param1);
>  }

Same comment here: please change the type of the 'str' argument in an
enum such that the strcmp() call can be changed into an integer comparison.

Thanks,

Bart.


[PATCH v1 2/3] scsi: ufs: Distinguish between TM request UPIU and response UPIU in TM UPIU trace

2020-12-06 Thread Bean Huo
From: Bean Huo 

Distinguish between TM request UPIU and response UPIU in TM UPIU trace,
for the TM response, let TM UPIU trace print its TM response UPIU.

Signed-off-by: Bean Huo 
---
 drivers/scsi/ufs/ufshcd.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index e10de94adb3f..29d7240a61bf 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -338,8 +338,12 @@ static void ufshcd_add_tm_upiu_trace(struct ufs_hba *hba, 
unsigned int tag,
int off = (int)tag - hba->nutrs;
struct utp_task_req_desc *descp = >utmrdl_base_addr[off];
 
-   trace_ufshcd_upiu(dev_name(hba->dev), str, >req_header,
-   >input_param1);
+   if (!strcmp("tm_send", str))
+   trace_ufshcd_upiu(dev_name(hba->dev), str, >req_header,
+ >input_param1);
+   else
+   trace_ufshcd_upiu(dev_name(hba->dev), str, >rsp_header,
+ >output_param1);
 }
 
 static void ufshcd_add_uic_command_trace(struct ufs_hba *hba,
-- 
2.17.1



Re: [PATCH] mmc: block: Let CMD13 polling only for MMC IOCTLS with the R1B response

2020-12-04 Thread Bean Huo
On Fri, 2020-12-04 at 15:38 +0100, Ulf Hansson wrote:
> > There is no need to poll device status through CMD13.
> > 
> > Meanwhile, based on the original change commit (mmc: block: Add
> > CMD13 polling
> > for MMC IOCTLS with R1B response), and comment in
> > __mmc_blk_ioctl_cmd(),
> > current code is not in line with its original purpose. So fix it
> > with this patch.
> > 
> > Fixes: a0d4c7eb71dd ("mmc: block: Add CMD13 polling for MMC IOCTLS
> > with R1B response")
> > Cc: sta...@vger.kernel.org
> > Reported-by: Zhan Liu 
> > Signed-off-by: Zhan Liu 
> > Signed-off-by: Bean Huo 
> 
> Applied for fixes, thanks!
> 
> Note, I took the liberty to rephrase the commit message (and the
> header) to clarify things a bit more.
> 

Uffe,
Nice, thanks a lot.

Bean



Re: [PATCH] mmc: block: Let CMD13 polling only for MMC IOCTLS with the R1B response

2020-12-04 Thread Ulf Hansson
On Wed, 2 Dec 2020 at 21:23, Bean Huo  wrote:
>
> From: Bean Huo 
>
> The CMD13 polling is only needed for the command with R1B Resp. For the
> command with R1 Resp, such as open-ended multiple block read/write
> (CMD18/25) commands, the device will just wait for its next paired command.
> There is no need to poll device status through CMD13.
>
> Meanwhile, based on the original change commit (mmc: block: Add CMD13 polling
> for MMC IOCTLS with R1B response), and comment in __mmc_blk_ioctl_cmd(),
> current code is not in line with its original purpose. So fix it with this 
> patch.
>
> Fixes: a0d4c7eb71dd ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B 
> response")
> Cc: sta...@vger.kernel.org
> Reported-by: Zhan Liu 
> Signed-off-by: Zhan Liu 
> Signed-off-by: Bean Huo 

Applied for fixes, thanks!

Note, I took the liberty to rephrase the commit message (and the
header) to clarify things a bit more.

Kind regards
Uffe


> ---
>  drivers/mmc/core/block.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> index 8d3df0be0355..42e27a298218 100644
> --- a/drivers/mmc/core/block.c
> +++ b/drivers/mmc/core/block.c
> @@ -580,7 +580,7 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card, 
> struct mmc_blk_data *md,
>
> memcpy(&(idata->ic.response), cmd.resp, sizeof(cmd.resp));
>
> -   if (idata->rpmb || (cmd.flags & MMC_RSP_R1B)) {
> +   if (idata->rpmb || (cmd.flags & MMC_RSP_R1B) == MMC_RSP_R1B) {
> /*
>  * Ensure RPMB/R1B command has completed by polling CMD13
>  * "Send Status".
> --
> 2.17.1
>


Re: [PATCH v3 1/7] bus: mhi: core: Allow receiving a STOP channel command response

2020-12-03 Thread Bhaumik Bhatt

On 2020-12-02 04:15 PM, Hemant Kumar wrote:

Hi Bhaumik,

On 12/2/20 3:40 PM, Bhaumik Bhatt wrote:

Add support to receive the response to a STOP channel command to the

How about saying "Add support to send the STOP channel command ?

Addressed in v4.

MHI bus. If a client would like to STOP a channel instead of issuing
a RESET to it, this would provide support for it.

Signed-off-by: Bhaumik Bhatt 
---
  drivers/bus/mhi/core/main.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 702c31b..a7bb8a7 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -1193,6 +1193,11 @@ int mhi_send_cmd(struct mhi_controller 
*mhi_cntrl,

cmd_tre->dword[0] = MHI_TRE_CMD_RESET_DWORD0;
cmd_tre->dword[1] = MHI_TRE_CMD_RESET_DWORD1(chan);
break;
+   case MHI_CMD_STOP_CHAN:
+   cmd_tre->ptr = MHI_TRE_CMD_STOP_PTR;
+   cmd_tre->dword[0] = MHI_TRE_CMD_STOP_DWORD0;
+   cmd_tre->dword[1] = MHI_TRE_CMD_STOP_DWORD1(chan);
+   break;
case MHI_CMD_START_CHAN:
cmd_tre->ptr = MHI_TRE_CMD_START_PTR;
cmd_tre->dword[0] = MHI_TRE_CMD_START_DWORD0;



Thanks,
Hemant


Thanks,
Bhaumik
---
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project


[PATCH] usb: typec: intel_pmc_mux: Use correct response message bits

2020-12-03 Thread Utkarsh Patel
When Intel PMC Mux agent driver receives the response message from PMC, it
checks for the same response bits for all the mux states.
Corrected it by checking correct response message bits, Bit 8 & 9 for the
SAFE Mode and Alternate Modes and Bit 16 & 17 for the Connect and
Disconnect Modes.

Signed-off-by: Utkarsh Patel 
---
 drivers/usb/typec/mux/intel_pmc_mux.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/typec/mux/intel_pmc_mux.c 
b/drivers/usb/typec/mux/intel_pmc_mux.c
index aa3211f1c4c3..e58ae8a7fefb 100644
--- a/drivers/usb/typec/mux/intel_pmc_mux.c
+++ b/drivers/usb/typec/mux/intel_pmc_mux.c
@@ -176,6 +176,7 @@ static int hsl_orientation(struct pmc_usb_port *port)
 static int pmc_usb_command(struct pmc_usb_port *port, u8 *msg, u32 len)
 {
    u8 response[4];
+   u8 status_res;
int ret;
 
/*
@@ -189,9 +190,13 @@ static int pmc_usb_command(struct pmc_usb_port *port, u8 
*msg, u32 len)
if (ret)
return ret;
 
-   if (response[2] & PMC_USB_RESP_STATUS_FAILURE) {
-   if (response[2] & PMC_USB_RESP_STATUS_FATAL)
+   status_res = (msg[0] & 0xf) < PMC_USB_SAFE_MODE ?
+    response[2] : response[1];
+
+   if (status_res & PMC_USB_RESP_STATUS_FAILURE) {
+   if (status_res & PMC_USB_RESP_STATUS_FATAL)
return -EIO;
+
return -EBUSY;
}
 
-- 
2.17.1



Re: [PATCH v3 1/7] bus: mhi: core: Allow receiving a STOP channel command response

2020-12-02 Thread Hemant Kumar

Hi Bhaumik,

On 12/2/20 3:40 PM, Bhaumik Bhatt wrote:

Add support to receive the response to a STOP channel command to the

How about saying "Add support to send the STOP channel command ?

MHI bus. If a client would like to STOP a channel instead of issuing
a RESET to it, this would provide support for it.

Signed-off-by: Bhaumik Bhatt 
---
  drivers/bus/mhi/core/main.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 702c31b..a7bb8a7 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -1193,6 +1193,11 @@ int mhi_send_cmd(struct mhi_controller *mhi_cntrl,
cmd_tre->dword[0] = MHI_TRE_CMD_RESET_DWORD0;
cmd_tre->dword[1] = MHI_TRE_CMD_RESET_DWORD1(chan);
break;
+   case MHI_CMD_STOP_CHAN:
+   cmd_tre->ptr = MHI_TRE_CMD_STOP_PTR;
+   cmd_tre->dword[0] = MHI_TRE_CMD_STOP_DWORD0;
+   cmd_tre->dword[1] = MHI_TRE_CMD_STOP_DWORD1(chan);
+   break;
case MHI_CMD_START_CHAN:
cmd_tre->ptr = MHI_TRE_CMD_START_PTR;
cmd_tre->dword[0] = MHI_TRE_CMD_START_DWORD0;



Thanks,
Hemant
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


[PATCH v3 1/7] bus: mhi: core: Allow receiving a STOP channel command response

2020-12-02 Thread Bhaumik Bhatt
Add support to receive the response to a STOP channel command to the
MHI bus. If a client would like to STOP a channel instead of issuing
a RESET to it, this would provide support for it.

Signed-off-by: Bhaumik Bhatt 
---
 drivers/bus/mhi/core/main.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 702c31b..a7bb8a7 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -1193,6 +1193,11 @@ int mhi_send_cmd(struct mhi_controller *mhi_cntrl,
cmd_tre->dword[0] = MHI_TRE_CMD_RESET_DWORD0;
cmd_tre->dword[1] = MHI_TRE_CMD_RESET_DWORD1(chan);
break;
+   case MHI_CMD_STOP_CHAN:
+   cmd_tre->ptr = MHI_TRE_CMD_STOP_PTR;
+   cmd_tre->dword[0] = MHI_TRE_CMD_STOP_DWORD0;
+   cmd_tre->dword[1] = MHI_TRE_CMD_STOP_DWORD1(chan);
+   break;
case MHI_CMD_START_CHAN:
cmd_tre->ptr = MHI_TRE_CMD_START_PTR;
cmd_tre->dword[0] = MHI_TRE_CMD_START_DWORD0;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH] mmc: block: Let CMD13 polling only for MMC IOCTLS with the R1B response

2020-12-02 Thread Bean Huo
From: Bean Huo 

The CMD13 polling is only needed for the command with R1B Resp. For the
command with R1 Resp, such as open-ended multiple block read/write
(CMD18/25) commands, the device will just wait for its next paired command.
There is no need to poll device status through CMD13.

Meanwhile, based on the original change commit (mmc: block: Add CMD13 polling
for MMC IOCTLS with R1B response), and comment in __mmc_blk_ioctl_cmd(),
current code is not in line with its original purpose. So fix it with this 
patch.

Fixes: a0d4c7eb71dd ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B 
response")
Cc: sta...@vger.kernel.org
Reported-by: Zhan Liu 
Signed-off-by: Zhan Liu 
Signed-off-by: Bean Huo 
---
 drivers/mmc/core/block.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 8d3df0be0355..42e27a298218 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -580,7 +580,7 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card, 
struct mmc_blk_data *md,
 
memcpy(&(idata->ic.response), cmd.resp, sizeof(cmd.resp));
 
-   if (idata->rpmb || (cmd.flags & MMC_RSP_R1B)) {
+   if (idata->rpmb || (cmd.flags & MMC_RSP_R1B) == MMC_RSP_R1B) {
/*
 * Ensure RPMB/R1B command has completed by polling CMD13
 * "Send Status".
-- 
2.17.1



URGENT RESPONSE NEEDED...

2020-11-30 Thread Adams Elena
My Donation To You in good faith.

May the peace of the Almighty God be with you and your Family,

With Due Respect and Humility, I was compelled to write you under
humanitarian ground. My name is Mrs Elena Adams, the Wife of Engineer
Ralph Alphonso Adams from United State Of America. I have took a
personal decision to donate what I inherited from my late husband to
the Charity, less privilege, I am 68 years old and I was diagnosed for
Lung and bronchial cancer since the past 4 years, immediately after
the death of my husband. We were both married for many years without a
child, I took this decision because I don't have any child that will
inherit this money  and rather to allow my husband relatives use my
husband hard-earned funds  in ungodly ways  I have decided  to donate
all I inherited from my late husband to you for good work of God.

I and My late husband based here in Burkina Faso West Africa since
eighteen years ago dealing with gold exportation and Sales. I have
decided to donate a fund through Credit Account €4.700.000.00 Four
Million Seven Hundred Thousand Euros to you for this assignment,
Charity, less privilege, building of schools, hospitals and also for
the assistance of the poor widows, Motherless babies, Charity
organization, CHRISTIAN OR MUSLIM, and orphans. I don't know you in
person but God knows you, so contacting you for this assignment is a
direction from the holy spirit of God to donate this fund outside this
country through you as my late husband has already donated a lot in
this country,

so you have to make sure that you use this donation fund as I have
directed so that the name of the Almighty God will be glorify forever.
Your urgent response is required in this matter due to my present
critical condition of my health, it was a Sister nurse working in this
hospital that helped me to type this message, because I am loosing
strength every minutes of the day. All I need from you is prayers that
GOD will accept my soul in case I didn't survive this surgery. Also
pray for the soul of my late Husband to rest in peace.

Please always be prayerful all through your life, we are visitors on
this earth and we must be very careful in whatever we do so that our
soul will not be a waste. I wish you all the best and may God bless
you abundantly.  I will give you more details about this orphanage
home, as soon as i receive your reply in my private
email(elenaadams...@gmail.com) to handle this project because I do not
want to state all here until I see your reply, desire and commitment
to handle this project. I AM WAITING FOR YOUR URGENT REPLY

Remain blessed in God.

Yours Sister.
Mrs Elena Adams.


Re: [PATCH v2 1/6] bus: mhi: core: Allow receiving a STOP channel command response

2020-11-23 Thread Bhaumik Bhatt

On 2020-11-21 09:16 AM, Manivannan Sadhasivam wrote:

On Mon, Nov 16, 2020 at 09:36:09AM -0800, Bhaumik Bhatt wrote:

Hi Mani,

On 2020-11-15 23:13, Manivannan Sadhasivam wrote:
> On Wed, Nov 11, 2020 at 11:21:08AM -0800, Bhaumik Bhatt wrote:
> > Add support to receive the response to a STOP channel command to the
> > MHI bus. If a client would like to STOP a channel instead of issuing
> > a RESET to it, this would provide support for it.
> >
> > Signed-off-by: Bhaumik Bhatt 
> > ---
> >  drivers/bus/mhi/core/init.c | 5 +++--
> >  drivers/bus/mhi/core/main.c | 5 +
> >  2 files changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> > index 8cefa35..4d34d62 100644
> > --- a/drivers/bus/mhi/core/init.c
> > +++ b/drivers/bus/mhi/core/init.c
> > @@ -1267,8 +1267,9 @@ static int mhi_driver_remove(struct device *dev)
> >
> >   mutex_lock(_chan->mutex);
> >
> > - if (ch_state[dir] == MHI_CH_STATE_ENABLED &&
> > - !mhi_chan->offload_ch)
> > + if ((ch_state[dir] == MHI_CH_STATE_ENABLED ||
> > +  ch_state[dir] == MHI_CH_STATE_STOP) &&
>
> This enum is not defined in this patch so it'll break. Please add a
> separate
> patch which introduces the new state enums alone and then have patches
> 1/2
> as a followup.
>
It is actually already defined and present in internal.h as enum
mhi_ch_state.

The old set of enums has MHI_CH_STATE_STOP from enum mhi_ch_state and 
the

new
enum I introduced is MHI_CH_STATE_TYPE_STOP from enum enum
mhi_ch_state_type.

If it seems confusing, suggestions to renaming them are welcome.



Ah, sorry. I got confused with MHI_CH_STATE_TYPE_STOP and 
MHI_CH_STATE_STOP.

Ignore my previous comment.

Thanks,
Mani


No problem.

> Also this change is not belonging to this commit I believe.
>
I included this change here because, a channel can be in "stopped" 
state and

a user module could be unloaded or a crash could force a driver remove
leading
us to come this check.

If you think I should move it as a separate patch, let me know.
> Thanks,
> Mani
>
> > +  !mhi_chan->offload_ch)
> >   mhi_deinit_chan_ctxt(mhi_cntrl, mhi_chan);
> >
> >   mhi_chan->ch_state = MHI_CH_STATE_DISABLED;
> > diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> > index f953e2a..ad881a1 100644
> > --- a/drivers/bus/mhi/core/main.c
> > +++ b/drivers/bus/mhi/core/main.c
> > @@ -1194,6 +1194,11 @@ int mhi_send_cmd(struct mhi_controller
> > *mhi_cntrl,
> >   cmd_tre->dword[0] = MHI_TRE_CMD_RESET_DWORD0;
> >   cmd_tre->dword[1] = MHI_TRE_CMD_RESET_DWORD1(chan);
> >   break;
> > + case MHI_CMD_STOP_CHAN:
> > + cmd_tre->ptr = MHI_TRE_CMD_STOP_PTR;
> > + cmd_tre->dword[0] = MHI_TRE_CMD_STOP_DWORD0;
> > + cmd_tre->dword[1] = MHI_TRE_CMD_STOP_DWORD1(chan);
> > + break;
> >   case MHI_CMD_START_CHAN:
> >   cmd_tre->ptr = MHI_TRE_CMD_START_PTR;
> >   cmd_tre->dword[0] = MHI_TRE_CMD_START_DWORD0;
> > --
> > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
> > Forum,
> > a Linux Foundation Collaborative Project
> >

Thanks,
Bhaumik
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project


Thanks,
Bhaumik
---
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project


  1   2   3   4   5   6   7   8   9   10   >