The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 10cea23b6aae15e8324f4101d785687f2c514fe5 Mon Sep 17 00:00:00 2001
From: YueHaibing <yuehaibing(a)huawei.com>
Date: Thu, 26 Mar 2020 11:26:18 +0800
Subject: [PATCH] misc: rtsx: set correct pcr_ops for rts522A
rts522a should use rts522a_pcr_ops, which is
diffrent with rts5227 in phy/hw init setting.
Fixes: ce6a5acc9387 ("mfd: rtsx: Add support for rts522A")
Signed-off-by: YueHaibing <yuehaibing(a)huawei.com>
Cc: stable <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/20200326032618.20472-1-yuehaibing@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/misc/cardreader/rts5227.c b/drivers/misc/cardreader/rts5227.c
index 423fecc19fc4..3a9467aaa435 100644
--- a/drivers/misc/cardreader/rts5227.c
+++ b/drivers/misc/cardreader/rts5227.c
@@ -394,6 +394,7 @@ static const struct pcr_ops rts522a_pcr_ops = {
void rts522a_init_params(struct rtsx_pcr *pcr)
{
rts5227_init_params(pcr);
+ pcr->ops = &rts522a_pcr_ops;
pcr->tx_initial_phase = SET_CLOCK_PHASE(20, 20, 11);
pcr->reg_pm_ctrl3 = RTS522A_PM_CTRL3;
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 10cea23b6aae15e8324f4101d785687f2c514fe5 Mon Sep 17 00:00:00 2001
From: YueHaibing <yuehaibing(a)huawei.com>
Date: Thu, 26 Mar 2020 11:26:18 +0800
Subject: [PATCH] misc: rtsx: set correct pcr_ops for rts522A
rts522a should use rts522a_pcr_ops, which is
diffrent with rts5227 in phy/hw init setting.
Fixes: ce6a5acc9387 ("mfd: rtsx: Add support for rts522A")
Signed-off-by: YueHaibing <yuehaibing(a)huawei.com>
Cc: stable <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/20200326032618.20472-1-yuehaibing@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/misc/cardreader/rts5227.c b/drivers/misc/cardreader/rts5227.c
index 423fecc19fc4..3a9467aaa435 100644
--- a/drivers/misc/cardreader/rts5227.c
+++ b/drivers/misc/cardreader/rts5227.c
@@ -394,6 +394,7 @@ static const struct pcr_ops rts522a_pcr_ops = {
void rts522a_init_params(struct rtsx_pcr *pcr)
{
rts5227_init_params(pcr);
+ pcr->ops = &rts522a_pcr_ops;
pcr->tx_initial_phase = SET_CLOCK_PHASE(20, 20, 11);
pcr->reg_pm_ctrl3 = RTS522A_PM_CTRL3;
Having spent some time with DBG_FORCE_RELOC == FORCE_CPU_RELOC, it
appears that our memory barriers around the clflush are lackluster for
our more seldom used paths. Seldom used does not mean never, so apply
the memory barriers or else we may randomly see incorrect relocation
addresses inside batches.
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 230ba1aee355..d9ab517bbce9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1037,6 +1037,8 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
void *vaddr;
if (cache->vaddr) {
+ if (cache->vaddr & CLFLUSH_AFTER)
+ mb();
kunmap_atomic(unmask_page(cache->vaddr));
} else {
unsigned int flushes;
@@ -1051,14 +1053,15 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
cache->vaddr = flushes | KMAP;
cache->node.mm = (void *)obj;
- if (flushes)
- mb();
}
vaddr = kmap_atomic(i915_gem_object_get_dirty_page(obj, page));
cache->vaddr = unmask_flags(cache->vaddr) | (unsigned long)vaddr;
cache->page = page;
+ if (cache->vaddr & CLFLUSH_BEFORE)
+ mb();
+
return vaddr;
}
@@ -1163,8 +1166,10 @@ static void clflush_write32(u32 *addr, u32 value, unsigned int flushes)
* mb barriers at the start and end of the relocation phase
* to ensure ordering of clflush wrt to the system.
*/
- if (flushes & CLFLUSH_AFTER)
+ if (flushes & CLFLUSH_AFTER) {
+ mb();
clflushopt(addr);
+ }
} else
*addr = value;
}
--
2.20.1
Hi all,
I've been running some tests on Debian 8 (which uses a 3.16.XX
kernel), and saw that my system would occasionally reboot when
performing an EFI variables dump. I did some digging and saw that this
problem first appeared in 4.4.110 and was fixed by Pavel Tatashin in
commit 7ec5d87df34a. At the same time, 4.9.XX, 4.14.XX and mainline
have commit 67a9108ed431, which also solves the issue. However, the
3.16 stable line doesn't seem to have either fix, and therefore the
crash is still there.
I don't know whether any distros use 3.16 other than Debian, but it'd
still be good to have this fix backported as well.
Whenever we get an -EFAULT, we failed to read in guest 2 physical
address space. Such addressing exceptions are reported via a program
intercept to the nested hypervisor.
We faked the intercept, we have to return to guest 2. Instead, right
now we would be returning -EFAULT from the intercept handler, eventually
crashing the VM.
Addressing exceptions can only happen if the g2->g3 page tables
reference invalid g2 addresses (say, either a table or the final page is
not accessible - so something that basically never happens in sane
environments.
Identified by manual code inspection.
Fixes: a3508fbe9dc6 ("KVM: s390: vsie: initial support for nested virtualization")
Cc: <stable(a)vger.kernel.org> # v4.8+
Signed-off-by: David Hildenbrand <david(a)redhat.com>
---
arch/s390/kvm/vsie.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
index 076090f9e666..4f6c22d72072 100644
--- a/arch/s390/kvm/vsie.c
+++ b/arch/s390/kvm/vsie.c
@@ -1202,6 +1202,7 @@ static int vsie_run(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
scb_s->iprcc = PGM_ADDRESSING;
scb_s->pgmilc = 4;
scb_s->gpsw.addr = __rewind_psw(scb_s->gpsw, 4);
+ rc = 1;
}
return rc;
}
--
2.25.1
When CONFIG_DEVFREQ_THERMAL is disabled all functions except
of_devfreq_cooling_register_power() were already inlined. Also inline
the last function to avoid compile errors when multiple drivers call
of_devfreq_cooling_register_power() when CONFIG_DEVFREQ_THERMAL is not
set. Compilation failed with the following message:
multiple definition of `of_devfreq_cooling_register_power'
(which then lists all usages of of_devfreq_cooling_register_power())
Thomas Zimmermann reported this problem [0] on a kernel config with
CONFIG_DRM_LIMA={m,y}, CONFIG_DRM_PANFROST={m,y} and
CONFIG_DEVFREQ_THERMAL=n after both, the lima and panfrost drivers
gained devfreq cooling support.
[0] https://www.spinics.net/lists/dri-devel/msg252825.html
Fixes: a76caf55e5b356 ("thermal: Add devfreq cooling")
Cc: stable(a)vger.kernel.org
Reported-by: Thomas Zimmermann <tzimmermann(a)suse.de>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com>
---
include/linux/devfreq_cooling.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/devfreq_cooling.h b/include/linux/devfreq_cooling.h
index 4635f95000a4..79a6e37a1d6f 100644
--- a/include/linux/devfreq_cooling.h
+++ b/include/linux/devfreq_cooling.h
@@ -75,7 +75,7 @@ void devfreq_cooling_unregister(struct thermal_cooling_device *dfc);
#else /* !CONFIG_DEVFREQ_THERMAL */
-struct thermal_cooling_device *
+static inline struct thermal_cooling_device *
of_devfreq_cooling_register_power(struct device_node *np, struct devfreq *df,
struct devfreq_cooling_power *dfc_power)
{
--
2.26.0
Hello stable team, Greg,
On Mon, Apr 06, 2020 at 06:06:29PM +0900, Takashi Kanamaru wrote:
> Dear Sean Young and all,
>
> In the last year, a change of the value of LIRCBUF_SIZE
> from 256 to 1024 was committed to the master branch at the time,
> and the new value can be used in the kernel 5.3 or later.
>
> https://github.com/torvalds/linux/commit/5c4c8b4a999019f19e770cb55cbacb89c9…
>
> This change of LIRCBUF_SIZE was proposed
> in order to treat long IR sequences of remote controllers
> on Raspberry Pi.
>
> However, Raspberry Pi now uses kernel 4.19,
> so the new value cannot be used.
>
> Can you backport the above commit
> to the older kernels, i.e.,
> 4.19, 4.20, 5.0, 5.1, and 5.2?
I'd like to propose this commit for the stable tree, from kernel 4.16 to
5.2. It has been in the tree from v5.3 onwards and no regressions have
been found.
Thank you,
Sean
> Sincerely,
>
> Takashi Kanamaru
>
> 2019年6月13日(木) 17:49 Sean Young <sean(a)mess.org>:
> >
> > The IR signal to control the Panasonic ACXA75C00600 air conditioner has
> > 439 pulse/spaces. Increase limit to make it possible to transmit signal.
> >
> > Reported-by: Takashi Kanamaru <neuralassembly(a)gmail.com>
> > Signed-off-by: Sean Young <sean(a)mess.org>
> > ---
> > drivers/media/rc/lirc_dev.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
> > index 10830605c734..f078f8a3aec8 100644
> > --- a/drivers/media/rc/lirc_dev.c
> > +++ b/drivers/media/rc/lirc_dev.c
> > @@ -19,7 +19,7 @@
> > #include "rc-core-priv.h"
> > #include <uapi/linux/lirc.h>
> >
> > -#define LIRCBUF_SIZE 256
> > +#define LIRCBUF_SIZE 1024
> >
> > static dev_t lirc_base_dev;
> >
> > --
> > 2.20.1
> >