From: Stylon Wang <stylon.wang(a)amd.com>
[Why]
Regression found in some embedded panels traces back to the earliest
upstreamed ASSR patch. The changed code flow are causing problems
with some panels.
[How]
- Change ASSR enabling code while preserving original code flow
as much as possible
- Simplify the code on guarding with internal display flag
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=213779
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1620
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Stylon Wang <stylon.wang(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
(cherry picked from commit 6be50f5d83adc9541de3d5be26e968182b5ac150)
---
This is a backport of this patch to 5.13. I originally sent this
out as a follow up to the reply that the original patch failed to
apply to 5.13, but it hasn't been applied yet. Resending to make
sure it didn't get lost.
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index ae6830ff1cf7..774e825e5aab 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -1675,9 +1675,6 @@ static enum dp_panel_mode try_enable_assr(struct dc_stream_state *stream)
} else
panel_mode = DP_PANEL_MODE_DEFAULT;
-#else
- /* turn off ASSR if the implementation is not compiled in */
- panel_mode = DP_PANEL_MODE_DEFAULT;
#endif
return panel_mode;
}
--
2.31.1
Hi all,
Commit cb011044e34c ("watchdog: iTCO_wdt: Account for rebooting on
second timeout") causes a regression on several systems. Symptoms are:
system reboots automatically after a short period of time if watchdog
is enabled (by systemd for example). This has been reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=213809
Unfortunately this commit was backported to all stable kernel branches
(4.14, 4.19, 5.4, 5.10, 5.12 and 5.13). I'm not sure why that is the
case, BTW, as there is no Fixes tag and no Cc to stable@vger either.
And the fix is not trivial, has apparently not seen enough testing,
and addresses a problem that has a known and simple workaround. IMHO it
should never have been accepted as a stable patch in the first place.
Especially when the previous attempt to fix this issue already ended
with a regression and a revert.
Anyway... After a glance at the patch, I see what looks like a nice
thinko:
+ if (p->smi_res &&
+ (SMI_EN(p) & (TCO_EN | GBL_SMI_EN)) != (TCO_EN | GBL_SMI_EN))
The author most certainly meant inl(SMI_EN(p)) (the register's value)
and not SMI_EN(p) (the register's address).
--
Jean Delvare
SUSE L3 Support
From: Paolo Bonzini <pbonzini(a)redhat.com>
commit bd2fae8da794b55bf2ac02632da3a151b10e664c upstream.
In order to convert an HVA to a PFN, KVM usually tries to use
the get_user_pages family of functinso. This however is not
possible for VM_IO vmas; in that case, KVM instead uses follow_pfn.
In doing this however KVM loses the information on whether the
PFN is writable. That is usually not a problem because the main
use of VM_IO vmas with KVM is for BARs in PCI device assignment,
however it is a bug. To fix it, use follow_pte and check pte_write
while under the protection of the PTE lock. The information can
be used to fail hva_to_pfn_remapped or passed back to the
caller via *writable.
Usage of follow_pfn was introduced in commit add6a0cd1c5b ("KVM: MMU: try to fix
up page faults before giving up", 2016-07-05); however, even older version
have the same issue, all the way back to commit 2e2e3738af33 ("KVM:
Handle vma regions with no backing page", 2008-07-20), as they also did
not check whether the PFN was writable.
Fixes: 2e2e3738af33 ("KVM: Handle vma regions with no backing page")
Reported-by: David Stevens <stevensd(a)google.com>
Cc: 3pvd(a)google.com
Cc: Jann Horn <jannh(a)google.com>
Cc: Jason Gunthorpe <jgg(a)ziepe.ca>
Cc: stable(a)vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
[OP: backport to 4.14, adjust follow_pte() -> follow_pte_pmd()]
Signed-off-by: Ovidiu Panait <ovidiu.panait(a)windriver.com>
---
virt/kvm/kvm_main.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 547ae59199db..4e23d0b4b810 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1491,9 +1491,11 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma,
kvm_pfn_t *p_pfn)
{
unsigned long pfn;
+ pte_t *ptep;
+ spinlock_t *ptl;
int r;
- r = follow_pfn(vma, addr, &pfn);
+ r = follow_pte_pmd(vma->vm_mm, addr, NULL, NULL, &ptep, NULL, &ptl);
if (r) {
/*
* get_user_pages fails for VM_IO and VM_PFNMAP vmas and does
@@ -1508,14 +1510,19 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma,
if (r)
return r;
- r = follow_pfn(vma, addr, &pfn);
+ r = follow_pte_pmd(vma->vm_mm, addr, NULL, NULL, &ptep, NULL, &ptl);
if (r)
return r;
+ }
+ if (write_fault && !pte_write(*ptep)) {
+ pfn = KVM_PFN_ERR_RO_FAULT;
+ goto out;
}
if (writable)
- *writable = true;
+ *writable = pte_write(*ptep);
+ pfn = pte_pfn(*ptep);
/*
* Get a reference here because callers of *hva_to_pfn* and
@@ -1530,6 +1537,8 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma,
*/
kvm_get_pfn(pfn);
+out:
+ pte_unmap_unlock(ptep, ptl);
*p_pfn = pfn;
return 0;
}
--
2.25.1
[ Upstream commit f1748b1ee1fa0fd1a074504045b530b62f949188 ]
A successfully received delayed response could anyway report a failure at
the protocol layer in the message status field.
Add a check also for this error condition.
Cc: <stable(a)vger.kernel.org> # v5.4+
Link: https://lore.kernel.org/r/20210608103056.3388-1-cristian.marussi@arm.com
Fixes: 58ecdf03dbb9 ("firmware: arm_scmi: Add support for asynchronous commands and delayed response")
Signed-off-by: Cristian Marussi <cristian.marussi(a)arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla(a)arm.com>
---
Upstream commit f1748b1ee1fa0fd1a074504045b530b62f949188 has been already
applied to stable/linux-5.13.y, this is a backport with conflicts resolved
for v5.4 and v5.10 (The code fixed here was introduced after v4.19)
---
drivers/firmware/arm_scmi/driver.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 48e6e2b48924..4e43bdfa041f 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -515,8 +515,12 @@ int scmi_do_xfer_with_response(const struct scmi_handle *handle,
xfer->async_done = &async_response;
ret = scmi_do_xfer(handle, xfer);
- if (!ret && !wait_for_completion_timeout(xfer->async_done, timeout))
- ret = -ETIMEDOUT;
+ if (!ret) {
+ if (!wait_for_completion_timeout(xfer->async_done, timeout))
+ ret = -ETIMEDOUT;
+ else if (xfer->hdr.status)
+ ret = scmi_to_linux_errno(xfer->hdr.status);
+ }
xfer->async_done = NULL;
return ret;
--
2.17.1
On Thu, Aug 05, 2021 at 04:23:40PM -0700, Nick Desaulniers wrote:
> On Thu, Aug 5, 2021 at 1:24 PM kernel test robot <lkp(a)intel.com> wrote:
> >
> > Hi Nick,
> >
> > First bad commit (maybe != root cause):
> >
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> > head: 7457eed4b647560ae1b1800c295efc5f1db22e4b
> > commit: 7c29fd831799d09474dfdae556207b7102647a45 [1181/1498] lib/string.c: implement stpcpy
> > config: x86_64-randconfig-r024-20210805 (attached as .config)
> > compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 31a71a393f65d9e07b5b0756fef9dd16690950ee)
> > reproduce (this is a W=1 build):
> > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/…
> > git remote add linux-stable-rc https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > git fetch --no-tags linux-stable-rc linux-4.19.y
> > git checkout 7c29fd831799d09474dfdae556207b7102647a45
> > # save the attached .config to linux build tree
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot <lkp(a)intel.com>
> >
> > All errors (new ones prefixed by >>):
> >
> > >> ERROR: "__compiletime_assert_491" [drivers/gpu/drm/i915/i915.ko] undefined!
>
> ^ I'm actively trying to improve these diagnostics in LLVM at the
> moment. Hopefully that will make this report clearer!
> https://reviews.llvm.org/D106030
It does help :)
drivers/gpu/drm/i915/intel_engine_cs.c:466:2: error: call to '__compiletime_assert_491' declared with attribute error: BUILD_BUG_ON failed: (execlists_num_ports(execlists)) == 0 || (((execlists_num_ports(execlists)) & ((execlists_num_ports(execlists)) - 1)) != 0)
BUILD_BUG_ON_NOT_POWER_OF_2(execlists_num_ports(execlists));
^
include/linux/build_bug.h:21:2: note: expanded from macro 'BUILD_BUG_ON_NOT_POWER_OF_2'
BUILD_BUG_ON((n) == 0 || (((n) & ((n) - 1)) != 0))
^
include/linux/build_bug.h:69:2: note: expanded from macro 'BUILD_BUG_ON'
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^
include/linux/build_bug.h:45:37: note: expanded from macro 'BUILD_BUG_ON_MSG'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^
note: (skipping 1 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
include/linux/compiler.h:336:2: note: expanded from macro '_compiletime_assert'
__compiletime_assert(condition, msg, prefix, suffix)
^
include/linux/compiler.h:329:4: note: expanded from macro '__compiletime_assert'
prefix ## suffix(); \
^
<scratch space>:83:1: note: expanded from here
__compiletime_assert_491
^
4 warnings and 1 error generated.
As it turns out, this has come up before and it was fixed by commit
410ed5731a65 ("drm/i915: Ensure intel_engine_init_execlist() builds with
Clang").
Greg and Sasha, could this be picked up for 4.19?
Cheers,
Nathan