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
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.
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
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.
response.
name and phone number
and I will call to give you more information.
I await your response.
Sincerely,
Mr. Ying Wang
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
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
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
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
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 ad
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
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
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
> 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
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
> >> >> >>
> >> >> >> 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
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
>
> 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 re
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).
>&
>
> 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).
> >>
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
&
>
> 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
&
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
--
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
> > +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
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
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
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
>
> 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)
> >
> 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)
> >
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
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: Tom
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
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: Tom
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
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: Tom
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
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
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
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
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
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
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
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
response.
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
.@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 1
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 re
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
&
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
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
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
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
> > + 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
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
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
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
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
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
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
>
> 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,
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
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
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
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
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
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
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
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
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
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
nux.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
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
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
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
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 res
ing 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 register
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
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 ncs
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
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
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 (&quo
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
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
--
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
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
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 th
>
>
> 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 chang
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 +
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
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
> >
ext 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
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
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.
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 pr
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
, 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 wit
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
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
1 - 100 of 1882 matches
Mail list logo
