- Linux-stable-mirror - lists.linaro.org

Patch "irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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

7 years, 5 months

1
0
0 0

Patch "ipmr: vrf: Find VIFs using the actual device" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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

7 years, 5 months

1
0
0 0

Patch "ipsec: check return value of skb_to_sgvec always" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ipsec: check return value of skb_to_sgvec always 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: ipsec-check-return-value-of-skb_to_sgvec-always.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 3f29770723fe498a5c5f57c3a31a996ebdde03e1 Mon Sep 17 00:00:00 2001 From: "Jason A. Donenfeld" <Jason(a)zx2c4.com> Date: Sun, 4 Jun 2017 04:16:23 +0200 Subject: ipsec: check return value of skb_to_sgvec always From: Jason A. Donenfeld <Jason(a)zx2c4.com> commit 3f29770723fe498a5c5f57c3a31a996ebdde03e1 upstream. Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> Cc: Steffen Klassert <steffen.klassert(a)secunet.com> Cc: Herbert Xu <herbert(a)gondor.apana.org.au> Cc: "David S. Miller" <davem(a)davemloft.net> Signed-off-by: David S. Miller <davem(a)davemloft.net> [natechancellor: Adjusted context due to lack of fca11ebde3f0] Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv4/ah4.c | 8 ++++++-- net/ipv4/esp4.c | 13 ++++++++----- net/ipv6/ah6.c | 8 ++++++-- net/ipv6/esp6.c | 12 ++++++++---- 4 files changed, 28 insertions(+), 13 deletions(-) --- a/net/ipv4/ah4.c +++ b/net/ipv4/ah4.c @@ -220,7 +220,9 @@ static int ah_output(struct xfrm_state * ah->seq_no = htonl(XFRM_SKB_CB(skb)->seq.output.low); sg_init_table(sg, nfrags + sglists); - skb_to_sgvec_nomark(skb, sg, 0, skb->len); + err = skb_to_sgvec_nomark(skb, sg, 0, skb->len); + if (unlikely(err < 0)) + goto out_free; if (x->props.flags & XFRM_STATE_ESN) { /* Attach seqhi sg right after packet payload */ @@ -393,7 +395,9 @@ static int ah_input(struct xfrm_state *x skb_push(skb, ihl); sg_init_table(sg, nfrags + sglists); - skb_to_sgvec_nomark(skb, sg, 0, skb->len); + err = skb_to_sgvec_nomark(skb, sg, 0, skb->len); + if (unlikely(err < 0)) + goto out_free; if (x->props.flags & XFRM_STATE_ESN) { /* Attach seqhi sg right after packet payload */ --- a/net/ipv4/esp4.c +++ b/net/ipv4/esp4.c @@ -268,10 +268,11 @@ static int esp_output(struct xfrm_state esph->spi = x->id.spi; sg_init_table(sg, nfrags); - skb_to_sgvec(skb, sg, - (unsigned char *)esph - skb->data, - assoclen + ivlen + clen + alen); - + err = skb_to_sgvec(skb, sg, + (unsigned char *)esph - skb->data, + assoclen + ivlen + clen + alen); + if (unlikely(err < 0)) + goto error; aead_request_set_crypt(req, sg, sg, ivlen + clen, iv); aead_request_set_ad(req, assoclen); @@ -481,7 +482,9 @@ static int esp_input(struct xfrm_state * } sg_init_table(sg, nfrags); - skb_to_sgvec(skb, sg, 0, skb->len); + err = skb_to_sgvec(skb, sg, 0, skb->len); + if (unlikely(err < 0)) + goto out; aead_request_set_crypt(req, sg, sg, elen + ivlen, iv); aead_request_set_ad(req, assoclen); --- a/net/ipv6/ah6.c +++ b/net/ipv6/ah6.c @@ -423,7 +423,9 @@ static int ah6_output(struct xfrm_state ah->seq_no = htonl(XFRM_SKB_CB(skb)->seq.output.low); sg_init_table(sg, nfrags + sglists); - skb_to_sgvec_nomark(skb, sg, 0, skb->len); + err = skb_to_sgvec_nomark(skb, sg, 0, skb->len); + if (unlikely(err < 0)) + goto out_free; if (x->props.flags & XFRM_STATE_ESN) { /* Attach seqhi sg right after packet payload */ @@ -603,7 +605,9 @@ static int ah6_input(struct xfrm_state * ip6h->hop_limit = 0; sg_init_table(sg, nfrags + sglists); - skb_to_sgvec_nomark(skb, sg, 0, skb->len); + err = skb_to_sgvec_nomark(skb, sg, 0, skb->len); + if (unlikely(err < 0)) + goto out_free; if (x->props.flags & XFRM_STATE_ESN) { /* Attach seqhi sg right after packet payload */ --- a/net/ipv6/esp6.c +++ b/net/ipv6/esp6.c @@ -248,9 +248,11 @@ static int esp6_output(struct xfrm_state esph->spi = x->id.spi; sg_init_table(sg, nfrags); - skb_to_sgvec(skb, sg, - (unsigned char *)esph - skb->data, - assoclen + ivlen + clen + alen); + err = skb_to_sgvec(skb, sg, + (unsigned char *)esph - skb->data, + assoclen + ivlen + clen + alen); + if (unlikely(err < 0)) + goto error; aead_request_set_crypt(req, sg, sg, ivlen + clen, iv); aead_request_set_ad(req, assoclen); @@ -423,7 +425,9 @@ static int esp6_input(struct xfrm_state } sg_init_table(sg, nfrags); - skb_to_sgvec(skb, sg, 0, skb->len); + ret = skb_to_sgvec(skb, sg, 0, skb->len); + if (unlikely(ret < 0)) + goto out; aead_request_set_crypt(req, sg, sg, elen + ivlen, iv); aead_request_set_ad(req, assoclen); Patches currently in stable-queue which might be from Jason(a)zx2c4.com are queue-4.9/ipsec-check-return-value-of-skb_to_sgvec-always.patch queue-4.9/skbuff-return-emsgsize-in-skb_to_sgvec-to-prevent-overflow.patch queue-4.9/macsec-check-return-value-of-skb_to_sgvec-always.patch

7 years, 5 months

1
0
0 0

Patch "ip6_tunnel: fix traffic class routing for tunnels" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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

7 years, 5 months

1
0
0 0

Patch "ipmi_ssif: unlock on allocation failure" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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

7 years, 5 months

1
0
0 0

Patch "Input: elantech - force relative mode on a certain module" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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

7 years, 5 months

1
0
0 0

Patch "Input: goodix - disable IRQs while suspended" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

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

7 years, 5 months

1
0
0 0

Patch "Input: elan_i2c - clear INT before resetting controller" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Input: elan_i2c - clear INT before resetting controller 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-elan_i2c-clear-int-before-resetting-controller.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: Thu, 25 May 2017 10:06:21 -0700 Subject: Input: elan_i2c - clear INT before resetting controller From: KT Liao <kt.liao(a)emc.com.tw> [ Upstream commit 4b3c7dbbfff0673e8a89575414b864d8b001d3bb ] Some old touchpad FWs need to have interrupt cleared before issuing reset command after updating firmware. We clear interrupt by attempting to read full report from the controller, and discarding any data read. 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/elan_i2c_i2c.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- a/drivers/input/mouse/elan_i2c_i2c.c +++ b/drivers/input/mouse/elan_i2c_i2c.c @@ -557,7 +557,14 @@ static int elan_i2c_finish_fw_update(str long ret; int error; int len; - u8 buffer[ETP_I2C_INF_LENGTH]; + u8 buffer[ETP_I2C_REPORT_LEN]; + + len = i2c_master_recv(client, buffer, ETP_I2C_REPORT_LEN); + if (len != ETP_I2C_REPORT_LEN) { + error = len < 0 ? len : -EIO; + dev_warn(dev, "failed to read I2C data after FW WDT reset: %d (%d)\n", + error, len); + } reinit_completion(completion); enable_irq(client->irq); 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

7 years, 5 months

1
0
0 0

Patch "Input: elan_i2c - check if device is there before really probing" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Input: elan_i2c - check if device is there before really probing 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-elan_i2c-check-if-device-is-there-before-really-probing.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: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Date: Fri, 19 Dec 2014 12:57:49 -0800 Subject: Input: elan_i2c - check if device is there before really probing From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> [ Upstream commit c5928551fd41b2eecdad78fa2be2a4a13ed5fde9 ] Before trying to properly initialize the touchpad and generate bunch of errors, let's first see it there is anything at the given address. If we get error, fail silently with -ENXIO. Reviewed-by: Guenter Roeck <linux(a)roeck-us.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/mouse/elan_i2c_core.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/input/mouse/elan_i2c_core.c +++ b/drivers/input/mouse/elan_i2c_core.c @@ -1082,6 +1082,13 @@ static int elan_probe(struct i2c_client return error; } + /* Make sure there is something at this address */ + error = i2c_smbus_read_byte(client); + if (error < 0) { + dev_dbg(&client->dev, "nothing at this address: %d\n", error); + return -ENXIO; + } + /* Initialize the touchpad. */ error = elan_initialize(data); if (error) Patches currently in stable-queue which might be from dmitry.torokhov(a)gmail.com are queue-4.9/input-elantech-force-relative-mode-on-a-certain-module.patch queue-4.9/input-elan_i2c-check-if-device-is-there-before-really-probing.patch queue-4.9/input-goodix-disable-irqs-while-suspended.patch queue-4.9/input-elan_i2c-clear-int-before-resetting-controller.patch

7 years, 5 months

1
0
0 0

Patch "iio: light: rpr0521 poweroff for probe fails" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: light: rpr0521 poweroff for probe fails 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: iio-light-rpr0521-poweroff-for-probe-fails.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: Mikko Koivunen <mikko.koivunen(a)fi.rohmeurope.com> Date: Thu, 18 May 2017 15:12:50 +0300 Subject: iio: light: rpr0521 poweroff for probe fails From: Mikko Koivunen <mikko.koivunen(a)fi.rohmeurope.com> [ Upstream commit 12d74949133e2450533894ea01ce0c56646ce006 ] Set sensor measurement off after probe fail in pm_runtime_set_active() or iio_device_register(). Without this change sensor measurement stays on even though probe fails on these calls. This is maybe rare case, but causes constant power drain without any benefits when it happens. Power drain is 20-500uA, typically 180uA. Signed-off-by: Mikko Koivunen <mikko.koivunen(a)fi.rohmeurope.com> Acked-by: Daniel Baluta <daniel.baluta(a)nxp.com> Signed-off-by: Jonathan Cameron <jic23(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iio/light/rpr0521.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) --- a/drivers/iio/light/rpr0521.c +++ b/drivers/iio/light/rpr0521.c @@ -510,13 +510,26 @@ static int rpr0521_probe(struct i2c_clie ret = pm_runtime_set_active(&client->dev); if (ret < 0) - return ret; + goto err_poweroff; pm_runtime_enable(&client->dev); pm_runtime_set_autosuspend_delay(&client->dev, RPR0521_SLEEP_DELAY_MS); pm_runtime_use_autosuspend(&client->dev); - return iio_device_register(indio_dev); + ret = iio_device_register(indio_dev); + if (ret) + goto err_pm_disable; + + return 0; + +err_pm_disable: + pm_runtime_disable(&client->dev); + pm_runtime_set_suspended(&client->dev); + pm_runtime_put_noidle(&client->dev); +err_poweroff: + rpr0521_poweroff(data); + + return ret; } static int rpr0521_remove(struct i2c_client *client) Patches currently in stable-queue which might be from mikko.koivunen(a)fi.rohmeurope.com are queue-4.9/iio-light-rpr0521-poweroff-for-probe-fails.patch

7 years, 5 months

1
0
0 0

Patch "iio: magnetometer: st_magn_spi: fix spi_device_id table" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: magnetometer: st_magn_spi: fix spi_device_id table 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: iio-magnetometer-st_magn_spi-fix-spi_device_id-table.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: Lorenzo Bianconi <lorenzo.bianconi83(a)gmail.com> Date: Tue, 6 Jun 2017 22:51:24 +0200 Subject: iio: magnetometer: st_magn_spi: fix spi_device_id table From: Lorenzo Bianconi <lorenzo.bianconi83(a)gmail.com> [ Upstream commit c83761ff0aac954aa368c623bb0f0d1a3214e834 ] Remove LSM303DLHC, LSM303DLM from st_magn_id_table since LSM303DL series does not support spi interface Fixes: 872e79add756 (iio: magn: Add STMicroelectronics magn driver) Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi(a)st.com> Signed-off-by: Jonathan Cameron <jic23(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iio/magnetometer/st_magn_spi.c | 2 -- 1 file changed, 2 deletions(-) --- a/drivers/iio/magnetometer/st_magn_spi.c +++ b/drivers/iio/magnetometer/st_magn_spi.c @@ -48,8 +48,6 @@ static int st_magn_spi_remove(struct spi } static const struct spi_device_id st_magn_id_table[] = { - { LSM303DLHC_MAGN_DEV_NAME }, - { LSM303DLM_MAGN_DEV_NAME }, { LIS3MDL_MAGN_DEV_NAME }, { LSM303AGR_MAGN_DEV_NAME }, {}, Patches currently in stable-queue which might be from lorenzo.bianconi83(a)gmail.com are queue-4.9/iio-magnetometer-st_magn_spi-fix-spi_device_id-table.patch

7 years, 5 months

1
0
0 0

Patch "iio: pressure: zpa2326: report interrupted case as failure" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: pressure: zpa2326: report interrupted case as 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: iio-pressure-zpa2326-report-interrupted-case-as-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: Nicholas Mc Guire <der.herr(a)hofr.at> Date: Sun, 14 May 2017 10:43:55 +0200 Subject: iio: pressure: zpa2326: report interrupted case as failure From: Nicholas Mc Guire <der.herr(a)hofr.at> [ Upstream commit e7215fe4d51e69c9d2608ad0c409d48e844d0adc ] If the timeout-case prints a warning message then probably the interrupted case should also. Further, wait_for_completion_interruptible_timeout() returns long not int. Fixes: commit 03b262f2bbf4 ("iio:pressure: initial zpa2326 barometer support") Signed-off-by: Nicholas Mc Guire <der.herr(a)hofr.at> Signed-off-by: Jonathan Cameron <jic23(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iio/pressure/zpa2326.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) --- a/drivers/iio/pressure/zpa2326.c +++ b/drivers/iio/pressure/zpa2326.c @@ -871,12 +871,13 @@ static int zpa2326_wait_oneshot_completi { int ret; unsigned int val; + long timeout; zpa2326_dbg(indio_dev, "waiting for one shot completion interrupt"); - ret = wait_for_completion_interruptible_timeout( + timeout = wait_for_completion_interruptible_timeout( &private->data_ready, ZPA2326_CONVERSION_JIFFIES); - if (ret > 0) + if (timeout > 0) /* * Interrupt handler completed before timeout: return operation * status. @@ -886,13 +887,16 @@ static int zpa2326_wait_oneshot_completi /* Clear all interrupts just to be sure. */ regmap_read(private->regmap, ZPA2326_INT_SOURCE_REG, &val); - if (!ret) + if (!timeout) { /* Timed out. */ + zpa2326_warn(indio_dev, "no one shot interrupt occurred (%ld)", + timeout); ret = -ETIME; - - if (ret != -ERESTARTSYS) - zpa2326_warn(indio_dev, "no one shot interrupt occurred (%d)", - ret); + } else if (timeout < 0) { + zpa2326_warn(indio_dev, + "wait for one shot interrupt cancelled"); + ret = -ERESTARTSYS; + } return ret; } Patches currently in stable-queue which might be from der.herr(a)hofr.at are queue-4.9/iio-pressure-zpa2326-report-interrupted-case-as-failure.patch

7 years, 5 months

1
0
0 0

Patch "iio: hi8435: avoid garbage event at first enable" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: hi8435: avoid garbage event at first enable 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: iio-hi8435-avoid-garbage-event-at-first-enable.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: Nikita Yushchenko <nikita.yoush(a)cogentembedded.com> Date: Fri, 19 May 2017 17:48:00 +0300 Subject: iio: hi8435: avoid garbage event at first enable From: Nikita Yushchenko <nikita.yoush(a)cogentembedded.com> [ Upstream commit ee19ac340c5fdfd89c6348be4563453c61ab54a9 ] Currently, driver generates events for channels if new reading differs from previous one. This "previous value" is initialized to zero, which results into event if value is constant-one. Fix that by initializing "previous value" by reading at event enable time. This provides reliable sequence for userspace: - enable event, - AFTER THAT read current value, - AFTER THAT each event will correspond to change. Signed-off-by: Nikita Yushchenko <nikita.yoush(a)cogentembedded.com> Signed-off-by: Jonathan Cameron <jic23(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iio/adc/hi8435.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) --- a/drivers/iio/adc/hi8435.c +++ b/drivers/iio/adc/hi8435.c @@ -121,10 +121,21 @@ static int hi8435_write_event_config(str enum iio_event_direction dir, int state) { struct hi8435_priv *priv = iio_priv(idev); + int ret; + u32 tmp; + + if (state) { + ret = hi8435_readl(priv, HI8435_SO31_0_REG, &tmp); + if (ret < 0) + return ret; + if (tmp & BIT(chan->channel)) + priv->event_prev_val |= BIT(chan->channel); + else + priv->event_prev_val &= ~BIT(chan->channel); - priv->event_scan_mask &= ~BIT(chan->channel); - if (state) priv->event_scan_mask |= BIT(chan->channel); + } else + priv->event_scan_mask &= ~BIT(chan->channel); return 0; } Patches currently in stable-queue which might be from nikita.yoush(a)cogentembedded.com are queue-4.9/iio-hi8435-avoid-garbage-event-at-first-enable.patch queue-4.9/iio-hi8435-cleanup-reset-gpio.patch

7 years, 5 months

1
0
0 0

Patch "iio: hi8435: cleanup reset gpio" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: hi8435: cleanup reset gpio 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: iio-hi8435-cleanup-reset-gpio.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: Nikita Yushchenko <nikita.yoush(a)cogentembedded.com> Date: Fri, 19 May 2017 17:48:02 +0300 Subject: iio: hi8435: cleanup reset gpio From: Nikita Yushchenko <nikita.yoush(a)cogentembedded.com> [ Upstream commit 61305664a542f874283f74bf0b27ddb31f5045d7 ] Reset GPIO is active low. Currently driver uses gpiod_set_value(1) to clean reset, which depends on device tree to contain GPIO_ACTIVE_HIGH - that does not match reality. This fixes driver to use _raw version of gpiod_set_value() to enforce active-low semantics despite of what's written in device tree. Allowing device tree to override that only opens possibility for errors and does not add any value. Additionally, use _cansleep version to make things work with i2c-gpio and other sleeping gpio drivers. Signed-off-by: Nikita Yushchenko <nikita.yoush(a)cogentembedded.com> Signed-off-by: Jonathan Cameron <jic23(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iio/adc/hi8435.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) --- a/drivers/iio/adc/hi8435.c +++ b/drivers/iio/adc/hi8435.c @@ -453,13 +453,15 @@ static int hi8435_probe(struct spi_devic priv->spi = spi; reset_gpio = devm_gpiod_get(&spi->dev, NULL, GPIOD_OUT_LOW); - if (IS_ERR(reset_gpio)) { - /* chip s/w reset if h/w reset failed */ + if (!IS_ERR(reset_gpio)) { + /* need >=100ns low pulse to reset chip */ + gpiod_set_raw_value_cansleep(reset_gpio, 0); + udelay(1); + gpiod_set_raw_value_cansleep(reset_gpio, 1); + } else { + /* s/w reset chip if h/w reset is not available */ hi8435_writeb(priv, HI8435_CTRL_REG, HI8435_CTRL_SRST); hi8435_writeb(priv, HI8435_CTRL_REG, 0); - } else { - udelay(5); - gpiod_set_value(reset_gpio, 1); } spi_set_drvdata(spi, idev); Patches currently in stable-queue which might be from nikita.yoush(a)cogentembedded.com are queue-4.9/iio-hi8435-avoid-garbage-event-at-first-enable.patch queue-4.9/iio-hi8435-cleanup-reset-gpio.patch

7 years, 5 months

1
0
0 0

Patch "igb: fix race condition with PTP_TX_IN_PROGRESS bits" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled igb: fix race condition with PTP_TX_IN_PROGRESS bits 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: igb-fix-race-condition-with-ptp_tx_in_progress-bits.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: Jacob Keller <jacob.e.keller(a)intel.com> Date: Wed, 3 May 2017 10:28:52 -0700 Subject: igb: fix race condition with PTP_TX_IN_PROGRESS bits From: Jacob Keller <jacob.e.keller(a)intel.com> [ Upstream commit 4ccdc013b0ae04755a8f7905e0525955d52a77d0 ] Hardware related to the igb driver has a limitation of only handling one Tx timestamp at a time. Thus, the driver uses a state bit lock to enforce that only one timestamp request is honored at a time. Unfortunately this suffers from a simple race condition. The bit lock is not cleared until after skb_tstamp_tx() is called notifying the stack of a new Tx timestamp. Even a well behaved application which sends only one timestamp request at once and waits for a response might wake up and send a new packet before the bit lock is cleared. This results in needlessly dropping some Tx timestamp requests. We can fix this by unlocking the state bit as soon as we read the Timestamp register, as this is the first point at which it is safe to unlock. To avoid issues with the skb pointer, we'll use a copy of the pointer and set the global variable in the driver structure to NULL first. This ensures that the next timestamp request does not modify our local copy of the skb pointer. This ensures that well behaved applications do not accidentally race with the unlock bit. Obviously an application which sends multiple Tx timestamp requests at once will still only timestamp one packet at a time. Unfortunately there is nothing we can do about this. Reported-by: David Mirabito <davidm(a)metamako.com> Signed-off-by: Jacob Keller <jacob.e.keller(a)intel.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(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/ethernet/intel/igb/igb_ptp.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) --- a/drivers/net/ethernet/intel/igb/igb_ptp.c +++ b/drivers/net/ethernet/intel/igb/igb_ptp.c @@ -721,6 +721,7 @@ void igb_ptp_rx_hang(struct igb_adapter **/ static void igb_ptp_tx_hwtstamp(struct igb_adapter *adapter) { + struct sk_buff *skb = adapter->ptp_tx_skb; struct e1000_hw *hw = &adapter->hw; struct skb_shared_hwtstamps shhwtstamps; u64 regval; @@ -748,10 +749,17 @@ static void igb_ptp_tx_hwtstamp(struct i shhwtstamps.hwtstamp = ktime_add_ns(shhwtstamps.hwtstamp, adjust); - skb_tstamp_tx(adapter->ptp_tx_skb, &shhwtstamps); - dev_kfree_skb_any(adapter->ptp_tx_skb); + /* Clear the lock early before calling skb_tstamp_tx so that + * applications are not woken up before the lock bit is clear. We use + * a copy of the skb pointer to ensure other threads can't change it + * while we're notifying the stack. + */ adapter->ptp_tx_skb = NULL; clear_bit_unlock(__IGB_PTP_TX_IN_PROGRESS, &adapter->state); + + /* Notify the stack and free the skb after we've unlocked */ + skb_tstamp_tx(skb, &shhwtstamps); + dev_kfree_skb_any(skb); } /** Patches currently in stable-queue which might be from jacob.e.keller(a)intel.com are queue-4.9/e1000e-fix-race-condition-around-skb_tstamp_tx.patch queue-4.9/igb-fix-race-condition-with-ptp_tx_in_progress-bits.patch

7 years, 5 months

1
0
0 0

Patch "IB/srpt: Avoid that aborting a command triggers a kernel warning" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/srpt: Avoid that aborting a command triggers a kernel warning 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: ib-srpt-avoid-that-aborting-a-command-triggers-a-kernel-warning.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: Bart Van Assche <bart.vanassche(a)sandisk.com> Date: Thu, 4 May 2017 15:50:54 -0700 Subject: IB/srpt: Avoid that aborting a command triggers a kernel warning From: Bart Van Assche <bart.vanassche(a)sandisk.com> [ Upstream commit bd2c52d733f126ff75f99c537a27655b2db07e28 ] Avoid that the following warning is triggered: WARNING: CPU: 10 PID: 166 at ../drivers/infiniband/ulp/srpt/ib_srpt.c:2674 srpt_release_cmd+0x139/0x140 [ib_srpt] CPU: 10 PID: 166 Comm: kworker/u24:8 Not tainted 4.9.4-1-default #1 Workqueue: tmr-fileio target_tmr_work [target_core_mod] Call Trace: [<ffffffffaa3c4f70>] dump_stack+0x63/0x83 [<ffffffffaa0844eb>] __warn+0xcb/0xf0 [<ffffffffaa0845dd>] warn_slowpath_null+0x1d/0x20 [<ffffffffc06ba429>] srpt_release_cmd+0x139/0x140 [ib_srpt] [<ffffffffc06e4377>] target_release_cmd_kref+0xb7/0x120 [target_core_mod] [<ffffffffc06e4d7f>] target_put_sess_cmd+0x2f/0x60 [target_core_mod] [<ffffffffc06e15e0>] core_tmr_lun_reset+0x340/0x790 [target_core_mod] [<ffffffffc06e4816>] target_tmr_work+0xe6/0x140 [target_core_mod] [<ffffffffaa09e4d3>] process_one_work+0x1f3/0x4d0 [<ffffffffaa09e7f8>] worker_thread+0x48/0x4e0 [<ffffffffaa09e7b0>] ? process_one_work+0x4d0/0x4d0 [<ffffffffaa0a46da>] kthread+0xca/0xe0 [<ffffffffaa0a4610>] ? kthread_park+0x60/0x60 [<ffffffffaa71b775>] ret_from_fork+0x25/0x30 Signed-off-by: Bart Van Assche <bart.vanassche(a)sandisk.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Cc: Doug Ledford <dledford(a)redhat.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: David Disseldorp <ddiss(a)suse.de> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/ulp/srpt/ib_srpt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/infiniband/ulp/srpt/ib_srpt.c +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c @@ -2666,7 +2666,8 @@ static void srpt_release_cmd(struct se_c struct srpt_rdma_ch *ch = ioctx->ch; unsigned long flags; - WARN_ON(ioctx->state != SRPT_STATE_DONE); + WARN_ON_ONCE(ioctx->state != SRPT_STATE_DONE && + !(ioctx->cmd.transport_state & CMD_T_ABORTED)); if (ioctx->n_rw_ctx) { srpt_free_rw_ctxs(ch, ioctx); Patches currently in stable-queue which might be from bart.vanassche(a)sandisk.com are queue-4.9/ib-srpt-avoid-that-aborting-a-command-triggers-a-kernel-warning.patch queue-4.9/ib-srpt-fix-abort-handling.patch

7 years, 5 months

1
0
0 0

Patch "IB/srpt: Fix abort handling" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/srpt: Fix abort handling 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: ib-srpt-fix-abort-handling.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: Bart Van Assche <bart.vanassche(a)sandisk.com> Date: Thu, 4 May 2017 15:50:53 -0700 Subject: IB/srpt: Fix abort handling From: Bart Van Assche <bart.vanassche(a)sandisk.com> [ Upstream commit 55d694275f41a1c0eef4ef49044ff29bc3999490 ] Let the target core check the CMD_T_ABORTED flag instead of the SRP target driver. Hence remove the transport_check_aborted_status() call. Since state == SRPT_STATE_CMD_RSP_SENT is something that really should not happen, do not try to recover if srpt_queue_response() is called for an I/O context that is in that state. This patch is a bug fix because the srpt_abort_cmd() call is misplaced - if that function is called from srpt_queue_response() it should either be called before the command state is changed or after the response has been sent. Signed-off-by: Bart Van Assche <bart.vanassche(a)sandisk.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Cc: Doug Ledford <dledford(a)redhat.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Andy Grover <agrover(a)redhat.com> Cc: David Disseldorp <ddiss(a)suse.de> Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/ulp/srpt/ib_srpt.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) --- a/drivers/infiniband/ulp/srpt/ib_srpt.c +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c @@ -2292,12 +2292,8 @@ static void srpt_queue_response(struct s } spin_unlock_irqrestore(&ioctx->spinlock, flags); - if (unlikely(transport_check_aborted_status(&ioctx->cmd, false) - || WARN_ON_ONCE(state == SRPT_STATE_CMD_RSP_SENT))) { - atomic_inc(&ch->req_lim_delta); - srpt_abort_cmd(ioctx); + if (unlikely(WARN_ON_ONCE(state == SRPT_STATE_CMD_RSP_SENT))) return; - } /* For read commands, transfer the data to the initiator. */ if (ioctx->cmd.data_direction == DMA_FROM_DEVICE && Patches currently in stable-queue which might be from bart.vanassche(a)sandisk.com are queue-4.9/ib-srpt-avoid-that-aborting-a-command-triggers-a-kernel-warning.patch queue-4.9/ib-srpt-fix-abort-handling.patch

7 years, 5 months

1
0
0 0

Patch "IB/rdmavt: Allocate CQ memory on the correct node" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/rdmavt: Allocate CQ memory on the correct node 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: ib-rdmavt-allocate-cq-memory-on-the-correct-node.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: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Date: Mon, 18 Dec 2017 19:57:06 -0800 Subject: IB/rdmavt: Allocate CQ memory on the correct node From: Mike Marciniszyn <mike.marciniszyn(a)intel.com> [ Upstream commit db9a2c6f9b6196b889b98e961cb9a37617b11ccf ] CQ allocation does not ensure that completion queue entries and the completion queue structure are allocated on the correct numa node. Fix by allocating the rvt_cq and kernel CQ entries on the device node, leaving the user CQ entries on the default local node. Also ensure CQ resizes use the correct allocator when extending a CQ. Reviewed-by: Sebastian Sanchez <sebastian.sanchez(a)intel.com> Signed-off-by: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/sw/rdmavt/cq.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/drivers/infiniband/sw/rdmavt/cq.c +++ b/drivers/infiniband/sw/rdmavt/cq.c @@ -197,7 +197,7 @@ struct ib_cq *rvt_create_cq(struct ib_de return ERR_PTR(-EINVAL); /* Allocate the completion queue structure. */ - cq = kzalloc(sizeof(*cq), GFP_KERNEL); + cq = kzalloc_node(sizeof(*cq), GFP_KERNEL, rdi->dparms.node); if (!cq) return ERR_PTR(-ENOMEM); @@ -213,7 +213,9 @@ struct ib_cq *rvt_create_cq(struct ib_de sz += sizeof(struct ib_uverbs_wc) * (entries + 1); else sz += sizeof(struct ib_wc) * (entries + 1); - wc = vmalloc_user(sz); + wc = udata ? + vmalloc_user(sz) : + vzalloc_node(sz, rdi->dparms.node); if (!wc) { ret = ERR_PTR(-ENOMEM); goto bail_cq; @@ -368,7 +370,9 @@ int rvt_resize_cq(struct ib_cq *ibcq, in sz += sizeof(struct ib_uverbs_wc) * (cqe + 1); else sz += sizeof(struct ib_wc) * (cqe + 1); - wc = vmalloc_user(sz); + wc = udata ? + vmalloc_user(sz) : + vzalloc_node(sz, rdi->dparms.node); if (!wc) return -ENOMEM; Patches currently in stable-queue which might be from mike.marciniszyn(a)intel.com are queue-4.9/ib-rdmavt-allocate-cq-memory-on-the-correct-node.patch

7 years, 5 months

1
0
0 0

Patch "i40iw: Correct Q1/XF object count equation" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled i40iw: Correct Q1/XF object count equation 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: i40iw-correct-q1-xf-object-count-equation.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: Shiraz Saleem <shiraz.saleem(a)intel.com> Date: Fri, 22 Dec 2017 09:46:56 -0600 Subject: i40iw: Correct Q1/XF object count equation From: Shiraz Saleem <shiraz.saleem(a)intel.com> [ Upstream commit fe99afd1febd74e0ef1fed7e3283f09effe1f4f0 ] Lower Inbound RDMA Read Queue (Q1) object count by a factor of 2 as it is incorrectly doubled. Also, round up Q1 and Transmit FIFO (XF) object count to power of 2 to satisfy hardware requirement. Fixes: 86dbcd0f12e9 ("i40iw: add file to handle cqp calls") Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/i40iw/i40iw_ctrl.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/infiniband/hw/i40iw/i40iw_ctrl.c +++ b/drivers/infiniband/hw/i40iw/i40iw_ctrl.c @@ -3644,8 +3644,10 @@ enum i40iw_status_code i40iw_config_fpm_ hmc_info->hmc_obj[I40IW_HMC_IW_APBVT_ENTRY].cnt = 1; hmc_info->hmc_obj[I40IW_HMC_IW_MR].cnt = mrwanted; - hmc_info->hmc_obj[I40IW_HMC_IW_XF].cnt = I40IW_MAX_WQ_ENTRIES * qpwanted; - hmc_info->hmc_obj[I40IW_HMC_IW_Q1].cnt = 4 * I40IW_MAX_IRD_SIZE * qpwanted; + hmc_info->hmc_obj[I40IW_HMC_IW_XF].cnt = + roundup_pow_of_two(I40IW_MAX_WQ_ENTRIES * qpwanted); + hmc_info->hmc_obj[I40IW_HMC_IW_Q1].cnt = + roundup_pow_of_two(2 * I40IW_MAX_IRD_SIZE * qpwanted); hmc_info->hmc_obj[I40IW_HMC_IW_XFFL].cnt = hmc_info->hmc_obj[I40IW_HMC_IW_XF].cnt / hmc_fpm_misc->xf_block_size; hmc_info->hmc_obj[I40IW_HMC_IW_Q1FL].cnt = Patches currently in stable-queue which might be from shiraz.saleem(a)intel.com are queue-4.9/i40iw-fix-sequence-number-for-the-first-partial-fpdu.patch queue-4.9/i40iw-correct-q1-xf-object-count-equation.patch

7 years, 5 months

1
0
0 0

Patch "i40evf: fix merge error in older patch" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled i40evf: fix merge error in older patch 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: i40evf-fix-merge-error-in-older-patch.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: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Date: Fri, 28 Apr 2017 16:53:16 -0700 Subject: i40evf: fix merge error in older patch From: Jesse Brandeburg <jesse.brandeburg(a)intel.com> [ Upstream commit 155b0f690051345deefc653774b739c786067d61 ] This patch fixes a missing line that was missed while merging, which results in a driver feature in the VF not working to enable RSS as a negotiated feature. Fixes: 43a3d9ba34c9c ("i40evf: Allow PF driver to configure RSS") Signed-off-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(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/ethernet/intel/i40evf/i40evf_virtchnl.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c +++ b/drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c @@ -154,6 +154,7 @@ int i40evf_send_vf_config_msg(struct i40 adapter->current_op = I40E_VIRTCHNL_OP_GET_VF_RESOURCES; adapter->aq_required &= ~I40EVF_FLAG_AQ_GET_CONFIG; caps = I40E_VIRTCHNL_VF_OFFLOAD_L2 | + I40E_VIRTCHNL_VF_OFFLOAD_RSS_PF | I40E_VIRTCHNL_VF_OFFLOAD_RSS_AQ | I40E_VIRTCHNL_VF_OFFLOAD_RSS_REG | I40E_VIRTCHNL_VF_OFFLOAD_VLAN | Patches currently in stable-queue which might be from jesse.brandeburg(a)intel.com are queue-4.9/i40evf-fix-merge-error-in-older-patch.patch

7 years, 5 months

1
0
0 0

Patch "i40iw: Fix sequence number for the first partial FPDU" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled i40iw: Fix sequence number for the first partial FPDU 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: i40iw-fix-sequence-number-for-the-first-partial-fpdu.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: Shiraz Saleem <shiraz.saleem(a)intel.com> Date: Fri, 22 Dec 2017 09:46:59 -0600 Subject: i40iw: Fix sequence number for the first partial FPDU From: Shiraz Saleem <shiraz.saleem(a)intel.com> [ Upstream commit df8b13a1b23356d01dfc4647a5629cdb0f4ce566 ] Partial FPDU processing is broken as the sequence number for the first partial FPDU is wrong due to incorrect Q2 buffer offset. The offset should be 64 rather than 16. Fixes: 786c6adb3a94 ("i40iw: add puda code") Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/i40iw/i40iw_d.h | 1 + drivers/infiniband/hw/i40iw/i40iw_puda.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) --- a/drivers/infiniband/hw/i40iw/i40iw_d.h +++ b/drivers/infiniband/hw/i40iw/i40iw_d.h @@ -86,6 +86,7 @@ #define RDMA_OPCODE_MASK 0x0f #define RDMA_READ_REQ_OPCODE 1 #define Q2_BAD_FRAME_OFFSET 72 +#define Q2_FPSN_OFFSET 64 #define CQE_MAJOR_DRV 0x8000 #define I40IW_TERM_SENT 0x01 --- a/drivers/infiniband/hw/i40iw/i40iw_puda.c +++ b/drivers/infiniband/hw/i40iw/i40iw_puda.c @@ -1320,7 +1320,7 @@ static void i40iw_ieq_handle_exception(s u32 *hw_host_ctx = (u32 *)qp->hw_host_ctx; u32 rcv_wnd = hw_host_ctx[23]; /* first partial seq # in q2 */ - u32 fps = qp->q2_buf[16]; + u32 fps = *(u32 *)(qp->q2_buf + Q2_FPSN_OFFSET); struct list_head *rxlist = &pfpdu->rxlist; struct list_head *plist; Patches currently in stable-queue which might be from shiraz.saleem(a)intel.com are queue-4.9/i40iw-fix-sequence-number-for-the-first-partial-fpdu.patch queue-4.9/i40iw-correct-q1-xf-object-count-equation.patch

7 years, 5 months

1
0
0 0

Patch "hwmon: (ina2xx) Make calibration register value fixed" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hwmon: (ina2xx) Make calibration register value fixed 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: hwmon-ina2xx-make-calibration-register-value-fixed.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: Maciej Purski <m.purski(a)samsung.com> Date: Wed, 22 Nov 2017 16:32:15 +0100 Subject: hwmon: (ina2xx) Make calibration register value fixed From: Maciej Purski <m.purski(a)samsung.com> [ Upstream commit 5d389b125186cf254ad5b8015763ac07c151aea4 ] Calibration register is used for calculating current register in hardware according to datasheet: current = shunt_volt * calib_register / 2048 (ina 226) current = shunt_volt * calib_register / 4096 (ina 219) Fix calib_register value to 2048 for ina226 and 4096 for ina 219 in order to avoid truncation error and provide best precision allowed by shunt_voltage measurement. Make current scale value follow changes of shunt_resistor from sysfs as calib_register value is now fixed. Power_lsb value should also follow shunt_resistor changes as stated in datasheet: power_lsb = 25 * current_lsb (ina 226) power_lsb = 20 * current_lsb (ina 219) Signed-off-by: Maciej Purski <m.purski(a)samsung.com> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hwmon/ina2xx.c | 87 ++++++++++++++++++++++++++++--------------------- 1 file changed, 50 insertions(+), 37 deletions(-) --- a/drivers/hwmon/ina2xx.c +++ b/drivers/hwmon/ina2xx.c @@ -94,18 +94,20 @@ enum ina2xx_ids { ina219, ina226 }; struct ina2xx_config { u16 config_default; - int calibration_factor; + int calibration_value; int registers; int shunt_div; int bus_voltage_shift; int bus_voltage_lsb; /* uV */ - int power_lsb; /* uW */ + int power_lsb_factor; }; struct ina2xx_data { const struct ina2xx_config *config; long rshunt; + long current_lsb_uA; + long power_lsb_uW; struct mutex config_lock; struct regmap *regmap; @@ -115,21 +117,21 @@ struct ina2xx_data { static const struct ina2xx_config ina2xx_config[] = { [ina219] = { .config_default = INA219_CONFIG_DEFAULT, - .calibration_factor = 40960000, + .calibration_value = 4096, .registers = INA219_REGISTERS, .shunt_div = 100, .bus_voltage_shift = 3, .bus_voltage_lsb = 4000, - .power_lsb = 20000, + .power_lsb_factor = 20, }, [ina226] = { .config_default = INA226_CONFIG_DEFAULT, - .calibration_factor = 5120000, + .calibration_value = 2048, .registers = INA226_REGISTERS, .shunt_div = 400, .bus_voltage_shift = 0, .bus_voltage_lsb = 1250, - .power_lsb = 25000, + .power_lsb_factor = 25, }, }; @@ -168,12 +170,16 @@ static u16 ina226_interval_to_reg(int in return INA226_SHIFT_AVG(avg_bits); } +/* + * Calibration register is set to the best value, which eliminates + * truncation errors on calculating current register in hardware. + * According to datasheet (eq. 3) the best values are 2048 for + * ina226 and 4096 for ina219. They are hardcoded as calibration_value. + */ static int ina2xx_calibrate(struct ina2xx_data *data) { - u16 val = DIV_ROUND_CLOSEST(data->config->calibration_factor, - data->rshunt); - - return regmap_write(data->regmap, INA2XX_CALIBRATION, val); + return regmap_write(data->regmap, INA2XX_CALIBRATION, + data->config->calibration_value); } /* @@ -186,10 +192,6 @@ static int ina2xx_init(struct ina2xx_dat if (ret < 0) return ret; - /* - * Set current LSB to 1mA, shunt is in uOhms - * (equation 13 in datasheet). - */ return ina2xx_calibrate(data); } @@ -267,15 +269,15 @@ static int ina2xx_get_value(struct ina2x val = DIV_ROUND_CLOSEST(val, 1000); break; case INA2XX_POWER: - val = regval * data->config->power_lsb; + val = regval * data->power_lsb_uW; break; case INA2XX_CURRENT: - /* signed register, LSB=1mA (selected), in mA */ - val = (s16)regval; + /* signed register, result in mA */ + val = regval * data->current_lsb_uA; + val = DIV_ROUND_CLOSEST(val, 1000); break; case INA2XX_CALIBRATION: - val = DIV_ROUND_CLOSEST(data->config->calibration_factor, - regval); + val = regval; break; default: /* programmer goofed */ @@ -303,9 +305,32 @@ static ssize_t ina2xx_show_value(struct ina2xx_get_value(data, attr->index, regval)); } -static ssize_t ina2xx_set_shunt(struct device *dev, - struct device_attribute *da, - const char *buf, size_t count) +/* + * In order to keep calibration register value fixed, the product + * of current_lsb and shunt_resistor should also be fixed and equal + * to shunt_voltage_lsb = 1 / shunt_div multiplied by 10^9 in order + * to keep the scale. + */ +static int ina2xx_set_shunt(struct ina2xx_data *data, long val) +{ + unsigned int dividend = DIV_ROUND_CLOSEST(1000000000, + data->config->shunt_div); + if (val <= 0 || val > dividend) + return -EINVAL; + + mutex_lock(&data->config_lock); + data->rshunt = val; + data->current_lsb_uA = DIV_ROUND_CLOSEST(dividend, val); + data->power_lsb_uW = data->config->power_lsb_factor * + data->current_lsb_uA; + mutex_unlock(&data->config_lock); + + return 0; +} + +static ssize_t ina2xx_store_shunt(struct device *dev, + struct device_attribute *da, + const char *buf, size_t count) { unsigned long val; int status; @@ -315,18 +340,9 @@ static ssize_t ina2xx_set_shunt(struct d if (status < 0) return status; - if (val == 0 || - /* Values greater than the calibration factor make no sense. */ - val > data->config->calibration_factor) - return -EINVAL; - - mutex_lock(&data->config_lock); - data->rshunt = val; - status = ina2xx_calibrate(data); - mutex_unlock(&data->config_lock); + status = ina2xx_set_shunt(data, val); if (status < 0) return status; - return count; } @@ -386,7 +402,7 @@ static SENSOR_DEVICE_ATTR(power1_input, /* shunt resistance */ static SENSOR_DEVICE_ATTR(shunt_resistor, S_IRUGO | S_IWUSR, - ina2xx_show_value, ina2xx_set_shunt, + ina2xx_show_value, ina2xx_store_shunt, INA2XX_CALIBRATION); /* update interval (ina226 only) */ @@ -441,10 +457,7 @@ static int ina2xx_probe(struct i2c_clien val = INA2XX_RSHUNT_DEFAULT; } - if (val <= 0 || val > data->config->calibration_factor) - return -ENODEV; - - data->rshunt = val; + ina2xx_set_shunt(data, val); ina2xx_regmap_config.max_register = data->config->registers; Patches currently in stable-queue which might be from m.purski(a)samsung.com are queue-4.9/hwmon-ina2xx-make-calibration-register-value-fixed.patch

7 years, 5 months

1
0
0 0

Patch "i2c: mux: reg: put away the parent i2c adapter on probe failure" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled i2c: mux: reg: put away the parent i2c adapter on probe 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: i2c-mux-reg-put-away-the-parent-i2c-adapter-on-probe-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: Peter Rosin <peda(a)axentia.se> Date: Sun, 7 May 2017 07:16:30 +0200 Subject: i2c: mux: reg: put away the parent i2c adapter on probe failure From: Peter Rosin <peda(a)axentia.se> [ Upstream commit 68118e0e73aa3a6291c8b9eb1ee708e05f110cea ] It is only prudent to let go of resources that are not used. Fixes: b3fdd32799d8 ("i2c: mux: Add register-based mux i2c-mux-reg") Signed-off-by: Peter Rosin <peda(a)axentia.se> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/i2c/muxes/i2c-mux-reg.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) --- a/drivers/i2c/muxes/i2c-mux-reg.c +++ b/drivers/i2c/muxes/i2c-mux-reg.c @@ -196,20 +196,25 @@ static int i2c_mux_reg_probe(struct plat res = platform_get_resource(pdev, IORESOURCE_MEM, 0); mux->data.reg_size = resource_size(res); mux->data.reg = devm_ioremap_resource(&pdev->dev, res); - if (IS_ERR(mux->data.reg)) - return PTR_ERR(mux->data.reg); + if (IS_ERR(mux->data.reg)) { + ret = PTR_ERR(mux->data.reg); + goto err_put_parent; + } } if (mux->data.reg_size != 4 && mux->data.reg_size != 2 && mux->data.reg_size != 1) { dev_err(&pdev->dev, "Invalid register size\n"); - return -EINVAL; + ret = -EINVAL; + goto err_put_parent; } muxc = i2c_mux_alloc(parent, &pdev->dev, mux->data.n_values, 0, 0, i2c_mux_reg_select, NULL); - if (!muxc) - return -ENOMEM; + if (!muxc) { + ret = -ENOMEM; + goto err_put_parent; + } muxc->priv = mux; platform_set_drvdata(pdev, muxc); @@ -235,6 +240,8 @@ static int i2c_mux_reg_probe(struct plat add_adapter_failed: i2c_mux_del_adapters(muxc); +err_put_parent: + i2c_put_adapter(parent); return ret; } Patches currently in stable-queue which might be from peda(a)axentia.se are queue-4.9/i2c-mux-reg-put-away-the-parent-i2c-adapter-on-probe-failure.patch

7 years, 5 months

1
0
0 0

Patch "hsr: fix incorrect warning" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hsr: fix incorrect warning 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: hsr-fix-incorrect-warning.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: "Karicheri, Muralidharan" <m-karicheri2(a)ti.com> Date: Mon, 12 Jun 2017 15:06:26 -0400 Subject: hsr: fix incorrect warning From: "Karicheri, Muralidharan" <m-karicheri2(a)ti.com> [ Upstream commit 675c8da049fd6556eb2d6cdd745fe812752f07a8 ] When HSR interface is setup using ip link command, an annoying warning appears with the trace as below:- [ 203.019828] hsr_get_node: Non-HSR frame [ 203.019833] Modules linked in: [ 203.019848] CPU: 0 PID: 158 Comm: sd-resolve Tainted: G W 4.12.0-rc3-00052-g9fa6bf70 #2 [ 203.019853] Hardware name: Generic DRA74X (Flattened Device Tree) [ 203.019869] [<c0110280>] (unwind_backtrace) from [<c010c2f4>] (show_stack+0x10/0x14) [ 203.019880] [<c010c2f4>] (show_stack) from [<c04b9f64>] (dump_stack+0xac/0xe0) [ 203.019894] [<c04b9f64>] (dump_stack) from [<c01374e8>] (__warn+0xd8/0x104) [ 203.019907] [<c01374e8>] (__warn) from [<c0137548>] (warn_slowpath_fmt+0x34/0x44) root@am57xx-evm:~# [ 203.019921] [<c0137548>] (warn_slowpath_fmt) from [<c081126c>] (hsr_get_node+0x148/0x170) [ 203.019932] [<c081126c>] (hsr_get_node) from [<c0814240>] (hsr_forward_skb+0x110/0x7c0) [ 203.019942] [<c0814240>] (hsr_forward_skb) from [<c0811d64>] (hsr_dev_xmit+0x2c/0x34) [ 203.019954] [<c0811d64>] (hsr_dev_xmit) from [<c06c0828>] (dev_hard_start_xmit+0xc4/0x3bc) [ 203.019963] [<c06c0828>] (dev_hard_start_xmit) from [<c06c13d8>] (__dev_queue_xmit+0x7c4/0x98c) [ 203.019974] [<c06c13d8>] (__dev_queue_xmit) from [<c0782f54>] (ip6_finish_output2+0x330/0xc1c) [ 203.019983] [<c0782f54>] (ip6_finish_output2) from [<c0788f0c>] (ip6_output+0x58/0x454) [ 203.019994] [<c0788f0c>] (ip6_output) from [<c07b16cc>] (mld_sendpack+0x420/0x744) As this is an expected path to hsr_get_node() with frame coming from the master interface, add a check to ensure packet is not from the master port and then warn. Signed-off-by: Murali Karicheri <m-karicheri2(a)ti.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/hsr/hsr_forward.c | 3 +-- net/hsr/hsr_framereg.c | 9 +++++++-- net/hsr/hsr_framereg.h | 2 +- 3 files changed, 9 insertions(+), 5 deletions(-) --- a/net/hsr/hsr_forward.c +++ b/net/hsr/hsr_forward.c @@ -324,8 +324,7 @@ static int hsr_fill_frame_info(struct hs unsigned long irqflags; frame->is_supervision = is_supervision_frame(port->hsr, skb); - frame->node_src = hsr_get_node(&port->hsr->node_db, skb, - frame->is_supervision); + frame->node_src = hsr_get_node(port, skb, frame->is_supervision); if (frame->node_src == NULL) return -1; /* Unknown node and !is_supervision, or no mem */ --- a/net/hsr/hsr_framereg.c +++ b/net/hsr/hsr_framereg.c @@ -158,9 +158,10 @@ struct hsr_node *hsr_add_node(struct lis /* Get the hsr_node from which 'skb' was sent. */ -struct hsr_node *hsr_get_node(struct list_head *node_db, struct sk_buff *skb, +struct hsr_node *hsr_get_node(struct hsr_port *port, struct sk_buff *skb, bool is_sup) { + struct list_head *node_db = &port->hsr->node_db; struct hsr_node *node; struct ethhdr *ethhdr; u16 seq_out; @@ -186,7 +187,11 @@ struct hsr_node *hsr_get_node(struct lis */ seq_out = hsr_get_skb_sequence_nr(skb) - 1; } else { - WARN_ONCE(1, "%s: Non-HSR frame\n", __func__); + /* this is called also for frames from master port and + * so warn only for non master ports + */ + if (port->type != HSR_PT_MASTER) + WARN_ONCE(1, "%s: Non-HSR frame\n", __func__); seq_out = HSR_SEQNR_START; } --- a/net/hsr/hsr_framereg.h +++ b/net/hsr/hsr_framereg.h @@ -18,7 +18,7 @@ struct hsr_node; struct hsr_node *hsr_add_node(struct list_head *node_db, unsigned char addr[], u16 seq_out); -struct hsr_node *hsr_get_node(struct list_head *node_db, struct sk_buff *skb, +struct hsr_node *hsr_get_node(struct hsr_port *port, struct sk_buff *skb, bool is_sup); void hsr_handle_sup_frame(struct sk_buff *skb, struct hsr_node *node_curr, struct hsr_port *port); Patches currently in stable-queue which might be from m-karicheri2(a)ti.com are queue-4.9/hsr-fix-incorrect-warning.patch

7 years, 5 months

1
0
0 0

Patch "HID: i2c: Call acpi_device_fix_up_power for ACPI-enumerated devices" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled HID: i2c: Call acpi_device_fix_up_power for ACPI-enumerated devices 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: hid-i2c-call-acpi_device_fix_up_power-for-acpi-enumerated-devices.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: Tue, 9 May 2017 10:04:36 +0200 Subject: HID: i2c: Call acpi_device_fix_up_power for ACPI-enumerated devices From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit f3d3eab667de62572376abb1aa26316191c39929 ] For ACPI devices which do not have a _PSC method, the ACPI subsys cannot query their initial state at boot, so these devices are assumed to have been put in D0 by the BIOS, but for touchscreens that is not always true. This commit adds a call to acpi_device_fix_up_power to explicitly put devices without a _PSC method into D0 state (for devices with a _PSC method it is a nop). Note we only need to do this on probe, after a resume the ACPI subsys knows the device is in D3 and will properly put it in D0. This fixes the SIS0817 i2c-hid touchscreen on a Peaq C1010 2-in-1 device failing to probe with a "hid_descr_cmd failed" error. Acked-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hid/i2c-hid/i2c-hid.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) --- a/drivers/hid/i2c-hid/i2c-hid.c +++ b/drivers/hid/i2c-hid/i2c-hid.c @@ -968,6 +968,15 @@ static int i2c_hid_acpi_pdata(struct i2c return ret < 0 && ret != -ENXIO ? ret : 0; } +static void i2c_hid_acpi_fix_up_power(struct device *dev) +{ + acpi_handle handle = ACPI_HANDLE(dev); + struct acpi_device *adev; + + if (handle && acpi_bus_get_device(handle, &adev) == 0) + acpi_device_fix_up_power(adev); +} + static const struct acpi_device_id i2c_hid_acpi_match[] = { {"ACPI0C50", 0 }, {"PNP0C50", 0 }, @@ -980,6 +989,8 @@ static inline int i2c_hid_acpi_pdata(str { return -ENODEV; } + +static inline void i2c_hid_acpi_fix_up_power(struct device *dev) {} #endif #ifdef CONFIG_OF @@ -1082,6 +1093,8 @@ static int i2c_hid_probe(struct i2c_clie if (ret < 0) goto err; + i2c_hid_acpi_fix_up_power(&client->dev); + pm_runtime_get_noresume(&client->dev); pm_runtime_set_active(&client->dev); pm_runtime_enable(&client->dev); 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

7 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror