January 2019 - Linux-stable-mirror

Re: Regression found (Stop-marking-clocks-as-CLK_IS_CRITICAL)

by Pierre-Louis Bossart

On 1/20/19 11:55 PM, Mogens Jensen wrote: > The only minor annoyance I'm experiencing now, is a large amount of debug output from something in kernel log when audio is played on the system: > > writing to lpe: 00000000: 01 01 01 01 00 00 08 00 ff ff ff ff 55 00 00 00 ............U... > writing to lpe: 00000000: 01 01 01 01 00 00 1a 00 ff ff ff ff 75 00 12 00 ............u... > ... That's enabled via dynamic debug so that's rather a configuration issue than a kernel problem?

5 years, 9 months

1
0
0 0

net/mlx5e: Force CHECKSUM_UNNECESSARY for short ethernet frames for 4.19.17

by Ivan Babrou

Hey, This issue on 4.19 makes us sad: * https://bugzilla.kernel.org/show_bug.cgi?id=201849 * https://www.mail-archive.com/netdev@vger.kernel.org/msg253346.html Luckily, fix for this landed in v5.0-rc3: * https://patchwork.ozlabs.org/patch/1027838/ It doesn't apply cleanly on v4.19.16, so I made a backported version: * https://github.com/bobrik/linux/commit/1c7cbb3cb62cf This fixed the issue for us and we'd like to have the fix included in v4.19.17 in some way. There are four patches in the series applied to v5.0-rc3, I'm not sure if others need to be backported as well. Thanks!

5 years, 9 months

2
3
0 0

[PATCHv2 1/4] EDAC, altera: Fix S10 persistent register offset

by thor.thayer＠linux.intel.com

From: Thor Thayer <thor.thayer(a)linux.intel.com> Correct the persistent register offset where address and status are stored. Fixes: 08f08bfb7b4c ("EDAC, altera: Merge Stratix10 into the Arria10 SDRAM probe routine") Cc: stable(a)vger.kernel.org Signed-off-by: Thor Thayer <thor.thayer(a)linux.intel.com> --- v2 Fixes tag should be on one line instead of wrapped. --- drivers/edac/altera_edac.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/edac/altera_edac.h b/drivers/edac/altera_edac.h index 4213cb0bb2a7..f8664bac9fa8 100644 --- a/drivers/edac/altera_edac.h +++ b/drivers/edac/altera_edac.h @@ -295,8 +295,8 @@ struct altr_sdram_mc_data { #define S10_SYSMGR_ECC_INTSTAT_DERR_OFST 0xA0 /* Sticky registers for Uncorrected Errors */ -#define S10_SYSMGR_UE_VAL_OFST 0x120 -#define S10_SYSMGR_UE_ADDR_OFST 0x124 +#define S10_SYSMGR_UE_VAL_OFST 0x220 +#define S10_SYSMGR_UE_ADDR_OFST 0x224 #define S10_DDR0_IRQ_MASK BIT(16) -- 2.7.4

5 years, 9 months

1
0
0 0

[PATCH v4.14.y] ip: fail fast on IP defrag errors

by Zubin Mithra

From: Peter Oskolkov <posk(a)google.com> commit 0ff89efb524631ac9901b81446b453c29711c376 upstream The current behavior of IP defragmentation is inconsistent: - some overlapping/wrong length fragments are dropped without affecting the queue; - most overlapping fragments cause the whole frag queue to be dropped. This patch brings consistency: if a bad fragment is detected, the whole frag queue is dropped. Two major benefits: - fail fast: corrupted frag queues are cleared immediately, instead of by timeout; - testing of overlapping fragments is now much easier: any kind of random fragment length mutation now leads to the frag queue being discarded (IP packet dropped); before this patch, some overlaps were "corrected", with tests not seeing expected packet drops. Note that in one case (see "if (end&7)" conditional) the current behavior is preserved as there are concerns that this could be legitimate padding. Signed-off-by: Peter Oskolkov <posk(a)google.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Willem de Bruijn <willemb(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Zubin Mithra <zsm(a)chromium.org> --- Backport Note: - Syzkaller reported a UAF, as 0ff89efb5246 ("ip: fail fast on IP defrag errors") was not applied prior to applying d5f9565c8d5a ("net: ipv4: do not handle duplicate fragments as overlapping"). Conflicts occur when 0ff89efb5246 is now applied onto 4.14.y/4.19.y, which this patch addresses. - An alternative to this patch would be to do the following :- - revert "net: ipv4: do not handle duplicate fragments as overlapping" (d5f9565c8d5ad on 4.19.y, 95b4b711444a on 4.14.y) - apply "ip: fail fast on IP defrag errors" (0ff89efb5246) - apply "net: ipv4: do not handle duplicate fragments as overlapping" (ade446403bfb) net/ipv4/ip_fragment.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c index f8bbd693c19c2..03576ff7557e0 100644 --- a/net/ipv4/ip_fragment.c +++ b/net/ipv4/ip_fragment.c @@ -382,7 +382,7 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb) */ if (end < qp->q.len || ((qp->q.flags & INET_FRAG_LAST_IN) && end != qp->q.len)) - goto err; + goto discard_qp; qp->q.flags |= INET_FRAG_LAST_IN; qp->q.len = end; } else { @@ -394,20 +394,20 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb) if (end > qp->q.len) { /* Some bits beyond end -> corruption. */ if (qp->q.flags & INET_FRAG_LAST_IN) - goto err; + goto discard_qp; qp->q.len = end; } } if (end == offset) - goto err; + goto discard_qp; err = -ENOMEM; if (!pskb_pull(skb, skb_network_offset(skb) + ihl)) - goto err; + goto discard_qp; err = pskb_trim_rcsum(skb, end - offset); if (err) - goto err; + goto discard_qp; /* Note : skb->rbnode and skb->dev share the same location. */ dev = skb->dev; @@ -425,6 +425,7 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb) * fragment. */ + err = -EINVAL; /* Find out where to put this fragment. */ prev_tail = qp->q.fragments_tail; if (!prev_tail) @@ -433,7 +434,7 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb) /* This is the common case: skb goes to the end. */ /* Detect and discard overlaps. */ if (offset < prev_tail->ip_defrag_offset + prev_tail->len) - goto discard_qp; + goto overlap; if (offset == prev_tail->ip_defrag_offset + prev_tail->len) ip4_frag_append_to_last_run(&qp->q, skb); else @@ -456,7 +457,7 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb) end <= skb1_run_end) goto err; /* No new data, potential duplicate */ else - goto discard_qp; /* Found an overlap */ + goto overlap; /* Found an overlap */ } while (*rbn); /* Here we have parent properly set, and rbn pointing to * one of its NULL left/right children. Insert skb. @@ -493,16 +494,18 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb) skb->_skb_refdst = 0UL; err = ip_frag_reasm(qp, skb, prev_tail, dev); skb->_skb_refdst = orefdst; + if (err) + inet_frag_kill(&qp->q); return err; } skb_dst_drop(skb); return -EINPROGRESS; +overlap: + __IP_INC_STATS(net, IPSTATS_MIB_REASM_OVERLAPS); discard_qp: inet_frag_kill(&qp->q); - err = -EINVAL; - __IP_INC_STATS(net, IPSTATS_MIB_REASM_OVERLAPS); err: kfree_skb(skb); return err; -- 2.20.1.97.g81188d93c3-goog

5 years, 9 months

1
0
0 0

[PATCH 1/3] gnss: sirf: fix premature wakeup interrupt enable

by Johan Hovold

Make sure the receiver is powered (and booted) before enabling the wakeup interrupt to avoid spurious interrupts due to a floating input. Similarly, disable the interrupt before powering off on probe errors and on unbind. Fixes: d2efbbd18b1e ("gnss: add driver for sirfstar-based receivers") Cc: stable <stable(a)vger.kernel.org> # 4.19 Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/gnss/sirf.c | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/drivers/gnss/sirf.c b/drivers/gnss/sirf.c index 226f6e6fe01b..8e3f6a776e02 100644 --- a/drivers/gnss/sirf.c +++ b/drivers/gnss/sirf.c @@ -310,30 +310,26 @@ static int sirf_probe(struct serdev_device *serdev) ret = -ENODEV; goto err_put_device; } + + ret = regulator_enable(data->vcc); + if (ret) + goto err_put_device; + + /* Wait for chip to boot into hibernate mode. */ + msleep(SIRF_BOOT_DELAY); } if (data->wakeup) { ret = gpiod_to_irq(data->wakeup); if (ret < 0) - goto err_put_device; - + goto err_disable_vcc; data->irq = ret; - ret = devm_request_threaded_irq(dev, data->irq, NULL, - sirf_wakeup_handler, + ret = request_threaded_irq(data->irq, NULL, sirf_wakeup_handler, IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT, "wakeup", data); if (ret) - goto err_put_device; - } - - if (data->on_off) { - ret = regulator_enable(data->vcc); - if (ret) - goto err_put_device; - - /* Wait for chip to boot into hibernate mode */ - msleep(SIRF_BOOT_DELAY); + goto err_disable_vcc; } if (IS_ENABLED(CONFIG_PM)) { @@ -342,7 +338,7 @@ static int sirf_probe(struct serdev_device *serdev) } else { ret = sirf_runtime_resume(dev); if (ret < 0) - goto err_disable_vcc; + goto err_free_irq; } ret = gnss_register_device(gdev); @@ -356,6 +352,9 @@ static int sirf_probe(struct serdev_device *serdev) pm_runtime_disable(dev); else sirf_runtime_suspend(dev); +err_free_irq: + if (data->wakeup) + free_irq(data->irq, data); err_disable_vcc: if (data->on_off) regulator_disable(data->vcc); @@ -376,6 +375,9 @@ static void sirf_remove(struct serdev_device *serdev) else sirf_runtime_suspend(&serdev->dev); + if (data->wakeup) + free_irq(data->irq, data); + if (data->on_off) regulator_disable(data->vcc); -- 2.20.1

5 years, 9 months

1
0
0 0

Re: [PATCH v3 01/11] mtd: cfi_cmdset_0002: Change do_write_oneword() to use chip_good()

by Joakim Tjernlund

On Wed, 2019-01-23 at 00:49 +0900, Tokunori Ikegami wrote: > > > Hi Boris-san, > > Very sorry for too late to update about this. > But could you please let me consult below about this patch? > > I have tried to investigate the issue root cause and confirmed below but > still the root cause seems not clear. > > 1. Without the change the write oneword is retried and recovered by the > current existing chip_good() checking. > But after the 1,001 times recovery it was continued to fail recovery > with the 3 times retry. I have lost track of all the details regarding this issue. I just want to add: There is a max number of suspend/resume cycles one can do during an erase(possibly also for write) and once that number is hit you get an error. One way to avoid this could be to wait after each resume until the erase has started again(look in status register) before continuing. If this has anything to do with this problem, I do not know. Jocke > 2. By the patch change the recovery failure can be avoided and the write > oneword works correctly without any failure. > There are different from the original chip_good() checking as the > original code resets the chip before the retry. > The patch change wait the chip_good() status until the timeout expiry > without the chip reset. > Note: There is a different from the original OpenWrt patch and needed > to be changed as same and it will be done by the next v4 patch. > > 3. To narrow down the cause I have added some delays into the original > code to check the chip ready and good status. > But the failure behavior was not changed so it seems that the issue is > not depended to the timing. (But not sure) > > 4. On the OpenWrt the write buffer is disabled but to narrow down the > issue I have changed to enable the write buffer. > Then the flash error was not happened by the write buffer operation so > it seems that the flash driver works correctly. > But another issue was caused and it is similar issue with the original > OpenWrt behavior with the patch change. > Note: On the original OpenWrt needs to wait the file system > completion to build but it was not finished with the write buffer. (But not > sure about this behavior) > > Do you have any comment about this result? > > If you can agree about the patch change basically with the current situation > I will do send the v4 patch set later with fix for the comments. > > But it seems that it is difficult to investigate the root cause more at this > moment to me. > Since but the behavior looks depended on the flash chip hardware behavior > and I cannot debug the hardware behavior more I think. > Note: Now I can reproduce the flash error issue behavior on the OpenWrt > unit. > > > > > It is depended on the actual flash chip behavior so the root cause > > > is > > > > unknown. > > > > > > Yes, and that's what I'd like you to figure out, or at least have a > > > good idea why this doesn't work on some chips but works on others. > > > > I see. > > But it is a little bit difficult situation since I do not have the failure > > environment locally at this moment. > > But if needed I may ask to get the help for this to Fabio-san. > > Regards, > Ikegami > > > -----Original Message----- > > From: IKEGAMI Tokunori [mailto:ikegami@allied-telesis.co.jp] > > Sent: Tuesday, November 6, 2018 6:47 PM > > To: Boris Brezillon; ikegami_to(a)yahoo.co.jp > > Cc: boris.brezillon(a)free-electrons.com; Felix Fietkau; Hauke Mehrtens; > > stable(a)vger.kernel.org; Joakim Tjernlund; PACKHAM Chris; > > linux-mtd(a)lists.infradead.org; Koen Vandeputte; Fabio Bettoni > > Subject: RE: [PATCH v3 01/11] mtd: cfi_cmdset_0002: Change > > do_write_oneword() to use chip_good() > > > > Sorry let me resend the mail below by changing the email address of > > Felix-san. > > > > -----Original Message----- > > From: IKEGAMI Tokunori > > Sent: Tuesday, November 06, 2018 6:37 PM > > To: 'Boris Brezillon'; 'ikegami_to(a)yahoo.co.jp' > > Cc: boris.brezillon(a)free-electrons.com; Felix Fietkau; Hauke Mehrtens; > > stable(a)vger.kernel.org; Joakim Tjernlund; PACKHAM Chris; > > linux-mtd(a)lists.infradead.org; Koen Vandeputte; Fabio Bettoni > > Subject: RE: [PATCH v3 01/11] mtd: cfi_cmdset_0002: Change > > do_write_oneword() to use chip_good() > > > > Hi Boris-san, > > > > > -----Original Message----- > > > From: stable-owner(a)vger.kernel.org > > > [mailto:stable-owner@vger.kernel.org] On Behalf Of Boris Brezillon > > > Sent: Tuesday, November 06, 2018 5:34 PM > > > To: IKEGAMI Tokunori > > > Cc: boris.brezillon(a)free-electrons.com; Felix Fietkau; Hauke Mehrtens; > > > stable(a)vger.kernel.org; Joakim Tjernlund; PACKHAM Chris; > > > linux-mtd(a)lists.infradead.org; Koen Vandeputte; Fabio Bettoni > > > Subject: Re: [PATCH v3 01/11] mtd: cfi_cmdset_0002: Change > > > do_write_oneword() to use chip_good() > > > > > > Hi IKEGAMI, > > > > > > On Tue, 6 Nov 2018 00:25:43 +0000 > > > IKEGAMI Tokunori <ikegami(a)allied-telesis.co.jp> wrote: > > > > > > > > > Also the issue can be fixed by using chip_good() instead of > > > chip_ready(). > > > > > > The chip_ready() just checks the value from flash memory twice. > > > > > > And the chip_good() checks the value with the expected value. > > > > > > Probably the issue can be fixed as checked correctly by the > > chip_good(). > > > > > > So change to use chip_good() instead of chip_ready(). > > > > > > > > > > Well, that's not really explaining why you think chip_good() should > > > be > > > > > used instead of chip_ready(). So I went on and looked at the > > > > > chip_good(), chip_ready() and do_write_oneword() implementation, and > > > > > also looked at users of do_write_oneword(). It seems this function > > is > > > > > used to write data to the flash, and apparently the "one bit should > > > > > toggle to reflect a busy state" does not apply when writing things > > to > > > > > the memory array (it's probably working for other CFI commands, but > > > I > > > > > guess it takes more time to actually change the level of a NOR cell, > > > > > hence the result of 2 identical reads does not mean that the write > > is > > > > > done). > > > > > > > > > > Also, it seems that cmdset_0001 is not implementing chip_ready() the > > > > > same way, and I wonder if cmdset_0002 implementation is correct to > > > > > start with. Or maybe I don't get what chip_ready() is for. > > > > > > > > > > Anyway, this is the sort of clarification I'd like to have. > > > > > > > > I am thinking to update the commit message as below. > > > > > > > > mtd: cfi_cmdset_0002: Use chip_good() to retry in > > do_write_oneword() > > > > As reported by the OpenWRT team, write requests sometimes fail on > > > some > > > > platforms. > > > > Currently to check the state chip_ready() is used correctly as > > > described by > > > > the flash memory S29GL256P11TFI01 datasheet. > > > > > > I had a look at the S29GL256P datasheet here [1], and if I'm correct, > > > it's using cmdset 0001. > > > > No actually the cmdset 0002 is used on the flash chip. > > The manufacturer ID xx01h and Device ID 2201h are used to decide. > > > > There is information from Fobis-san below also about this. > > > > On forum thread musashino posted picture of flash chip: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforum.open… > > on-wzr-hp-g300nh-18-06-1 > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cypress… > > > > [ 0.862264] physmap platform flash device: 02000000 at 1e000000 > > [ 0.868331] physmap-flash: Found 1 x16 devices at 0x0 in 16-bit > > bank. Manufacturer ID 0x000001 Chip ID 0x002201 > > [ 0.878493] Amd/Fujitsu Extended Query Table at 0x0040 > > [ 0.883668] Amd/Fujitsu Extended Query version 1.3. > > [ 0.888768] number of CFI chips: 1 > > [ 0.894557] Searching for RedBoot partition table in physmap-flash > > at offset 0x1fc0000 > > [ 0.918009] Searching for RedBoot partition table in physmap-flash > > at offset 0x1fe0000 > > [ 0.941464] No RedBoot partition table detected in physmap-flash > > [ 0.947926] Creating 5 MTD partitions on "physmap-flash": > > [ 0.953384] 0x000000000000-0x000000040000 : "u-boot" > > [ 0.960853] 0x000000040000-0x000000060000 : "u-boot-env" > > [ 0.968803] 0x000000060000-0x000001fc0000 : "firmware" > > [ 0.981859] 2 uimage-fw partitions found on MTD device firmware > > [ 0.987900] 0x000000060000-0x0000001b5706 : "kernel" > > [ 0.994916] 0x0000001b5706-0x000001fc0000 : "rootfs" > > [ 1.001986] mtd: device 4 (rootfs) set to be root filesystem > > [ 1.007789] 1 squashfs-split partitions found on MTD device rootfs > > [ 1.014014] 0x0000003c0000-0x000001fc0000 : "rootfs_data" > > [ 1.022093] 0x000001fc0000-0x000001fe0000 : "user_property" > > [ 1.030283] 0x000001fe0000-0x000002000000 : "art" > > > > Maybe you could post links to forum thread, and data sheet. > > > > > > Also chip_good() is used to check if the write is succeeded and > > it > > > was > > > > implemented by the commit fb4a90bfcd6d8 ("[MTD] CFI-0002 - Improve > > > error > > > > checking"). > > > > But actually the write failure is caused on some platforms and > also > > > it can > > > > be fixed by using chip_good() to check the state and retry > instead. > > > Do you know on which NOR chips this happens? Do you have access to the > > > datasheet? > > > > But it looks SST49LF008A [3] from the changes below but I am not sure at > > this moment and probably it should be confirmed to the authr Eric W. > > Biedermann <ebiederman(a)lnxi.com> to make sure. > > > > +#define SST49LF008A 0x005a > > > > static int cfi_amdstd_read (struct mtd_info *, loff_t, size_t, size_t *, > > u_char *); > > static int cfi_amdstd_write_words(struct mtd_info *, loff_t, size_t, > > size_t *, const u_char *); > > @@ -191,6 +192,7 @@ static struct cfi_fixup cfi_fixup_table[] = { > > }; > > static struct cfi_fixup jedec_fixup_table[] = { > > { MANUFACTURER_SST, SST49LF004B, fixup_use_fwh_lock, NULL, }, > > + { MANUFACTURER_SST, SST49LF008A, fixup_use_fwh_lock, NULL, }, > > > > > > It is depended on the actual flash chip behavior so the root cause > > > is > > > > unknown. > > > > > > Yes, and that's what I'd like you to figure out, or at least have a > > > good idea why this doesn't work on some chips but works on others. > > > > I see. > > But it is a little bit difficult situation since I do not have the failure > > environment locally at this moment. > > But if needed I may ask to get the help for this to Fabio-san. > > > > > > If any comment please let me know. > > > > > > > > > > Signed-off-by: Tokunori Ikegami <ikegami(a)allied-telesis.co.jp> > > > > > > Signed-off-by: Hauke Mehrtens <hauke(a)hauke-m.de> > > > > > > Signed-off-by: Koen Vandeputte <koen.vandeputte(a)ncentric.com> > > > > > > Signed-off-by: Fabio Bettoni <fbettoni(a)gmail.com> > > > > > > > > > > Has the patch really gone through all those people? SoB is used when > > > you > > > > > apply a patch in your tree or when you're the original author. > > > > > > > > I have just checked the OpenWRT git log again and it looks that it was > > > originally > > > > implemented by Felix Fietkau <nbd(a)openwrt.org> by the patch below so > > I > > > will update the Signed-off-by tag as so. > > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.openwr… > > > f07cd2b3b14fe9ec03fa63a586452cc5f> > > > > > > Co-Developed-by: Hauke Mehrtens <hauke(a)hauke-m.de> > > > > > > Co-Developed-by: Koen Vandeputte <koen.vandeputte(a)ncentric.com> > > > > > > Co-Developed-by: Fabio Bettoni <fbettoni(a)gmail.com> > > > > > > > > > > Not sure we want to add new undocumented tags, but you can mention > > > > > that all those people helped you find/debug the issue. They can also > > > > > add their Reviewed-by/Tested-by if they like. > > > > > > My bad, I just noticed these are valid flags [2], so you can keep them, > > > and according to the doc, you should also keep the SoB. > > > > I see. > > Yes I had also checked it. > > > > By the way in near future my company email address will be not able to > use. > > So I will change the mail address to my personal email address [4] after > > that or before. > > > > Regards, > > Ikegami > > > > > Regards, > > > > > > Boris > > > > > > [1]https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cypre… > > > > > [2]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern… > > > tree/Documentation/process/submitting-patches.rst?h=v4.20-rc1#n546 > > > > [3]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.micr… > > [4]ikegami_to(a)yahoo.co.jp

5 years, 9 months

1
0
0 0

RE: [PATCH for-rc 5/7] IB/hfi1: Close race condition on user context disable and close

by Ruhl, Michael J

Hi, This patch needs to be redone. Please drop. Thanks, Mike >-----Original Message----- >From: Sasha Levin [mailto:sashal@kernel.org] >Sent: Tuesday, January 22, 2019 10:56 AM >To: Sasha Levin <sashal(a)kernel.org>; Dalessandro, Dennis ><dennis.dalessandro(a)intel.com>; Ruhl, Michael J ><michael.j.ruhl(a)intel.com>; jgg(a)ziepe.ca; dledford(a)redhat.com >Cc: linux-rdma(a)vger.kernel.org; stable(a)vger.kernel.org >Subject: Re: [PATCH for-rc 5/7] IB/hfi1: Close race condition on user context >disable and close > >Hi, > >[This is an automated email] > >This commit has been processed because it contains a "Fixes:" tag, >fixing commit: f683c80ca68e IB/hfi1: Resolve kernel panics by reference >counting receive contexts. > >The bot has tested the following trees: v4.20.3, v4.19.16, v4.14.94. > >v4.20.3: Build OK! >v4.19.16: Build OK! >v4.14.94: Failed to apply! Possible dependencies: > 071e4fec8e4d ("IB/hfi1: Reorg ctxtdata and rightsize fields") > 1b311f8931cf ("IB/hfi1: Add tx_opcode_stats like the opcode_stats") > 40442b30aad0 ("IB/hfi1: Move rhf_offset from devdata to ctxtdata") > b0ba3c18d6bf ("IB/hfi1: Move normal functions from hfi1_devdata to const >array") > c8314811f9b2 ("IB/hfi1: Cleanup of exp_rcv") > ed71e86a8d66 ("IB/hfi1: Rename exp_lock to exp_mutex") > > >How should we proceed with this patch? > >-- >Thanks, >Sasha

5 years, 9 months

1
0
0 0

Re: patch "usb: chipidea: fix static checker warning for NULL pointer" added to usb-linus

by Greg KH

On Tue, Jan 22, 2019 at 03:55:54PM +0000, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v4.20.3, v4.19.16, v4.14.94, v4.9.151, v4.4.171, v3.18.132. > > v4.20.3: Failed to apply! Possible dependencies: > 7c8e8909417e ("usb: chipidea: imx: add HSIC support") > > v4.19.16: Failed to apply! Possible dependencies: > 7c8e8909417e ("usb: chipidea: imx: add HSIC support") > > v4.14.94: Failed to apply! Possible dependencies: > 7c8e8909417e ("usb: chipidea: imx: add HSIC support") > be9cae2479f4 ("usb: chipidea: imx: Fix ULPI on imx53") > > v4.9.151: Failed to apply! Possible dependencies: > 7c8e8909417e ("usb: chipidea: imx: add HSIC support") > be9cae2479f4 ("usb: chipidea: imx: Fix ULPI on imx53") > d13631bb15ce ("usb: chipidea: imx: configure imx for ULPI phy") > > v4.4.171: Failed to apply! Possible dependencies: > 7c8e8909417e ("usb: chipidea: imx: add HSIC support") > be9cae2479f4 ("usb: chipidea: imx: Fix ULPI on imx53") > d13631bb15ce ("usb: chipidea: imx: configure imx for ULPI phy") > d3d8425a21ed ("usb: chipidea: imx: avoid EPROBE_DEFER printed as error") > > v3.18.132: Failed to apply! Possible dependencies: > 19c1eac2685b ("usb: rename phy to usb_phy in OTG") > 560400875d56 ("usb: chipidea: imx: using common platform flag directly") > 69e28882dc7a ("usb: musb: gadget: do not rely on 'driver' argument") > 7c8e8909417e ("usb: chipidea: imx: add HSIC support") > e14db48dfcf3 ("usb: chipidea: imx: add runtime power management support") > e47d92545c29 ("usb: move the OTG state from the USB PHY to the OTG structure") > ef44cb4226d1 ("usb: allow to supply the PHY in the drivers when using HCD") > > > How should we proceed with this patch? Heh, good catch checker! turns out this patch is not for the stable tree, I messed up :) greg k-h

5 years, 9 months

1
0
0 0

Re: [PATCH 2/2] RDMA/srp: Rework SCSI device reset handling

by Bart Van Assche

On Tue, 2019-01-22 at 15:55 +0000, Sasha Levin wrote: > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: 94a9174c630c IB/srp: reduce lock coverage of command completion. > > The bot has tested the following trees: v4.20.3, v4.19.16, v4.14.94, v4.9.151, v4.4.171, v3.18.132. > > v4.20.3: Build OK! > v4.19.16: Build OK! > v4.14.94: Build OK! > v4.9.151: Build failed! Errors: > drivers/infiniband/ulp/srp/ib_srp.c:2657:2: error: implicit declaration of function ‘blk_freeze_queue_start’; did you mean ‘blk_mq_freeze_queue_start’? [-Werror=implicit-function-declaration] > drivers/infiniband/ulp/srp/ib_srp.c:2658:14: error: implicit declaration of function ‘blk_mq_freeze_queue_wait_timeout’; did you mean ‘blk_mq_freeze_queue_start’? [-Werror=implicit-function- > declaration] > > v4.4.171: Build failed! Errors: > drivers/infiniband/ulp/srp/ib_srp.c:2612:2: error: implicit declaration of function ‘blk_freeze_queue_start’; did you mean ‘blk_mq_freeze_queue_start’? [-Werror=implicit-function-declaration] > drivers/infiniband/ulp/srp/ib_srp.c:2613:14: error: implicit declaration of function ‘blk_mq_freeze_queue_wait_timeout’; did you mean ‘blk_mq_freeze_queue_start’? [-Werror=implicit-function- > declaration] > > v3.18.132: Failed to apply! Possible dependencies: > 205619f2f824 ("IB/srp: Remove stale connection retry mechanism") > 34aa654ecb8e ("IB/srp: Avoid that I/O hangs due to a cable pull during LUN scanning") > 394c595ee8c3 ("IB/srp: Move ib_destroy_cm_id() call into srp_free_ch_ib()") > 509c07bc1850 ("IB/srp: Separate target and channel variables") > 747fe000ef38 ("IB/srp: Introduce two new srp_target_port member variables") > 77f2c1a40e6f ("IB/srp: Use block layer tags") > d92c0da71a35 ("IB/srp: Add multichannel support") > > > How should we proceed with this patch? Hi Sasha, Patch 2/2 does not have a "Cc: stable" tag because it definitely should NOT be backported to older kernels. This patch only works for blk-mq which is fine with kernel v5.0. Older kernels however support both the legacy block layer and blk-mq. Bart.

5 years, 9 months

1
0
0 0

[PATCH] drm/amdgpu: Add APTX quirk for Lenovo laptop

by Alex Deucher

Needs ATPX rather than _PR3 for dGPU power control. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=202263 Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c index a028661d9e20..92b11de19581 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c @@ -576,6 +576,7 @@ static const struct amdgpu_px_quirk amdgpu_px_quirk_list[] = { { 0x1002, 0x6900, 0x1028, 0x0812, AMDGPU_PX_QUIRK_FORCE_ATPX }, { 0x1002, 0x6900, 0x1028, 0x0813, AMDGPU_PX_QUIRK_FORCE_ATPX }, { 0x1002, 0x6900, 0x1025, 0x125A, AMDGPU_PX_QUIRK_FORCE_ATPX }, + { 0x1002, 0x6900, 0x17AA, 0x3806, AMDGPU_PX_QUIRK_FORCE_ATPX }, { 0, 0, 0, 0, 0 }, }; -- 2.20.1

5 years, 9 months

3
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2019