st/pci.c
> > > > > > +++ b/drivers/nvme/host/pci.c
> > > > > > @@ -1249,8 +1249,8 @@ static enum blk_eh_timer_return
> > > > > > nvme_timeout(struct request *req, bool reserved)
> > > > > > dev_warn_ratelimited(dev
On Fri, 28 Aug 2020 at 12:29, Anders Roxell wrote:
>
> On Fri, 28 Aug 2020 at 11:35, Ulf Hansson wrote:
> >
> > On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju
> > wrote:
> > >
> > > On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju
> > > wrote:
> > > >
> > > > On Thu, 27 Aug 2020 at 15:42, Viresh
On Fri, 28 Aug 2020 at 11:35, Ulf Hansson wrote:
>
> On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju
> wrote:
> >
> > On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju
> > wrote:
> > >
> > > On Thu, 27 Aug 2020 at 15:42, Viresh Kumar
> > > wrote:
> > > >
> > > > On 27-08-20, 11:48, Arnd Bergmann
On Fri, 28 Aug 2020 at 15:05, Ulf Hansson wrote:
>
> On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju
> wrote:
> >
> > On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju
> > wrote:
> > >
> > > On Thu, 27 Aug 2020 at 15:42, Viresh Kumar
> > > wrote:
> > > >
> > > > On 27-08-20, 11:48, Arnd Bergmann
On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju wrote:
>
> On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju
> wrote:
> >
> > On Thu, 27 Aug 2020 at 15:42, Viresh Kumar wrote:
> > >
> > > On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > > > [3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > > > >
On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju wrote:
>
> On Thu, 27 Aug 2020 at 15:42, Viresh Kumar wrote:
> >
> > On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > > [3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > > > [3.683431] sdhci_msm_probe+0x284/0x9a0
> > >
> > >
On Thu, 27 Aug 2020 at 15:42, Viresh Kumar wrote:
>
> On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > [3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > > [3.683431] sdhci_msm_probe+0x284/0x9a0
> >
> > dev_pm_opp_put_clkname() is part of the error handling in the
> > probe function, so
t; > > index ba725ae47305..c4f1ce0ee1e3 100644
> > > > > --- a/drivers/nvme/host/pci.c
> > > > > +++ b/drivers/nvme/host/pci.c
> > > > > @@ -1249,8 +1249,8 @@ static enum blk_eh_timer_return
> > > > > nvme_
mple returns for clarity.
>
> While we are at it, move the call to memset, as variable bd is not used
> on all code paths.
>
> Fixes: 7b57b2ddec21 ("ath11k: create a common function to request all
> firmware files")
> Signed-off-by: Alex Dewar
> Signed-off-by:
On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > [3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > [3.683431] sdhci_msm_probe+0x284/0x9a0
>
> dev_pm_opp_put_clkname() is part of the error handling in the
> probe function, so I would deduct there are two problems:
>
> - something failed
roller Interface driver
> > [3.493508] sdhci: Copyright(c) Pierre Ossman
> > [3.500902] Synopsys Designware Multimedia Card Interface Driver
> > [3.507441] sdhci-pltfm: SDHCI platform and OF driver helper
> > [3.514308] Unable to handle kernel paging request at vir
.493508] sdhci: Copyright(c) Pierre Ossman
> [3.500902] Synopsys Designware Multimedia Card Interface Driver
> [3.507441] sdhci-pltfm: SDHCI platform and OF driver helper
> [3.514308] Unable to handle kernel paging request at virtual
> address dead0108
> [3.514695
tx channel not available
> [3.493455] sdhci: Secure Digital Host Controller Interface driver
> [3.493508] sdhci: Copyright(c) Pierre Ossman
> [3.500902] Synopsys Designware Multimedia Card Interface Driver
> [3.507441] sdhci-pltfm: SDHCI platform and OF driver helper
Card Interface Driver
[3.507441] sdhci-pltfm: SDHCI platform and OF driver helper
[3.514308] Unable to handle kernel paging request at virtual
address dead0108
[3.514695] Mem abort info:
[3.522421] ESR = 0x9644
[3.525096] EC = 0x25: DABT (current EL), IL = 32 bits
This patch introduces the capability to stop a remote processor
that has been attached to by the remoteproc core. For that to
happen a rproc::ops::stop() operation need to be available.
Signed-off-by: Mathieu Poirier
---
drivers/remoteproc/remoteproc_cdev.c | 5 +++--
This patch introduces the capability to detach a remote processor
that has been attached to or booted by the remoteproc core. For
that to happen a rproc::ops::detach() operation need to be
available.
Signed-off-by: Mathieu Poirier
---
drivers/remoteproc/remoteproc_cdev.c | 6 ++
;ifcvf_config_changed, 0,
> >vf->config_msix_name, vf);
> > + if (ret) {
> > + IFCVF_ERR(pdev, "Failed to request config irq\n");
> > + return ret;
> > + }
> > for (i = 0; i < IFCVF_MAX_QUEUE_PAIRS * 2; i++) {
> > snprintf(vf->vring[i].msix_name, 256, "ifcvf[%s]-%d\n",
>
>
> Hi Michael:
>
> Any comments on this series?
>
> Thanks
>
Applied, thanks!
are at it, move the call to memset, as variable bd is not used
on all code paths.
Fixes: 7b57b2ddec21 ("ath11k: create a common function to request all firmware
files")
Signed-off-by: Alex Dewar
---
drivers/net/wireless/ath/ath11k/qmi.c | 20 +---
1 file changed, 9 inserti
ftrace_buffer_size_kb.sh: line 33: echo: write error: Cannot allocate memory
[ 55.868262] Unable to handle kernel paging request at virtual
address 800036ac1000
[ 55.868317] Mem abort info:
[ 55.874729] Exception class = DABT (current EL), IL = 32 bits
[ 55.877427] SET = 0, FnV = 0
[ 55.883323
From: Shuo Liu
An I/O request of a User VM, which is constructed by the hypervisor, is
distributed by the ACRN Hypervisor Service Module to an I/O client
corresponding to the address range of the I/O request.
For each User VM, there is a shared 4-KByte memory region used for I/O
requests
From: Stanley Chu
[ Upstream commit b10178ee7fa88b68a9e8adc06534d2605cb0ec23 ]
If somehow no interrupt notification is raised for a completed request and
its doorbell bit is cleared by host, UFS driver needs to cleanup its
outstanding bit in ufshcd_abort(). Otherwise, system may behave
From: Stanley Chu
[ Upstream commit b10178ee7fa88b68a9e8adc06534d2605cb0ec23 ]
If somehow no interrupt notification is raised for a completed request and
its doorbell bit is cleared by host, UFS driver needs to cleanup its
outstanding bit in ufshcd_abort(). Otherwise, system may behave
From: Stanley Chu
[ Upstream commit b10178ee7fa88b68a9e8adc06534d2605cb0ec23 ]
If somehow no interrupt notification is raised for a completed request and
its doorbell bit is cleared by host, UFS driver needs to cleanup its
outstanding bit in ufshcd_abort(). Otherwise, system may behave
From: Stanley Chu
[ Upstream commit b10178ee7fa88b68a9e8adc06534d2605cb0ec23 ]
If somehow no interrupt notification is raised for a completed request and
its doorbell bit is cleared by host, UFS driver needs to cleanup its
outstanding bit in ufshcd_abort(). Otherwise, system may behave
From: Stanley Chu
[ Upstream commit b10178ee7fa88b68a9e8adc06534d2605cb0ec23 ]
If somehow no interrupt notification is raised for a completed request and
its doorbell bit is cleared by host, UFS driver needs to cleanup its
outstanding bit in ufshcd_abort(). Otherwise, system may behave
completion.
Meanwhile the timeout handlers get timer_list as context argument and do a
timer-specific container-of to zfcp_fsf_req which can have been freed.
Fix it by making sure that any request timeout handlers, that might just
have started before del_timer(), are completed by using del_timer_sync
completion.
Meanwhile the timeout handlers get timer_list as context argument and do a
timer-specific container-of to zfcp_fsf_req which can have been freed.
Fix it by making sure that any request timeout handlers, that might just
have started before del_timer(), are completed by using del_timer_sync
completion.
Meanwhile the timeout handlers get timer_list as context argument and do a
timer-specific container-of to zfcp_fsf_req which can have been freed.
Fix it by making sure that any request timeout handlers, that might just
have started before del_timer(), are completed by using del_timer_sync
TID RDMA WRITE request is followed by an
IB_WR_RDMA_WRITE_WITH_IMM request, the latter could be completed first on
the responder side. As a result, no ACK packet for the latter could be
sent because the TID RDMA WRITE request is still being processed on the
responder side.
When the TID RDMA WRITE
completion.
Meanwhile the timeout handlers get timer_list as context argument and do a
timer-specific container-of to zfcp_fsf_req which can have been freed.
Fix it by making sure that any request timeout handlers, that might just
have started before del_timer(), are completed by using del_timer_sync
TID RDMA WRITE request is followed by an
IB_WR_RDMA_WRITE_WITH_IMM request, the latter could be completed first on
the responder side. As a result, no ACK packet for the latter could be
sent because the TID RDMA WRITE request is still being processed on the
responder side.
When the TID RDMA WRITE
TID RDMA WRITE request is followed by an
IB_WR_RDMA_WRITE_WITH_IMM request, the latter could be completed first on
the responder side. As a result, no ACK packet for the latter could be
sent because the TID RDMA WRITE request is still being processed on the
responder side.
When the TID RDMA WRITE
From: Niklas Schnelle
commit b76fee1bc56c31a9d2a49592810eba30cc06d61a upstream.
A configuration request event may be stale, that is the event
may reference a zdev which was already configured.
This can happen when a hotplug happens during boot such that
the device is discovered and configured
On Sat, Aug 22, 2020 at 01:12:50PM +0300, Oded Gabbay wrote:
> Hello Greg,
>
> This is the pull request for habanalabs driver fixes for 5.9-rc2/3.
> Mostly security fixes but also some functionality fixes. More details are
> in the tag.
>
> Thanks,
> Oded
>
> The
Hello Greg,
This is the pull request for habanalabs driver fixes for 5.9-rc2/3.
Mostly security fixes but also some functionality fixes. More details are
in the tag.
Thanks,
Oded
The following changes since commit 51072c0f5b5e98a035c6f63b83ba2afedbb7accd:
mei: hdcp: fix
Instead of storing IV data in the channel context, store them in the
request context.
Storing them in the channel structure was conceptualy wrong since they
are per request related.
Signed-off-by: Corentin Labbe
---
.../allwinner/sun8i-ce/sun8i-ce-cipher.c | 27 +--
drivers
The driver requests IRQs to disable them immediately. This is
potentially racy, fix this by requesting the IRQs to come disabled
instead using the IRQ_NOAUTOEN flag of irq_set_status_flags().
Reported-by: Ezequiel Garcia
Signed-off-by: Alexandre Courbot
---
The "media: mtk-vcodec: venc: support
On Fri, Aug 21, 2020 at 09:35:04AM +0200, LABBE Corentin wrote:
>
> Since cryptodev now have 453431a54934 ("mm, treewide: rename kzfree() to
> kfree_sensitive()"), my serie should apply cleanly.
Please resubmit. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP
On Fri, Jul 31, 2020 at 06:24:27PM +1000, Herbert Xu wrote:
> On Tue, Jul 21, 2020 at 07:06:22PM +, Corentin Labbe wrote:
> > Instead of storing IV data in the channel context, store them in the
> > request context.
> > Storing them in the channel structure was co
Hi all,
On Wed, 19 Aug 2020 07:11:37 -0500 Nishanth Menon wrote:
>
> Could you add my ti-k3-next branch to linux-next? You can find it
> here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git#ti-k3-next
>
> NOTE: This tree will eventually supersede Tero's tree[1] which is
>
Hi Stephen,
Could you add my ti-k3-next branch to linux-next? You can find it
here:
git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git#ti-k3-next
NOTE: This tree will eventually supersede Tero's tree[1] which is
currently in linux-next.
--
Regards,
Nishanth Menon
Key
hus
media_request_close() will no longer get called for a partially created
media request.
Reported-by: syzbot+6bed2d543cf7e48b8...@syzkaller.appspotmail.com
Cc: sta...@vger.kernel.org
Signed-off-by: Tuomas Tynkkynen
Fixes: 10905d70d788 ("media: media-request: implement media requests")
Reviewed-by:
hus
media_request_close() will no longer get called for a partially created
media request.
Reported-by: syzbot+6bed2d543cf7e48b8...@syzkaller.appspotmail.com
Cc: sta...@vger.kernel.org
Signed-off-by: Tuomas Tynkkynen
Fixes: 10905d70d788 ("media: media-request: implement media requests")
Reviewed-by:
hus
media_request_close() will no longer get called for a partially created
media request.
Reported-by: syzbot+6bed2d543cf7e48b8...@syzkaller.appspotmail.com
Cc: sta...@vger.kernel.org
Signed-off-by: Tuomas Tynkkynen
Fixes: 10905d70d788 ("media: media-request: implement media requests")
Reviewed-by:
Once the driver gets sync_reset_request from firmware it prepares for the
coming reset and sends acknowledge.
After getting this event the driver expects device reset, either it will
trigger PCI reset on sync_reset_now event or such PCI reset will be
triggered by another PF of the same device. So
syzbot suspects this issue was fixed by commit:
commit 1378817486d6860f6a927f573491afe65287abf1
Author: Eric Dumazet
Date: Thu May 21 18:29:58 2020 +
tipc: block BH before using dst_cache
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1537694a90
start commit:
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index ba725ae47305..c4f1ce0ee1e3 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1249,8 +1249,8 @@ static enum blk_eh_timer_return nvme_timeout(struct
request *req, bool reserved
drivers/nvme/host/pci.c
> > > > +++ b/drivers/nvme/host/pci.c
> > > > @@ -1249,8 +1249,8 @@ static enum blk_eh_timer_return
> > > > nvme_timeout(struct request *req, bool reserved)
> > > > dev_warn_ratelimited(
ba725ae47305..c4f1ce0ee1e3 100644
> > > --- a/drivers/nvme/host/pci.c
> > > +++ b/drivers/nvme/host/pci.c
> > > @@ -1249,8 +1249,8 @@ static enum blk_eh_timer_return nvme_timeout(struct
> > > request *req, bool reserved)
> > > dev_warn_rat
c
> > +++ b/drivers/nvme/host/pci.c
> > @@ -1249,8 +1249,8 @@ static enum blk_eh_timer_return nvme_timeout(struct
> > request *req, bool reserved)
> > dev_warn_ratelimited(dev->ctrl.device,
> >"I/O %d QID %d timeout, disable
eh_timer_return nvme_timeout(struct
> request *req, bool reserved)
> dev_warn_ratelimited(dev->ctrl.device,
>"I/O %d QID %d timeout, disable controller\n",
>req->tag, nvmeq->qid);
> - nvme_dev_disable
t_work() is still in execution. This patch fixed the problem by
> > setting flag of the problematic request to NVME_REQ_CANCELLED before
> > calling nvme_dev_disable() to make sure __nvme_submit_sync_cmd() returns
> > an error code and let nvme_submit_sync_cmd() fail g
of the problematic request to NVME_REQ_CANCELLED before
calling nvme_dev_disable() to make sure __nvme_submit_sync_cmd() returns
an error code and let nvme_submit_sync_cmd() fail gracefully.
The following is console output.
[ 62.472097] nvme nvme0: I/O 13 QID 0 timeout, disable controller
led while
> nvme_reset_work() is still in execution. This patch fixed the problem by
> setting flag of the problematic request to NVME_REQ_CANCELLED before
> calling nvme_dev_disable() to make sure __nvme_submit_sync_cmd() returns
> an error code and let nvme_submit_sync_cmd() fail graceful
by
setting flag of the problematic request to NVME_REQ_CANCELLED before
calling nvme_dev_disable() to make sure __nvme_submit_sync_cmd() returns
an error code and let nvme_submit_sync_cmd() fail gracefully.
The following is console output.
[ 62.472097] nvme nvme0: I/O 13 QID 0 timeout, disable
syzbot has bisected this issue to:
commit a51486266c3ba8e035a47fa96df67f274fe0c7d0
Author: Jiri Pirko
Date: Sat Jun 15 09:03:49 2019 +
net: sched: remove NET_CLS_IND config option
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1746350990
start commit: 1ca0fafd
The pull request you sent on Thu, 13 Aug 2020 23:09:06 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-5.9
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e764a1e32337aaf325fc5b14a5bbd06eabba4699
Thank you!
--
Deet-doot-dot, I am a
Tegra20 has a high-priority-request control that allows to configure
when display's memory client should perform read requests with a higher
priority (Tegra30+ uses other means like Latency Allowance).
This patch changes the controls configuration in order to get a more
aggressive memory
Linus,
likely because of the holiday season, the I2C pull request is quite smaller
this time. Main features:
* bus recovery can now be given a pinctrl handle and the I2C core will
do all the steps to switch to/from GPIO which can save quite some
boilerplate code from drivers
* "fallth
> >
> > Signed-off-by: Stanley Chu
> > Reviewed-by: Can Guo
> > Signed-off-by: Bean Huo
Acked-by: Avri Altman
The pull request you sent on Wed, 12 Aug 2020 13:39:03 +0200:
> git://www.linux-watchdog.org/linux-watchdog.git tags/linux-watchdog-5.9-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4586039427fab2b8c4edd49c73002e13e04315cf
Thank you!
--
Deet-doot-dot, I
On Wed, Aug 12, 2020 at 5:38 AM Wim Van Sebroeck
wrote:
>
> Please pull the watchdog changes for the v5.2 release cycle.
Spot the cut-and-paste from an old email.. I went back and see that
the same thing happened in 5.7 pull request too..
Pulled,
Linus
On Wed, 2020-08-12 at 20:47 +0800, Stanley Chu wrote:
> Hi Avri, Bean,
>
> On Tue, 2020-08-11 at 16:18 +0200, Bean Huo wrote:
> > From: Stanley Chu
> >
> > If somehow no interrupt notification is raised for a completed
> > request
> > and its doorbell b
Hi Avri, Bean,
On Tue, 2020-08-11 at 16:18 +0200, Bean Huo wrote:
> From: Stanley Chu
>
> If somehow no interrupt notification is raised for a completed request
> and its doorbell bit is cleared by host, UFS driver needs to cleanup
> its outstanding bit in ufshcd_abort(). Otherw
The output from git request-pull:
The following changes since commit 92ed301919932f13b9172e525674157e983d:
Linux 5.8-rc7 (2020-07-26 14:14:06 -0700)
are available in the git repository at:
git://www.linux-watchdog.org/linux
int ifcvf_request_irq(struct ifcvf_adapter *adapter)
> ret = devm_request_irq(>dev, irq,
> ifcvf_config_changed, 0,
> vf->config_msix_name, vf);
> + if (ret) {
> + IFCVF_ERR(pdev, "Failed to re
From: Stanley Chu
If somehow no interrupt notification is raised for a completed request
and its doorbell bit is cleared by host, UFS driver needs to cleanup
its outstanding bit in ufshcd_abort(). Otherwise, system may behave
abnormally by below flow:
After ufshcd_abort() returns, this request
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest.git
for-next
Head SHA1: ff131efff141fc679cccde28bc265f4c79cbe329
Colin Ian King (1):
ktest.pl: Fix spelling mistake "Cant" -> "Can't"
Steven Rostedt (VMware) (1):
ktest.pl: Change the logic to control the size of
ret = devm_request_irq(>dev, irq,
ifcvf_config_changed, 0,
vf->config_msix_name, vf);
+ if (ret) {
+ IFCVF_ERR(pdev, "Failed to request config irq\n");
+ return ret;
+ }
for (i = 0;
On 8/5/20 6:17 AM, Grygorii Strashko wrote:
On 05/08/2020 14:32, Vinod Koul wrote:
On 05-08-20, 14:27, Peter Ujfalusi wrote:
The original commit mixed up the forward and completion ring IDs for the
rx flow configuration.
Acked-By: Vinod Koul
Fixes: 4927b1ab2047 ("dmaengine: ti:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
for-next
Head SHA1: 37f9e8b51dbe7f69d9f80aec98f1514f0cd4085e
Masami Hiramatsu (1):
bootconfig: Fix to find the initargs correctly
Muchun Song (1):
kprobes: Fix compiler warning for !CONFIG_KPROBES_ON_FTRACE
> diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
> index 3a5d33ea5ebe..12da38a92218 100644
> --- a/drivers/dma/ti/k3-udma-glue.c
> +++ b/drivers/dma/ti/k3-udma-glue.c
> @@ -579,8 +579,8 @@ static int k3_udma_glue_cfg_rx_flow(struct
> k3
On 05/08/2020 14:32, Vinod Koul wrote:
On 05-08-20, 14:27, Peter Ujfalusi wrote:
The original commit mixed up the forward and completion ring IDs for the
rx flow configuration.
Acked-By: Vinod Koul
Fixes: 4927b1ab2047 ("dmaengine: ti: k3-udma: Switch to
k3_ringacc_request_rings_pair")
Hello,
syzbot found the following issue on:
HEAD commit:ac3a0c84 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=141a4c1a90
kernel config: https://syzkaller.appspot.com/x/.config?x=c0cfcf935bcc94d2
On 2020-07-24 22:02, Stanley Chu wrote:
If somehow no interrupt notification is raised for a completed request
and its doorbell bit is cleared by host, UFS driver needs to cleanup
its outstanding bit in ufshcd_abort(). Otherwise, system may behave
abnormally by below flow:
After ufshcd_abort
encoding.
>>> > > > > > > •Synchronize the buffer requirement across both the video
>>> > > > > > > node/session
>>> > > > > > > (incase metadata is being processed as a separate v4l2 video
>>>
>> prevent
> >> >> the concurrency of abort and real completion of it.
> >> >>
> >> >> Check func scsi_times_out(), hope it helps.
> >> >>
> >> >> enum blk_eh_timer_return scsi_times_out(struct request
t; layer
>> use the atomic state, namely SCMD_STATE_COMPLETE, of a scsi cmd to
>> prevent
>> the concurrency of abort and real completion of it.
>>
>> Check func scsi_times_out(), hope it helps.
>>
>> enum blk_eh_timer_return scsi_times_out(struct re
Hi Bart,
On 2020-08-03 11:12, Bart Van Assche wrote:
On 2020-07-31 16:17, Can Guo wrote:
For scsi_dma_unmap() part, that is true - we should make it serialized
with
any other completion paths. I've found it during my fault injection
test, so
I've made a patch to fix it, but it only comes in
On 2020-07-31 16:17, Can Guo wrote:
> For scsi_dma_unmap() part, that is true - we should make it serialized with
> any other completion paths. I've found it during my fault injection test, so
> I've made a patch to fix it, but it only comes in my next error recovery
> enhancement patch series.
> >> use the atomic state, namely SCMD_STATE_COMPLETE, of a scsi cmd to
> >> prevent
> >> the concurrency of abort and real completion of it.
> >>
> >> Check func scsi_times_out(), hope it helps.
> >>
> >> enum blk_eh_time
of it.
Check func scsi_times_out(), hope it helps.
enum blk_eh_timer_return scsi_times_out(struct request *req)
{
...
if (rtn == BLK_EH_DONE) {
/*
* Set the command to complete first in order to
prevent
a real
* completion from releasing
The pull request you sent on Fri, 31 Jul 2020 21:16:54 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7dc6fd0f3b8404542718039f5de19fe56e474578
Thank you!
--
Deet-doot-dot, I
Linus,
here are some I2C core improvements to prevent NULL pointer usage and a
MAINTAINERS update.
Please pull.
Thanks,
Wolfram
The following changes since commit 92ed301919932f13b9172e525674157e983d:
Linux 5.8-rc7 (2020-07-26 14:14:06 -0700)
are available in the Git repository
t(), hope it helps.
>
> enum blk_eh_timer_return scsi_times_out(struct request *req)
> {
> ...
> if (rtn == BLK_EH_DONE) {
> /*
> * Set the command to complete first in order to prevent
> a real
> * completion from
On Tue, Jul 21, 2020 at 07:06:22PM +, Corentin Labbe wrote:
> Instead of storing IV data in the channel context, store them in the
> request context.
> Storing them in the channel structure was conceptualy wrong since they
> are per request related.
>
> Signed-off-
unc scsi_times_out(), hope it helps.
enum blk_eh_timer_return scsi_times_out(struct request *req)
{
...
if (rtn == BLK_EH_DONE) {
/*
* Set the command to complete first in order to prevent
a real
* completion from releasing the command while er
On 2020-07-30 18:30, Stanley Chu wrote:
> On Mon, 2020-07-27 at 11:18 +, Avri Altman wrote:
>> Looks good to me.
>> But better wait and see if Bart have any further reservations.
>
> Would you have any further suggestions?
Today is the first time that I took a look at ufshcd_abort(). The
Hello,
syzbot found the following issue on:
HEAD commit:04300d66 Merge tag 'riscv-for-linus-5.8-rc7' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13e6fb6490
kernel config: https://syzkaller.appspot.com/x/.config?x=f87a5e4232fdb267
rupt notification is raised for a completed request
> > and its doorbell bit is cleared by host, UFS driver needs to cleanup
> > its outstanding bit in ufshcd_abort(). Otherwise, system may behave
> > abnormally by below flow:
> >
> > After ufshcd_abort() returns,
From: Tomasz Figa
On FIMC variants which don't have writeback channel, there is no need to
access system registers. This patch makes the driver request sysreg
regmap conditionally depending on whether writeback is supported.
Signed-off-by: Tomasz Figa
Signed-off-by: Jonathan Bakker
Reviewed
Since GPIOlib-based IRQ-chip interface is now utilized there is no need
in calling the methods acpi_gpiochip_{request,free}_interrupts() here.
They will be called from gpiochip_add_irqchip()/gpiochip_irqchip_remove()
anyway.
Signed-off-by: Serge Semin
Reviewed-by: Andy Shevchenko
On Thu, Jul 30, 2020 at 04:55:33PM +0300, Serge Semin wrote:
> Since GPIOlib-based IRQ-chip interface is now utilized there is no need
> in calling the methods acpi_gpiochip_{request,free}_interrupts() here.
> They will be called from gpiochip_add_irqchip()/gpiochip_irqchip_remove()
Since GPIOlib-based IRQ-chip interface is now utilized there is no need
in calling the methods acpi_gpiochip_{request,free}_interrupts() here.
They will be called from gpiochip_add_irqchip()/gpiochip_irqchip_remove()
anyway.
Signed-off-by: Serge Semin
---
Changelog v2:
- This is a new patch
for when we use poll triggered retry. For that case, we cannot
safely use req->io, as that could be used by the request type itself.
Add a second io_poll_iocb pointer in the structure we allocate for poll
based retry, and ensure we use the right one from the two paths.
Fixes: 18bceab101ad ("
From: Chris Lew
In high traffic scenarios a remote may request extra intents to send
data faster. If the work thread that handles these intent requests is
starved of cpu time, then these requests can build up. Some remote
procs may not be able to handle this burst of built up intent requests
On Tue, Jul 28, 2020 at 05:26:29PM +0200, Paul Cercueil wrote:
> The driver only uses the registers up to offset 0x54. Since the EFUSE
> registers are in the middle of the NEMC registers, we only request
> the registers we will use for now - that way the EFUSE driver can
> probe too.
The driver only uses the registers up to offset 0x54. Since the EFUSE
registers are in the middle of the NEMC registers, we only request
the registers we will use for now - that way the EFUSE driver can
probe too.
Tested-by: H. Nikolaus Schaller
Signed-off-by: Paul Cercueil
---
Notes:
v2
Le mar. 28 juil. 2020 à 11:21, Krzysztof Kozlowski a
écrit :
On Mon, Jul 27, 2020 at 06:20:34PM +0200, Paul Cercueil wrote:
The driver only uses the registers up to offset 0x54. Since the
EFUSE
registers are in the middle of the NEMC registers, we only request
the registers we will use
901 - 1000 of 18873 matches
Mail list logo
