This is a note to let you know that I've just added the patch titled
iwlwifi: fix min API version for 7265D, 3168, 8000 and 8265
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
iwlwifi-fix-min-api-version-for-7265d-3168-8000-and-8265.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Luca Coelho <luciano.coelho(a)intel.com>
Date: Tue, 25 Apr 2017 10:18:10 +0300
Subject: iwlwifi: fix min API version for 7265D, 3168, 8000 and 8265
From: Luca Coelho <luciano.coelho(a)intel.com>
[ Upstream commit 15098803d38778070b8edfa5a3d5fc4fef10d0a1 ]
In a previous commit, we removed support for API versions earlier than
22 for these NICs. By mistake, the *_UCODE_API_MIN definitions were
set to 17. Fix that.
Fixes: 4b87e5af638b ("iwlwifi: remove support for fw older than -17 and -22")
Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/intel/iwlwifi/iwl-7000.c | 4 ++--
drivers/net/wireless/intel/iwlwifi/iwl-8000.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/net/wireless/intel/iwlwifi/iwl-7000.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-7000.c
@@ -79,8 +79,8 @@
/* Lowest firmware API version supported */
#define IWL7260_UCODE_API_MIN 17
#define IWL7265_UCODE_API_MIN 17
-#define IWL7265D_UCODE_API_MIN 17
-#define IWL3168_UCODE_API_MIN 20
+#define IWL7265D_UCODE_API_MIN 22
+#define IWL3168_UCODE_API_MIN 22
/* NVM versions */
#define IWL7260_NVM_VERSION 0x0a1d
--- a/drivers/net/wireless/intel/iwlwifi/iwl-8000.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-8000.c
@@ -74,8 +74,8 @@
#define IWL8265_UCODE_API_MAX 26
/* Lowest firmware API version supported */
-#define IWL8000_UCODE_API_MIN 17
-#define IWL8265_UCODE_API_MIN 20
+#define IWL8000_UCODE_API_MIN 22
+#define IWL8265_UCODE_API_MIN 22
/* NVM versions */
#define IWL8000_NVM_VERSION 0x0a1d
Patches currently in stable-queue which might be from luciano.coelho(a)intel.com are
queue-4.9/iwlwifi-mvm-fix-command-queue-number-on-d0i3-flow.patch
queue-4.9/iwlwifi-tt-move-ucode_loaded-check-under-mutex.patch
queue-4.9/iwlwifi-fix-min-api-version-for-7265d-3168-8000-and-8265.patch
queue-4.9/iwlwifi-mvm-fix-firmware-debug-restart-recording.patch
queue-4.9/mac80211-bail-out-from-prep_connection-if-a-reconfig-is-ongoing.patch
queue-4.9/iwlwifi-pcie-only-use-d0i3-in-suspend-resume-if-system_pm-is-set-to-d0i3.patch
This is a note to let you know that I've just added the patch titled
irqchip/mbigen: Fix the clear register offset calculation
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
irqchip-mbigen-fix-the-clear-register-offset-calculation.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: MaJun <majun258(a)huawei.com>
Date: Fri, 12 May 2017 11:55:28 +0800
Subject: irqchip/mbigen: Fix the clear register offset calculation
From: MaJun <majun258(a)huawei.com>
[ Upstream commit 9459a04b6a5a09967eec94a1b66f0a74312819d9 ]
The register array offset for clearing an interrupt is calculated by:
offset = (hwirq - RESERVED_IRQ_PER_MBIGEN_CHIP) / 32;
This is wrong because the clear register array includes the reserved
interrupts. So the clear operation ends up in the wrong register.
This went unnoticed so far, because the hardware clears the real bit
through a timeout mechanism when the hardware is configured in debug
mode. That debug mode was enabled on early generations of the hardware, so
the problem was papered over.
On newer hardware with updated firmware the debug mode was disabled, so the
bits did not get cleared which causes the system to malfunction.
Remove the subtraction of RESERVED_IRQ_PER_MBIGEN_CHIP, so the correct
register is accessed.
[ tglx: Rewrote changelog ]
Fixes: a6c2f87b8820 ("irqchip/mbigen: Implement the mbigen irq chip operation functions")
Signed-off-by: MaJun <majun258(a)huawei.com>
Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org>
Acked-by: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com>
Cc: linuxarm(a)huawei.com
Cc: Wei Yongjun <weiyongjun1(a)huawei.com>
Link: http://lkml.kernel.org/r/1494561328-39514-4-git-send-email-guohanjun@huawei…
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/irq-mbigen.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -105,10 +105,7 @@ static inline void get_mbigen_type_reg(i
static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq,
u32 *mask, u32 *addr)
{
- unsigned int ofst;
-
- hwirq -= RESERVED_IRQ_PER_MBIGEN_CHIP;
- ofst = hwirq / 32 * 4;
+ unsigned int ofst = (hwirq / 32) * 4;
*mask = 1 << (hwirq % 32);
*addr = ofst + REG_MBIGEN_CLEAR_OFFSET;
Patches currently in stable-queue which might be from majun258(a)huawei.com are
queue-4.9/irqchip-mbigen-fix-the-clear-register-offset-calculation.patch
This is a note to let you know that I've just added the patch titled
ipv6: avoid dad-failures for addresses with NODAD
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipv6-avoid-dad-failures-for-addresses-with-nodad.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Mahesh Bandewar <maheshb(a)google.com>
Date: Fri, 12 May 2017 17:03:39 -0700
Subject: ipv6: avoid dad-failures for addresses with NODAD
From: Mahesh Bandewar <maheshb(a)google.com>
[ Upstream commit 66eb9f86e50547ec2a8ff7a75997066a74ef584b ]
Every address gets added with TENTATIVE flag even for the addresses with
IFA_F_NODAD flag and dad-work is scheduled for them. During this DAD process
we realize it's an address with NODAD and complete the process without
sending any probe. However the TENTATIVE flags stays on the
address for sometime enough to cause misinterpretation when we receive a NS.
While processing NS, if the address has TENTATIVE flag, we mark it DADFAILED
and endup with an address that was originally configured as NODAD with
DADFAILED.
We can't avoid scheduling dad_work for addresses with NODAD but we can
avoid adding TENTATIVE flag to avoid this racy situation.
Signed-off-by: Mahesh Bandewar <maheshb(a)google.com>
Acked-by: David Ahern <dsahern(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/addrconf.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -988,7 +988,10 @@ ipv6_add_addr(struct inet6_dev *idev, co
INIT_HLIST_NODE(&ifa->addr_lst);
ifa->scope = scope;
ifa->prefix_len = pfxlen;
- ifa->flags = flags | IFA_F_TENTATIVE;
+ ifa->flags = flags;
+ /* No need to add the TENTATIVE flag for addresses with NODAD */
+ if (!(flags & IFA_F_NODAD))
+ ifa->flags |= IFA_F_TENTATIVE;
ifa->valid_lft = valid_lft;
ifa->prefered_lft = prefered_lft;
ifa->cstamp = ifa->tstamp = jiffies;
Patches currently in stable-queue which might be from maheshb(a)google.com are
queue-4.9/bonding-don-t-update-slave-link-until-ready-to-commit.patch
queue-4.9/ipv6-avoid-dad-failures-for-addresses-with-nodad.patch
This is a note to let you know that I've just added the patch titled
irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
irqchip-gic-v3-fix-the-driver-probe-fail-due-to-disabled-gicc-entry.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Shanker Donthineni <shankerd(a)codeaurora.org>
Date: Tue, 5 Dec 2017 13:16:21 -0600
Subject: irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry
From: Shanker Donthineni <shankerd(a)codeaurora.org>
[ Upstream commit ebe2f8718007d5a1238bb3cb8141b5bb2b4d5773 ]
The ACPI specification says OS shouldn't attempt to use GICC configuration
parameters if the flag ACPI_MADT_ENABLED is cleared. The ARM64-SMP code
skips the disabled GICC entries but not causing any issue. However the
current GICv3 driver probe bails out causing kernel panic() instead of
skipping the disabled GICC interfaces. This issue happens on systems
where redistributor regions are not in the always-on power domain and
one of GICC interface marked with ACPI_MADT_ENABLED=0.
This patch does the two things to fix the panic.
- Don't return an error in gic_acpi_match_gicc() for disabled GICC entry.
- No need to keep GICR region information for disabled GICC entry.
Observed kernel crash on QDF2400 platform GICC entry is disabled.
Kernel crash traces:
Kernel panic - not syncing: No interrupt controller found.
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.13.5 #26
[<ffff000008087770>] dump_backtrace+0x0/0x218
[<ffff0000080879dc>] show_stack+0x14/0x20
[<ffff00000883b078>] dump_stack+0x98/0xb8
[<ffff0000080c5c14>] panic+0x118/0x26c
[<ffff000008b62348>] init_IRQ+0x24/0x2c
[<ffff000008b609fc>] start_kernel+0x230/0x394
[<ffff000008b601e4>] __primary_switched+0x64/0x6c
---[ end Kernel panic - not syncing: No interrupt controller found.
Disabled GICC subtable example:
Subtable Type : 0B [Generic Interrupt Controller]
Length : 50
Reserved : 0000
CPU Interface Number : 0000003D
Processor UID : 0000003D
Flags (decoded below) : 00000000
Processor Enabled : 0
Performance Interrupt Trig Mode : 0
Virtual GIC Interrupt Trig Mode : 0
Parking Protocol Version : 00000000
Performance Interrupt : 00000017
Parked Address : 0000000000000000
Base Address : 0000000000000000
Virtual GIC Base Address : 0000000000000000
Hypervisor GIC Base Address : 0000000000000000
Virtual GIC Interrupt : 00000019
Redistributor Base Address : 0000FFFF88F40000
ARM MPIDR : 000000000000000D
Efficiency Class : 00
Reserved : 000000
Signed-off-by: Shanker Donthineni <shankerd(a)codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -1250,6 +1250,10 @@ gic_acpi_parse_madt_gicc(struct acpi_sub
u32 size = reg == GIC_PIDR2_ARCH_GICv4 ? SZ_64K * 4 : SZ_64K * 2;
void __iomem *redist_base;
+ /* GICC entry which has !ACPI_MADT_ENABLED is not unusable so skip */
+ if (!(gicc->flags & ACPI_MADT_ENABLED))
+ return 0;
+
redist_base = ioremap(gicc->gicr_base_address, size);
if (!redist_base)
return -ENOMEM;
@@ -1299,6 +1303,13 @@ static int __init gic_acpi_match_gicc(st
if ((gicc->flags & ACPI_MADT_ENABLED) && gicc->gicr_base_address)
return 0;
+ /*
+ * It's perfectly valid firmware can pass disabled GICC entry, driver
+ * should not treat as errors, skip the entry instead of probe fail.
+ */
+ if (!(gicc->flags & ACPI_MADT_ENABLED))
+ return 0;
+
return -ENODEV;
}
Patches currently in stable-queue which might be from shankerd(a)codeaurora.org are
queue-4.9/irqchip-gic-v3-fix-the-driver-probe-fail-due-to-disabled-gicc-entry.patch
This is a note to let you know that I've just added the patch titled
ipmr: vrf: Find VIFs using the actual device
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipmr-vrf-find-vifs-using-the-actual-device.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Thomas Winter <Thomas.Winter(a)alliedtelesis.co.nz>
Date: Tue, 16 May 2017 10:14:44 +1200
Subject: ipmr: vrf: Find VIFs using the actual device
From: Thomas Winter <Thomas.Winter(a)alliedtelesis.co.nz>
[ Upstream commit bcfc7d33110b0f33069d74138eeb7ca9acbb3c85 ]
The skb->dev that is passed into ip_mr_input is
the loX device for VRFs. When we lookup a vif
for this dev, none is found as we do not create
vifs for loopbacks. Instead lookup a vif for the
actual device that the packet was received on,
eg the vlan.
Signed-off-by: Thomas Winter <Thomas.Winter(a)alliedtelesis.co.nz>
cc: David Ahern <dsa(a)cumulusnetworks.com>
cc: Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com>
cc: roopa <roopa(a)cumulusnetworks.com>
Acked-by: David Ahern <dsahern(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ipmr.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1929,6 +1929,20 @@ int ip_mr_input(struct sk_buff *skb)
struct net *net = dev_net(skb->dev);
int local = skb_rtable(skb)->rt_flags & RTCF_LOCAL;
struct mr_table *mrt;
+ struct net_device *dev;
+
+ /* skb->dev passed in is the loX master dev for vrfs.
+ * As there are no vifs associated with loopback devices,
+ * get the proper interface that does have a vif associated with it.
+ */
+ dev = skb->dev;
+ if (netif_is_l3_master(skb->dev)) {
+ dev = dev_get_by_index_rcu(net, IPCB(skb)->iif);
+ if (!dev) {
+ kfree_skb(skb);
+ return -ENODEV;
+ }
+ }
/* Packet is looped back after forward, it should not be
* forwarded second time, but still can be delivered locally.
@@ -1966,7 +1980,7 @@ int ip_mr_input(struct sk_buff *skb)
/* already under rcu_read_lock() */
cache = ipmr_cache_find(mrt, ip_hdr(skb)->saddr, ip_hdr(skb)->daddr);
if (!cache) {
- int vif = ipmr_find_vif(mrt, skb->dev);
+ int vif = ipmr_find_vif(mrt, dev);
if (vif >= 0)
cache = ipmr_cache_find_any(mrt, ip_hdr(skb)->daddr,
@@ -1986,7 +2000,7 @@ int ip_mr_input(struct sk_buff *skb)
}
read_lock(&mrt_lock);
- vif = ipmr_find_vif(mrt, skb->dev);
+ vif = ipmr_find_vif(mrt, dev);
if (vif >= 0) {
int err2 = ipmr_cache_unresolved(mrt, vif, skb);
read_unlock(&mrt_lock);
Patches currently in stable-queue which might be from Thomas.Winter(a)alliedtelesis.co.nz are
queue-4.9/ipmr-vrf-find-vifs-using-the-actual-device.patch
This is a note to let you know that I've just added the patch titled
ip6_tunnel: fix traffic class routing for tunnels
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ip6_tunnel-fix-traffic-class-routing-for-tunnels.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Liam McBirnie <mcbirnie.l(a)gmail.com>
Date: Thu, 1 Jun 2017 15:36:01 +1000
Subject: ip6_tunnel: fix traffic class routing for tunnels
From: Liam McBirnie <mcbirnie.l(a)gmail.com>
[ Upstream commit 5f733ee68f9a4df94775299ac6a7ab260704f6ed ]
ip6_route_output() requires that the flowlabel contains the traffic
class for policy routing.
Commit 0e9a709560db ("ip6_tunnel, ip6_gre: fix setting of DSCP on
encapsulated packets") removed the code which previously added the
traffic class to the flowlabel.
The traffic class is added here because only route lookup needs the
flowlabel to contain the traffic class.
Fixes: 0e9a709560db ("ip6_tunnel, ip6_gre: fix setting of DSCP on encapsulated packets")
Signed-off-by: Liam McBirnie <liam.mcbirnie(a)boeing.com>
Acked-by: Peter Dawson <peter.a.dawson(a)boeing.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_tunnel.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1097,6 +1097,9 @@ int ip6_tnl_xmit(struct sk_buff *skb, st
if (!dst) {
route_lookup:
+ /* add dsfield to flowlabel for route lookup */
+ fl6->flowlabel = ip6_make_flowinfo(dsfield, fl6->flowlabel);
+
dst = ip6_route_output(net, NULL, fl6);
if (dst->error)
Patches currently in stable-queue which might be from mcbirnie.l(a)gmail.com are
queue-4.9/ip6_tunnel-fix-traffic-class-routing-for-tunnels.patch
This is a note to let you know that I've just added the patch titled
ipmi_ssif: unlock on allocation failure
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipmi_ssif-unlock-on-allocation-failure.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Fri, 5 May 2017 08:33:24 +0300
Subject: ipmi_ssif: unlock on allocation failure
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit cf9806f32ef63b745f2486e0dbb2ac21f4ca44f0 ]
We should unlock and re-enable IRQs if this allocation fails.
Fixes: 259307074bfc ("ipmi: Add SMBus interface driver (SSIF) ")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Corey Minyard <cminyard(a)mvista.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/char/ipmi/ipmi_ssif.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/char/ipmi/ipmi_ssif.c
+++ b/drivers/char/ipmi/ipmi_ssif.c
@@ -409,6 +409,7 @@ static void start_event_fetch(struct ssi
msg = ipmi_alloc_smi_msg();
if (!msg) {
ssif_info->ssif_state = SSIF_NORMAL;
+ ipmi_ssif_unlock_cond(ssif_info, flags);
return;
}
@@ -431,6 +432,7 @@ static void start_recv_msg_fetch(struct
msg = ipmi_alloc_smi_msg();
if (!msg) {
ssif_info->ssif_state = SSIF_NORMAL;
+ ipmi_ssif_unlock_cond(ssif_info, flags);
return;
}
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/block-fix-an-error-code-in-add_partition.patch
queue-4.9/x.509-fix-error-code-in-x509_cert_parse.patch
queue-4.9/rdma-iw_cxgb4-avoid-touch-after-free-error-in-arp-failure-handlers.patch
queue-4.9/drm-amdkfd-null-dereference-involving-create_process.patch
queue-4.9/pnfs-flexfiles-missing-error-code-in-ff_layout_alloc_lseg.patch
queue-4.9/drivers-misc-vmw_vmci-vmci_queue_pair.c-fix-a-couple-integer-overflow-tests.patch
queue-4.9/cxl-unlock-on-error-in-probe.patch
queue-4.9/md-cluster-fix-potential-lock-issue-in-add_new_disk.patch
queue-4.9/ipmi_ssif-unlock-on-allocation-failure.patch
queue-4.9/powercap-fix-an-error-code-in-powercap_register_zone.patch
queue-4.9/perf-core-fix-error-handling-in-perf_event_alloc.patch
queue-4.9/libceph-null-deref-on-crush_decode-error-path.patch
This is a note to let you know that I've just added the patch titled
Input: elantech - force relative mode on a certain module
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
input-elantech-force-relative-mode-on-a-certain-module.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: KT Liao <kt.liao(a)emc.com.tw>
Date: Mon, 12 Dec 2016 11:03:42 -0800
Subject: Input: elantech - force relative mode on a certain module
From: KT Liao <kt.liao(a)emc.com.tw>
[ Upstream commit d899520b0431e70279bfb5066ecb6dc91d0b7072 ]
One of Elan modules with sample version is 0x74 and hw_version is 0x03 has
a bug in absolute mode implementation, so let it run in default PS/2
relative mode.
Signed-off-by: KT Liao <kt.liao(a)emc.com.tw>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/input/mouse/elantech.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1711,6 +1711,17 @@ int elantech_init(struct psmouse *psmous
etd->samples[0], etd->samples[1], etd->samples[2]);
}
+ if (etd->samples[1] == 0x74 && etd->hw_version == 0x03) {
+ /*
+ * This module has a bug which makes absolute mode
+ * unusable, so let's abort so we'll be using standard
+ * PS/2 protocol.
+ */
+ psmouse_info(psmouse,
+ "absolute mode broken, forcing standard PS/2 protocol\n");
+ goto init_fail;
+ }
+
if (elantech_set_absolute_mode(psmouse)) {
psmouse_err(psmouse,
"failed to put touchpad into absolute mode.\n");
Patches currently in stable-queue which might be from kt.liao(a)emc.com.tw are
queue-4.9/input-elantech-force-relative-mode-on-a-certain-module.patch
queue-4.9/input-elan_i2c-clear-int-before-resetting-controller.patch
This is a note to let you know that I've just added the patch titled
Input: goodix - disable IRQs while suspended
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
input-goodix-disable-irqs-while-suspended.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Fri, 12 Jan 2018 00:36:48 -0800
Subject: Input: goodix - disable IRQs while suspended
From: Hans de Goede <hdegoede(a)redhat.com>
[ Upstream commit faec44b6838312484d63e82286087cf2d5ebb891 ]
We should not try to do any i2c transfers before the controller is
resumed (which happens before our resume method gets called).
So we need to disable our IRQ while suspended to enforce this. The
code paths for devices with GPIOs for the int and reset pins already
disable the IRQ the through goodix_free_irq().
This commit also disables the IRQ while suspended for devices without
GPIOs for the int and reset pins.
This fixes the i2c bus sometimes getting stuck after a suspend/resume
causing the touchscreen to sometimes not work after a suspend/resume.
This has been tested on a GPD pocked device.
BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10
BugLink: https://www.reddit.com/r/GPDPocket/comments/7niut2/fix_for_broken_touch_aft…
Tested-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Reviewed-by: Bastien Nocera <hadess(a)hadess.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/input/touchscreen/goodix.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -778,8 +778,10 @@ static int __maybe_unused goodix_suspend
int error;
/* We need gpio pins to suspend/resume */
- if (!ts->gpiod_int || !ts->gpiod_rst)
+ if (!ts->gpiod_int || !ts->gpiod_rst) {
+ disable_irq(client->irq);
return 0;
+ }
wait_for_completion(&ts->firmware_loading_complete);
@@ -819,8 +821,10 @@ static int __maybe_unused goodix_resume(
struct goodix_ts_data *ts = i2c_get_clientdata(client);
int error;
- if (!ts->gpiod_int || !ts->gpiod_rst)
+ if (!ts->gpiod_int || !ts->gpiod_rst) {
+ enable_irq(client->irq);
return 0;
+ }
/*
* Exit sleep mode by outputting HIGH level to INT pin
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.9/gpio-crystalcove-do-not-write-regular-gpio-registers-for-virtual-gpios.patch
queue-4.9/acpi-video-default-lcd_only-to-true-on-win8-ready-and-newer-machines.patch
queue-4.9/hid-i2c-call-acpi_device_fix_up_power-for-acpi-enumerated-devices.patch
queue-4.9/ata-libahci-properly-propagate-return-value-of-platform_get_irq.patch
queue-4.9/input-goodix-disable-irqs-while-suspended.patch
queue-4.9/asoc-intel-cht_bsw_rt5645-analog-mic-support.patch
queue-4.9/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch